Effective Software Design

It is a well-known fact that many software projects fail. Thus it is natural to ask: what is the main contributor for the success of software projects, the processes or the people? In other words, we may ask who has the better chances to succeed: a great team with no emphasis in the process or an average team with a well-defined process?

The Capability Maturity Model (CMM) is a tool to assess the ability of software development organizations to implement software projects. There are five levels defined in the model, which represent gradually improving degrees of capacity to build software systems in a predictable and effective way:

1. Initial (chaotic, ad hoc, individual heroics) – the starting point for use of a new or undocumented repeat process.
2. Repeatable – the process is at least documented sufficiently such that repeating the same steps may be attempted.
3. Defined – the process is defined/confirmed as a standard business process.
4. Managed – the process is quantitatively managed in accordance with agreed-upon metrics.
5. Optimizing – process management includes deliberate process optimization/improvement.

In particular, I would like to focus on Level 1 – Initial (Chaotic):

“It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes.”

In this case, software developers are “reacting to events”, in a similar way to which firefighters react to emergencies.

Here is anoter definition by Tom Schorsch from his article “The Capability Im-Maturity Model (CIMM)“:

“Level 1 – Initial Ad hoc and Chaotic: Few processes are defined, and success depends more on individual heroic efforts than on following a process and using a synergistic team effort.”

Tom uses the expression “individual heroic efforts”. Indeed, for organizations at this level, the only chance of success is the heroic behavior of software developers. Again, like firefighters, programmers must risk their own health to deliver a project.

Individual Heroic Efforts are Harmful

The fact the we are comparing programmers to heroes does not mean that this is a positive and desirable situation. No organization should be proud of having its software developers doing such sacrifices in order to succeed.

Sammy Larbi wrote a nice article “Rewarding Heroic Development Promotes Bad Behavior” in which he says:

“When developers have to stay up all night and code like zombies on a project that may very well be on a death march, you’ve got a problem, and it’s not solely that your project might fail. Even when that super heroic effort saves the project, you’ve still got at least three issues to consider:
– Was the business side too eager to get the project out the door?
– Are the developers so poor at estimating that it led to near-failure?
– Is there a failure of communication between the two sides?”

Note that the term “Heroic Programming” also has a negative meaning:

“Heroic Programming, usually a pejorative term, is used to describe the expenditure of huge amounts of (coding) effort by talented people to overcome shortcomings in process, project management, scheduling, architecture or any other shortfalls in the execution of a software development project in order to complete it. Heroic Programming is often the only course of action left when poor planning, insufficient funds, and impractical schedules leave a project stranded and unlikely to complete successfully. It is highly probable that more projects are, in fact, completed by acts of Heroic Programming than by proper analysis, design, architecting, planning, scheduling, budgeting and implementation combined.”

Heroic Efforts are not Sustainable

In my opinion the main problem with these Individual Heroic Efforts is that they are not sustainable over time. Eventually the software developers will lack the necessary motivation to make such sacrifices. In particular this will happen if a project fails despite the heroic efforts of the programmers.

Dan Ariely in his paper “Man’s search for meaning: The case of Legos” describes a series of experiments to show that the effort that a person invests in a task depends on the meaning of this task. Here is the description of the famous Lego experiment:

“In each of the two conditions, subjects received payments for assembling Bionicle Lego models…

In the Meaningful condition, after the subject would build each Bionicle, he would place it on the desk in front of him, and the experimenter would give him a new box with new Bionicle pieces. Hence, as the session progressed, the completed Bionicles would accumulate on the desk.

In the Sisyphus condition, there were only two boxes. After the subject completed the first Bionicle and began working on the second, the experimenter would disassemble the first Bionicle into pieces and place the pieces back into the box. Hence, the Bionicles could not accumulate; after the second Bionicle, the subject was always rebuilding previously assembled pieces that had been taken apart by the experimenter…

Results: Despite the fact that the physical task requirements and the wage schedule were identical in the two conditions, the subjects in the Meaningful condition built significantly more Bionicles than those in the Sisyphus condition. In the Meaningful condition, subjects built an average of 10.6 Bionicles and received an average of $14.40, while those in the Sisyphus condition built an average of 7.2 Bionicles and earned an average of $11.52.”

Thus we may expect software developers to continue their heroic efforts as long as their success is “accumulating on the desk”. But if for some reason the project fails and their sacrifices bring no fruits, they will not be able to keep working with the same motivation as before. And then the organization will be in serious trouble…