I'm a relatively new developer, fresh from college. While in college and during subsequent job-seeking, I realized that there were a lot of "modern" software development methodologies that my education was lacking: unit testing, logging, database normalization, agile development (vs. generic agile concepts), coding style guides, refactoring, code reviews, no standardized documentation methods (or even requirements), etc.

Overall, I didn't see this is a problem. I expected my first job to embrace all of these ideas and to teach them to me on the job. Then I got my first job (full stack web development) at a big corporation and I realized that we do none of these things. In fact I, the least experienced on the team, am the one who is spearheading attempts to bring my team up to speed with "modern" programming techniques - as I worry that not doing so is professional suicide down the road.

First I began with logging software (log4J), but then I quickly moved on to writing my own styleguide, then abandoning it for the Google styleguide - and then I realized that our Java web development used hand-written front controllers, so I pushed for our adoption of Spring - but then I realized we had no unit tests, either, but I was already learning Spring... and as you can see, it becomes overwhelming all too quickly, especially when paired with normal development work. Furthermore, it is difficult for me to become "expert" enough in these methodologies to teach anyone else in them without devoting too much time to a single one of them, let alone them all.

Of all these techniques, which I see as "expected" in today's software development world, how do I integrate them into a team as a new player without overwhelming both myself and the team?

How can I influence my team to become more agile? is related, but I'm not an Agile developer like the asker here, and I'm looking at a much broader set of methodologies than Agile.

closed as too broad by user53019, durron597, Ampt, user40980, Robert Harvey May 24 '15 at 2:53


  • 92
    "modern"? Strip that "agile" buzzword from your list and I can see only things with an age of > 20 years. – Doc Brown May 19 '15 at 12:58
  • 10
    Perhaps "modern" in the sense that widespread adoption of them is modern, not the ideas' geneses, then? I'm not an expert on this subject either, this is just my impression. – WannabeCoder May 19 '15 at 13:01
  • 41
    I assure, you, unit testing, logging, database normalization, coding style guides, code inspections (=reviews) are all older than 30 years. The term "refactoring" is at least 15 years old (Fowler wrote his book in 2000). And having no formal documentation or written requirements is not "a modern technique", it is IMHO not even a "technique". – Doc Brown May 19 '15 at 13:12
  • 69
    @DocBrown admit it, you just sent Marty back in time to create all these things before making your comment. – null May 19 '15 at 16:48
  • 17
    I'm more concerned that his college isn't teaching those things up front - I've been out of school 15+ years and most of those things were covered pretty early on. (Minus the buzzwords, of course). – Allen Gould May 19 '15 at 17:12

11 Answers 11


It sounds to me like you are putting the cart before the horse.

What is the major problem your team is facing and which technologies would help fix it?

For example, if there are lots of bugs, particularly regression-type bugs, then unit testing may be a starting point. If your team is lacking time, perhaps a framework may help (medium to long term). If people have difficulty reading each others' code, styling may be useful.

Remember that the purpose of the business you work for is to make money, not to make code.

  • 35
    Pretty much. Partly from a pragmatic point of having to start somewhere and partly from a reputational point that if you can fix a problem for the team, they may be more willing to listen to other suggestions. Also bear in mind that this company was making money before you arrived with its existing methods, so what you put in place has to increase the money making ability of the company. – Jaydee May 19 '15 at 13:07
  • 6
    Accepting this, but I would appreciate a follow-up to address the risks of this professionally (e.g. "my resume would have more stuff, but my old job didn't embrace change very well.") – WannabeCoder May 19 '15 at 17:06
  • 4
    @WannabeCoder - You have to start using it before you become proficient. You can still put code into production. Sometimes coding is like being a medical doctor. We're all still practicing. – JeffO May 19 '15 at 18:20
  • 5
    Great answer. You should only be implementing these things to solve problems, not to manufacture problems. – Kik May 19 '15 at 20:27
  • 5
    @WannabeCoder It's important to realize that none of these methodologies were created in a vacuum. They're becoming wide spread because they help solve problems. If you try to implement them and they don't help solve problems your team is facing, then you've accomplished nothing and possibly completely misunderstood and abused the practices. Your focus as a developer should be on solving problems in every action you take. Look for small wins where putting these practices in place just a little bit more will improve the situation. This helps build a case for expanding them. – jpmc26 May 19 '15 at 23:53

