Greenfield projects are cursed

Victor Nascimento — Tue, 22 Jun 2021 05:45:52 +0000

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.

The 3 kinds of developers

Victor Nascimento — Sat, 07 Sep 2019 06:51:45 +0000

Based on my software development experience over the years I have been able to identify mainly 3 types of developers, independently of seniority level.

The lazy

All developers are somewhat lazy on their craft, but some belong to "The lazy" class. They do their job, sometimes they do their job well, but you can really identify them by how averse to change they are. Usually not looking for new things to do, following the "if it works, why change it?" mentality that can last for years. Probably the most common developer to find.

The curious

They are diametrically opposite of "The lazy". They try to read and implement bleeding edge solutions to problems just for the sake of curiosity. They bring a positive view to the workplace by exploring new stuff every day and talking about it with their team. Usually they deliver quality work, always trying to improve themselves in the process having a great impact on the team and product. You probably met one or two - or belong to this class yourself - but this type is quite rare to encounter.

The liability

They are a result of a bad hire. It makes the team think "how am I supposed to work with this developer?". Slowing down the team, asking for the most basic advice on well known / well documented things. Producing bad quality code with rookie mistakes even though they have been hired as seniors. They are usually non-communicative, misunderstanding and keep making wrong assumptions, a pain to work with. The worst part is they might not even realize they belong to this class until is too late and the damage is done already.

Afterthoughts