I’ve been meaning to write out my philosophy of software development for a while now. Over the years I’ve watched developers struggle to find solid ground when stuck in design, development, and debugging. They get stuck in what they believe about problems, and the related knowledge that would help them. And when they don’t believe that something can be solved, they make make it harder to find the paths that would get them there.

So if you find yourself swearing at your compiler, computer, or sacrificing chickens to solve difficult problems, then you’re missing a fundamental part of the reality of software: problems are simple once you believe that they are, and once you learn approach them objectively.

The laws (simplified for the impatient)

You (and I) suck. Plan for it. Expect it. Get over it.

It’s a humility thing. Be open to the possibilities, including you’re own fallibility.

The laws (extended mix)

1. Every problem can be solved, and most are solved already. Solid ground exists, it can be found, it has been found, and it’s usually easy to find. If you don’t believe that a difficult problem can be solved, then you’re missing something. Step back and look for possibilities, and test each theory carefully.
2. There aren’t just possibilities, there are many great possibilities. If you can’t see more than one way to approach a problem, then you’re not looking hard enough. If you can’t see any possibilities, then you need to know that you are wrong. There are always possibilities.
3. Software and hardware are deterministic. Have you found a problem that appears to be intermittent or flaky? Relax, you just haven’t discovered the cause or understood the underlying mechanism yet. Focus your tests, and look for a simple, plausible explanation: it’s there. If you think you’ve found something non-deterministic, then expect that you’re wrong and keep looking for answers.
4. It’s your fault, until it isn’t. Have you found a compiler bug, a CPU flaw, or a library issue? You’re probably wrong. It’s not that it doesn’t happen, it just doesn’t happen very often. Be absolutely certain before you’re willing to believe that it’s not your fault. It’s much more likely to misunderstand syntax, usage, side-effects, and such, than it is for well-vetted tools to be broken. If you can’t prove it, then you don’t understand it well enough.
5. Study history, as it’s almost always smarter than you are. There’s a whole universe of thinking that exists outside of your head. Until you realize this, you’re going to bang your head needlessly. Don’t be stupid: look around you, and know that many people are intelligent. If you believe that everyone is an idiot, then you really only know yourself.
6. Your intuition isn’t as good as you think it is. Or as a friend says, “Always, always measure, ” and “Do the arithmetic.” Even when you’re sure that something is true, it’s doesn’t mean anything until it’s proven. Test it. Measure it. And make sure you’re looking at it in isolation of other changes. If you fix it by chance, then you’ve lost a critical piece of learning. Go back and figure out what the underlying truth was, or it will bite you again and again.
7. Your code isn’t as good as you think it is. No, really, it isn’t. Neither is mine. And that’s just the way it is. Learn to accept your flaws, and the experiences of others. And if you think you’re the best developer on your team, you’re wrong. The best developer is the one who realizes that they’re not the best.
8. Leave yourself a trail. When you hit a particularly sticky problem, write down the possibilities and record your progress. If you try to do it all in your head, you’ll get lost. And sometimes the act of writing it down (or talking it out) will uncover the path, or at least uncover new possibilities. But mostly, writing it down will save you from wandering around in circles.
9. RTFM. No really, read it. If you can’t solve a problem, and you haven’t read THE FUCKING MANUAL, then you don’t deserve to solve the problem in the first place. Newsgroups, forums, and wikis can help too. And if you’re stuck and not thinking, testing or reading, then you’ll stay stuck. And as likely as you’re wrong about something, TFM can be wrong too, so test what you learn carefully.
10. And finally, Just f@ck!ng do it. Are you stuck in development because there’s something you don’t understand? You need to attack the problem and get it over with. There’s only so much to learn about any given problem, and it doesn’t happen any faster when you avoid it. Take small steps. Measure, test, learn, ask questions. You’ll find the solution more quickly when you stop wasting time throwing chairs.

