How To Prevent Falling In The Trap Of The “Next Big Project™”

3 options for when the temporary prototype becomes the permanent solution

A rule and a pencil on top of some papers representing an architectural design

Teams are bombarded by an unexpected project that arrives overnight. Executives decide to hire more developers for this "big new project" expecting that there will be no ramp up. The context doesn't allow the payment of technical debt. Managers turn requirements into a demand for low-quality software in the form of implicit (or explicit) pressure. All sorts of problems start popping up and you wonder what happened.

There’s something fundamentally wrong going on in this industry.

People say that maintaining and improving a nontrivial piece of software is a different skill set than building it in the first place. It's not like those who can maintain and improve software are not able to build it, they can. What happens is that building low-quality software is much easier (and therefore cheaper) than building it right, and the effects of low-quality software are not perceived until it's too late. For that reason, we have companies (mostly startups) that decide to lower the barrier of entry to the market with low-quality software in order to raise the capital necessary to "fix it" later. That's their only viable choice because most of them lack money and statistics show that there is a high chance they will never see the light of day.

People say that maintaining and improving a nontrivial piece of software can be considered a different skill set than building it in the first place

So the company comes up with this next "big new project" that is just a hypothesis they want to test in the wild. They decide to go for a "prototype". The "prototype" is not an "MVP" (Minimum Viable Product) or an "MLP" (Minimum Loveable Product), it's just a facade with a crap implementation that will be thrown away and rebuilt properly once the business feasibility is proven.

When it goes live it gets some traction but then somebody realizes that it could have been even better if "this small thing" is added, so they add that on top of the prototype to test it. Then they see that it could have even more traction if they add "this other small thing", so they implement it on the top of the prototype to test it again.

At the end of the day there are hundreds of "small things" piled up on top of the prototype and now it has become a monster that is too expensive to be thrown away and rebuilt. The only alternative left is to do incremental improvements. The problem is that, at this stage, incremental improvements are very hard to make, even if the company hires more experienced developers. The original developers never imagined that this messy "prototype" would have to be maintained, everyone did the exact opposite of making it maintainable for the sake of the "prototype" promise, and even if they tried to do it right they would still struggle because they were hired to make it work not to make it right.

A successful prototype tends to become the final product instead of being rebuilt after serving its purpose

This kind of mindset seems to happen mostly to software development.

Can you imagine what would happen if Ford decided to produce one thousand prototypes of an unfinished car and then after several adjustments here and there they allowed the same product to be sold to the customer without building new ones? A bunch of cars full of band-aids that risk the security of everyone in the streets including their passengers? Maybe a software prototype doesn’t have the potential to directly kill anyone (yet), but if we call something a prototype then we should at least treat it as such!

So the company has this "prototype" that became the final thing and there's nothing anyone can do. It's a monster that became very hard to maintain, and the only ones who have the mental context of how it works are the ones who built it. However, instead of allowing the best developers who built it to help on the incremental fix, the company will tend to promote them to a role they are not good at based on their performance on the building of that successful product, not on their performance in the new role.

A company tends to promote developers to do something they are not good at based on their performance on something else

Normally for an experienced software developer the only path to promotion is to management. That's where a developer tends to be promoted after a successful project, and they tend to keep being promoted until they reach a role where they seriously lack skills or are not interested at all. We know, since 1969, that organizations tend to promote individuals to their level of incompetence, but we keep committing the same mistakes over and over again.

An image entitled "Peter Principle". It shows "success" and "advancement" forming a ladder with "success" at the bottom of each step and "advancement" vertically in between. At the top, the bottom of the last step reads "failure" in a highlighted form. The text on the bottom right corner says: "Advancement in position is based on the candidate's performance in his or her previous roles rather than performance in current role".

At the end, those who participated in building the "successful project" will leave for new roles and the new hires will be given the task to fix the remnant mistakes of a project that has grown out of proportions.

Until one day the company comes up with this next “big new project”.

It's a vicious cycle of pain. Companies hire to build something and then hire to fix it. Some companies are aware of that and do it consciously, they hire cheap developers to kick off a project and then hire more experienced developers to fix their mistakes. Would you consider this a legit strategy?

There are projects built under the assumption of “hire to build” and then “hire to fix”

This leads to a trend where experienced developers leave the industry because they are tired of fixing the mistakes of somebody else. Others can't handle it and get angry. Those who stay eventually accept that fixing mistakes will always be part of their job, hoping that someday things will change.

This is a very known problem in the industry. There are many techniques, either for development or for teams, that aim to solve those problems. However, it’s not everyone that knows that and not all teams can apply all of it efficiently. Those who know are expensive and fall into the "hired to fix" group because some companies can only afford the "hire to build" ones.

Now the million dollar question is: what can we do about it?

I can think of 3 potential options that can be applied when creating a prototype without enough resources.

The first one is to create code that is easy to delete. You don't need to know everything, just make sure that the system is built with small parts that can be easily deleted. The prototype may or may not become the final product, but if we build parts of the system in a way that they can be deleted and rewritten easily instead of having to rewrite the whole system, then we will be able to incrementally fix it in an easy way instead of being tied to decisions that have been made when it was still just a "prototype".

The second one is to refrain from building anything based on speculation. This goes hand in hand on accepting and understanding the traps of over-engineering. As developers, we have this urge to build the best we can and try to account for every single condition possible, but most of the time it will just add a lot of complexity for features that have no real value in the context of a "prototype". If there's a chance that other developers will have to change the wheels with the car running, let's have some empathy and not force them to worry about features or code that don't really matter.

The third one is to keep learning and not be afraid to ask for help. This goes hand in hand with continuous improvement. Pair Programming is a very good candidate to help on this, but many people despise it because they do it wrong. Asking for help will make it possible to do the best we can in a project (because the perfect solution doesn’t exist). In a personal level, continuous learning will allow us to grow and eventually we can be able to reduce the amount of developers that are "hired to fix" so that we can all be "hired to build" on top of the great work of the giants before us.

Creating code that is easy to delete, not building to speculation and keep learning are the three things that can be kept in mind if we don't have a lot of resources and know that a prototype has the potential to become the final product

The trend of building a prototype and turn it into the final solution doesn't seem to be something that will fade away soon. Companies will exploit that and hire developers to build the product and then hire developers to fix it. After that, due to the effects of the Peter Principle, the original developers will tend to be promoted to management and stop doing things that they are really good at.

There's definitely something going on in this industry, and hopefully, we can do something about it.

Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook or Github.