I’ve been thinking about the, much ignored and rather unglamorous, state software ends in, when it’s about to be replaced by a newly developed version. It may be an old maintained branch, or it may have been or be about to be replaced, with a new version that’s based on a new code base.
While thinking about this I heard the song The Bare Necessities from Disneys The Jungle Book. Here Baloo sings:
Look for the bare necessities
The simple bare necessities
Forget about your worries and your strife
I mean the bare necessities
That’s why a bear can rest at ease
With just the bare necessities of life
The Bare Necessities, by Phil Harris, Bruce Reitherman
I decided to name the method used for this kind of development after Baloo.
And in the true spirit of The Baloo Software Development Method (tBSDM), I’ll pretty much keep it at that, with just a few more defining comments:
- While I think that it’s a special case of Agile Software Development, it’s also, more or less, 50% XP and 50% anti-XP.
- We do try to do the thing that will give us the most value for the least amount of work.
- The 90/10 rule applies. We aim to do 10% of the work (of a “real” solution), that will make 90% of the users happy.
- We try to avoid doing new testing or change existing testing procedures
- We don’t pair-program, as we don’t want to foul other peoples minds with our ugly hack.
- We do not re-factor.
- We are afraid of change.
- The perfect fix, is to do nothing, but release a “known issue/work-around” document.
- The all important question is. What’s the smallest possible change I can make that will make this go away.
- The important factors to evaluate as part of that questions is:
- Will it solve the issue to most peoples satisfaction?
- Will it impact any other parts of the program?
- Will it impact testing procedures?
One more thing: Is it a “software development method” when it’s used to maintain (or try not to) piece of software? Yes. You would be amazed how much software is actually developed using this method. It may be intended to be just a quick fix of a special case, but one day it may end up being an important feature.
This blog post is one of the rare real advances made in software development. Well done, TC!
Thanks Lars. It was an inspired moment…