The three best practices in software development

Michael Cusumano has documented the three most effective practices in software development  in his

book  "The Business of Software". These three practices have resulted in significant defect reductions in large companies.While  Six Sigma, Lean, CMMI and other methodologies can be applied to software and have been effective with varying degrees  , the following three practices have to be   implemented. All other methodologies and practices would be add-ons. So,  what are the three key practices ?.

1.Early prototyping -

Do a proof of concept by prototyping early and show it to the users.

Seeing is believing. When the users see something, they can spot obvious flaws and limitations.  

2.Reviews,reviews,reviews

We need reviews at each stage - High level design reviews ,detailed design review, code reviews, unit test cases reviews, system test reviews , project plan reviews etc. Review provides a negative feedback mechanism and hence stabilizes the output, to give an analogy of a closed look negative feedback control system.  In a control system with a negative feedback, the output Y = X * (G/1 + GH) .

X is the input, G is the gain/amplification/distortion  and H is the amount of feedback

In a  large project , G can be assumed to  be large and H close to 1 . Hence  GH  can be assumed to be much greater 

than 1. Thus Y = X * (G/GH) = X/H

Now if the review is 100% perfect , H =1 . Therefore,  Y =X .

Thus the output of the software stage equals the inputs which is the   specification to that stage.

In essence the output of the software development   will follow the specifications accurately if there are

rigorous reviews.

Linus Torvalds , the inventor of Linux said " Every bug appears shallow if a large number of eyes look at the code". How true ! No wonder why Linux is such a robust operating system despite being open source.

Millions of eyes look at each line of code each day  and suggest improvements.  So the next time you want to review code, call all developers in a room  and project their code . Let them all look at it and have fun dissecting it in a cordial  and friendly environment.

3.Daily regression tests and builds.

The code must be compiled and linked daily.

Automated regression tests must be run daily - the more the better and emails send to all concerned including

senior management when RT's fail. This ensures that as new features are added, existing features continue to work.