If you could add only ne tool or Process

Question

Let us posit a company which is doing just about as much wrong as it is possible to do with regard to software development.

Let us suppose that management, which imagines software to fall from the trees, grudgingly recognizes that there may possibly be a small problem and is finally willing to all to "try something".

The something has to be free (as in dollars) and "non-disruptive".

Basically, something for nothing. If you choose right it won't be mentioned at your next performance review (because the dear leader will take the credit), but you may have the privilege of suggesting a second "something" to "try" (of course, if you choose wrongly, management will shoot a puppy and drown a kitten and the whole thing will become more of a Yourdon-death-march than it already is).

Choose wisely, for you only have one choice. What single tool, Process, anything, will have the most bang, preferably in the least time, for the least buck.

And to anyone thinking of deleting this as being too subjective, I can only say, "you lucky offspring-of-unwed-parents, your fellow developers and project managers around the world are in this very situation even as you reach for the "delete" button".

Answer 1

Daily automation testing. This way at least the old stuff doesn't go bad over time.

Answer 2

I'm afraid that there are no magic bullets - anything that will improve a team's performance is likely to involve some changes in working practice, and it will take some time for the effects to be shown. Change is likely to seem a bit disruptive at first - but if the current practices were working, you wouldn't need to change, right? :)

I agree with Martin above that automated testing is the single most important way to improve code quality. Even automated tests that must be triggered manually is better than nothing (have a look at NUnit or JUnit).

The other two practices that I would recommend are automated builds and structured peer code review. And if you want to know all about best practice, get yourself a copy of Code Complete by Steve Mcconnell.

How do you eat an elephant? One bite at a time ... so set yourself a goal to write 10 unit tests for the code that is the most flaky, and see where that takes you.

Answer 3

Unfortunately there are a huge number of ways things can suck. So I'll start at the top.

Most projects fail due to poor requirements gathering and specification. Insist on no new code without proper specs. These do not need to be ridiculously detailed waterfall artifacts that are never looked at -- but at a minimum, you need to know:

• Why is the feature needed? (a quick history or summary of the problem being solved)
• What will success look like? (a summary of expected behavior)

Then you reply with a document that looks like this:

• It looks like you want me to write something that does (what they said in their document).
• To accomplish this, I propose these changes to the existing code.

Send that back and get them to agree that it sounds good. They will because they have no clue what you do and they trust that you do.

Then, and only then, start talking about how long it will take to do this. The conversation, hopefully, will go like this:

• The right way to do it will take me a month.
• What, you wanted it in a week? OK, well, I can get you 70% of what's in this spec if we make this small change. This last feature is really hard, even though it looks like we're just changing the font to comic sans...

Now you've gone from management hating your guts for not working miracles to having them understand -- before you start coding -- what kinds of things are holding back success.

The next best thing is dedicated QA resources and a good bug tracking system, though they cost money (though Joel would say that they cost a lot less than programmers doing testing!).

I agree with others that unit tests are an important part of maturing your code, but they are useless if your problem is poor requirements.

===

Quick edit for a book recommendation: http://www.amazon.com/Software-Requirements-Techniques-Throughout-Development/dp/0735618798

Answer 4

Version control.

Not only does it give you the ability to do things you couldn't before (revert to previous versions, branch, record what changed when etc.) but also provides a certain level of insurance.

I can test my own code (badly) and we lived without automated unit test for decades, I can have bugs tracked via e-mail (though I'll lose many of them and possibly my mind) but if I lose control of my source code there's not much I can do.

I may not get credit for the improvements but at least I'm safe from the sort of error that would lose me my job and the whole company it's product.

Answer 5

Well if everything is absolutely wrong, the first thing I would institute is database backups. If the company data isn't recoverable then you will be out of business very quickly when a hard drive dies.

Next thing would be Source control. Code is every bit as critical as data and needs to have a way to revert if need be to an earlier version. Plenty of open source source control programs, so cost not an issue. And put all database changes in scripts and stick them in source control too!

If you have that, the next tool would be a bug tracker.