Let’s build better products.
By Rob van der Leek.
Pick your favorite product… have something in mind?
I’m pretty sure the product you have in mind is not a software product. Perhaps you picked your phone, a loyal daily companion that became an indispensable part of your life. Perhaps you picked your backpack or your favorite pair of running shoes, both still going strong after years of heavy use. Or maybe you picked a drink or food product, just because you’re reading this article around lunch time.
Whatever you picked, I bet it wasn’t your mobile banking app. Or the app you used this morning to check the weather forecast. Or the website you visited yesterday to book that hotel in Berlin.
And that’s strange.
Digital products, software products, are playing an increasingly important role in our lives. They are also becoming an increasingly bigger part of our monthly budget. Think about the paid app you use to track your sporting activities, or your cloud storage subscription, or the website you use to order Tuesday evening Thai food.
A reason digital products are not top of mind when we think about great products — products we love — is that we seldom value their quality when they work as advertised. We do, however, immediately notice the lack of quality when they don’t. Because your running shoes still feel comfortable after years of heavy use it makes you appreciate their durability. When checking in for a flight took you half an hour instead of minutes because the site was annoyingly sluggish, that makes you want to scream about how it #fails on Twitter.
Writing a computer program to automate a task is easy. Building a software product, a great product that users will love, is hard. Extremely hard. And figuring out if you’re doing one or the other is not easy since both activities involve developers writing code.
Except building a great product involves much more than writing code. Besides the challenge to provide your users the right type of functionality, you want to build a product that’s secure, reliable, intuitive and fast. And that list is not extensive, just wait until your product becomes a modest success to see it grow (integrations? analytics? multiple platforms?).
And that’s why truly great software products are not built by great developers. Great software products are built by great development teams. You want your users to talk about that snappy, clean user-interface? Better have that UX miracle worker on the team. You want your users to be amazed by the speed and stability of your application? Better have that experienced back-end engineer on board.
The way that team organizes itself, the processes it follows, the tools and technologies it uses. Eventually these factors enable development teams to produce great products.
But there’s a problem here. Great software products are the result of development done by great teams, but how can you tell if your team is great while you are still building the product? We’ve seen great developers working in teams that build not-so-great software. Also, great teams don’t grow on trees, it usually takes a while for a team to become great.
If you want to build great digital products it’s all about the quality of the team and the quality of the product.
And when it comes to the product, all software products, great and not-so-great, share one similarity: they are built from code. A great development team produces great code, just like a great R&D team designed your favorite pair of running shoes. Code is the single most important output of a development team. It’s the logic that defines the behavior of the product. But code can vary in quality. There’s low quality code and high quality code, and that difference can be measured, not only when the product is finished but also while it’s being built.
Building a great software product is hard but it’s certainly not a matter of sheer luck. Building great software products is something you can, to a large extent, control.
Having seen billions of lines of code in almost all programming languages used in the world, we’ve seen examples of great engineering achievements and examples of not-so-great engineering achievements. From that experience we learned two important things when it comes to software quality. First, we learned what things matter most. Second, we learned what level of quality great teams can achieve.
With this knowledge we developed our Better Code program. The Better Code program helps you to get one (1) aspect of product quality right: maintainability (that is, is your software easy to understand and simple to change). This may not look like much, it tells little about if your software is secure, or fast, or reliable, but we’ve experienced over and over again that maintainability is an enabler for all other quality aspects. If your code is maintainable, getting it secure is possible. If your code is unmaintainable (that is, hard to understand and difficult to change), getting it secure is, well, sheer luck.
Better Code is a way of working. A way of working that great development teams master and apply every day. For Better Code we have selected the 10 most important best practices, we call them guidelines, when it comes to maintainability. Based on an industry benchmark filled with over 8 billion lines of code we can rate if the code a team writes is compliant to how great teams write it.
To get you started writing Better Code we have a book, a training, and an industry certification program. But more importantly we have Better Code Hub. Better Code Hub supports a team in applying the Better Code principles in the development process.
Writing better code is a matter of consistently applying the 10 guidelines, all the time (because, really, every commit counts). This sounds deceptively simple, and in a way it is, but it’s certainly not easy. Adopting this way of working, with the whole development team, will take some time and effort (because, yes, writing maintainable, elegant code is hard). But in time we are confident this way of working becomes a second nature and a core team value.
And the reward of writing Better Code is a multi, no magnitude of all the effort you put into it. Because a development team that performs like a great development team will build a great product. A product your users in time will love and remember!
This blog was also published on Medium by Rob van der Leek