DEV Community

Cover image for How to create high quality software
Thomas Hansen
Thomas Hansen

Posted on • Updated on • Originally published at

How to create high quality software

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.

  1. Group 1 was to spend 8 hours creating one single ceramic pot
  2. 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)

slag88 profile image
Alexander Becker • Edited

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:

  • OOP a software development mass psychosis (key idea for me: bad thing, because encapsulation results in unnecessary complexity)
  • Over engineering is the root of all evil (quote: "All of the failed projects I have seen have one thing in common; Over engineering")
  • Algorithms and Data Structures are irrelevant ("Why would you need to know the difference between Binary Trees and B-Trees?")
  • Software development is DEAD SIMPLE!! ("Software development is difficult" has been repeated so often that everyone started believing it which lead to a self fulfilling prophecy)
  • The 10x software developer (always asks himself "What is the simplest possible thing that solves this problem?")
  • Adding more devs to your project makes it slower ("The more people you add to the same project, the more 'project overhead' you acquire, until you reach the point where nothing can be done, because your employees spends all their time simply planning how to do things, to avoid messing up somebody else's job as a consequence of doing their own job.")
  • Lada is better than Ferrari (Lada does exactly what it should, while Ferrari quickly becomes a liability)
  • Go from Junior to Senior developer in a couple of hours ("Being a senior software developer is not about what you do or know, it’s about what you do NOT do and what you do NOT care about"... most things are simply not essential)
  • What is pure CRUD? ("The dirty little secret of our industry is that the simpler you keep things, the more you can expand upon it, and the better the end result becomes")

By the way: I highly recommend those articles!

polterguy profile image
Thomas Hansen

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

damian_cyrus profile image
Damian Cyrus

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 😃

polterguy profile image
Thomas Hansen

We don't even take long for reviews

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 ...

sticking for days on one merge request

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 ... ^_^