Code Simplicity

I don’t often dive deep into the philosophical underpinnings of Code Simplicity, but I’ve been realizing more and more that there are a few philosophical principles behind the writings that would be valuable to share. Also, some of these philosophies haven’t been fully formed until I sat with the work for a long time, applied it in a lot of situations, and talked about it with many people. This one–a theory that I have developed over time about how software can be thought of and worked with in the mind–has sort of been percolating with me for quite a while now. It’s time to get at least least part of it out on “paper,” in a blog post. So here you go:

Software is, fundamentally, a solid object that is made of knowledge. It follows all the rules and laws of knowledge. It behaves exactly as knowledge behaves in just about any given situation, except that it’s in concrete form. For example, when software is complex it tends to be mis-used. When software is wrong (i.e., has a bug), it tends to cause harm or problems. When people don’t understand some code, they tend to alter it incorrectly. One could say these things of knowledge just as one could say them of software. Bad data causes people to misbehave; bad code causes computers to misbehave. I’m not saying that computers and people can be compared–I’m saying that software and knowledge can be.

One wishes to have knowledge in a sensible and logical form. Similarly, Continue reading →

Your program is not important to me. I don’t care about its user interface. I don’t care what its name is. I don’t care that you made it, or what version it is.

The only thing I care about is that your program helps me accomplish my purpose. That’s a truly remarkable feat, and if your program does it, you should be proud. There’s no need to make your program take up more of my attention just because you think it’s important.

Now of course, your program important to you! When you work on code for a long time, it’s easy to become attached to it. It was so hard to write. Your cleverness is unbounded, shadowing lesser mortals in the mountain of your intellect. You have overcome some of the greatest mental obstacles man has ever faced. Truly, you must shout this from the tops of every tower, through the streets of every city, and even unto the caves of the Earth.

But don’t. Because your users do not care. Your fellow developers might be interested, but your users are not.

When you’re truly clever, what will show up for users is that program is awesome. It’s so awesome, the user hardly notices it’s there. That is true brilliance.

The worst offenders against this ideal are programs that pop up a window every time my computer starts. I know your software is there. I installed it. You really don’t need to remind me. If my purpose is to start up my computer so I can use it, how is your pop up window helping me accomplish that? It’s not, so get rid of it.

There are smaller ways to cause problems, too, that all revolve around asking for too much time or attention from the user:

• “Users will definitely be okay with clicking through three screens of forms before they can use my product.”
• “I’m sure that users will want to learn all the icons I invented for this program, so taking away the text labels for those icons is fine!”
• “I’m sure it’s okay to stop the user from working by popping up these dialog boxes.”
• “Users will totally want to search through this huge page for a tiny little piece of text so they can click on it.”
• “Why should we make this simpler? That would be a lot of work, and it’s already pretty easy…for me.”

And so on.

The true humility required of a developer is the willingness to remove their identity from the user’s world. Stop telling the user the program is there. Don’t think that the user cares about your program, wants to spend time using its interface, or wants to learn about it. It’s not your program that they care about–it’s their purpose. Help them accomplish that perfectly, and you will have created the perfect program for them.

-Max

Growing and maintaining an open-source community depends essentially on three things:

1. Getting people interested in contributing
2. Removing the barriers to entering the project and contributing
3. Retaining contributors so that they keep contributing

If you can get people interested, then have them actually contribute, and then have them stick around, you have a community. Otherwise, you don’t.

If you are just starting a project or need to improve the community of an existing project, you should address these points in reverse order. If you get people interested in a project before you do the later two steps, then people won’t be able to enter and won’t stick around when they do enter. You won’t actually expand your community. So first, we want to be sure that we can retain both existing and new contributors. Once we’ve done that, then we want to remove the barriers to entry, so that interested people can actually start contributing. Only then do we start worrying about getting people interested.

So let’s talk about how you accomplish each step in reverse order: Continue reading →

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 →