Much has been written about the Software Development Life Cycle. Less well known, however, are the cycles through which engineers personally progress when developing software. This brief study attempts to rectify somewhat this sad dearth of knowledge.

The simplest way to explain these cycles is with a diagram:

Ordinarily one hopes to attain a state of continuous cautious optimism in whatever project is under way, based on a number of factors:

1. A reasonable understanding of the software being developed,
2. Prior experience with this and other projects,
3. Belief in the general stability of the software in question, and,
4. An understanding that this project solves a real problem, and will ultimately be of benefit to others.

Unfortunately, in all but the smallest of projects, one will invariably encounter something that looks odd. Often this occurs when interacting with other people who are actually attempting to use the software in question.

With luck, the odd thing is intentional, and the software is operating per spec; perhaps there is room for improvement in documentation or the user interface, but basically, the software is fine. Alternately, the odd thing really is a bug, but within a minute or two it is possible to mitigate any minor issues.

Things become slightly worse, however, when one finds oneself looking at some aspect of the software, and exclaiming “What?” This tends to suggest that some basic assumptions about the software or project in question are perhaps incorrect.

Thankfully, even at this stage, it is often possible to take a step back, analyse the problem, turn to one’s peers and say with confidence “It’s OK, I can fix this”. Not long thereafter, the major issues are fixed, any remaining minor issues are mitigated, and one can return to a peaceful state of equilibrium.

The trouble only really starts when one progresses past that first “What?” and discovers something else is broken in a major way. This takes time to work through, and often the first solution is of dubious correctness, or breaks other parts of the system in disastrous ways.

Worse, when delving into unknown areas, this cycle can continue for dangerous lengths of time. This is not so bad when due to individual lack of experience, because that will be rectified simply by going through the cycle a couple of times. It is far more damaging when due to fundamental flaws in the software itself, especially on large projects, and more so if one is under pressure from customers, management or other stakeholders such as marketing. This can result in entire teams of engineers spinning rapidly from hope, to annoyance, to shock, to horror and back again semi-indefinitely.

While these harsher cycles often serve to aid the broader economy in many respects (including increased rates of purchase of pizza, caffeinated and/or alcoholic beverages), they are a major cause of engineer burnout. Unless one can tear free, they will ultimately result in either breakage of individual engineers (anything from simple resignation to severe emotional and/or physical ailments), or complete catastrophic failure of the project as a whole.

It is this last point which must be brought most to light; general awareness of the possibility and dangers of being caught in an endless death spiral will hopefully allow some to avoid this fate. If that fails, at the very least, it should provide others with a better understanding of individuals and teams currently trapped in these cycles.

Finally, there is a ray of hope in all this. If one falls from cautious optimism to the very bottom of the circle; pulls oneself up only to encounter further disaster; rises once again only to slip faintly short of the goal; then ultimately transits successfully through one more arc of oddities to rest with satisfaction — after weeks or months of toil — in a state of truly justified cautious optimism… Nothing can compare to this sense of achievement.

Then, it’s time to do it all again.