BT builds Etch-a-Sketch UMPC for Dilbert’s boss

Just about everyone has seen the famous Dilbert strip where Dilbert reminds his boss to turn his laptop over and shake it to reboot. As the PHB is walking away, Dilbert asks his co-workers if they think he'll ever figure out that they gave him an etch-a-sketch.

Well, I just about fell out of my chair when I saw this one, but Engadget is reporting that BT has finally built the famous etch-a-sketch computer. I have no idea how they could resist the urge to release the first picture without a Adams' famous strip on the screen!

Bugs should not be logged?

Here's a fun one. I came across an article explaining why bugs should not be tracked via a post on Joel on Software. As I read the article, I oscillated between outrage and amusement. Could this guy really be serious?

I considered the possibility that Mr. Thorup just wasn't experienced in software development, and then I thought that perhaps he was being intentionally outlandish in order to make a point. I'm leaning toward the latter.

No matter. Let's take his idea at face value and examine it.

To summarize the article, Lars suggests that the ability to log a bug breeds a casual attitude toward these bugs. Log it and forget it. Out of sight, out of mind. Better to deal with the little beastie right now, or if now isn't doable, then at least keep the bug somewhere close-at-hand. A post-it on your monitor. A bug report in a database, says Lars, adds no value to your software. It's unnecessary overhead, and it not only can be eliminated, it should be eliminated.

Fair enough, and all things considered, a pretty healthy attitude towards software development. After all, I've long been a proponent of using only as much process as is needed for the task at hand. So why am I not beaming with excitement at the prospect of ditching my bug database?

Simple. Two reasons: workflow and usability.

Workflow should be pretty easy to understand. It's really difficult for one guy with a fist-full of post-it notes to scale a bug tracking process up to deal with more than a small workgroup. Throw in a remote tester / user / developer / manager, and you're cooked. Simply put, the larger your project, the more people are going to be involved in the process. There are guaranteed to be cases where the person who's reporting the bug isn't the person who needs to fix it. In fact, the person who's reporting the bug may not even know who's supposed to fix it. This implies workflow, and that isn't satisfied well with post-its.

Of course, the post-it that falls off the wall of shame and behind the desk will kill you, too.

But what does usability have to do with tracking bugs? Besides the really clever segue from my last post, the way you handle bug reports has a very real usability factor for your users and testers, and your developers, too. Again, for small shops and small projects, I can see the value of hollering, "got another one!", and then slapping another yellow square on the wall.

Lars suggests that the optimum approach is to fix the bug as soon as it's seen. Great -- as long as the bug I see is my own, and and long as the fix can happen quickly without tearing me off of whatever I was working on when I found the bug. If I find a bug in an area of the code I'm not familiar with, or if the fix for the bug is going to turn into a non-trivial refactoring effort, I really have to question whether you want your developers dropping everything to play exterminator.

How about when users or testers find bugs? Every developer fights a constant battle to get "into the zone" -- it takes time to get your head into a design or coding task, and interruptions cause a loss of productivity entirely out of proportion to the time apparently taken by the interruption. This is the premise behind point #8 in Joel Spolsky's 12 Steps to Better Code -- be sure that developers have quiet working conditions. If you have testers and users running up to developers every time they think they've found a bug, the developers quite literally won't get anything done.

Say "yes" to frequent interaction, but say "no" to real-time interruptions.

This, by the way, is the same reason that computer architectures make use of asynchronous channels like message queues. It is far more scalable and efficient to let multiple subsystems operate with a little buffer between them, lest all of the component parts get hung up waiting on one another.

A bug database can also be more user-friendly to someone reporting a bug. Consider what would happen if you made every tester and user run a gauntlet before you accepted a bug report. Is this bug already logged? Is it reproducible? On our system, too? Is this bug *really* important enough to work right now? Don't you think we should walk around to see the other stakeholders to see if they agree that we should make this change right now?

Never mind.

Your goal when tracking bugs is not to collect the smallest number of bugs. In fact, if your bug reporting mechanism is working well, you'll probably get a ton of feature requests and product suggestions via bug reports. Don't flog these users for improper use of the bug system. Thank them for their feedback. It's far easier to categorize bug reports into feature requests than it is to guess what your users are thinking.

Make bug reporting as easy as possible for testers and users. The closer the testers are to your team, the more you want to work with them to educate them on what makes a good bug report, because that will save everyone a ton of time, but for the beta testers, non-technical testers, or users, just take whatever they'll give you. The alternative, in many cases, is to just not learn about their experiences, and you can't recover that lost data.

To log or not to log? No contest -- you won't catch me without a bug database any more than you'll catch me without source code control. It's just not going to happen.

You call this usability? ‘Cause I don’t!

So, how useless is this?? If you’ve got an email without any formatting in it, you don't need print preview very badly, do you? I mean, how hard is it, exactly, to figure out what it’s going to look like when it’s printed? When your email is formatted, on the other hand, you're up a creek. Nice.

I'm pretty sure that Lewis Black would be able to come up with something far more colorful to say about the bozo's who punted on this feature, but it might not be printable for polite company. Still, this is a pretty lame cop out.