Java? Modern?! You've failed at the first hurdle. If you want to be truly modern and avoid "professional suicide" then you must be writing Rust code. Of course, next week, it'll all change and you'll have to learn something even newer to keep up!

Or, you could accept that no amount of buzzword technologies or methodologies or frameworks or any other du jour will change the fact that you want to build quality products that work. It doesn't matter if you don't use agile if you are successfully producing the right output. Of course, if you're not, then you might want to change things but chances are no particular practice will fix the problems. They will remain human problems that can be fixed in any number of different ways.

As for professional suicide, if you know what you're doing and are flexible then you don't need any of the things you mentioned. People will continue to come up with new ways of doing the old work and you'll always be catching up. Or you can simply use whatever techniques your current company uses regardless. When you change your company, you simply learn and use the techniques they use.

Too many kids get hung up on all the new tools they could use, forgetting that these tools are worthless in the hands of a novice. Learn the practice first, once you're an experienced developer you can start to "fix" the development practices with "cool new things", but by then you will hopefully have realised that they are not nearly as important as you currently think, and only to be used when they are really needed.

  • 4
    Very nice answer (+1), especially the last paragraph. A very modern book (modern in the sense that I find it very relevant today) I am reading recently is SICP. – Giorgio May 19 '15 at 18:02
  • 1
    +1 for the mention of how quickly these buzzwords and popular languages change. A good dev putting out good code trumps any methodology. Do what works and works well! – WeRelic May 19 '15 at 23:16
  • 2
    While you're right that these need to be used properly, I disagree with the notion that "they are not nearly as important as you currently think." Okay, sure, that might be true of some practices (I'm somewhat skeptical of unit testing.), but others are extremely valuable. I got the chance to start doing a lot of CI and automation and good use of source control early on, and now working on a project where those aren't present, I see all the problems we wanted to solve in action: mistakes, inconsistencies, nobody knows what code is where, the works. Those practices make a huge difference. – jpmc26 May 19 '15 at 23:58
  • 6
    Nobody says "don't solve problems", the issue is when solutions are introduced looking for problems to solve. They are not as important as many think, the cargo-cultists think the tools are the important part, where they are actually just tools. Its the practitioner that matters, and whichever tools work in the right places are the ones to choose. my point is to never choose a tool simply because its in the toolbox. – gbjbaanb May 20 '15 at 7:36
  • 2
    A fool with a tool is still a fool. – Pete Becker May 20 '15 at 19:51

Many companies are stuck like this; you might even be surprised to find that some of your developer colleagues are self-taught and became developers with no formal background whatsoever. These developers are often better at their jobs, since they will be the ones that are driven to learn new skills and succeed instead of simply doing the job. Unfortunately this can also mean that, while they're excellent at programming, they might not be aware of the benefits of these practices. The fact is these are best practices, not common practices. The best use them, but they are not at all requirements to succeed, they are simply tools to help make success easier.

You're absolutely right, it's going to be overwhelming to try to implement everything all at once. You'll likely burn yourself (and maybe your team) out trying to do it, which is going to demotivate future pushes to adopt new methodologies/technologies. The best thing to do in a situation like this is pick one thing (logging is probably a good start, as you've probably got a tough road ahead finding bugs without logging, and there are sure to be bugs) and talk to the team about it. You don't have to singlehandedly implement this; you'll do much better discussing the pros and cons with the team (and your boss, who absolutely MUST be on board with something like this) and coming up with a plan to implement it. It's going to have to be as painless as possible (remember, you're telling people that they now have to write extra code in addition to what they already do).

