I have lots of ideas about how software should be written but I’m not particularly adept at expressing them. Jeffrey Snover’s writing, OTOH, is very eloquent and persuasive. His latest blog post here  discusses a topic that is near and dear to my heart. He uses the term technical debt. I don’t know if he is the originator of the term, but it succinctly captures the issue. In a nutshell the problem is product managers who favor investing in shiny, new features at the expense of basic functionality. This has been a problem for as long as I’ve been involved in the computer software industry (25 years). The marketeers want to have impressive bullet lists of features for a new product release. They give lip service to customer satisfaction but would much rather sell something first and worry about how well it works afterwards. This is a big problem for desktop software but becomes critical for customers who pay for online services.

Paid-for online services give a service level agreement (SLA) guarantee as to the availability and reliability of the service. It is a major problem (and a breach of contract) if the service is unavailable for any extended period of time. There is a more insidious problem that can occur when transient loads cause service resources to be momentarily unavailable. In the aggregate it appears that everything is fine, but individual users could see disconnections or other service failures. The only way to detect these situations is with very fine-grained performance monitoring of all of the service components. This is a difficult problem to solve but it can be solved with sufficient development resources. Unfortunately it is not very sexy. Will management have the wisdom to make this investment or will it be just more technical debt. Time will tell.

The Husky Stadium at the University of Washington (my Alma Mater) is being revamped. The south stands are being torn down and replaced. I was wondering how the stands were going to be removed. It is a very large structure made of both structural steel and concrete. Well, it turns out the plan was to have a controlled collapse of the steel stadium roof onto the seats below. Unfortunately something went very wrong and nearly brought down the huge crane that was manipulating the remote cutting device. You can see the crane flexing way beyond its safe design parameters near the end of the following video.


This is my first post attempting to embed a youtube video. Appologies if it doesn’t work.

The first thing that went through my mind was “thank Goodness no one was hurt!” Now I am wondering if this is going to throw a monkey wrench into the stadium reopening schedule. The State construction safety department has opened an investigation and will probably put a stop on any continuing work until there is a solid understanding of what went wrong and a plan to proceed with a new demolition design that will avoid this problem.

This is my new blog where I can write about topics that I want to share. I have two major interests, technology and construction. At some point I might break these into separate blogs, but for now I am going to combine them here.