migrating product and team from startup race to quality development

Question

Possible Duplicate:
A simple ways to improve the release quality in RAD environment

This is year 3 and product is selling good enough. Now we need to enforce good software development practices. The goal is to monitor incoming bug reports and reduce them, allow never ending features and get ready for scaling 10x. The phrases "test-driven-development" and "continuous-integration" are not even understood by the team cause they were all in the first 2 year product race. Tech team size is 5.

The question is

1. how to sell/convince team and management about TDD/unit testing/coding standards/documentation - with economics.
2. train the team to do more than just feature coding and start writing test units along - which looks like more work, means needs more time!
3. how to plan for creating units for all backlog production code

Answer 1

You need to do this incrementally. A "big bang" approach is going to cause more disruption and potential problems than the solution (TDD/Unit testing etc.) is designed to solve.

Take one problem at a time and deal with that. If it's too big, break it down into a series of smaller problems.

You need to show both your co-workers and management that the problem is real and is costing the company money - either directly or in increased development times. Then you need to demonstrate that the solution will solve this problem and, equally importantly, not cause any additional problems along the way.

By doing this you will gain the support of everyone and hopefully get their ownership of the solution. This should make them more willing to try it in the first place and keep going with even if it's not showing immediate improvements.

Your colleagues have probably spotted these problems themselves and are (hopefully) doing the same as you - wondering how they can be solved. Even the simple act of talking about them can go a long way.

Answer 2

This is year 3 and product is selling good enough. Now we need to enforce good software development practices.

You are not sure of the quality of the processes and the product and it is still selling? Lucky! No. i didn't want to really criticize you, but my point is that, the fact that your product is doing ok in market, it is a positive sign. Don't throw away things yet!

What you, need really is to slowly make things formal. In my opinion, it is not important to do best fit with respect to some standard process; rather you need to use that suits the team.

I am not very much aware how much maturity you have got in some of this, but make it really work for the team. First of all, you must ensure 4 essential things: a. Version control, b. Bug tracking and c. effective release management. d. Build the suit of regression tests.

In the answer here - i have enumerated some good and simple practices, if followed builds good momentum in the people and it helps bring trustworthy code as the key focus.

The same small step-by-step improvement criteria applies if you want to automate the testing process and move towards continuous integration - start with what most people agree that can be trivially and reliably automated (after a while people will begin to think, why did we ever did this manually).

Finally, about the documentation and code review process. I guess, most programmers wants to do a good job at this one; Issue is there are no consensus, best is try to bring purely a peer driven approach to a larger question: what do all of us think is a good code and documentation! (read this) As you evolve, again people will slowly convert into more of a personal responsibility than policy dodging activity.

This truth is, there are no great alternatives to "small-step-by-step" way of evolving code. Call it TDD, agile, iterative or whatever; these steps is what make it possible that team can fathom the evolution of the code and in all likelihood, try to accelerate to their maximum speed.

Once, people see success in these small steps, and finds the ownership, their biggest commitment to learn better practices and improving even further rapidly increase - leave them with this ownership and you will see wonders!

Answer 3

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 may help you a lot in this situation. Not exactly does it help to sell the idea of TDD/agile (you should use other sources explaining its advantages like nearly constant, low cost of change, reduced fear of change, etc., for this I would use Kent Beck's "Extreme Programming: Explained"), but it helps exactly with the process of moving legacy code to the agile process - isolating pieces of the code, make them a module, unit-testify it, then peossibly rewrite to new version developed by TDD and replacing the old with the new - this is what the book is about.