This post is the twenty-third part of a ramble-rant about the software business. The current posts in this series are:
- Goodwill, Negative and Positive
- Visions, Quests, Missions
- Right, Wrong, and Style
- Follow Me
- Balance, Part 1
- Balance, Part 2
- Definition of a Great Team
- The 15-Minute Meeting
- Metaproblems: Drama
- The Right Question
- Software is Organic, Part 1
- Metaproblem: Terror
- I Don’t Work On My Car
- A Turning Point
- Human Doings
- Everything Changes
- Getting It Right The First Time
- One-Time Boosts
- Perfection vs. Precision
- Software is Organic, Part 2
This post is about natural development cycles.
“Ringing” describes the curve of a waveform that occurs naturally. It’s called “ringing” because striking a bell is one of the natural places this curve appears. I see this curve in software projects.
- Code churn
- Bug rate and severity
- Developer enthusiasm
Code Churn is a generic attempt to measure the stability of software under development. It improves upon the earlier Lines-of-Code metric by measuring line of code added, deleted, and edited. One of my more productive days as a developer resulted in removing 90% of the lines of code. My LOC metric for that day was “-1800” but the software (code-behind a web page pre-.Net, before code-behind was automated) was 10 times faster.
At the beginning of a project, code churn will spike and bottom-out as teh development team figures out the best approach to solving complex challenges. One way developers manage this is to sketch out the workflow and identify the “difficult” stuff. Let’s face it: If you’ve been designing solutions for any length of time you have solved some common problems before. You don’t need to reinvent the wheel, you can simply utilize the same design pattern.
Once the difficult items are identified, it’s common to start by developing those pieces of code. Solving the big mysteries first allows you to knock out a proof-of-concept and will drive the more familiar portion of the design. It’s not uncommon to develop several proofs-of-concept applications to test various approaches to the solution and even different tools. This makes for lots of code additions, deletions, and modifications. As development time nears the release date, code churn stabilizes to a predictable norm.
Bug Rate and Severity
When testing begins, you’ll see lots of bugs reported and then fixed, then almost as many bugs reported and then fixed. The curve will ebb and flow, it’s as natural as ocean waves washing ashore. In general (and all generalizations are false), the number and severity of bugs will decrease over time. they will become “fewer and farther between.” Stability ensues as the ringing subsides.
Developers need a challenge. Stop challenging them and they get bored. They respond to challenges differently – most start new projects enthusiastically, followed by stark realization of the scope of work vs. the timeline – which dimishes enthusiasm. As the project progresses, mysteries are revealed and problems solved. Gradually, the unknowns dissipate. For developers, emotions ring at the beginning of the project until the unknowns are resolved.
Ringing is normal. It’s tempting to react to the troughs – or even the crests. Relaxing when things look good can be just as damaging as creating drama when things look bad. A steady hand is required to manage ringing. Realize it’s normal, and be a normalizing influence.