Greenfield vs Brownfield Software
At a place where I worked for a while, I was not a dev but I worked with them, and I got to both see their decisions and influence some of them.
This place produced software for its own use - it ran a large and complicated website and that required data handling, user decision handling, content management, and many other pieces of software that heavily affected the flow of money.
One of the inevitabilities if you do this is you will need to revisit software that you wrote years (occasionally even just months) ago and change it. Sometimes circumstances have drifted so much that it is obviously time to rewrite it from scratch. Other times such software just needs a few tweaks to catch up.
An uncomfortable number of times, devs are torn between the two. This happens a lot because meddling with existing software, that is currently making money, is often left until it’s unavoidable, and that coincides with that uncertainty line.
But here’s the thing; devs (myself included) much prefer greenfield. Start again. Make something entirely new. A fully, empty playground for you to do whatever you want in. Maybe even branch out into a new language, new framework, new patterns.
Brownfield is none of those things.
So when I came to ask for somebody to work on some code that clearly needed improvements - operational improvements mainly, the functionality was largely good - I asked for a certain senior developer from the owning team to take it on. He was, to say the least, not thrilled.
So I had to sit him down and tell him why. Spread some wisdom. I’m old.
You see, the reason I want you to do this is because it’s brownfield, I explained. Yes, yes, he knew. It’s boring, can’t one of the more junior people do it?
Ah, there we come to it. You see, greenfield is fun because it’s easy. No constraints. Your choice of patterns. Nobody else’s thinking in the mix. Easy.
I want you because this is hard. This isn’t frolicking in the fields of code, this is juggling two chainsaws and a live badger in a lift surrounded by live wires. This has intermediate stages, every one of which needs to be both adding functionality and being backwards compatible, until it’s time to not be.
Brownfield isn’t boring, it’s frustrating, and hard, and that instinct to start again fresh (and to make all new mistakes that took months of pain and debugging to get out of the previous version) is made of a dislike of that frustration and difficulty.
One of the common questions non-senior devs would ask is, what does it take for me to get promoted to senior dev?
Well, there are various answers and some hurdles to pass, but let’s start with this: show me a good brownfield project.
Conclusion
Imagine, if you will, a day when all the drama is removed from your software production: no panic, no crisis, just smooth software releases that exceed your customer’s expectations. This is what we have done in the past and can do for you.