And let me say again, make sure your boss buys in. This is crucial; you will probably find that the speed of fixes/releases slows down as you implement new things. The point is that you're paying upfront to save down the line; they MUST understand this and be on your side. If you don't get them on board, you're fighting a losing battle at best, and at worst they may consider you as actively sabotaging the team (ask me how I know).

Once you bring these items to the table, discuss them with the team, plan how to implement them, and follow through, the second, third, eighth, etc. will be easier. Not only that, there's a potential for the team and your boss to gain respect for you as your suggestions are implemented and recognized as adding value. Great! Just make sure that you stay flexible: you'r pushing against inertia here, and change isn't easy. be prepared to slowly make small changes, and make sure that you can track progress and value earned. If you implement logging in a new process and it helps you save hours finding a bug in three weeks, make a big deal about it! Make sure everyone knows that the company just saved $XXX by doing the right thing ahead of time. On the other hand, if you get pushback, or have a tight deadline, don't try forcing the issue. Let the new change slide for the moment, and circle back. You won't ever win by trying to force the team to do something they don't want to do, and you can be sure the first thing they'll suggest dropping is the new 'extra' work (like writing logging, or following a styleguide instead of just 'getting it working').

  • 6
    I doubt you meant much by it, but I kinda resent the gibe at devs like me without a university compsci education. My experience has (rather unfortunately) been that university education has little correlation with developer quality. And so far in my career, I've been one of those advocating for and implementing best practices. Your advice is great though. – djeikyb May 21 '15 at 9:20
  • 5
    Actually I meant it the other way: the OP would be surprised by how many good devs are out there without formal education. Many tech positions opened up in the past 20/30 years that were filled by people willing to learn instead of kids with a degree. And my findings mirror yours: experience is always better than education. That's why the OP needs to go slow... pushing a team to adopt new practices too fast will make them resent him, and he won't have the experience to temper those attitudes. Also important to realize is some teams will never use these tools; that's when you get a new job. – DrewJordan May 21 '15 at 10:40
  • 1
    "Many companies are stuck like this; you might even be surprised to find that some of your 'developer' colleagues are self-taught and became developers with no formal background whatsoever." These often turn out to be the most valuable developers due to their domain expertise. – pmf May 21 '15 at 13:50
  • Right, I totally agree. Reworded the first paragraph so it sounds less condescending. I just wanted to make sure that OP knew that a good portion of the workforce out there doesn't actually have a formal background. Poor choice of words on my part. – DrewJordan May 21 '15 at 14:41

I hope you have not presented the issues to your coworkers as you did to us in your post. THAT would be professional suicide.

The first issue is that you are trying to teach technologies and methods that even you do not have experience with to a group of programmers that, maybe are a little outdated, but get the job "done". The possibilities of that backfiring are endless, and will probably bring a lot of joy to your coworkers. It is interesting and admirable that you want to improve yourself and your department, but avoid using terms like "spearheading". Sincerely, don't use that word.

As a side issue to the above, check that you are doing some work. I have been working as a lone, self-learning programmer for a lot of time, and I know how easy is to set aside the actual work in order to explore promising frameworks, technologies and the like. Ensure yourself that your performance is within the expected parameters (no, nobody cares that you spend 20 hours researching Spring if that report they asked you is not done).

From all of the above, avoid being the teacher (unless it is related to a field/tech in which actually you have enough experience). A more neutral presentation would be pointing the advantages of, say, automated testing, and letting management chose who they want to research the pros and cons of those practices.

Now, for presenting those "best practices", there are two ways of explaining them to your team:

  • Because I say that they are the best practices, and that is enough.
  • Because they are useful and help solve problem.

Using the first argument, unless you are the boss or a very senior member of the team, it is unlikely that they will give you any attention. And "I read a book from Knuth that says so" or "the guys of the SE say that" will not cause any impression, neither ("those guys do not work here so they do not really know what is good for this IT shop"). They have their methods, routines, procedures, and things "more or less" work, so why take the effort and risks of changing?

