Introduction
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
- Institutionalized!
- Perfection vs. Precision
- Diversity
- Software is Organic, Part 2
This post is about natural development cycles.
Ringing
“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
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.
Developer Enthusiasm
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.
Conclusion
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.
:{>
Your analogy brings up a few questions. Speaking from a control systems view, what, if anything for these examples could/would be an influence to make it a more critically damped system, to smooth out the oscillations earlier? Second, does this assume no other outside forces are acting over the duration? I could see things settling down when an outside force applies an impulse which causes higher oscillations again. Third, as an extension of the second and as a worst case scenario, what situations would cause this pattern to reach its resonant frequency where oscillations would get worse over time instead of better?
Hi Chuck,
These are outstanding questions. As someone with controls knowledge, you realize one solution is to introduce Proportional/Integral/Derivative (PID) feedback. Finding (proper) analogues with managing software teams is the challenge before me now. I have some, but I am taking time to work through some good examples (test-driven blogging?) before I write more.
If you have thoughts on the topic, please share.
:{> Andy
Ok, I’ll give it a shot. I asked the questions because I could see this idea turn into its own full post, or just rat-hole off on its own tangent. I’m not sure how well thought out my ideas are, so here’s a rough sketch of what was starting to go through my head. Plus, it’s been a while since I’ve really had to think about control systems, I could hear the rust falling off the grey matter.
First, there will always be some measure of oscillation and volatility due to current iterative dev approaches (agile, scrum, xp, etc.), and the fact that we’re human, we have good days and bad, and there are always those things which are completely out of our control no matter how much we wish it were otherwise.
So to abbreviate my previous questions, I’ll label each as follows and consider them for each of your headings.
q1: critical dampening?
q2: external impulses?
q3: resonance?
Code churn:
q1: I think you achieve dampening through an experienced team familiar with problem domain and tool set. You know what the problem is, you have enough experience and/or forethought to mock out a good framework, then go out and build it.
q2: An example would be new directives mid-stream, such as "ok, but now make it do this other thing instead" which wasn’t in the original plan and requires going back to the original architecture. Things might have been settling down before but now you have to adapt to the new input.
q3: An example of resonant code churn would be loss of project direction, or a spray and pray dev model, or teams building pieces in isolation that when integrated blow up and you have to go back to the drawing board, or projects initiated to build a tool to do x but then it morphs into something else and each time it goes through another iteration it has to do something else, where code reusability basically goes out the window.
Bug rates and severity:
q1: Probably the same answer as q1 under code churn. I suspect there’s a strong correlation between code churn and bug rates, but maybe not.
q2: An impulse to cause a jump in bugs here could be new tech, like adopting cloud or new languages. Or maybe someone runs a new security tool against it and finds a new set of vulnerabilities you have to address.
q3: Resonance could if people start introducing more problems than they fix.
Developer enthusiasm:
q1: As I said above, people are variable, and similar to answer for the other headings. The goal would be to increase enthusiasm yet still have the "been there done that" mindset to prevent the highs or lows.
q2: Impulses on enthusiasm could be + or -, + if there’s new found support from upper mgt, – if beta users blast it, or mgt suddenly says it needs to launch next week when there’s two months’ work left.
q3: Resonant enthusiasm, that sounds like manic depression or something. Or perhaps an unstable environment, perhaps due to recent layoffs, etc.
So there you have it, for better or worse. I see a bit of recurring patterns and variation on a theme, which I guess could all be neatly summed by the idea of adaptability.