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.
Comments
blog comments powered by Disqus