For the second approach to work, there must be the realization that a problem exists. So:

  • don't go pushing day and night for automatic testing. Wait until an update breaks some features, and the team has to work overtime to fix it, and then propose to build an automated test system.
  • don't ask for code reviews. Wait until Joe is in a extended leave and there is a need to change in that module that only Joe knows about, and point to your boss how much time was lost just trying to understand Joe's code.

Of course, change will be slow and progressive (more so in a big corporation). If you get to introduce code review and automated testing in five years, you should congratulate yourself on a work well done. But, unless there is a complete rewrite due to external causes, forget about any fantasy that they will switch the core IS to, say, Spring (Joel explained that way better than I ever could, even before you were born1); in that time you could, at most, get Spring in the list of supported platforms to write non-critical systems.

Welcome to the world of enterprise IT, boy! :-p

1: Ok, maybe I am exagerating a little, but not too much.

  • 1
    Mostly disagree. The only way to get some change in a team is if someone is willing to do the research and drag the rest along. Of course you should remain productive, but if everyone keeps their head low you end up "a little outdated, but you get the work done". And completely burnt out from boredom. – winkbrace May 21 '15 at 21:45
  • @winkbrace I do not claim that you should not try to improve (in fact I state the opposite). But pushing those changes without management support and without the authoritas of some seniority may be quite difficult and cause some resistence; add to that the OP not being quite an expert himself and may have troubles with the actual implementation. It would be nice if the OP could volunteer to a research/prototyping team to properly introduce changes; but barred that he should be careful in chosing the right approach to promote those and be patient. – SJuan76 May 22 '15 at 7:54
  • @winkbrace for the boredom bit, it depends of your personality and what you are looking for in a job. It is sensible to try to land in a job position that satisfies you, rather than go anywhere and try to change the organization to your tastes. And usually big corporations (except for R&D departments) are not the place for people who likes to test a new technology each few months. – SJuan76 May 22 '15 at 8:03
  • It's a little messed about to say "make sure you're actually doing work". Sure you should do the work but you also need to think long-term and every day you should be improving. It took me 5 months to get our manager to buy into the fact that unit tests help even when we're trying to code "fast". But I needed to take 10min here and there every few days for that to happen. – Rudolf Olah May 22 '15 at 14:29
  • @omouse I was just pointing a risk that has hit myself sometimes, when doing research. Certainly I do not see that risk in the situation that you describe, but the form in which the OP describes his research ("first I started with... then I quickly moved...") made me add that caution. Note that I do not claim that the OP is not doing his assigned work properly (that is something I simply do not know, and that is his boss'job), I just warn him to make sure that he does not get too carried away. – SJuan76 May 22 '15 at 21:01

You should start with the book Working Effectively with Legacy Code by Michael Feathers. From the book's introduction, "It's about taking a tangled, opaque, convoluted system and slowly, gradually, piece by piece, step by step, turning it into a simple, nicely structured, well-designed system." He mostly starts with automated testing, so that you can refactor safely (you'll know if you break anything), and he includes lots of strategies for bringing difficult code under automated testing. This is useful for every project that's still under development. Once you've got some basic order in place, you can see what other modern technologies your project could really benefit from--but don't assume you need all of them.

If you want to learn a new framework (or something) for professional reasons rather than because your current project actually needs it, then you should use it in some personal project (on your own time).

  • I agree with topics in Working Effectively with Legacy Code but it is not very compact. Take it as a reference and glance at chapters rather than expecting to read it like a novel. – Lukas May 22 '15 at 20:42

Source control.

You did not mention it, hopefully because it's already in place, but, in case it's not, start there.

Source control has the biggest bang-for-buck, except in rare circunstances pathologically in need of something else.

And you can start alone if no one initially buys in.

  • 1
    Biggest bang-for-buck is more like a few ASSERTs in the right places. – Peter Mortensen May 20 '15 at 22:39
  • @PeterMortensen True, but only if you know what the right places are. – Emilio M Bumachar May 21 '15 at 16:28
  • You beat me to it. No matter in which direction the OP takes his team, getting there with Git will be much easier and more productive than without. – dotancohen May 22 '15 at 23:44

A Direct Answer

Other answers make good 'meta-points' about adopting better practices but, just to give you some directly relevant guidance, here's a rough ordering of the best practices I'd suggest your team (or any team) adopt (first):

  1. Source control
  2. Issue tracking (project and task management)
  3. Automated builds1
  4. Automated deployments

1 A very much related practice is to automate, or at least document, setting-up the build and development environment of each app or software project you're developing or maintaining. It's much less useful tho because you're (hopefully) doing this infrequently or rarely.

Everything Else

You mention several other good practices – "unit testing, logging, database normalization, ... refactoring, ... documentation" – but these are all practices that can and should be adopted gradually and incrementally. None of them need to be adopted all at once and you'll probably better adopt them at all by adopting them carefully and mindfully.

The four practices I listed above will also make adopting, and experimenting with, new practices as easy as possible. For example, unit testing can be incorporated into your automated builds and documentation can be published as part of your automated deploys.

Some of the other practices you mention – "agile development, ... coding style guides, ... code reviews, ... standardized documentation methods" and frameworks (e.g. Spring) – are really optional or of dubious value. And that's true of a lot (most?) possible practices you'll discover or encounter.

Agile development isn't obviously superior to any other methodology used. And a lot of people (including myself) have had horrible experiences with it. But lots of people really like it (or love it) too. Try it!

Coding style guides can be helpful, especially for large projects, or in large teams, but it's also a lot of work to enforce those guidelines and that may not be the best use of the time of whomever is doing so.

Code reviews can be very helpful too – have you asked your coworkers to review your code? Keep in mind that you don't need a formal process to adopt good practices!

Documentation is great – do you have any at all? If so, good for you! Are you facing lots of extra work that could be prevented by having (more) "standardized" documentation? If you are, then that's probably something worth doing. However, say if your software is being used by a small group of people, you may not need any documentation. (Or you could directly incorporate the documentation into your software. That's always my preference.)

