Code Simplicity

How many times have you used a piece of software that was full of incredibly convoluted features, strange decisions, and unusable interfaces? Have you ever wanted to physically or verbally abuse a computer because it just wouldn’t do things right, or you couldn’t figure out how to make it function properly? And how often have you thought, “How could any programmer think this was a sane idea?”

Well if you’ve ever experienced any of those things, your next thought might have been something like “**** this computer” or “**** the silly programmer who made it behave this way”. After all, aren’t programmers and hardware designers to blame for the crazy behavior of the system? Well, yes, to some extent they are. But after being intimately involved in software design for many years, I now have another reaction to poorly-implemented features. Instead of becoming angry with the programmer who implemented the system, I ask myself, “Who was the software designer who authorized this feature?” Who stood by silently and let this feature happen when they had the power to stop it?

Granted, sometimes there is no software designer at all, in which case you’re practically guaranteed to have a broken system. But when there is a software designer, they are ultimately responsible for how the system is put together. Now, quite a bit of this job involves designing the structure of features before they go into the system. But there’s also another part of the job of a software designer–preventing bad ideas from being implemented. In fact, if there’s any lesson I’ve learned from my years in the software industry, it’s this:

The most important word in a software designer’s vocabulary is “no”.

Continue reading →

One of the major goals that I have with researching software design is the hope that we can take people who are “bad programmers” or mediocre programmers and, with some simple education and only a little experience, bring them into being good programmers or great programmers. I want to know–what are the fundamental things you have to teach somebody to make them into a great programmer? What if somebody’s been programming for years and hasn’t gotten any better–how can you help them? What are they missing? So I’ve written quite a bit about that, particularly in some of my recent articles.

However, before somebody can even start on the path of becoming a better software developer, one thing has to be true:

In order to become an excellent programmer, you must first want to become an excellent programmer. No amount of training will turn somebody who does not want to be excellent into an excellent programmer.

If you are a person who is passionate about software development–or even just somebody who likes being good at their job–it may be hard to understand the viewpoint of somebody who simply doesn’t want to get any better. Continue reading →

So, there’s a lot of talk on the Internet about privacy. Some people say that privacy is only desired by those who have something to hide. Some people insist that privacy is a human right that should never be violated without consent.

There’s only one problem with this whole debate: what is privacy, and why would anybody want it? This is rarely defined–most people just seem to assume that “everybody knows” that privacy is, so why would it have to be explained?

Well, I’m not a big fan of “everybody knows.” And in fact, it turns out that privacy actually means two different things, which many people use interchangeably without specifying what they’re actually talking about. So to help clear up some of the debate online, and to hopefully shed some light on how it can all be resolved, here are some clear definitions and discussions of what privacy is, and why people would want it.

Privacy of Space

The first type of privacy is “privacy of space”. Continue reading →

A long time ago, I wrote an essay called “Why Computers Suck” (it was given the title “Computers” and “What’s Wrong With Computers” in two later revisions, and the original title never saw the light of day). The article was fairly long, but it basically came down to the idea that computers suck because programmers create crazy complicated stuff that nobody else can understand, and complexity builds on complexity until every aspect of a program becomes unmanageable.

What I didn’t know at the time was why programmers did this. It was obvious that they did do it, but why would the software development industry produce so many crazy, complex masses of unreadable code? Why did it keep happening, even when developers should have learned their lesson after their first bad experience? What was it that made programmers not just make bad code, but keep on making bad code?

Well, this was a mystery, but I didn’t worry too much about it at first. Just the revelation that “bad programs are caused entirely by bad programmers”, as simple and obvious as it may seem, was enough to fuel an entire investigation and study into the field of programming, one which had some pretty good results (that’s mostly what I’ve written about on this blog, and it’s also the subject of a book that’s in development). The problem had been defined (bad programmers who create complexity), it seemingly had a solution (describe laws of software design that would prevent this), and that was enough for me.

But it still baffled me that the world’s universities, technical schools, and training programs could turn out such terrible programmers, even with all of the decades of advancement in software development techniques. Sure, a lot of the principles of software design hadn’t been codified, but a lot of good advice was floating around, a lot of it very common. Even if people hadn’t gone to school, didn’t they read any of this advice?

Well, the truth was beyond my imagination, and it took almost five years of working on the Bugzilla Project with a vast number of separate contributors until one day I suddenly realized an appalling fact:

The vast majority (90% or more) of programmers have absolutely no idea what they are doing.

Continue reading →

Before all the laws of software, before the purpose of software, before the science of software design itself, there is a singular fact that determines the success or failure of a software developer. This fact makes the difference between the senior engineer who can seem to pick up new languages in a day and the junior developer who struggles for ten years just to get a paycheck, programming other people’s designs and never improving enough to get a promotion. It differentiates the poor programmers from the good ones, the good programmers from the great ones, and the great ones from the “rockstar” programmers who have founded whole multi-billion dollar empires on their skill.

It’s not anything complicated, and it’s not something that’s hard to know. It’s not something that you can only do if you’re born with a special talent or a “magical ability to program well.” There is nothing about the nature of the individual that determines whether or not they will become an excellent programmer or a poor one.

There is only one, singular fact:

The better you understand what you are doing, the better you will do it.

Continue reading →

The attitude that every engineer should have, in every field of engineering, is:

I can solve this problem the right way.

Continue reading →

So, after my last post, a few people asked, “Okay, but how do you figure out what sucks?”

Continue reading →

When I started working on Bugzilla in 2004, it was a difficult time for the whole project. There were tremendous problems with the code, we hadn’t gotten a major release out in two years, and a lot of the main developers had left to go do paid work.

But eventually, thanks to a bunch of new members in the Bugzilla community, we released Bugzilla 2.18. Hooray! Bells rang, birds sang, and there was much rejoicing.

However, in the space between Bugzilla 2.16 (which was before my time) and Bugzilla 2.18 (which was the first release that I helped get out), something very strange happened–we developed serious competition. All of the sudden there were a bunch of new bug-tracking systems, some of them open-source and some of them not, that people were actually using.

At first it wasn’t too worrisome. Bugzilla was pretty dominant in its field, and it’s hard to lose that kind of position. But as time went on, there was more and more competition, and some people were predicting doom and gloom for Bugzilla. We were a tiny group of completely unpaid volunteers, and some of these competing products were being made by companies whose marketing and development resources absolutely dwarfed us.

And yet, with every release, our download numbers kept going up. And always significantly–30-50% more than the previous release, every time.

And then we hit Bugzilla 3.0, and our download numbers nearly doubled. And they’ve kept going up with every release from there. Nowadays we get over 10 times the number of downloads per release that we did in 2004.

So how did we pull this off? Well, as far as I can tell:

All you have to do to succeed in software is to consistently suck less with every release.

Continue reading →