San Francisco, California

Why Software is Slow and Shitty

Although I’ve argued before that software development is suffering from extreme mismanagement, I hadn’t thought much about how the structure of a company plays into the quality of the software; the way tasks are filtered down to underlings, the way that decisions are made, the thick layer of mismanagement in between. So I was surprised to find myself nodding along to this blog post over the weekend about why software is almost universally bad (and I will gently place the majority of websites into this bucket, too). But here’s the kicker: most companies are simply not structured properly to make good software in the first place.

Huh!

The author references Super Mario 64 as an example of great software and the reason why the game was so damn good wasn’t luck—it was because they structured the company to make a good videogame:

You might think that Mario 64 was built with tickets and sprints, but, according to interviews, there was no master plan, only the principles that the game should feel good and be fun. They started with just Mario in a small room, and tuned his animations and physics until he felt nice and responsive. After that, the levels were also created as they went, with the designers, developers, and director going back and forth using sketches and prototypes.

My own time in a Silicon Valley startup has proved this much to be true; planning doesn’t make for better software. In fact today our design systems team doesn’t have sprints, we don’t have tickets or a daily standup. Each day we come to work, figure out what’s the most important thing that we could be doing, and then we—gasp!—actually do it. We have one meeting a week but we constantly talk about our work together like detectives solving a crime.

No one gives us work to do, we independently solve problems at a blistering pace, and without an added layer of bullshit planning on top it’s become the greatest work I’ve contributed to in my career so far. (Of course our team is not perfect but we correct things incredibly quickly when we notice something going off the rails and that to me is what I love the most.)

But watching so many other teams slowly flail about whilst they plan for quarter 3.2 of subplan A, whilst our team produces more work in a week than they all do combined in a quarter has been shocking to me. I now know that most companies are not organized for employees to do great work. Companies are organized in the way that they are so that managers can hide in the system, so that responsibility for tough decisions can be delegated, so that no-one can be blamed for royally fucking things up.

The software is hardly taken into consideration.

After four years of working in a large startup, I know what I always assumed was true: you don’t need a plan to make a beautiful thing. You really don’t. In fact, there’s a point where overplanning can be a signal of inexperience and fear and bullshit. The scrum board and the sprints and the inane meetings each and every day are not how you build another Super Mario 64.

Instead all you have to do is hire smart people, trust them to do their best work, and then get the hell out of their way.