Frameworks are ... a (very sharp) double-edged sword. A nicely encapsulated and well-maintained solution for a non-core feature of your software is great ... until it isn't. I'm not sure what "hand-written front controllers" are exactly but there's no obvious explanation as to why they're inferior to code that leverages Spring. Have you considered encapsulating the common logic in all of these controllers into your own in-house framework? Adopting Spring, and rewriting all your existing code, could be an immense refactoring (or, more likely, rewriting) project and that might not be the best change you could make to your code. Of course you shouldn't write all of the software you use – frameworks (and libraries) are great! But maybe you don't have to use Spring (or an alternative) to write great (or good) web apps.

  • I would put automated regression testing right up there with automated build and deployment. It also has the advantage that it is something you can work on incrementally. – sdenham May 21 '15 at 18:57
  • Unit testing should be first, start with manually always running it locally (or on every checkout/checkin) and then get the rest of the team to buy into automated regression testing. There really do exist devs who are afraid of running tests constantly for some reason. – Rudolf Olah May 22 '15 at 15:07

Look around the team that you're a part of. Can you see any evidence that test driven development or database normalization will improve the quality of the software you're writing or make people more productive?

Have you tried speaking to one of the development supervisors about it, or the head of development? A really informal chat would be a good start. What makes you think that the people above you haven't had the same ideas but can't / won't implement them because the business won't allow it?

I find that leading by example is a good way to go. People are a lot less resistant if someone else has already done the work and can show them how to replicate it. Introduce TDD into a project you're working on. Ask to give a presentation to the rest of the team, or even a couple of others and show them what you have done. What @DrewJordan said about getting buy in from the boss is more important than you probably realise.


