How many companies died because of technical debt?
Early stage startup accelerates their development because they need to proof the model and do not spend too much time on the code quality. They needed to show the market traction, growth and pivoted quickly if the hypothesis is wrong.
In the result of this behavior, very often we get unusable solutions, with poor functionality, and this style of doing things very encourage by famous entrepreneurs. Famous quote: "If you are not embarrassed by the first version of your product, you've launched too late." Reid Hoffman, the founder of LinkedIn,
What you will have after one year of rapid product development:
- 1) You pivoted.
- 2) You succeed.
- 3) You do not know.
I think if you pivoted it does not matter what technology you use and what is going on with your code base.
One good example of a real company that existed until 2018.
Raised a few millions of eurs during the good connections in Silicon Valley/Berlin Alley. Hire employees professional people start building the product.
Work hard for two years, did not release anything, but use right methodologies, latest cutting-edge technologies like(GraphQL, Serverless, React, Flutter, etc.). They spent a considerable amount of money on employees happiness (conferences, cold office in the hipster area, other perks).
Still, do not release anything.
Got bankrupted cause not possible to get next round, cause not even a thing was released. Company pivoted. Employees fired reason for insolvency.
Sounds familiar to you right?
One question that I want to raise this story. Do we need that beautiful code architecture and structure, spent months on it if in the end nobody even sees the results?
Almost the same case was described in the book “The Bad Blood: Secrets and Lies in a Silicon Valley Startup”
In another hand, we can go in a dirty way like to follow the success.
Look to the famous examples of technical debt.
"Reddit is another case of bad tech debt. As you know, the website is pretty old - so that time coding standards were far from what we have now. When devs try to implement new features using modern methods of building architecture, the system couldn’t take it. For example, in 2015, they were implementing automated moderation bots, and they didn’t work effectively and missed many inappropriate posts. It was indeed a big scandal - and all because they didn’t catch the problem in time."
You do not know:
You do not know yet that should you pivoted or not or should you continue.
This situation was close to the success topic but with a bit risky. I found a lot of companies in this situation which in the phase of the raised investment for round A.
It is the most critical stage, and the technical debt can put your business down in this stage.
The narrowing problem:
We believed last ten years in an industry that the agile methodology is the panacea of all our problems if you look how many coaches, scrum masters, certified scrum masters, conferences nowadays you will be wondered what all of these people try to solve? Why they are here, and what they are doing?
I want to raise a question. Do the Agile methodology, and business challenges increase the technical debt, or it is just bad architectural decisions?
Let's have a look at the statistics about the reasons of technical debt in a codebase and studies.
As you can see that time pressure is an only third factor. For that reason, I think that the developers should take more responsibilities regarding the fact of technical debt.
I heard a lot of stories about "let's do it quickly, we will rewrite it later anyway". Never. Never it will be rewritten. It will always stay as it is with all legacy crap what have written, then it will come to support mode. Sounds familiar, right?
But what about Agile? I thought you are going to write about the agile methodology and criticized that.
The main question in agile is the reason for technical debt, or is it unprofessionalism of development department? As more, I work with developers as more I see that the problem of technical debt is not about Agile at all. Agile methodology tries to make the process of doing software more predictable and understandable. If more developers try to understand business positions and value what they should bring, not cutting the edges but also not be a perfectionist.
We are as a developer community should change our way to implement things as a quick a dirty way.
Quantity and Quality
“The law of the transformation of quantity into quality and vice versa. For our purpose, we could express this by saying that in nature, in a manner exactly fixed for each individual case, qualitative changes can only occur by the quantitative addition or subtraction of matter or motion”(Engels' Dialectics of Nature)
Before you start to build anything or adding new features to your product, please be sure that your product needs it, because when you make quickly and rushing everything you increase the pressure, and pressure can increase technical debt, no matter do you use agile or not.
I think instead of building a real product in the early stage to check and proof your model you should make MVP dummies(surprise) and test it everywhere is possible.
And after your prototype proof your hypothesize, then start building but build with a proper quality: For that reason, you need to find a balance between code acceleration and delivery on time. You need to to have appropriate style-guides: tools and Good people who can help you in your journey.
These techniques will help you to build a click dummies prototype.
Some methodologies and techniques that can help you.
Be sure that problem exists before you build something for that reason interview as many people as possible.
Assume that we already have a project running.
But this technique can also be beneficial to build a new feature. Sometimes, the business also thinks and assume that the problem exists and the customer wanted to solve it with customer development.
Value proposition Design
Creating compelling products and services customers want to buy. This highly practical concept, paired with its online companion, will teach you the processes and tools you need to create products that sell.
A design sprint is a time-constrained, five-phase process that uses design thinking with the aim of reducing the risk when bringing a new product, service or a feature to the market. More about design sprint you can find here.
In the next part, I would like to talk about building a real working prototype in 5 days. Stay tuned.