Writing code isn’t the bottleneck

What is the birthdate of the last framework you’re working with? Why have you chosen it? Did you choose it?
I feel more and more puzzled by the state of our industry, and how we’re used to deal with the fact that we suck at building software. I think a part of it might be due to a feeling that the problem is how fast we can build software. Spoiler alert: writing code isn’t the bottleneck.

Why frameworks exist?

They usually promise you to avoid writing tons of “boiler plate” code. This code that has absolutely no value to your business, but still is not optional to make your system work in production.
In other words, frameworks are here to “increase” your productivity by gaining time to write code that matters for your business.
What frameworks usually forget to tell you is that the time you’ll get by avoiding boiler plate code will mostly be used to understand and configure the framework. No pain no gain, right?

A pact with the devil.

But the worst part of it is not that it will take you time to configure. It’s that you are now highly dependent of a framework. It matters because frameworks are opinionated. They are here to solve problems, but the way they solve them might not be exactly what you need on your project. And to be fair, I’ve seen this many times: in the end you’ll burn 95% of your energy trying to make the business fit your framework, instead of building a software fitting your business.

Do you want to understand problems or solutions?

And let me add this important point: you should never use a framework if you don’t understand all the problems it’s solving. By building your expertise over a framework, you are building your expertise on a solution. And if you do not understand the problems, you are an imposter, because bringing a solution is not enough to be a software professional. You have to understand and challenge the problems.

Writing code isn’t the bottleneck.

Believe it or not, writing code is cheap. The cost is in maintenance and communication. Thus all efforts made in order to deliver features faster are false friends when they increase the burden in maintenance and/or communication. The real challenge is to keep the code easy to change.

Writing code isn’t the bottleneck.

 

The Design of Everyday Things

Do you know a job hard to explain, hard to do and usually underestimate? Of course, I’m talking about the job of designer 😊
What do I know about it? Almost nothing, like anybody after reading a book. This book is the bible in this area: the design of everyday things, by Don Norman. Let me share with you a short feedback about it.

The design of everyday software?

As Scott said, like for any topic, “When you’re outside an area of expertise looking in, it can often seem monolithic and uniform, but when you’re an insider you quickly realize that there are many different subcommunities, each with different specialties and different approaches.”
I tend to oversimplify the job of designers, mainly because I lack knowledge about it. And this book helped me to understand something really important: building Software is Design, and we have tons of things to learn from their practices. And to be fair, people like Johan Martinsson and Alex Bolboaca have already talk and share a lot about this.
Basically, you can replace almost everywhere in the book “Designer” by “Developer,” and it still makes sense.

It resonates a lot with my daily work

This book is well written and a pleasure to read. It starts by talking about psychology, then about the fallacy of accusing the user before accusing the design. In other words, “Read The Fucking Manual” is not an acceptable answer, because who read the manual? People that are not able to use your product the first time, and still are forced to use it. When was the last time that you read the user manual from your phone or any online application, you’re using?
The assumption that a good design can remove the very risk of errors is absolutely powerful, both in design and software.
The end of the book talks about the (hard) collaboration with the marketing to build a product, and I’m sure it would remind you many anecdotes as well!

Go read it

This book is a reference in the design world but should be as much a reference in the software world. If you haven’t done it already, you can add it on your list of books to read!