Find a flaw. Fix a flaw. Show the fix.

Let's take normalisation* first. And indeed, I'd suggest you take it first, because lack of normalisation is likely to result in actual buggy data that couldn't exist otherwise, whereas the rest are cases where best-practice could likely help but it's harder to say "Bug A was caused by not following policy X". If you have a database that isn't normalised, then you have a place where data can be inconsistent.

It's a good bet that you will be able to find an actual case of inconsistent data. You have now found two things:

  1. A bug in your data.

  2. A bug in your database schemata.

You actually knew about the second bug first, but the first one is more easily demonstrable and also something that is causing a real problem, not something that theoretically could.

Unfortunately one of the real reasons for resisting normalising denormalised database is that the question of what to do with such buggy data is not always easy, but you will have found an actual bug.

(Do be aware though that there are reasons why one might sometimes denormalise some data on purpose. Don't mistake knowledgeable breaking of the rule for ignorance of the rule; if you normalise a table that is deliberately denormalised for speed of lookup, you won't win any kudos. Even here though, denormalising being fraught is something that should be done procedurally, so if the denormalised table isn't created automatically based on the contents of normalised tables there is still progress to make).

For the rest, introduce them when they help in the short-term, to later build on them in the long term. E.g. if you are given a small piece of code to build, write a unit test for it. Better still, if you are given a bug to fix, write a unit test that fails because of the bug and then when you have fixed the bug mention the fact that it passes when you close off the bugs (or send an email saying it's fixed, or whatever).

*Incidentally, not very modern. The reason it is called normalization and not normalizing or something else, is that at the time it was a topical joke to stick -ization on the end of things to make fun of the name of Richard Nixon's Vietnamization policy.


I'm going to go against the grain and say: find a new job after spending some time at this one to build your resume a little. Aim for a year or so. Although many things are "buzzwords," issues like a complete lack of unit testing are intractable for a single developer, and chances are that if the programmers working there have no desire for testing, you'll never get purchase and may even jeopardize your position at the company by making people think of you as a blowhard. You need to be in a place where you can get mentoring, not trying to push the culture towards basic competence.

  • 3
    That is exactly what I've done. There were only one time (out of ~5 attempts at various places) when I successfully introduced some new "good practice" or made a significant change in existing practices, and it was when the team was fresh and we started most of projects from scratch. All the other times good practices were either introduced from the top (team leads), or just failed because no one else participated. I believe it all comes to ability to force your decision by being a leader/boss. – scriptin May 20 '15 at 23:24
  • 1

There have been plenty of proposals for improving the programming paradigm. The hottest buzzwords now seem to be agile programming and object-oriented. Or are they? Both have faded substantially compared to what they were just five years ago.

You can be fairly confident that whatever methodology put in place is trying to accomplish the same end result: help engineers economically produce a final product which is good enough.

There is one paradigm that was controversially introduced in the 1960s: structured programming: only use "high level" constructs like while, for, repeat, if/then/else, switch/case statements instead of the heavily used goto statement which had been accepted by default. There are still debates about whether goto has any legitimate use at all.

I accept that minimizing use of goto is a good thing, but like all good things, it is possible to go too far.

You mention agile methodologies as something positive. I was in one development team for about six months that intentionally followed a prescribed agile regimen. I found it to be just like enlightened project management methodologies from decades ago, except everything is renamed. Perhaps by re-bundling and reselling ideas for communicating someone makes a living and companies can feel good about "seeing" the emperor's new clothes.

Agile's most valuable lesson, which was known long ago, is that flexibility to find a better path to the finished product is a good thing and the ability to find that path can come from anyone—not just upper management.

From a writing by anti-goto ringleader Edsger Dijkstra:

The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible.

—Dijkstra, in: Dahl, Dijkstra & Hoare 1972, pg. 6. (see page 6 here.)
