Development styles: gardener or warrior?

Users of a software product can only view the outside behavior of the software; they cannot look under the hood to see how the software actually works. This allows for a lot of differences in source code. It is almost guaranteed that different developers will deliver different code, even if the behavior is exactly the same. A large part of this difference can be explained by how the developer regards his source code. This article explores two development styles. I’ll call them gardeners and warriors.

Development gardener style

The gardener developer sees the code as something that is good as it is, and as such, he wants to keep it in this shape. Like in a real garden the gardener has to do weeding regularly, the software gardener also is zealous to find and fix any flaws, but he does not endeavor to refactor any more than strictly needed. The garden is kept in current shape. The software design stays like it was defined initially and every new feature must adapt to it.

Of course, fixing flaws is important. But it is still important to remember that flawless software does not exist, no matter how hard you try. What’s even more important, there must also be some tradeoff between fixing bugs and adding features.

A gardener stance is also observable at the architectural level, where existing design or technologies are used up to (or over) their limits, when better solutions exist. Want some examples? Signs of gardeners are:

• Don’t replace code with a widely used package when you discover that you can do this. Don’t even look for possible solutions for your problems that the world has come up with.
• Do not make use of functionality that comes with a new version of your favorite language. For example, in C#: instead of using LINQ, keep using foreach loops for everything.
• Keep extending the custom text file format, instead of switching to a database.
• Always try to keep obsolete features alive, regardless whether they are used or not.
• When a new feature is coming up, the gardener knows of all the past and present uses of the current code that are being affected.

Summarized, a gardener assumes that the current design of the software is a given, instead of making the design and architecture fit for the current demands.

Development warrior style

More or less on the opposite side of this spectrum is the warrior kind of developer. He sees the code base as a battle field. The code base resists his changes, so results must be forced in. He regards it as an obstacle when the software does not work as intended, and this obstacle is something to be conquered. As such, he gets in battle with the code. Warriors are not interested in the state of the source code, just that the code obeys them no matter what. His vision is on short term results no matter what happens.

Are there signs that a warrior has been around? Of course:

• Lots of if..else constructs, especially in the lowest level parts of the code. if..else is the sword to force his will on the software.
• Copy paste coding.
• No unit tests. The warrior relies on the debugger to find and fix any flaws.
• Misuse of existing features to get new features working: can’t access a file? That means that the app is not running with admin privileges. Because that is the quickest we can do now.
• Don’t care about readability in general.

However…

As with many things, those two development styles gardeners and warriors have another side. I pictured them in a negative sense, but they have also positive traits:

• Not refactoring to include new insights can be sensible in many cases. But if you never refactor, you will eventually lose a lot of time maintaining a legacy code base that could have been much more efficient.
• There is also little risk in replacing a foreach loop with a LINQ query when you have to change the code anyway.
• Taking on a warrior stance can be necessary when making fixes to production code. Here, cleanup comes with risks and time loss which is unacceptable when the customer is waiting for a fix.
• Warriors are good at prototyping, where the result is thrown away anyway.

Also, keep in mind that these two development styles can easily be extended with many others. Similar stories are possible using miners, generals, surgeons or lawyers.

The point of this post is this: think about the way you look at the code. When you do this, you can actually change the stance you take. If you do so, you can take the positive parts of each metaphor and apply them in your daily work, while avoiding the negative parts.