Like most developers, I relish any green-fields opportunity - a chance to build a new system from the ground up, unfettered by history and to be able to do things the best way I know how.

But how realistic is this?

It’s a simple fact that not every project can be greenfield. I’d venture that most development work is brownfield, maintaining and enhancing existing systems.

What about the assertion by some developers that there’s no challenge in a maintenance role?

No experienced developer would dispute that there are some maintenance jobs that are boring and repetitive, lacking in challenge. That some systems fall into this situation is, however, no reason to write off all maintenance roles as such.

If there is management buy-in to the idea of keeping the system current; motivation to not just ensure the system does’t die, but to improve and enhance the system to provide greater value; then maintenance can be at least as much challenge - as much fun - as a green-fields development.

It’s been written: if necessity is the mother of invention, constraint is the father.

Building a system with a good architecture might be easy when you start from scratch and you have the freedom to choose. Taking a system with a poor architecture, one where a good architecture has been partly eroded or largely disregarded and economically transforming it into a system with a good architecture, now that’s a real challenge.

We’re all familiar with the idea of bit-rot: the idea that older computer systems are harder to work on and update because of all the cruft and special case support that has accreted around the original system over time.

Bit-rot is not inevitable.

Avoiding (or curing) bit-rot takes both hard work and a commitment to doing things the best you know how. There is real challenge in making changes (small or large) that improve the system in measurable ways.

Sometimes we do need to throw out old systems, but that’s far rarer than you might think.


blog comments powered by Disqus
Next Post
Working with fxCop  27 Sep 2010
Prior Post
Typography  20 Sep 2010
Related Posts
Using Constructors  27 Feb 2023
An Inconvenient API  18 Feb 2023
Method Archetypes  11 Sep 2022
A bash puzzle, solved  02 Jul 2022
A bash puzzle  25 Jun 2022
Improve your troubleshooting by aggregating errors  11 Jun 2022
Improve your troubleshooting by wrapping errors  28 May 2022
Keep your promises  14 May 2022
When are you done?  18 Apr 2022
Fixing GitHub Authentication  28 Nov 2021
September 2010