There are 3 attributes necessary for a software project to succeed: Time, Money and Quality.

Time is a resource. It's necessary to build any project. Without time, nothing can be done. Because it's a limited and finite resource, the only way you can get more of it is to wait.

Money is also a resource. It's necessary to pay developers. Without money, you can't afford anybody (not even yourself) to build anything.

Quality is also known as Internal Quality. It's a characteristic of the software necessary to ensure it can resist change without consuming more resources than it needs. Without quality, you can't have long-term sustainability.

Quality is the hardest thing to achieve in a software project. It's a by-product of Tacit Knowledge.

A diagram in the format of a diamond showing the time and money necessary to evolve a piece of software and their quality. The top dimension represents "Money", the bottom dimension represents "Time". "Quality" is represented by the left and right dimensions. At the start of a project, the diagram is symmetric: "Money", "Time" and "Quality" are expected to be roughly of the same size, their relationship is unknown.

There are 3 attributes necessary for a software project to succeed. In order to have quality, you need to have more resources.

One year ago, I wrote about how prototypes tend to evolve. The post states that greenfield software projects tend to be developed with low-quality. Low-quality means a poor design that will have to be fixed later by more senior devs. Over time, those devs become frustrated because they have to fix somebody else’s mistakes over and over again for every project they join.

But why does that happen exactly?

Startups have a limited amount of money and therefore shorter time to become profitable. If they take too long, they can miss the market or be taken out by the competition.

Due to how economics work, if a Startup invests in quality when they have less money and time, they might run out of resources and fail to build traction in the short term.

In order to sacrifice quality, they have to hire inexperienced junior developers that can do things faster and cheaper at the cost of quality. Once they have traction, they can hire more experienced and expensive senior developers.

They will have a "good problem" to solve.

As a Startup, you're more likely to end up like this:

The same diagram as before. In this case, "Money" and "Time" have stretched while "Quality" has shrunk. As quality is reduced, it increases the amount of time and money necessary to evolve a piece of software.

Due to how economics work, Startups are forced to sacrifice quality in order to be successful.

Once a Startup gets traction, you can call them a Company.

At this point, they have enough passive income to keep the software running and making money. A Software project is very easy to scale to a profitable level, even if it's badly designed. You just need more users to join and electricity to run it. However, if it's built with low quality, improvements and new features start to consume an insane amount of time and money.

Over time, due to the natural increase of Software Entropy, it becomes very hard to increase quality. The more it stays like this, the harder it becomes.

At some point, the company has to hire senior developers which are more expensive and will take longer to fix the problems. The expected result should be like this:

The same diagram as before. In this case, "Money" and "Time" have shrunk while "Quality" has stretched. As quality is increased, it reduces the amount of time and money necessary to evolve a piece of software.

However, most companies fail to achieve this expectation when their resources become too stretched. They don't understand the amount of time and money necessary to increase quality at that point. It can be orders of magnitude higher and sometimes economically inviable.

When a Startup becomes a company, it has more time and money to spend and can increase quality, but it will take an insane amount of time and money to do so.

The amount of friction low-quality code can have in a project is huge, and it doesn't happen only to small companies.

Take PayPal for example. In 2011, PayPal could take up to 6 weeks for a copy text change to get live on the website (source).

This situation is frustrating.

Senior devs tend to suffer burnout because they feel that they’re always hired to fix somebody else’s mistake other than build new things. That can cause some of them to leave the software industry, which reduces the overall talent pool.

On the other side, you have new developers joining the industry all the time. Many of them are dazzled by the sheer amount of money that is paid for an experienced software developer.

They want to become one of them.

But to acquire more experience you need to have… experience!

You need to find opportunities being cheaper and faster because otherwise, you won't be able to acquire the desired experience.

After many years, once the junior developers become seniors, they start to be hired to fix somebody else's mistakes. Those who don't, continue to make things worse and increase the time and money necessary to evolve the system. They are the ones who will have 20 years of experience of the same year.

Look at this diagram I call the "Developer's Journey":

The diagram for a developer's journey. It has circles with captions pointing to one another in this order: "New Developer", "Write Bad Code", "Get More Experience", "Write Better Code", "Fix Bad Code" and then "Frustration".

In the diagram above you can see the phases that a frustrated senior developer can go through.

As a "New Developer" you figure out that writing software can be quick, you just need to memorize the language constructs.

You start to "Write Bad Code" and get opportunities in greenfield projects by delivering faster without knowing the long-term implications.

Once you "Get More Experience", you start seeing things you didn't see before. There's a realization that the code you wrote wasn't that good and decisions of the past can't be easily undone.

After that, you start to "Write Better Code" and learn more about the long-term implications of something. The code is not just the syntax anymore.

Now you realize you have to "Fix Bad Code" other people have written. You're not selected to work on unimportant greenfield experiments or prototypes anymore. Now you're more experienced, you'll work on projects that are already known to be important.

Once you see that more skill doesn't afford you to build interesting stuff and you always have to fix somebody else's mistake, you get to the point of "Frustration".

At this point, you become another developer with more knowledge of how things work. You can accept things as they are, become a consultant, contractor or leave the software industry.

Each person reacts differently.

As long as the economic system remains the same, these problems won't be fixed.

Of course, there are many other variables into play.

If the hiring process is bad, you can pay a lot of money for developers believing they are experienced when they are not. That will make things much worse. It will consume time, money and reduce quality.

If the developer has a poisonous behavior, like being the "Hero" or being the angry dev, they can infect the culture of the team, causing a lot of other problems.

Let's assume the hiring process and behavioral patterns are not an issue. Still, there's a fundamental cause for the source of frustration that can't be changed, or at least nobody have come up with a solution yet:

In order to survive, a software project needs to sacrifice quality for money and time. In order to exist, a software project needs to sacrifice money and time for quality.

Due to how the traditional economic system works, you’ll be cursed to see this vicious cycle over and over again for many years to come.

What you can do is to accept it and try to build awareness in order to enable everyone else to see and understand these tradeoffs.

This looks like a problem that is impossible to solve.

History tells us that the solution to an impossible problem usually comes from unexpected places. Most of the time by looking at the problem from a different perspective and finding a point of leverage that can cause a huge impact.

Software powers everything, yet we don't give it due care.

What you should know is that a solution never comes out just because a problem exists.

First, you need to recognize it.