Coding Horror

Does this look familiar?

Temporary Post Used For Style Detection (14debf21-5e75-4077-9bf0-88d425739dc7)

This is a temporary post that was not deleted. Please delete this manually. (f19173c9-9b1f-4430-8823-bae7c95236a0)

Seriously. Enough with this already. I'm gonna hurt somebody.

If you're not in on the joke, it's an artifact of Microsoft's Windows Live Writer blogging tool. It generates "hidden" skeleton blog posts to detect CSS styles in its editor, but these posts somehow keep showing up in my aggregator. And that's annoying.

There are also 19,500 google results for the phrase "temporary post used for style detection". Gee, thanks, Windows Live Writer. That's exactly 19,499 too many. This post is actually useful, since it describes the problem in more detail.

On the plus side, I did get the chance to bring two new GUIDs into the world. And you know how I love GUIDs.

In classic project management parlance , every project is a combination of money, scope and time.

1. Here's what we're going to do
2. Here's how much time we have to do it
3. Here's how much money we can spend doing it.

These three factors are all related. If you pull on one "edge" of the triangle, the other sides have to give. If we cut the budget in half, we can't do as much, so scope has to give. That's why it's often called the iron triangle.

In software development, the terms are a little different, but the underlying meaning is the same. We use Time, Resources, and Functionality.

Sometimes all three dimensions of the triangle are locked. If you're given three people, four months, and a non-negotiable budget of $300k to build software, then that's what you do. But how is this possible? Something still has to give. There's an unstated fourth ingredient in the iron triangle: quality.

Once you add the fourth ingredient, the triangle metaphor breaks down. Sam Guckenheimer calls it a tetrahedon. But my co-worker Susan has an even better analogy: it's a stool.

At least for software development there's still some debate as to whether or not the stool really is made of iron:

Although widely practiced, [the iron triangle] paradigm does not work well. Just as Newtonian physics is now known to be a special case, the iron triangle is a special case that assumes the process is flowing smoothly to begin with. It assumes that resource productivity is uniformly distributed, that there is little variance in the effectiveness of task completion, and that no spare capacity exists throughout the system. These conditions exist sometimes, notably on low-risk projects. Unfortunately, for the types of software projects usually undertaken, they are often untrue.

Many users of agile methods have demonstrated experiences that pleasantly contradict this viewpoint. If you improve qualities of service, such as reliability, you can shorten time. Significant improvements in flow are possible within the existing resources and time

It's definitely a good idea to keep the "classic" stool resources in mind. But the highly variable nature of software development means that, if you're careful, you may be able to build your stool out of a more malleable material than iron.

One side effect of building quiet PCs is that you tend to develop a giant heatsink fetish.

From left to right:

• Arctic Cooling Accelero X1 on the ATI 1900XTX video card
• Thermalright HR-05 on the Intel 965 northbridge chipset
• Scythe Infinity on the Core 2 Duo CPU

It pains me to replace the northbridge cooling on the Asus P5B Deluxe, which already includes a luxe heatpipe and radiator arrangement. But it wasn't working for me-- I had serious overheating problems very specific to the northbridge.

I guess that's not too surprising if you consider that modern Intel northbridges dissipate almost 20 watts under load.* For comparison, Intel CPUs didn't dissipate more than 20 watts under load until the introduction of the Pentium II 450 in 1998.

* more like 30+ watts if you're using the craptacular integrated graphics on some motherboards.

Now that Internet Explorer 7.0 is final, the browser wars can begin again in earnest. It's clear that users should upgrade, because IE6 is so ancient. Security concerns alone compel an upgrade. But should IE6 users upgrade to IE7, or should they choose an alternative?

This comment in a web forum recently summed up my feelings nicely:

I have no idea why anyone cares that much about their browser, or why they feel it needs to be some sort of contest. I visit websites, which I consider more important than what I use to view said websites.

I've used IE7 at work and Firefox at home for the last six months or so. They're both modern web browsers. I don't see a big difference between the two. But there are dozens of killer add-ins for Firefox that extend the browser in useful ways. The lack of a viable FlashBlock for IE7 is enough to make me switch.

It's not that Firefox is inherently a better product than IE7. It isn't. But Firefox has a stronger, more vibrant user community, and that ultimately makes it a better product than IE7. Which makes me wonder: is the community around a product more important than the product itself?

Community doesn't happen accidentally. And Microsoft hasn't done much to cultivate community around Internet Explorer 7:

