Coding Horror

So my much-anticipated Asus W3J laptop arrived a few days ago. To recap, my requirements for a laptop were:

• Core Duo
• 5 pounds maximum weight
• Dedicated video hardware
• Removable optical drive

Laptops have outsold desktops since 2003, depending on whose data you believe. And today's laptops are definitely converging with desktops (and vice-versa, in terms of noise and size). Laptops involve far fewer compromises than in years past. But I still consider laptops a necessary evil when I'm travelling. All other things being equal, I'd rather be sitting in front of a less expensive and more flexible desktop machine.

So, in no particular order, some thoughts about the W3J.

• I love the glossy LCD display. I was a little apprehensive about glare, but after using a glossy LCD for a few days, I am a total believer. I wish all of my LCDs, including the ones I use on my desktops, were glossy. The increase in contrast and brightness is truly remarkable. Matte LCD screens? They're dead to me.

• The Radeon Mobility X1600 is a great video card. After installing the latest ATI mobility drivers-- you can only do this if you download the full package and skip the tedious validation executable-- I get a 3dMark05 score of ~4200. That's in the same ballpark as a desktop GeForce 6800GT, which is mightily impressive for a laptop.

  I was able to play Battlefield 2 on relatively high settings at 1280x768 (use the -szx, and -szy startup params to get widescreen resolutions) and my framerate never dipped below 40 frames per second through an entire botmatch. After that, Vista's hardware accelerated Aero Glass interface should be a walk in the park.

  The usual ATI caveat applies, of course. Avoid installing the Catalyst Center software at all costs. It's bloated and slow. Stick with the core driver and use ATI Tray Tools if you need to tweak advanced settings.

• The metal cover is a nice touch. The rest of the laptop is plastic, of course, but I'm hoping the metal cover is more functional than cosmetic. Every laptop I've owned, the LCD screen eventually gets scratched by the keyboard. Maybe the stiffer metal cover will prevent this from happening with the W3J. Until I know for sure, I'm not taking any chances-- I'll be putting a small piece of fabric on the keyboard before closing the laptop.

  I also like the way there's no latch on the screen. Simply flip down to close; flip up to open. The hinge is a little overly resistant right now, so it takes a bit more force than I'd like, but I assume it will loosen up over time as it's used.

• Unfortunately, the touchpad has a dedicated vertical scroll area. This is nearly a deal breaker for me. There's no tactile feedback of any kind when you move your finger from the normal touchpad area into the dedicated scroll area. I'm suffering through it for now, because it's the only substantive complaint I have about the W3J. But how I wish there was a way to turn off that damn dedicated vertical scrolling area. You can scroll just fine without a dedicated area; the driver detects when your finger is near the edge and it switches dynamically.

• It's very easy to upgrade. There's a large panel on the bottom which, when removed, allows easy access to the hard drive, memory, CPU, and (what I think is) the video card. The CPU appears to be socketed, so it's theoretically replaceable. The hard drive and memory are obvious and easy upgrade candidates. In fact, I have another 1 gigabyte SO-DIMM on the way.

• The two gigabyte laptop memory limit is alive and well. Although you can get laptops that theoretically allow you to use 4 gigabytes of memory, I doubt any of them have more than two SO-DIMM slots. So that means 2x2gb-- but have you priced a 2 gigabyte SO-DIMM? Consider Dell's XPS M1710; the 4gb memory upgrade option is currently $1,800 for DDR-533. That's as much as I paid for the entire laptop! And it's a whopping $3,000 if you want DDR-667.

  I can get a 1 gigabyte SO-DIMM for under $90. Given current (and forseeable future) prices, I'm more than OK with a 2 gigabyte memory limit on this laptop. 2 gigabytes of memory should be workable for the next 3 years. Or at least until 4 gigabytes of laptop memory costs less than an entire laptop.

• Without optical drive, the machine is right at 5 pounds. After unpacking the laptop, I snapped the DVD-R drive out and snapped in the lightweight plastic "traveller's bay" to reduce the overall weight. It's a bit back-heavy due to the weight of the battery, and it's no match for the flyweight three pound Dell 300M I used to cary, but it's quite portable considering the massive, uncompromising leap in performance.

  I use a small Timbuk2 messenger bag to carry my laptop and other stuff. It's a little tight, but I'd rather pack light when possible. Unfortunately, it doesn't have a dedicated laptop compartment, so I use a waterfield SleeveCase to cushion the laptop before storing it in the bag. If you're into laptop sleeves, I can recommend the SleeveCase highly. It comes in sizes to fit any laptop perfectly (the W3J uses a 26-19), and they're made in nearby San Francisco.

