This will be a surprise to most developers, but the faster you create code the higher quality you will get (in the end). It's almost impossible to believe in this for the average software developer. However, it's actually got nothing to do with software, but rather how the human brain works. To understand it, let me include you on some science about quality, and how to create high quality software.
20+ years ago some scientists were researching how humans taught themselves to create high quality products. They invited 100 people, divided these into two equal groups, with 50 in each group. They verified that none of the participants had any prior experience with ceramics, and gave these two groups two different tasks.
- Group 1 was to spend 8 hours creating one single ceramic pot
- Group 2 was to spend 8 hours creating as many ceramic pots as they wanted to
After the groups were done, they hired professional ceramic teachers, and had them evaluate the work. The group that had been allowed to create as many pots as they wanted to consistently outperformed the group that was told to create only one pot. Some of the participants that were told to only create one pot, weren't even able to deliver anything at all.
Transforming this to software development implies that the more projects you've participated in, the higher quality you'll be able to deliver over time. Hence, don't try to create "perfect code". In fact, ignore the quality of the code completely initially, and just deliver as fast as you can, as many projects as you can, churning out as much code as you can - And over time, the quality of your software will inevitably soar.
I realised this many years ago myself. As a consequence of my "discovery" I started creating LowCode software development automation systems that automagically created my code. Over time, as I analysed my code, I realised the code was literally perfect. There was literally nothing I could do to improve its quality. Today in Aista, each of us working for Aista can create literally hundreds of software projects per hour each. And we are taking advantage of it as we create software for our clients and partners.
Don't chase quality. Quality is a function of lines of code per second. Increase your LOC count, and quality becomes a natural side effect
In a way, this is the equivalent of applying "machine learning" to your own brain. The reasons are because machine learning is all about the number of iterations. The more iterations a machine based chess algorithm have gone through, the better the machine becomes at playing chess. The paradox is that the human brain works the same way.
As proof of my thesis, realise I wrote this article in 5 minutes. I basically just "plunged my thoughts" into the Markdown editor of DEV, yet still it's probably higher quality than whatever 98% of the world's population would be able to churn out, even if given hours to write. The reasons of course is that I've written thousands of such articles before.
Quality is a function of quantity. The higher the quantity, the higher the quality!
If you want to enable yourself to create thousands of projects per day, like we're able to do, you can follow the white rabbit below ... ;)
Top comments (4)
Great article!
It reminds me of one of my favorite quotes which helped me a lot.
Entrepreneur, billionaire and founder of Telegram and Europe's largest social network Vkontakte, Pavel Durov, said:
Everything can be done quickly. I put together the first version of VKontakte in 2006 in a matter of a month. It began to grow immediately. Contrary to popular belief, work is done either quickly and well or slowly and badly.
After reading that quote I realized that it fits 100% to my own experience. When I have not much time, I focus on the essential things and nothing more. When I spend a lot of time on a project, I keep adding stuff, adding more functionalities, using more technologies. The result: The few essential things are lost within a bunch of unimporting stuff. Simplicity is lost, dependencies to other technologies, complexity everywhere, which leads to bugs, maintaining, long documentation, meetings and discissions how to handle those problems, which wouldn't even be there in the first place if it wasn't for the complexity.
I either finish a project fast with a good result or I spend an outrageous amount of time for a bad result.
Pavel Durov made that observation for Telegram and Vkontakte and for you (Thomas) it's obviously the same. For most of your articles this seems to be a recurring theme:
By the way: I highly recommend those articles!
Wow, you've summed up every single one of my greatest articles in a couple of paragraphs. You really got it ^_^
Thank you, I will share your comment with my colleagues to have them read it. You arguably kept things (even simpler) than I did :D
Interesting pararell at a experimental web project for me: we have decided to run small, fast merge requests.
We trust the developer to not destroy the UI. We get faster to the result the faster we merge. Something broke? Fixed within minutes. We don't even take long for reviews.
On the other side there are developers who don't go this way, sticking for days on one merge request. They just can't follow up, and get behind quickly.
Small, consistent steps seem to work well in our case. Bigger merges get reevaluated and checked if it is possible to split into smaller merges if possible. This way the reviews are not too long, too. Why the extra effort: to learn for the future to structure your code for merges a little better.
End result: we move faster, get faster feedback, deliver faster.
It still is a marathon 😃
Bravo! We're pushing straight to master in aista ... ;)
Of course we can do it, because we have single individual teams, where each of us controls one aspect of the codebase ...
The more process overhead you apply to the project, the slower it goes - And, it does not increase quality either ...
Read "The Mythical Man Month" for a break down of the whys ... ^_^