Avoid code donuts
(May 8th, 2007)
Nothing fattens up code like a code donut. Tasty and sweet they satisfy your feature needs temporarily but leave you wanting more and more and more. They also turn your lean runner’s body into something better suited to “Sweating to the Oldies”.
I’ve used the term code donut for a while to describe a certain kind of feature request: the kind that moves you sideways from where you want to go (or sometimes backwards). When a company has a well defined need for something of moderate size, it’s very common to build something stopgap that takes care of the “low-hanging fruit” without solving the whole problem. These kinds of solutions are frequently both necessary and useful since the ideal solution may be to complex to build all at once. These aren’t code donuts, but they are the precursors to code donuts. The code donut is the small well defined improvement to the initial temporary solution that comes as a follow up (and the one after that, and the one after that, and so on). Developers often like these little additions because they are well defined and straightforward. Small simple projects are fun since you get that nice sense of completion. The problem is that all of the little changes that come after the interim solution usually do nothing to move you towards what you really need, they just fatten up the current solution and often other parts of your code as well.
Companies build on top of these interim solutions for a few different reasons. Sometimes the temporary solution just doesn’t do the job. Continuing to build off of a poor solution that doesn’t do the job is almost certainly a case of spending good money to try to recover bad. The idea of the temporary solution was that half a solution was good enough, if that’s not the case it probably never will be. Another reason for these small enhancements is that the temporary solution does what it’s supposed to and people are using it and finding other things it needs to do. This is the bigger and more insidious case. It means that people and processes are going to adapt themselves to the temporary solution which virtually guarantees that it will be anything but temporary. When these changes move gradually and inexorably towards the desired solution they are all great things. When they don’t they are probably code donuts making you fatter and not really taking you where you need to go. The demand for more is an indication that the problem is an important one. It’s an indication that spending the time and energy to get what you need is a good idea.
I recently had a contract with a company that had been code donuting itself to death for a long time. They had a large system that amounted to little more than glorified email, but they had managed to intertwine themselves with it from a data, code and process standpoint to a degree that made it difficult to consider the many superior alternatives that could have made their jobs easier. No one wanted the system any more, but neither could they find their way out from under it. The code was one thing, but even more challenging was the way people had become dependent on it. Any alternative would be framed in terms of the current system, funneling conversation down a narrow and deep hole and keeping people from understanding that there are other ways of doing things.
Agile processes are highly vulnerable to code donuts. The nature of the short development cycle and the near term prioritization encourage finding the best solution for now and then expanding on it. Several agilists I know have even challenged the legitimacy of the notion, apparently subsumed in their belief that as long as the code is well factored the short term decision is always the right one. Unfortunately I’ve seen too many broken systems fashioned gradually around a temporary solution to believe that weak dogma.
Some of the ways you can avoid code donuts are:
- Craft interim solutions that are part of an ideal solution rather than instead of and ideal solution. This is hard and not always possible, but look for ways to do it. It’s the single best approach you can take.
- As soon as an interim alternative starts to become critical to your internal processes invest in the preferred solution.
- Leave interim internal solutions unpolished. Strange as this sounds, if you believe something is temporary then making it feel that way keeps people from getting too attached. It also saves development time. Quality fanatics feel free to fax me a copy of your hand so I can slap myself silly with it.
- Avoid integrating interim solutions. When they stand alone they are easier to replace and they don’t pollute the rest of the code stream.
- If you really have no plans to do “the right thing” then acknowledge that and do the closest thing you can. Sometimes what you want is beyond your reach. In these cases you need to stop acting like the temporary solution is temporary and recognize that it is a real product, giving it the care and attention it deserves and not just a long running series of code donuts.
If you fail to follow these simple dietary suggestions, be prepared to fight a long and running battle with bloat.
May 8th, 2007 at 4:52 pm
You misspelled doughnut.
May 8th, 2007 at 4:54 pm
I find that one common cause of software donuts is “last week’s problem”. You know, there was a problem with the system last week that comes up (say) every Christmas. In January you get to add the curative donut and the code just sits there until next year. If you manage to recall the code extension the following year and check to see how it ran – well, nine times out of ten the business process changed in some subtle way and the problem never arose.
The other cause is new managers in a user department. New managers like to boost their popularity by ordering (software) donuts – and as often as not cancelling the donuts ordered by the previous manager.
May 8th, 2007 at 4:55 pm
Go with the flow - like I did
May 8th, 2007 at 5:36 pm
My spell checker shows that doughnut is wrong and donut is right, although doughnut appears to be in Websters. I suspect the American spelling of donut is just fine.
May 9th, 2007 at 2:40 am
“There” -> “their”
May 9th, 2007 at 8:06 am
I really liked your list of approaches. When I first started reading this I was like “yeah, yeah, I know, but try selling anyone on the amount of time it’s going to take to do it right”. But I found that your practical suggestions about what to do about it very useful. I have used the “code part of the solution” approach. Even if it’s as little as you learning something about a new technology that you think is the right approach, that’s something that won’t be wasted.
One of the best things you brought up, and one of the hardest things to do, is to not gold-plate the pile of poop. It’s very important to help people remember that it’s a pile of poop. It’s practically impossible to live by this rule–I don’t want to watch people suffer. But I guess you have to guess where the balancing point is. If you work too hard to “relieve their suffering” you might very well be prolonging the larger suffering. Still, it’s hard to tell when you’re doing one or the other.
And the idea of “as soon as it becomes critical, start working on the right thing”, again, this is a very hard thing to be disciplined about, but this is exactly where you are making the big make-or-break decision for the future. When you ignore the fact that your temporary solutions are becoming permanent, that’s when you end up in technical bankruptcy.
Anyway, didn’t want to just repeat all your points. I think it’s important to note that while some of the suggestions are just “knowledge that, once you have it, will help you in these situations” while others are more a matter of long term discipline that you will have to talk your company into abiding by.
If you are having to do that, it’s very useful to have them stated so succinctly. Thanks.
May 15th, 2007 at 9:34 pm
Nice metaphor.
Agile projects sometimes do come a cropper with doughnuts, it’s a particular gripe that I have with Scrum that practitioners will tell you that the product owner should be able to actively choose to incur the long-term risk of quick’n'dirty short-term solutions. This is contra the ExtremeProgramming stance wich is quite similar to what you suggest, particularly in terms of implementing a partial solution absolutely as well as it can be implemented (I don’t like talk of “ideal” solutions, I don’t believe they are found in nature and even if they were they’d be near impossible to determine ahead of time).
I very much am in favour of unpolished (although of production quality) and especially unintegrated interim solutions and even said so once at an Agile conference (http://www.keithbraithwaite.demon.co.uk/professional/presentations/#AA2), didn’t go down terribly well…
May 28th, 2007 at 3:05 pm
[…] An Agile trap for the unwary Code Craft » Avoid code donuts Agile processes are highly vulnerable to code donuts […]
June 8th, 2007 at 7:02 pm
I haven’t been overwhelmingly guilty of code donuts at my employer’s expense, but my personal projects at home are rife with them.
I have been trimming them out, but it is amazing how you can get yourself trapped into being dependent on them.
Nice post. Thanks.
July 28th, 2007 at 6:54 pm
I think that engineering practices might help with this problem. When developing a new car, you don’t mass produce the working prototype; it has to be re-engineered for the production line. But, because software can be duplicated at no expense we never go through that process - we simply leave all our kludges and experimentation in the “finished” product. Software products need to go through a process of re-engineering (or rationalization) every now and then to clear out the temporary fixes. Just don’t let your manager know !
January 23rd, 2008 at 10:54 am
[…] Code Craft » Avoid code donuts “I’ve used the term code donut for a while to describe a certain kind of feature request: the kind that moves you sideways from where you want to go (or sometimes backwards)” (tags: agile projectmanagement) […]