About 12 years.
12 years ago I bought a new computer with 3GB of hard drive space (yes, just three). Today, the average new computer has about 3GB of RAM. It took 12 years to convert all that disk space to RAM.
If this pattern holds, then by the year 2021 we should have computers with about 500GB of RAM.
Awesome.
Today in Windows XP, I double clicked on a scanner icon under “My Computer” after installing a new scanner. Here’s the dialog that popped up:
A few gripes worth considering:
How many more years am I going to have to wait before I get a Linux desktop that doesn’t look like it was cobbled together?
Before I rant about the Fedora 11 user interface, I have to say that I am a huge fan of Linux. I write code for Linux all day at work (both user interface and back-end code), and I love it. Linux is great. However, the Linux desktop has not kept up with the quality of its back-end counterpart, and I want to talk about it today. Thanks for reading.
I installed Fedora 11 today, the latest and greatest that the Linux community has to offer. I opted to use the KDE version just for fun. Here’s what I got:
When I logged in for the first time, my fonts were too large, so I opened the “System Settings” (by the way, that name is way too scary for lay users) and navigated to the fonts section. This is what I saw:
First of all, I have to change the font size 8 times. Why? Because I don’t know what each of those 8 settings means, and I want to make sure I get them all. Why do I have a “Menu”, a “Toolbar”, and a “Small” font? If you’re going to give this much fine grained control, you have to at least show screenshots of where each of these fonts shows up on the screen. Your average user does not know the difference between a “Menu” and a “Toolbar”.
Secondly, this font preferences screen has at least 4 different fonts on it that I can see. How’s that for ironic?
KDE seems to be trying to emulate Mac OS X and Windows Vista at the same time, but failing to emulate either of them very well. Compare this screenshot from the Mac OS X system preferences and the equivalent KDE attempt.
Mac OS X (clean, efficient, polished)
KDE (sloppy, inefficient, unappealing):
Notice how the Mac OS X preferences screen manages to fit twice as many icons in the same amount of screen real estate, and yet, somehow the items are easier to read? That’s because the Mac uses word wrapping for long item names. Focus on this item from the KDE System Settings:
Why would you not word wrap that text? Not word wrapping that text forces all the other icons in this column to be disproportionately wide. This causes the screen to both waste space and make each column width irregular.
Also take a look at the sheer quantity of lines on the KDE System Settings screen. Lines are the enemy. They make the user interface complicated by adding more information that your brain must (subconsciously) process. The KDE System Settings has a perimeter of 3 lines. The Mac OS X System Preferences has 1.
Lasty, notice what happens when I click on “Appearance”. The screen morphs into a totally different kind of user interface. It went from a grid-shaped navigation pane to a left-hand navigation bar:
The change in navigation is startling. It looks like the KDE team took a stand-alone form and crammed it into this one. In fact, I’m sure that’s what they’ve done. That’s pretty cool from a programmer’s perspective, but it makes for inconsistent UI.
Consistency is crucial to an easy-to-use interface, especially when it comes to user input like mouse clicking. When I logged into my new Fedora 11 desktop, I noticed a tray icon in the lower left that looked like two networked computers. I right-clicked on it so I could try to turn on my wireless networking, and this is what I got:
I can’t tell what I’m supposed to do here. I right-clicked. I got a context menu, which is usual and customary for right-clicking. But nowhere do I see a place to choose my wireless network. I tried turning off the wireless networking, and turning it back on. That didn’t help.
Finally I tried a left click, and I got a different context menu (big no no):
It appears now that KDE has adopted a paradigm of providing two different context menus depending on which mouse button you click. In my view, these two context menus should be merged into a single context menu that appears when you right click. Look how Mac OS X does it. You can right click or left click and you get the same all-in-one context menu:
This seems so obvious and easy to get right, and it’s crucial because this isn’t the kind of feature that users will use every day. The less frequently used stuff needs to be the most obvious.
As I was writing this post (on my Mac), my Fedora 11 laptop went to sleep and suspended. It made two ding-dong sounds before it did so. When I pressed the power button to wake it back up, I was greeted by lots of spinning fan sounds, a blinking WiFi light, and a blank screen. I had to power off the laptop to bring back a login screen.
I have been using Linux for 8 years, and only one distribution ever provided me a working suspend feature: Red Hat 7.3. Yes, the free Red Hat, back before Fedora existed. In the mean time, I’ve used Windows 95, 98, 2000, XP, and Vista, and every single one of them has provided a functioning suspend feature, and I’m no fan of Windows.
When I click the “F” menu, and then click on the “Leave” tab, the menu morphs into a list of “Leave”-like options, like shut down, restart, and logout. If I click “Restart”, I get a picture of a stretched-out moon with some text crammed next to it that says “Restart Computer”. This text doesn’t look like a button. It doesn’t act like a button when I hover on it. But guess what, it’s a button. KDE wants me to click on that button-like thing to confirm that I really want to shut down the computer. Here’s what it looks like:
When you want the user to click on a button, it needs to look and act like a button, even if you’re trying to do fancy graphics.
While I’m on the restart confirmation box, why is it so small? You have a huge screen. Spread out a bit. Get a little breathing room. Put about 50 pixels between each widget in that box, and give it about 100 pixels of padding around its perimeter.
Oh, and fix that moon. It looks like it got sat upon. 
I think this dialog speaks for itself:
This was one of several dialogs that I could not read fully due to chopped text.
Icon sizes are not consistent with other icons, nor are they consistent with input elements, like the little “plus” signs in tree views. Take this example:
Notice how the picture of the bug is about 20 times bigger than the “plus” sign to the left of it? In my opinion, this should not be a tree view at all, but rather a nice flat list with header text between the categories. Keep it simple. Perhaps just show the quantities, and then provide a “Show details” button.
Notice also the two different styles of buttons along the bottom of the form? The bottom row uses fixed width buttons, while the next row up uses super-wide-fill-the-screen buttons. Additionally, as near as I can tell, the lower row of buttons (”OK”, “Apply”, and “Cancel”) are not actually useful. I can get what I want without them. So not only are they inconsistent, they are also superfluous.
I do like the twirly ribbon thing that appears while you are logging in to KDE. That thing is pretty cool. Smoothly animated, and yet it gives you actual progress while KDE is starting up. It is oddly engaging. I can’t take my eyes off it.
I like the new default desktop wallpaper (though I liked the Fedora 10 solar flare better).
In conclusion, I think that the KDE desktop as packaged by Fedora 11 needs a good, long walkthrough with a fine-toothed comb by a team of user interface experts. I encountered all the inconsistencies noted in this article within the first 15 minutes of using Fedora 11, and I’m sure a focused team could find dozens more. If they’re fixed, I think Fedora 11 and KDE show great promise for the future.
The prolific Mark Twain wasn’t talking about computer programmers, but he could have been.
There are a lot of differences between excellent computer programmers and your average, run-of-the-mill hackers. But there’s one major difference, and it’s subtle but critical. And, in my experience, it doesn’t have anything to do with age or tenure.
Great programmers can accomplish the same thing as run-of-the-mill hackers with a lot less code and a lot less complexity. I’m not talking about the kind of code you write for the IOCCC contest or Perl golf. I’m talking about simple, readable, minimal code that gets the job done.
It’s story time
A couple years ago, I was sitting in a room with some great programmers. (By the way, one of the great things about working at AST is that you often find yourself sitting in a room with great programmers.) Management had asked them to solve an engineering problem. The problem seemed hopelessly complicated, and most of our engineering team had put it on the back burner because it was so unapproachable. Finally management forced the problem on us, and we all sat down in a conference room and brainstormed solutions. Ideas slowly began to emerge. After 30 minutes, the engineers had produced lots of complex ideas to solve the problem: client/server approaches, database-driven approaches, roll-your-own-Linux-distro approaches, and so on. All the ideas scared us. At that point, a light turned on. Ideas started getting simpler, and simpler, and by the end of the meeting we had whittled the solution down to something more elegant, a simple Python script that Byron hacked out in a couple hours.
The point of the story is this: Great programmers produce simple solutions.
The converse of this point is that bad programmers produce huge, complicated, and expensive solutions.
It’s time for another story.
To protect the guilty, I won’t share any specifics. I’ve heard tell of a team that had produced a piece of software over the course of a few years. The software had, as usual, grown to be quite complex, and the engineering team had grown to a dozen people. The software was deployed at a few customer sites, and was reasonably successful. I talked to some of the users, and every time the story was the same: “This software is so complicated”. The users weren’t judgmental. I think they just assumed that the problem was hard to solve, so the software was hard to use, and equally hard to write. One of the most complicated parts of the software was its installation procedure. It required the user to run several scripts in a custom csh environment. The user had to become an expert in a lot of areas unrelated to the problem domain. Customers approached the team and asked them to package the software in a standard installer format for Linux. The engineers dutifully estimated how much this would cost, and came back with an estimate of nearly … are you sitting down? … a half million dollars. Why so expensive you may ask? Their software had grown so complex and so hard to maintain, that a simple change like this would cost hundreds of thousands of dollars. Customers agreed (great customers, eh?), and the team went to work. After a few months, the job was so badly done, that the installer wasn’t “standard” at all, and it totally failed.
Why does this happen?
I don’t know for sure, but I think this blog post might give a hint.
Have you made this classic programming mistake? You’re 2,000 lines into developing this awesome framework that is going to make your team’s life so much easier when you realize that you’ve just done it:
You just reinvented the wheel.
This happens because you are a programmer, and therefore you are lazy. You love to write code, but you hate reading it. Reading code is for computers, you tell yourself, and you are, after all, made of carbon not silicon, so there. Plus, you write Perl, so it’s basically impossible to read anyway. But back to design patterns…
Design patterns are great because they provide a common vocabulary that helps developers communicate complicated ideas with a few short words like “Observer” or “Singleton”. If you’ve ever read a book on design patterns, I bet the first thing you did afterwards was implement one in your current project. That’s what I did. If you’re thick like me, which you obviously are, because you’re reading this drivel (be honest with yourself), then you probably missed the main point of design patterns. The main point of design patterns isn’t to give you something to code up. They exist to help you recognize patterns in code that already exists so you can reuse it in your project. Sure, you’ll implement one once in a while, but you really ought to be using them more than you’re writing them.
It’s story time
I recently spent some time with a friend reviewing his software project. It was a Qt/C++ user interface project in its infancy. He’s a super smart guy, and a good programmer. He knows Qt pretty well, and he knows that one of the things that makes it great are its signals and slots. Signals and slots are awesome. They make it so you can easily interact with the Qt library with very little work. They tell you when a user clicked on a button or changed some text in a text box, and things like that. In a nutshell, they let your code “observe” the state of things. Back to my friend and his model/view. For my friend’s model, he implemented the observer design pattern. This required each of his classes to implement an Observer or an Observable interface. He used C++ vectors to store pointers to each Observer so he could notify them of when things changed, and wrote all the code to add and remove new Observers on each Observable object. He was careful not to leak memory, or hang on to deleted Observer instances in each Observable. Great, right?
Head scratching time
Yes, my friend reinvented the wheel. Qt already provides the observer design pattern. Qt calls them signals and slots. Yes, you can define your own signals and slots, and Qt manages all the “observer” stuff for you, and I guarantee Qt does it better than my friend’s code (less memory, faster, etc etc). So now my friend has two observer design pattern implementations in his code base, one from Qt and one he coded up himself. Which one do you think has fewer bugs? The one that’s been around for 10 years and used by thousands of people, or the one he hacked together in a few days at work? Oh, and by the way, Qt’s signal/slot system handles crossing thread boundaries too. I’m telling you, signals and slots are awesome.
Why does this happen?
The answer is chilling: Those who fail to read the documentation are doomed to reimplement it (apologies to Mr. Churchill). The next time you are reading an API documentation, try plucking out the design patterns, and boiling the library down to its essence. What does this library really resemble, at its heart? How could I describe this feature in 3 words or less? You may be surprised by what you see that has been there all along.
I finally updated the LDS General Conference Podcast to include the April 2009 sessions. Sorry it took me so long. I just plumb forgot until now.
If you’re already subscribed, you don’t have to do anything. The new sessions will automagically download.
For more info, check out the General Conference Podcast page.
Enjoy!
I am no shell scripting expert, but I have written a lot of bash code in my day. Most of my shell scripting know-how has come from trial-and-error and desperate googling. This has (slowly) taught me a few nifty tricks and some of the more interesting details of how bash actually “works” (for lack of a better word). I’d like to share one small tidbit with you now.
The “[" program.
No, that's not a mistake. There actually is a program on UNIX systems called "[", and it generally lives in /usr/bin. Don't believe me? Check out this which command:
# which [
/usr/bin/[
Isn't that odd? On some systems (namely Fedora-variants) the "[" program is actually a symbolic link ("symlink" among friends) to a program called "test":
# ls -l /usr/bin/[
lrwxrwxrwx root /usr/bin/[ -> test
You see, every good UNIX-like OS ships with a handy utility called test (man 1 test). It's a simple program that takes input like "Is variable $foo greater than 42?", and it looks like this:
# foo=43
# test $foo -gt 42
# echo $?
0
# test $foo -lt 42
# echo $?
1
It can do a whole slew of other comparisons too, including math, string comparisons, file operations (does file $foo exist?), and a bunch of other stuff (man 1 test for full details)
The "test" program gives output solely by its exit status (that's what $? stores after you run a program in bash). That way, you can use it in bash if statements, like this:
foo=43
if test $foo -gt 42; then
echo $foo is greater than 42
else
echo $foo is NOT greater than 42
fi
It turns out that our good UNIX forebears hated typing, so they invented the "[" program, which does exactly the same thing, but it looks a heck of a lot like a C conditional when used in shell scripts, like this:
foo=43
if [ $foo -gt 42 ]; then
echo $foo is greater than 42
else
echo $foo is NOT greater than 42
fi
The only difference between "test" and "[" is that "[" requires you to have a matching "]" as its last argument or it complains on stderr. Isn't that nifty? I think so. This explains why, by the way, you have to have spaces before and after the "[" and "]". It's because "[" is actually a program name and "]" is just a command line argument like any other argument.
Now get back to that shell script you were hacking.
I have become the de-facto neighborhood tech support geek. Huh, you ask? Well, combine a pretty face with a bit of computer hackery know-how, and what do you expect?
During the course of regular Windows tech support adventures, I have accidentally observed an interesting trend ever since our friends in Redmond gave us Windows Vista. The trend: Tech support calls are up — way up. Before Vista, I would go months without a call, and now I’m getting called constantly. Here are a couple gems from this week:
1. The infinite reboot
We all know we’re supposed to keep our computers up to date with the latest patches from Microsoft, right? If not, the boogey man will get you, and the terrorists will win the War. So we all dutifully download and install (automatically, of course) these beloved patches every month like it’s our patriotic duty. Well, this week Microsoft released a particularly good patch. This one causes your computer to reboot so it can finish applying the updates (a normal course, to be sure), but after the reboot, and before you can actually login to your computer, it reboots again. Then it repeats the process, reboot, apply the patch, fail, reboot, apply the patch, fail, and you get the picture. There is no solution that I could find, though I did find lots of forums full of irate users whose computers stopped working. The only solution was a complete system wipe and re-install from scratch. The cost: about 8 hours.
2. “Easy” internet access
Jamie and I bought an iMac computer last week. It’s awesome. I brought it home, unboxed it, plugged it in, and it just worked. No configuration, no settings, no “cancel or allow?”, no headaches. It just worked. Internet worked, sound worked, movies worked, and I have about 75% fewer cords under my desk now.
On the other side of the coin, I was helping a friend setup their Comcast internet tonight in Windows Vista. I noticed that, out of the box, internet access is actually disabled (a “security” measure I’m sure since only Terrorists and Communists use the internet). But you can’t tell by looking at any settings in the control panel. It appears that it should be working. To make it work, you actually have to navigate to the control panel, then to “Network and sharing center” (yeah, I would have guess that meant “get me on the freaking internet”), then you have to disable the “Local Area Network Connection”, and then, and finally, you have to re-enable it. Some of this requires a right mouse click, some of it a double click, and some of a left mouse click. What a pain. Oh, and by the way, you get asked a couple times whether you want to “cancel or allow”, with a helpful warning that you should only “allow” if you trust the “executable” from “Unknown Publisher”, which of course happens to be the publisher that I trust the most!
I just don’t know how Microsoft expects non-programmers to figure out how to use their computers.
I have never struggled to use a computer so much. This really is the hardest computer I’ve ever used, and I’ve used some of the most arcane UNIX and Linux workstations imaginable (HP-UX anyone?).
So, seriously people, do yourself a favor and get a Mac. Save yourself the hours of pain and suffering setting up this piece of crap from Microsoft.
Oh, and don’t complain that Macs cost more than Windows PC’s because a PC is only cheaper if your time is worthless.
The hot iMac with the hotter Wife.
I have the best bash prompt ever. It took a lot of hacking and googling, but here she is:
Notice that the smiley face and text colors change depending on the exit code of the last run command (red = failed, green = happy). This is handy, for example, after a big long build that has error messages buried in it, and the last line of output just isn’t that useful.
To make your prompt awesome, put this in your .bashrc and enjoy:
Happy bashing!
Taking a break from computer science and model aviation for the moment, I want to make sure my readership (both of you, not counting my mother) is aware that my company is currently hiring software developers. I know that many developers in the Salt Lake City area have recently found themselves on the job market. I also know that new job opportunities have slowed significantly. Although I take a more optimistic view than most, I readily admit that times are harder today for developers than they were one year ago. Despite the current state of the economy, my company is doing extraordinarily well. If you are looking for work, and you would enjoy working on a small team of engineers solving problems of national and global importance, then this may be the job for you.
At my company, we build the world’s most advanced signal processing systems. Developers here tend to get intimately involved in projects from the early idea stage all the way through delivery. You won’t be an insignificant cog in a massive corporate machine. Although we tend to have a small company feel, we have big company stability and benefits. Our Salt Lake City office of 60 people is actually a satellite office of our California-based headquarters, so we have all the best medical benefits afforded to larger companies, and yet we still maintain that small company feel: no office politics, no bureaucracy, no pigeon-holing, just pure engineering at its best. We have been very fortunate for the past couple years, and now we have more revenue coming in than we’ve ever had before.
As for experience and requirements, I won’t mention the specific technologies we work with since the only real job requirement is that you are smart and get things done. You’ll pick up the job-specific knowledge you need once you start working.
If this sounds good to you, feel free to email me your resume: dave@thesmithfam.org
I look forward to hearing from you.