This is a classic case of a user interface usability problem. This is what most people think of when they refer to usability. Interface design and implementation is the most easily-seen, and often the most vividly-felt form of usability we encounter in software development. Plenty of books have been written about this sort of usability. Cooper's About Face is one of my favorites.

The inspiration for this post was a classic UI usability foible, but this isn't the only kind of usability you should be aware of. As software developers, we encounter usability in a number of areas beyond the traditional "pretty picture" stuff (apologies to Cooper).

Consider the dynamics of that Outlook dialog, and ask yourself why it's so immediately identifiable as a usability problem. It's a disruption. It was supposed to work, and then suddenly, it didn't. I got angry at Outlook. That's how I know it's a usability problem.

I'm going to explore some other aspects of usability in software development in some coming articles, and I think this well-timed error message is a great leaping-off point.

Where do you find usability in unconventional places -- in development or otherwise?

Turning off a Unit Test does not fix it.

Late this afternoon (is there any other time for things to go wrong?) I found myself hunting down a bug. I found it, and when I did, I had one of those, "how in the world could this have gone unnoticed" moments.

Specifically, how in the world could this have gotten by our unit tests?

I found that, too. It turns out that there used to be a unit test that would have caught precisely this error, and someone had commented it out. Most readers at this point are either asking, "what's a unit test", or exclaiming, "Duh!". For the rest of you, here's a free scrap of wisdon to tuck away:

If a unit test fails, commenting it out does not count as "fixing" it.

This makes roughly as much sense as a miner watching his canary drop dead, and fixing the problem by chucking the canary corpse in a hole. After all, if he doesn't see the bird anymore, then there's no problem, right?

Come on -- get real.

Great .Net 2.0 data access resources

Here are a couple of things you should definitely check out if you work with data access in .Net 2.0. This stuff should tide you over until you're ready for Linq.

Scott Guthrie just posted a great list of ASP.Net data access tutorials. By the way, if you aren't already subscribed to Scott's blog, do so right away. He's a great source of information about the latest in Visual Studio development tools.

Also in his post is an announcement for a Beta 3 release of SubSonic 2.0. From the announcement: SubSonic is a zero code data access layer for ASP.Net. Sounds pretty cool to me.

Rant: Don’t programmers read McConnell anymore?

When I was a developer learning my trade, I picked up a copy of Steve McConnell's Code Complete. It was wonderful. An entire book filled with practices to my my trade easier and more reliable.

Much of it seemed like common sense, building on a lot of what I'd learned as I gained experience in object-oriented design and development. Concepts like understanding what a routine does and making sure that a method accomplishes one and only one objective resonated with me because they reinforced the things that worked well for me in my own experience.

There were other principles that seemed so basic that they might not even need to be covered in a book about the craft of software development. A programmer should be able to understand inherently that a six-page function wasn't maintainable, right?

Sadly, there was a reason these ideas had to be included in the book back when it was initially published, and there are still individual developers who don't find these principles to be second nature.

To this day, I see coders who have a hard time understanding the principles that make code reliable, extensible, and maintainable. Requirements change, architectures change, and refactoring happens. If you're a developer, you have to see this coming, and you have to do the right things to prepare for change.

If you're a manager, and any of your developers haven't seen this book, buy it for them and encourage them as strongly as you can to read the book.

If you're a developer and you haven't read this book (or haven't read it recently), pick up a copy, and read it.


My Windows Home Server beta experience

About the time that the Windows Home Server beta program was announced, I decided to give it a shot. The product looks interesting, and my biggest reservations came from lack of familiarity, and there's only one way to fix that. I applied, and was accepted. Woohoo!

So I started scouting for a suitable machine. I toyed with building up an old wreck I had laying around, but quickly came to the conclusion that by the time I patched it up to working order, I'd have sunk more into it that I'd like.

I was also trolling ebay, and noticed that some really nice old servers were going for not a lot of money. The bad news is that they're big and heavy, so shipping was expensive -- but not if I found one locally. Long story short, I ended up finding a Dell PowerEdge 2400 with a single 866mhz P-III processor, integrated SCSI and RAID, and 1gig of ECC RAM. I paid $59.

I wasn't ready to install yet, as I had no storage for the box, but that was easily remedied with a Promise TX4 SATA controller, an Asus SATA DVD, and two 320mb Seagate SATA drives from Newegg. I also found a second processor for $10 shipped. I was ready to roll.

When I got all the parts together, I did an install of W2K3 Standard just to make sure that all the moving pieces were working. No problem. Then, I fired up the WHS install with great anticipation, and got a minute into the install when it crapped out on me with a vague error about the UI.


I hit the forums, and posted my problem. I got a few suggestions:

  • Verify the checksum on the DVD image. Done.
  • Update your bios. Done.
  • Put the Promise drivers on a USB stick. Done.
  • Update the bios of the Promise card. Done.

All that, and no joy.

So, here I sit, waiting for a fix. Maybe they'll have a Beta 3.