Introduction

TIP

Programming is the art of telling another human what one wants the computer to do. — Donald Knuth

This section of the book is not about development itself, but about what every developer, every designer, every project manager, everyone who is directly part of a software project should know. In fact, even investors should know some of these things. Understanding how a software project goes is more or less like having an idea of how building a house works. I've seen plenty of people involved in these projects asking for an upside-down pool, or to start the project by the roof. It's understandable: software is abstract. We play building houses when we are kids with blocks, and we see how roofs need beams and columns to not crush down. Software is invisible.

On the other hand, heads up: of course this section is a bit opinionated. But it's not about the One True Way To Do It. Because there's no such thing. Instead of trying to find a perfect formula that should be followed as a religion, it tries to point out things that don't work. If I can summarize my experience in one sentence, it's this one:

The Software Failure Equality Principle

Software projects always fail for the same reasons.

It's a dual of Anna Karenina's Principle ("Happy families are all alike; every unhappy family is unhappy in its own way"). It's not easy to repeat success, particularly in business, but it's very easy to repeat failure. This section comes from my own experience working, managing and even just watching, hearing about or watching countless projects, aided by numbers and research from reputable third parties.

What's interesting is that reasons for failure are almost always not technical. They more often have to do with project management, people, expectations, and not the language you picked for your backend. They have to do with treating software as a completely formless thing, not realizing it needs just as much structure as a skyscraper -- or even more, because it's never finished.

In fact, it's perhaps because software is not physical -- even less than a book, because we see printed books -- that people have no idea of what it is like. Your average non developer doesn't even know what it is, much less an idea of size and complexity. People immediately guess the difference between building a small house and a large skyscraper, but they think that building their complex idea of a web app will take two or three weeks, tops.

So, let's spend some time looking at why projects fail, and what we can do to avoid that.