Disclaimer: This is a fiction story from a great guy here at hung.dev. Because it’s too real to me so I have to translate an English version in case of… you know why.
Disclaimer#2: I do not own the images and the memes.
From the idea of Uncle Bob in a series of Clean Code
The beginning: Forming an All-Stars team
Imagine you are a talented programmer with several years of experience. Your company decided to build a complex but fascinating and challenging product that was expected to deliver outstanding success for the company in the future. The team of 5 best engineers in the company, including you, were selected to build this product.
It’s great to be working on a brand new project. Everything would be made fresh from scratch. Star Team (short for a selected team of 5) will be able to apply the latest and hottest technologies to this new project. They experiment, then choose a stack they thought was the best and most reasonable for the company: fast performance, fast development speed, lots of documentation available, and good support community. And. Boom. All-Star Team’s productivity was exceptionally high, to the moon 🚀 🌖.
The first Monday morning after the kickoff meeting about the product development plan was. The first feature All-Stars Team would do was the Authentication feature. Usually, a feature like this will take the team 3 to 4 days to complete. But, Star Team delivered the feature right…** 4 pm that day**. PM didn’t believe it. The CTO didn’t believe it. The CEO didn’t believe it. And the members of the Star Team themselves did not believe it. How could that be true? Fortunately, it is valid with a perfect stack used and backed by giant technology giants like Google and Facebook plus implemented by a stallion team. Productivity is now even faster than the speed of a dev googling StackOverflow!
A month later, this continued and showed no sign of stopping. The features were released one after another. The most extended feature only took two days to complete. The product’s primary function has been able to work relatively well to offer, even though many customers had spent money to buy the product and been ready to use it while it is still in the alpha version.
Everything went very smoothly. Engineers were delighted because their work productivity went up to the ninth cloud. The management team was happy because more and more customers were buying the product. Contracts on more and more, the requirements for adding more features also increased, they also gave feedback on old features to suit the needs better. Money returns, managers, and engineers all get a raise and bonus. With feature requests and feedback at the current speed of development like a 🚀, the team did not worry about lack of work, and the product was becoming more and more perfect and had more customers. A bright future opened up for the entire Star Team and board team. Star Team worked harder, updated, learned, and applied new things to the project. With great confidence, the manager met and made an extremely detailed Business Plan for the next six months.
Hold your horses. It seems that something is not right here. But no one has found out yet.
In the second month, things were more stable. The growth rate was not as “crazy” as in the first month. On average, Star Team shipped a new feature in 2 to 3 days. It’s not as fast as the first month, but it’s still a super-fast pace. They still had new customers who bought the product this month.
In the third month, with the number of B2B customers and B2C increased significantly, the feedback on built features and user feature requests increased dramatically. On the other side, Star Team had a lot of work to do with the features in the pre-existing roadmap. The average shipping speed of the feature was about four days. That month, things were still going well for both Star and the management teams. They were meeting about why it took longer to ship a feature than in previous months. And they gave several reasons:
-
Since the initial features are relatively simple, mostly MVP (Minimum Viable Product), development is quite fast.
-
The system already has a framework, so putting new features together takes more time than just putting together a blank page. This is also natural—nothing to worry about.
-
For the features requested by the customer, bug fixing at this time is more complicated than the first time, so it is natural to do it longer.
-
At first, because they wanted to bring the product out as quickly as possible, Star Team volunteered a lot to OT to avoid the competition from losing customers, so it was easy to understand the code soon. Now that you have a ready-to-pay customer base, there’s no need for that.
The above reasons, in general, are all objective causes that a product will have to encounter when it grows up. The whole team agreed there was no problem.
The turning point
But the turning point of the story lies in the seventh month. When Star Team delivered feature X takes up to 2 weeks, while in the roadmap of Manager Team, it was only one week. The manager Team broke a promise to a B2B client, causing them to cancel the contract. Star Team and Manager Team had a meeting about the issue of productivity not being as expected and not as fast as the first month. But Star Team explained that the system was more complex, so it took more time to integrate the new feature.
In the months that followed, the same thing happened a few times. The time in the Business Plan and the actual development time was growing significantly. It’s a Scary Gap.
By the 9th month, feature development time continues to increase. Star Team meets with Manager Team to find a solution. And they decided on an option, that is: hire more engineers.
In the 10th month, five carefully selected new engineers joined the team, bringing a great hope that work productivity would double. However, in the 10th month, work productivity was a bit decreased. But that is understandable, as Star Team took quite a long time to interview candidates. And after you’re new to work, you need time to onboard, and the current Star Team members guide the new guys.
In the 11th month, the new friends got used to the code base structure and convention, and the team’s productivity returned to the same as the 9th month.
By December, work productivity has also increased. The 13th and 14th months’ productivity was still the same as the 12th. The manager Team didn’t understand why. Work productivity should have doubled (10 = 5x2). Only the engineer team understands because they know that there is a theorem.
A task for one engineer finishes in 1 day, then 2 engineers will complete it in 2 days.
Someone on the internet —
The board members gradually accepted that the engineering team was twice as large, but the productivity increased only 1.3 times 😂. Of course, they were unhappy because the salary fund was expanding, and their expectations were unmet. They continued to hire five more engineers, but the productivity immediately after hiring more workers decreased and increased gradually after one month. It peaked at 1.8 times compared to the original (expected 15 people will increase their productivity). capacity 3 times)
In the 15th month, the company turned to develop this product only.
So it’s been 1.5 years since the company decided to build the product. The system was already quite complex and extensive. The productivity was decreasing day by day. A meeting was held to resolve this issue. Hiring more workers did not seem feasible because of its proven inefficiencies in the past. And after an afternoon of brainstorming, the whole engineer team came to a common solution, which is:
Start from scratch
The management team was very unhappy, but they had no choice but to keep the current system with poor productivity. Even though the engineering team was not lazy, they took care and worked very hard on the other side. But the system was too big, with too much special and hidden logic to please all customers, and no one dared to delete it. It’s much harder to remove than to add; saying “NO” is too difficult.
Features rushed to meet deadlines are full of technical debt with the promise: “will fix later” or “Fix it when you’re free.” A massive legacy architecture made it impossible for an engineer to ship/release a feature even if he works 8–10 hours a day.
The business plan still had to continue. The manager Team couldn’t tell customers to wait a few months, and we would have a completely new, better, faster system for them to use (actually their customers didn’t care what the new system does, as long as they had a stable, usable product). Adding features and fixing bugs still had to happen on the old system. And building a new system, approved, but only with 5 original members of Star Team, because they are the most experienced, let’s call them Tiger Team. The rest of us continue to work on the old code base with a particular appetite.
Tiger Team found a new stack, better than the current stack in every way. They started implementing the new system. Work productivity is extremely fast as before. But an existing problem is: “What are the requirements?”. There is no specific document about the requirements in the current system. It is sporadic, scattered in tickets, public and private chats on Skype, and Slack between PM and engineer. It’s even from PM’s mouth to the engineer’s ear. At the time of development, there were engineers, PMs and heaven knew what that feature was. Now only heaven knows exactly what the requirement is. However, there was still a single place that contained all the requirements in the past, which is the old code base. Tiger Team rummaged through the code base to re-read the old logic, sometimes copying the whole logic of a 2-page function, only changing the programming language.
But the story does not stop there. Since bug fixes and new features were constantly being added to the old system, the new system also needed those. Now, a new race began.
And that race went on for 2 years. On the release date of the new version, shut down the old version, the whole company gathered at the boss’s house, held a party to celebrate, determined to not get drunk and not return, even drunk could not return. And then at 2am, calls from Customer Support kept coming to the whole team because of the major problems that customers complained about when they switched to the new system. Ghost programmers are still out of breath, so they had to hotfix, patch errors, and find out the logic on the old system, they hadn’t passed the new system. They deployed right at 3am, then fall back into a dream at any time…
Over the next few days, the same thing happened. Manager Team has decided to rebuild the old system and will maintain both versions simultaneously for a while longer, and customers will have the right to choose the old or new version to use. New version is recommended, even offered an incentive to use the new version. A bunch of new engineers were hired to develop both versions at the same time.
After 4 months, the new system also began to expand, productivity gradually decreased, a loop appeared.
8 months later the company closed!
Open for discussion
Does the reader find this story familiar? I’m sure that if you work long enough in the tech industry, you’ll find companies that have problems like this, then come up with solutions like this, and have the same problems. like this in terms of finance, personnel, productivity, and eventually even closing.
So in short, what is the cause of the company’s failure on it?
First of all, that’s bad code. Bad code has led to the system being too cumbersome, complex, and not reliable. The movement is broken here and there, no one dares to fix it. Looking at a piece of code that is clearly no longer used, but the first time it was deleted, the app died, the customer wailed. The second time it was deleted, the logic went wrong, the customer cursed, the manager yelled. Third time, oh no third time. Because the third time the engineer was too scared to delete a piece of code that “seems to be unused”. They always find ways to avoid having to touch confusing code or redundant code. And instead of fixing bad code, the team is afraid of bad code, and hopes the bad code will go away when building a whole new system. But in fact, the team still copied a lot of old, “dirty” logic from the old system to the new system. And the increased productivity when starting a new system gives us the illusion that “breaking and rebuilding” will solve all problems.
Secondly, the PO/board team was too greedy. They are the hoarders, always wanting to take it all but not letting go. It’s like when you clean your house but keep regretting an item, afraid you’ll need it later, don’t dare to throw it away, but in fact, never use it. Plus constantly buying new items. As a result, your house is filled with unnecessary items and you can’t step out of the house anymore. Then everything collapses, just like that.
The trade-off between software quality, and accepting technical debt (Technical Debt) in exchange for faster product release times also played an important role in the failure of the above company.
So what’s the solution?
You cannot deal with a mess by running from it. The only way to effectively deal with that mess is to turn around and face it, find the rot and clean it.
Also, you need to have a clear plan and scope of what you’re going to build. Learn to let go of things, as a very famous giant purple philosophy/general said
Running away from dirty code is not the right way to go. If you have debt, you have to pay it and live as beautiful as Tchaikovsky’s swans. Technical debt is similar to bank debt. Bank debt if you hesitate to pay, sooner or later you will be taken home. If technical debt is not paid, sooner or later the company will be taken away.
Conclusion
In short, it is very important to have clean code in an industrial environment. But it is also quite difficult, especially with the current super-fast software development rate. The difference in thinking of software engineers and product management teams is also a big barrier that makes implementing clean code more difficult. Every engineer not only needs to equip himself with solid programming skills but also needs to equip himself with clean programming skills. And technology managers should also equip themselves with knowledge about the technologies in use, aware of the importance of a clean system so that in addition to developing many fast features, they also improve product quality. products over time. A feature that is developed quickly does not mean good quality and in the future, the feature will not work anymore.
Thank you for reading. In the next article, I will discuss why code that has been kept for a long time “stinks” or is “out of date”. Please look forward to the next articles in the series of articles about the Clean Code.