Greenfield projects are considered the holy grail when talking about working somewhere. Of course, who would not want to contribute from the get go in shaping the project technologies of choice, architecture and starting bug-free (no code, no bugs, right?)?
In my many years as a software engineer my experience aligns with most people, as I worked in:
- small projects
- big projects
- maintenance mode
- greenfield
Looking back, it is interesting to see how different types of projects are the compound investment of multiple people's ideas, (dis)agreements, (mis)communications. By compound investment one might think projects eventually give you good outputs and increasing benefits, but more often than not, instead of compound investment, a project is a result of accumulated and propagated errors. Disagreement and miscommunication - also bad ideas - are the main cause of project downfall. You likely know a project people dreaded to work on because "it is legacy code and the people that made it already left", right?
Greenfield projects usually start with very good intentions. People get together to discuss what shall be the seed, the set of technologies, techniques and patterns being used to make sure the project won't derail from its intended purpose. But requirements change, and if you are in a fast-paced industry, they change a lot and quickly. And the project everyone was excited to work on starts to show signs of the same accumulated errors that insist to propagate through every iteration.
There is an interesting quote from Nicolas Carlo that says "Legacy Code is the code you need to change and you struggle to understand". And why does that happen? I have a hypothesis:
when you start a Greenfield you often have no idea of how the project, requirements and people involved will behave in the future. And when you reach the future and look back - now that you are more mature - you realize bad decisions have been made but changing them are too expensive.
How many times have you seen some piece of code and thought "how could this be written this way"? But what you (potentially) fail to realize is that when a piece of code was written, the context around the past decisions was different and likely more immature. Just like with money, good decisions compound over time and bad decisions propagate over time. And just like money, tech debt is hard to pay back, especially in fast-paced environments.
In conclusion, I tend to think Greenfield projects are great to work with, but it is likely that people and processes mistakes will carry over throughout the lifetime of the project. This is what makes them cursed from the start.
Top comments (0)