Just a Thought...

I’ve decided that even though I have a hard time saving up a big chunk of change at once to buy a computer, I’ll be building one a set of pieces at a time. I’m three components away from being able to have something I can use directly. In some ways the process is fun. I get to upgrade to the current decade’s equipment. My existing laptop is nearing four years old, if not more. I have an external monitor that maxes out at 1280×1024, etc. Since I’m treating myself to a new machine, I thought I’d also add some gaming features for the fun of it.

I’m not a big gamer, but making a system that will be capable of pushing 1080p video fast enough has its own challenges. Combining that with my programming and exploration of parallel processing means that this machine has the potential to cost a whole heck of a lot of money. My latest purchase is a Razer Lycosa keyboard. My sister’s family gave me a gift certificate, so combining that with a rewards card from my credit card company I got it from Best Buy. The keyboard is very nice, even though I can’t make the most of it until my dreaded Windows 7 purchase. I’m using it now to type this post.

Here’s the problem with playing integrator. You get to find all the wonderful components that weren’t really designed to work together. For example, the computer desk I have looks really nice, but the keyboard tray is very shallow and the hole made for passing cables through can’t accommodate the cable block that has to pass through it. Mod to the desk. The cabinet for the computer caused my old desktop (long since retired) to overheat. I can’t imagine what it would do to a powerful machine like what I’m building. Either more desk mods, or keep the computer outside the cabinet. Not all RAM modules work with all motherboards—and I’m not talking incompatible RAM modules like DDR2 and DDR3. Oh, and don’t forget the power requirements.

An integrator’s job can be pretty tough. There’s a lot of details to work out, and a lot of testing required to make sure the system as a whole works as you expect. It’s not too different from doing software systems integration.

Many companies seem to believe that if you have project management (read: a schedule in Microsoft Project), that’s all you need to deliver something to the client. Not only is that thinking wrong, it can get you in a lot of trouble. There is one engineering practice that is so fundamental, so necessary, it is the only one every open source project observes: Configuration Management.

The big definition of configuration management is that you know where every artifact is, and what version the artifact belongs to. For example, it is absolutely critical that you know where your project’s source code lives. It is also critical to be able to back out a change you started that causes more problems than it solves. If you deliver a version of software, you should be able to know how to get to the source code for that software without hardly thinking about it. It’s for that reason that we need to use some form of version control. Whether you want to use Subversion, Git, ClearCase, or SourceSafe is up to you and the person paying the bills. The bottom line is you need version control. The other side of CM is being able to track the progress of issues, tasks, requirements, bugs, etc. until they are closed. That’s why we use tools like JIRA, RedMine, ClearQuest, or VersionOne.

Yet, it seems like every company I go to, I’m the one setting up these basic tools. Naturally I go for what I like, which excludes products from Rational or Microsoft. It’s not that I hate the companies, but Rational is expensive to set up and use and Microsoft corrupts its version control if you are not careful. I hope at least that Microsoft has fixed that bug in SourceSafe. In SourceSafe, if you permanently delete an item, all your version history is corrupted and lost (at least the last time I used it, approximately 6 years ago). You can only corrupt my version history once before I switch to another product and never trust yours again.

Another basic engineering practice needed, but seldom practiced, is managing client expectations. Communication is the cornerstone of understanding. That means both talking and listening (it’s the latter part that is seldom practiced). All too often, the client says to do something and the engineer springs to action. Neither party has given any thought to the impact of the request, much less whether it was feasible. Unless you start the relationship by always responding with “let me get back you on that”, you are doomed to an eternal do loop of putting out fires.

I’m not advocating ignoring your client, I’m advocating that both parties are fully informed. If the client wants a new section in a document you delivered, they have a right to know how long it will take, and if it will cause rework in other sections of that document. Same with the code. If the client wants a new whiz-bang feature, they need to know how much its going to affect the schedule. They might be really surprised at the new delivery date. You’re an agile team, right? What they don’t know, and need to be told, is that the feature they wanted affects several other sections of the application. Work with the client, but have the decency to understand what’s going on. If you have a feeling that might be the case, help them understand that and then tell them I’ll get you a definite answer by some date.

You can go a long way with these two practices. The processes you put around them will probably be different than what I do. That’s OK. All too often I see no CM, no unit tests, no management of customer expectations. The effects are obvious. How about going through a year of busy work, and no real progress because of that eternal do loop? It’s time to grow up. Playing cowboys and Indians was cute when you were a kid, but now it just burns money and makes people frustrated.

I’ve been running Ubuntu 9.1 for more than 8 months now, so I’ve been able to come up with my list of complaints and quibbles about the OS. Video was a second class citizen, and you had to jump through some hoops to get it working at all, much less properly. Particularly if you wanted to watch MKV or AVI movies, you had to add a special entry to your package manager to find the binaries for the codecs. For some video, I had an annoying light gray block that took up a portion of the video that would only go away if I resized the video playback screen. I couldn’t leave it maximized because then the whole screen would go gray. Add to that the fact that if you clicked anywhere on the time bar in the video player it was an offer that was undercut. You want the bar at 1:30? I’ll give you 0:29. Skipping an intro was a pain. There were many minor issues like that which piled up. However, I can say that the 64bit operating system actually ran on my aging hardware, and the USB ports were working; unlike a certain OS from Redmond which stopped working completely on my laptop.

Enter the Lucid Lynx , the current crown offering by the Ubuntu team. The upgrade process was quite a bit of a pain, but not too bad overall. In the beginning it did a good job keeping my 20megabit line saturated promising a download time of around 45:00. That quickly slowed down and the process was more like 4 hours. It wouldn’t be so bad if the install was completely hands free. There were a few times where a dialog box would pop up asking me to “forward” something to continue the install. The install would then pause until I dealt with the dialog box. Same thing happened for some files that were altered by other installation processes. Eventually I took my wife on a date and finished the process when I got home.

Once the install is complete, you will notice one thing off the bat. It’s noticeably more responsive. When Ubuntu said they were focusing on performance, they were not kidding. All my complaints about video? gone. They fixed the kludgey multi-monitor support in the previous version quite nicely. It behaves like you would expect it to. Even Firefox was suddenly more spritely (although the V8 benchmark didn’t improved any). Ubuntu 10 took advantage of a number of video acceleration features which makes drawing windows and controls much quicker, and video works so much better. One thing to consider when upgrading (per the Ubuntu site): the new default file system is ext4 instead of ext3. While ext4 offers a number of improvements overall, it is noticeably slower on installs. The main problem has to do with file renames not being atomic, so the installer is extra careful.

Although I still won’t say this OS is for your grandma right now, its much friendlier than it used to be. I don’t spend a lot of time rebooting my machine, but it starts up quicker. I haven’t had time to see how well it does with battery life yet. I remember my battery draining much quicker with Ubuntu 9.1 than with Windows XP on the same box. I’ll pay attention to that next time I take it on the road. Granted I’m a bit harder on a battery because I’m not just surfing the web. I’m doing software development when I test it. Compiles tend to use the CPU more.