• The integrated intel "HD" audio is impressive. I may not think integrated video makes sense, but I definitely think integrated audio does. Intel's improved "HD" audio standard is a welcome improvement to the creaky, ancient AC97 audio standard. It's a standard feature on the W3J's Intel 945PM chipset. When I slapped my headphones on and plugged them into the W3J, I was pleasantly surprised how much crisper this sounded than the generic AC97 in my old Dell 300m. It far exceeded my modest expectations for integrated audio.

One other minor niggle with the W3J is the extremely bright blue LEDs on the bottom left. I don't mind a blue LED on the power switch, since it's on the right side of the hinge, and not directly in my line of sight. But we really need to disabuse manufacturers of the idea that consumers want super-bright blue LEDs directly in our faces.

But aside from the minor touchpad and LED issues, the W3J is a fine machine, and very enjoyable to use.

One of the central themes in McConnell's Software Estimation: Demystifying the Black Art is the ominously named Cone of Uncertainty. The cone defines statistically predictible levels of project estimate uncertainty at each stage of the project.

The cone has several ramifications, the most important of which is that early project estimates will always be wildly inaccurate:

As you can see from the graph, estimates created very early in the project are subject to a high degree of error. Estimates created at initial concept time can be inaccurate by a factor of 4x on the high side, or 4x on the low side.

That means the total estimate range is a staggering 16x at the time of initial concept! And believe it or not, that's a best case scenario:

An important-- and difficult-- concept is that The Cone of Uncertainty represents the best-case accuracy that is possible to have in software estimates at different points in a project. It is easily possible to do worse. It isn't possible to be more accurate; it's only possible to be more lucky.

Furthermore, the cone doesn't narrow itself. If you don't actively work to reduce the variability of your project*, the cone of uncertainty quickly becomes a cloud of uncertainty. When will the software be done? Who knows. That's one reason for the long, dismal history of software project failure.

You may also be familiar with this software proverb:

The first ninety percent of the task takes ninety percent of the time, and the last ten percent takes the other ninety percent.

Getting trapped in the Cone of Uncertainty is a classic software project mistake. You think you're 99 percent done for months. It's a cruel failure of perspective that's endemic to the profession of software development.

It reminds me of the popular Mystery Spot tourist attraction in nearby Santa Cruz.

I've been there. The Mystery Spot is a tacky tourist attraction, sure, but it's fun. And even if you're a complete skeptic and card-carrying Mensa member, the Ames Room illusion is incredibly convincing when you, and everyone around you, is standing in it.

Are you really 99 percent done? Or is your entire project stuck in the early, distorted part of the Cone of Uncertainty where you only look 99 percent done? Sometimes it's awfully difficult to tell the difference.

* This is something the book goes into great detail on, naturally.

Scott Hanselman was kind enough to sing the praises of my blog a few months ago, completely unprompted. I finally met Scott in person at TechEd this year, and I can assure you that if you suck, Scott will be the first person to tell you that you suck.* That's how he rolls, ese. So getting a thumbs up from Mr. Hanselman is hard-earned praise indeed, and I do appreciate it.

In the fine tradition of paying it forward, I want to pass on similar kudos to one of my favorite blogs-- Leon Bambrick's secretGeek.

Sure, there may be other blogs out there by authors who are better writers, or who have killer technical chops, but Leon is all that stuff, and he's consistently funny, too. And not in an uncomfortable, soul-baring, More Than I Needed To Know Rory Blythe kind of way, or in the highly unfortunate I Can't Believe This Passes For Humor way of User Friendly.

Secretly, we may all be geeks-- but very few geeks are as talented at walking the fine line of technical comedy as Mr. Leon Bambrick. It's all funny because it's all true. Take a few minutes to read through his archives and you'll see what I mean.

* But in an amusing way, so you'll laugh at how much you suck, too. ;)

I had an opportunity to meet Ted Neward at TechEd this year. Ted, among other things, famously coined the phrase "Object-Relational mapping is the Vietnam of our industry" in late 2004.

It's a scary analogy, but an apt one. I've seen developers struggle for years with the huge mismatch between relational database models and traditional object models. And all the solutions they come up with seem to make the problem worse. I agree with Ted completely; there is no good solution to the object/relational mapping problem. There are solutions, sure, but they all involve serious, painful tradeoffs. And the worst part is that you can't usually see the consequences of these tradeoffs until much later in the development cycle.

Ted posted a much anticipated blog entry analyzing the ORM problem in minute detail. It's a long post. But unless you're a battle-scarred veteran of the ORM wars, I highly recommend at least skimming through it so you're aware of the many pitfalls you can run into trying to implement an ORM solution. There are a lot of magic bullets out there, and no shortage of naive developers.

Ted's post is excellent and authoritative, but it's a little wordy; I felt like I was experiencing a little slice of Vietnam while reading it. Let's skip directly to the summary at the end which provides an great list of current (and future) solutions to the ORM problem:

• Abandonment. Developers simply give up on objects entirely, and return to a programming model that doesn't create the object/relational impedance mismatch. While distasteful, in certain scenarios an object-oriented approach creates more overhead than it saves, and the ROI simply isn't there to justify the cost of creating a rich domain model. ([Fowler] talks about this to some depth.) This eliminates the problem quite neatly, because if there are no objects, there is no impedance mismatch.

• Wholehearted acceptance. Developers simply give up on relational storage entirely, and use a storage model that fits the way their languages of choice look at the world. Object-storage systems, such as the db4o project, solve the problem neatly by storing objects directly to disk, eliminating many (but not all) of the aforementioned issues; there is no "second schema", for example, because the only schema used is that of the object definitions themselves. While many DBAs will faint dead away at the thought, in an increasingly service-oriented world, which eschews the idea of direct data access but instead requires all access go through the service gateway thus encapsulating the storage mechanism away from prying eyes, it becomes entirely feasible to imagine developers storing data in a form that's much easier for them to use, rather than DBAs.

• Manual mapping. Developers simply accept that it's not such a hard problem to solve manually after all, and write straight relational-access code to return relations to the language, access the tuples, and populate objects as necessary. In many cases, this code might even be automatically generated by a tool examining database metadata, eliminating some of the principal criticism of this approach (that being, "It's too much code to write and maintain").

• Acceptance of ORM limitations. Developers simply accept that there is no way to efficiently and easily close the loop on the O/R mismatch, and use an ORM to solve 80% (or 50% or 95%, or whatever percentage seems appropriate) of the problem and make use of SQL and relational-based access (such as "raw" JDBC or ADO.NET) to carry them past those areas where an ORM would create problems. Doing so carries its own fair share of risks, however, as developers using an ORM must be aware of any caching the ORM solution does within it, because the "raw" relational access will clearly not be able to take advantage of that caching layer.

• Integration of relational concepts into the languages. Developers simply accept that this is a problem that should be solved by the language, not by a library or framework. For the last decade or more, the emphasis on solutions to the O/R problem have focused on trying to bring objects closer to the database, so that developers can focus exclusively on programming in a single paradigm (that paradigm being, of course, objects). Over the last several years, however, interest in "scripting" languages with far stronger set and list support, like Ruby, has sparked the idea that perhaps another solution is appropriate: bring relational concepts (which, at heart, are set-based) into mainstream programming languages, making it easier to bridge the gap between "sets" and "objects". Work in this space has thus far been limited, constrained mostly to research projects and/or "fringe" languages, but several interesting efforts are gaining visibility within the community, such as functional/object hybrid languages like Scala or F#, as well as direct integration into traditional OO languages, such as the LINQ project from Microsoft for C# and Visual Basic. One such effort that failed, unfortunately, was the SQL/J strategy; even there, the approach was limited, not seeking to incorporate sets into Java, but simply allow for embedded SQL calls to be preprocessed and translated into JDBC code by a translator.

• Integration of relational concepts into frameworks. Developers simply accept that this problem is solvable, but only with a change of perspective. Instead of relying on language or library designers to solve this problem, developers take a different view of "objects" that is more relational in nature, building domain frameworks that are more directly built around relational constructs. For example, instead of creating a Person class that holds its instance data directly in fields inside the object, developers create a Person class that holds its instance data in a RowSet (Java) or DataSet (C#) instance, which can be assembled with other RowSets/DataSets into an easy-to-ship block of data for update against the database, or unpacked from the database into the individual objects.

Ted quickly posted a followup entry which addressed common criticisms of his original post. If you have an itchy left mouse finger poised over the "comment" link right now, you may want to read that first.
Personally, I think the only workable solution to the ORM problem is to pick one or the other: either abandon relational databases, or abandon objects. If you take the O or the R out of the equation, you no longer have a mapping problem.

It may seem crazy to abandon the traditional Customer object – or to abandon the traditional Customer table – but picking one or the other is a totally sane alternative to the complex quagmire of classes, objects, code generation, SQL, and stored procedures that an ORM "solution" typically leaves us with.

Both approaches are certainly valid. I tend to err on the side of the database-as-model camp, because I think objects are overrated.

In a world of 43Folders* and dozens of other blogs that worship at the altar of Getting Things Done, it's a little surprising that nobody has taken aim at the #1 enemy of productivity everywhere: The Internet.

Do you spend so much time obsessively keeping up with the latest ninja tips on productivity, programming, and time management that you run out of time to actually Get Things Done?

If so, you're not alone.

I have a wee problem with procrastination. The internet, and chain upon chain of fascinating links, is never more than a keystroke away. It's a problem.

**

Sometimes I truly think I'd be more productive if I disconnected my ethernet jack.

All things in moderation, I suppose, but it's hard to sip from a firehose of information.

* Soon to be a book, I'm sure.
** Reprinted from Asher Sarlin's Elephantitis of the Mind