Remember, if you don’t come to understand why things work the way the do (and how things often break), then you will run into the same problems over and over again. It’s always worth the time to figure out the fundamental truths in what we do: it will save time and prevent future pain.

It’s difficult to pick a development stack on Windows. Is Windows development falling into the minority?

For what it’s worth, I prefer C++/QT/Boost/STL on Windows, despite the cost and complexity. C# was disappointing, based on having to deploy the runtime with the application (and lack of portability). Python + QT sound enticing, but really I’m looking forward to Webkit/PHP/Apache.

I noticed an interesting side effect of the iPod’s mass storage tonight: I pay far less attention to each album than I used to. I was wandering through my CD shelves when I realized how many great albums I have that I never listen to. I either shuffle past them, listen to my algorithmically perfect playlists, or obsessively listen to my newest purchases. The real-life metaphors like cover flow are a shitty mirror of the real world, and I don’t find them as inspiring as browsing the real thing.

Storage on my PC has bloated in the same way. I have more than a terabyte now with more than 5 years of digital photos, 15 years of source code, and hundreds of other projects. Sometimes it’s just too much damned stuff. Not only is there too much stuff, the ways to browse it all really suck.

Maybe it’s just a matter of despising accumulation, or perhaps I need to learn to browse the stuff better, but I wonder if storing it all digitally devalues the quality of all of it all. What happens when our DVD collections fit on our iPods? And all of our books? I don’t doubt that it happens, but browsing it all will be a very different experience than what we have now.

Not that browsing in the real world is perfect either. Where is that damned CD, did I lend it out? It’s got to be here somewhere … Things get lost, or they end up out of order, or the shear size of the stuff makes it impossible to traverse. And relating physical objects is difficult, so learning more about each thing requires real work.

But somewhere between losing the identity of the individual things and gaining the ability to relate them better, there has to be a better way. I’ll miss my shelves of CDs and books, where i can quietly browse and appreciate each work. On the other hand, I’d love the ability to jump to Wikipedia from my CD shelf, but I can’t easily do that yet from my iPod (and I’m pretty sure Apple doesn’t wants me to).¹ Will software ever solve the problem well?

1. Because Apple wants me to go to their store ↩

Will Shipley talks about hype, product sluts, advertising, and licensing in his funny, smart way. Worth watching if you plan to release software, ever. I normally don’t post things from Daring Fireball (most people here read him already), but this talk is totally worth the 1.5 hours.

It’s here. VOIP for the iPod touch. Sweet.

Oh, and there’s some news on the new iPhone 1.13 firmware.¹

1. Thanks John ↩

Yes, that’s right, Siemens forks Perl to remove features that their engineers don’t like. via DF

Midori is a Webkit-based browser for Gnome. It’s new, and the artwork is a bit weird, but it means that other Webkit-esque browsers are coming. Yay.

It’s been a few weeks since I booted to my XP partition at home. So when I boot this morning, every single application¹ informs me that it has an update, forcing me to stop everything I’m doing to wait for the downloads and required reboots. It only took 20 minutes, but boy did it take the wind out of my morning productivity.²

Updates impose on your users. When will we get that? We push so many things on the people using our software, without really considering what they want. We argue for the user, with a facade of our own ego, not really knowing or caring what they want (but readily supporting our own viewpoints). Today software sucks.

1. Updates included: Windows update, Trillian, Cygwin (via E), E, and iTunes … bah! ↩
2. Especially annoying was Windows XP, who asked me 3 times if I wanted to reboot ↩

I don’t normally link to 37Signals¹, but this lecture is worth watching. It’s one of the first inspiring lectures on business that I feel good about: it’s sharp, honest, and highly critical of the status quo. Even if you don’t agree with all of it, it should nudge you to think more realistically about the business of software.

1. You already read their feed, don’t you? ↩

Fog Creek’s new sites slide into the painful state of design by “a committee of tasteless slobs,” a condition to be aware of, and run screaming from when encountered. The Fog Creek guys started over again, gaining sanity and a cleaner, honest design.