Another area where IE7 has serious shortcomings is with add-ons that give extra features to the browser. Firefox has an incredibly rich community of developers creating extensions, and IE has nothing that comes remotely close to it.

Don't expect much to happen in the way of add-ons for IE7, at least for the foreseeable future. There are several reasons for this. A big one has to do with how add-ons are written. To write an add-on for Internet Explorer, you need to be a C programmer. To write an extension for Firefox, you only need to be able to write a script -- and there are far more people in the world capable of writing scripts than are capable of writing C code.

Microsoft is aware of the problem and says that it hopes to ultimately make it possible to author add-ons via scripting. But there's no timetable for this.

Beyond that is a cultural issue. There is a sizable community of people that believes in open-source as a movement and philosophy, but outside the confines of Microsoft, you won't find a similar community devoted to Microsoft. So you don't have people with the same fervor devoted to writing IE add-ons as you have writing Firefox extensions.

Microsoft doesn't seem to be doing anything to foster an add-on movement, either. The Firefox extension site, for example, is run by the Mozilla Foundation, which plays an integral role in the open-source movement. Microsoft's add-on site, meanwhile, isn't even completely run by Microsoft itself; it's a co-branded download library powered by CNET's Download.com.

It's clear that community support can make or break a product. But popularity can be a curse, too. Dare Obasanjo asks, what happens when your community turns on you?

A number of times while he was speaking, Tim O'Reilly gave the impression that extensions like Greasemonkey are examples of Firefox's superiority as a browser platform. I completely disagree with this notion, and not only because Internet Explorer has Greasemonkey clones like Trixie and Turnabout. The proof is in the fact that the average piece of Windows spyware actually consists of most of the core functionality of Greasemonkey. The big difference is that Firefox has a community of web developers and hobbyists who build cool applications for it while most of the folks extending Internet Explorer in the Windows world are writing spyware and other kinds of malware.

It'll be interesting to see if the Firefox community can avoid this pitfall as Firefox gains in popularity. But the benefits of a strong community are worth the risk; it's enough to make the choice between IE7 and Firefox a meaningful one.

In Lean Software Development: An Agile Toolkit, Mary and Tom Poppendieck describe a counter-intuitive technique for making better decisions:

Concurrent software development means starting development when only partial requirements are known and developing in short iterations that provide the feedback that causes the system to emerge. Concurrent development makes it possible to delay commitment until the last responsible moment, that is, the moment at which failing to make a decision eliminates an important alternative. If commitments are delayed beyond the last responsible moment, then decisions are made by default, which is generally not a good approach to making decisions.

Paradoxically, it's possible to make better decisions by not deciding. I'm a world class procrastinator, so what's to stop me from reading this as carte blanche? Why do today what I can put off until tomorrow?

Making decisions at the Last Responsible Moment isn't procrastination; it's inspired laziness. It's a solid, fundamental risk avoidance strategy. Decisions made too early in a project are hugely risky. Early decisions often result in work that has to be thrown away. Even worse, those early decisions can have crippling and unavoidable consequences for the entire future of the project.

Early in a project, you should make as few binding decisions as you can get away with. This doesn't mean you stop working, of course – you adapt to the highly variable nature of software development. Often, having the guts to say "I don't know" is your best decision. Immediately followed by … "but we're working on it."

Jeremy Miller participated in a TDD panel with Mary Poppendieck last year, and he logically connects the dots between the Last Responsible Moment and YAGNI:

The key is to make decisions as late as you can responsibly wait because that is the point at which you have the most information on which to base the decision. In software design it means you forgo creating generalized solutions or class structures until you know that they're justified or necessary.

I think there's a natural human tendency to build or buy things in anticipation of future needs, however unlikely. Isn't that the Boy Scout motto – Be Prepared?

As a former Scout myself, I think we should resist our natural tendency to prepare too far in advance. My workshop is chock full of unused tools I thought I might need. Why do I have this air compressor? When was the last time I used my wet/dry vac? Have I ever used that metric socket set? It's a complete waste of money and garage space. Plus all the time I spent agonizing over the selection of these tools I don't use. I've adopted the Last Responsible Moment approach for my workshop. I force myself to only buy tools that I've used before, or tools that I have a very specific need for on a project I'm about to start.

Be prepared. But for tomorrow, not next year. Deciding too late is dangerous, but deciding too early in the rapidly changing world of software development is arguably even more dangerous. Let the principle of Last Responsible Moment be your guide.