“Adding man­power to a late soft­ware pro­ject makes it later.” – res­ult of the fact that the expec­ted advant­age from split­ting devel­op­ment work among N pro­gram­mers is O(N) (that is, pro­por­tional to N), but the com­plex­ity and com­mu­nic­a­tions cost asso­ci­ated with coordin­at­ing and then mer­ging their work is O(N^2) (that is, pro­por­tional to the square of N) – Brooks’ law

In 1975, Fred Brooks wrote a clas­sic book on soft­ware pro­ject man­age­ment called The Myth­ical Man-Month. Brooks’s obser­va­tions are based on his exper­i­ences at IBM while man­aging the devel­op­ment of OS/360. He had mis­takenly added more work­ers to a pro­ject fall­ing behind sched­ule. The tend­ency for man­agers to do such errors in pro­ject devel­op­ment led Brooks to quip that his book is called “The Bible of Soft­ware Engin­eer­ing” because “every­body reads it but nobody does any­thing about it!”

Sequen­tial devel­op­ment method

The Water­fall Model is a widely pop­u­lar soft­ware devel­op­ment method used by many large soft­ware houses. This approach applies the insights from mature engin­eer­ing dis­cip­lines (mech­an­ical, elec­trical) to software.

The per­fectly sound idea is to con­struct sys­tems by first gath­er­ing require­ments, then doing the design, then imple­ment­ing it, then test­ing, and finally get­ting it out the door in one lin­ear sequence. Pro­gress is gen­er­ally meas­ured in terms of deliv­er­able arti­facts –require­ment spe­cific­a­tions, design doc­u­ments, test plans, code reviews and the like.

The heavy pro­cess water­fall shops have elab­or­ate respons­ib­il­ity matrices. Archi­tects do all the design upfront in com­pre­hens­ive doc­u­ments and developers code what they’re told.

The require­ments will never be correct

The ori­gin of the term “water­fall” is often cited to be an art­icle pub­lished in 1970 by W. W. Royce. Iron­ic­ally, Royce was actu­ally present­ing this model as an example of a flawed, non-working model.

The Water­fall Model is flawed because it is too rigid and unreal­istic. In the real world, soft­ware pro­jects have ill-defined and con­stantly evolving require­ments, mak­ing it impossible to think everything through at once.

Soft­ware now needs to be built faster and more cor­rectly. It needs to con­stantly change to address the chan­ging nature of the mar­ket and meet cus­tomer demands. Using the Water­fall Model, these changes are impossible, the devel­op­ment cycle is too long and iter­a­tions too expens­ive. Sys­tems are over engin­eered and ends up cost­ing a fortune.

Soft­ware is not a product

The core issue with the busi­ness of soft­ware is that we repeatedly mis­un­der­stand what soft­ware really is. Soft­ware is thought of as being a product, it is looked at as being a product, it is mostly man­aged as if it were a product. But it’s not a product, it’s a process.

The sys­tems we ship to our cus­tom­ers are actu­ally the byproducts of the real activ­ity, which is to learn. The busi­ness imper­at­ive is that the real product is the know­ledge that is in the sys­tems we ship to the cus­tomer, and we don’t man­age that at all.

Soft­ware is an ongo­ing prac­tice, a recital between the com­puter and the mind. It begins in the devel­op­ing brain with a child’s appre­hen­sion of logic and con­tin­ues from tech­nique to innov­a­tion to tra­di­tion. No soft­ware any­where is a work on its own, and most soft­ware is an amal­gam of lib­rary tech­niques, usu­ally writ­ten by other people based, in turn, on work by their predecessors.

Iter­at­ive devel­op­ment model

In the late nineties a num­ber of agile soft­ware devel­op­ment meth­ods emerged. While they differed in details, they agreed at large that soft­ware devel­op­ment needed a major rethink­ing. First, soft­ware has to embrace change. To meet the chal­lenge, agile approaches advoc­ate focus­ing on sim­pli­city. Make the simplest pos­sible sys­tem that sat­is­fies today’s require­ments and when tomor­row comes, be ready to adapt.

Agile devel­op­ment principles:

  • focus on simplicity
  • embrace change
  • release often
  • com­mu­nic­ate and get feedback
  • test and refactor
  • remem­ber to have fun

Refact­or­ing is what allows agile sys­tems to embrace change, while remain­ing eleg­ant. Code is con­stantly changed to make sure we end up with the simplest, and best pos­sible sys­tem that reflects our cur­rent needs. Agile meth­ods emphas­ize work­ing soft­ware as the primary meas­ure of progress.

Pro­gram­ming is a cre­at­ive pro­cess, not an indus­trial one.

Since early days of soft­ware devel­op­ment people have struggled to build good sys­tems. More and more people where thrown at the prob­lem, mak­ing mat­ters worse. But with the recent explo­sion of social web we’ve wit­nessed a new and inter­est­ing phe­nomenon: a hand­ful of developers are now able to build sys­tems that are used by mil­lions of people. How can this be?

The secret is that pro­gram­mers should not be con­sidered as fact­ory work­ers. An army of code mon­keys and non-coding IT-architects doesn’t usu­ally deliver bet­ter products than a smal­ler group of motiv­ated indi­vidu­als. Give your developers more lee­way in their approach and decent amount of coach­ing, and their code is con­sist­ently bet­ter because they’re think­ing while they code.

Iron­ic­ally, we are com­ing full circle with the myth­ical man-month. What was true twenty years ago is true of course today, but for a whole new set of reas­ons. An impress­ive array of mod­ern pro­gram­ming lan­guages and infra­struc­ture lib­rar­ies com­bined with agile meth­ods has allowed us to break free of inad­equate soft­ware devel­op­ment dog­mas and be more productive.

Less is more applies equally to code and the num­ber of people work­ing on it.