The Expense of Errors

A widely demanded feature delivered with Visual Studio 2005 is "Edit and Continue"; which is the ability to alter running debug code to incorporate code-changes on the fly: You're debugging and realize that you initialized a variable to the wrong value, or your loop control has a off-by-one error. You pause the run, quickly hash out the changes, it builds it into the running image, and you continue debugging from where you were.

Great feature that can be a tremendous time saver, avoiding having to stop the session, make the changes, rebuild everything, and then begin the developer test session anew.

Is it, coupled with similar tool advances over the years, making programmers generally sloppier, though?

Sloppy Programming Habits

Observing the habits of many peer developers in the field, I would say that it and similar advances absolutely have made us more careless in general: The less expensive errors become, the fewer checks and mental effort we'll expend ensuring that they don't get into the code in the first place. We're continually pushing the onus of catching errors one level higher.

To contrast with a slightly earlier time, there was a time, way back when (circa 1990), when I was plugging away with DJGPP (GCC for MSDOS), editing the source files in a simple DOS text editor, exiting out, building (very time consuming, with few benefits like precompilation), and then running. It was such an onerous, expensive process that I put a significant amount of care and concern into every single line of code. I would follow-up careful coding by going back and auditing every single function and interaction to ensure that it was syntactically accurate, but more importantly that it was logically accurate.

The cost of an error making it to the next level was high enough that I was very motivated to avoid them in the first place.

After such a personal code audit, I was very confident in the code, and it was very rare that an error made it any further: The cost of an error making it to the next level was high enough that I was very motivated to avoid them in the first place. The original level of quality was high enough that few additional checks were actually needed - it simply worked correctly for all scenarios.

Of course I had it incredibly easy in contrast to those who programmed before (I already had the benefit of a significantly easier development process). I'm sure the folks who programmed punch cards redoubled and tripled the effort again, achieving amazingly high at-origin quality levels in their code: You can't just spit something out when you're printing and sorting punch cards, and then feeding it into the mainframe during your tight allotted time window. Nor did programming assembly in the 8-bit days leave much room for errors.

Contrast this with the habits of many developers today (myself included at times): Spit out a bunch of code, occasionally hitting compile/syntax check to automatically detect gross syntax errors. Build and run, and if it blows up then follow the exception back to the error and correct it. Drop into breakpoints and watch what values are to ensure they're what you wanted (a modern variation of printf debugging), and if they aren't then use edit and continue to quickly hash in some changes. Keep debugging. Run the TDD sets to ensure that the superficial, incomplete collection of tests "guarantee" that the code is "perfect". 

Toss the result over the wall to the QA department. They're likely running a macro script that tests a small sub-section of the code, so there are few guarantees there either. In the corporate space, they'll throw it over the wall to the UA testers who again will likely only catch the most obvious of errors.

Deal with the inevitable problem when failures occur in the field, pointing out their inevitability given the numerous layers of quality control you have in place.

Of course some developers will strongly object to even the possibility of such a scenario: Their code is flawless at inception, crafted with the utmost of care and concern, and they need never evaluate their habits or tool usage because they couldn't possibly come closer to perfection. That level of ridiculous denial is destructive on any team or project, and I can offer no advice on how to solve or manage it (though it's the foolishness of the inexperienced, so generally developers grow out of such bravado with time). Instead I choose to deal in the real world, with real developers on real projects in real organizations.

Additional Checks Are No Guarantee

For all of the process (including layers of QA, UA, regression testing, and so on), many errors aren't caught at many shops until the code reaches the field, which is why it's critical that they don't enter into the code in the first place.

the addition of layers can paradoxically increase the probability that errors will be introduced in the first place

Indeed, sometimes the addition of extra layers can paradoxically increase the probability that errors will be introduced in the first place: At one very large organization where I observed development firsthand, developers would hand their obviously flawed code (it was clear that there wasn't even a superficial quality check) over the wall, doing so knowing both that there was a QA department that should catch these things (and if they didn't then it's their fault if it makes it further, exonerating the developers even more), and if that department does find a fault it came as a largely ignored problem report that held few ramifications or negative implications.

Change precisely what was documented as defective, rebuild and resubmit.

Eventually the QA department would pass on the code to the UA department, which was a set of user testers that simply relied upon the comforting idea that the developers and QA surely would have found any possible faults. UA could be relied upon largely to restate long-known system limitations instead of verifying the changes.

All of these layers relieved developers, and each of the other layers, of the real responsibility of defective code. Advanced tools facilitated sloppy coding in the first place, and layer upon layers of ineffective checks ensured that there was little actual responsibility for faults that made it to the field. In the corporate space where developers generally don't have a passion for the software they're creating, the result was often of questionable quality.

False Efficiency

It would be an interesting experiment to have two concurrent mid-sized projects, each completing the same task, with one development team having a modern complement of development tools, and the other with no ability to automatically syntax check, run automated tests, or debug in any way outside of a small number of scheduled debug builds and test sessions. It would be interesting to evaluate both the overall timeline (did the tools save much time?), and the quality levels of the resulting product.

I believe that the results would be very surprizing to many software developers. In real world projects (e.g. not pre-project timelines, but actual post-mortem results), approximately one half of development is dedicated to finding, and fixing, software faults. Making the per-item cost of faults cheaper may reduce the per-fault cost, but it also might increase the frequency of faults to the point of being a net loss.

A comment that I frequently hear relates to the efficiency of development - That modern tools make us so much more efficient. Under the right conditions, and with proper usage, this is certainly the case. Edit and Continue, for example, could be a very useful feature once every blue moon. Yet by the outpouring of demand for that feature, one would think that developers were crippled by the inability to alter running code: The responsibility to craft quality code before hitting build was just too overwhelming. This is a sign that quality code craftsmanship is on the decline.

Tagged: [Software Development], [Programming], [Software-Development]

A St. Olaf Christmas In Norway

Caught this on PBS HDTV tonight and it was spectacular (it'll be on several more times over the next week). The choirs were great, and the setting - Nidaros Cathedral - was extraordinary.

Norway is yet another list of countries that I'd really like to visit and spend a month or so in. As a Canadian, I've always found it odd that nationally we haven't fostered more of a friendship and alliance with the smaller Northern countries (Sweden, Norway, the Baltic States, Finland): We share common political (e.g. smaller countries amongst heavyweights) and environmental conditions (cold!).

Speaking of togetherness - I've been to the Twin Cities (Minneapolis/St. Paul) in Minnesota quite a few times, and I would truthfully say that the classic stereotype of Canadians (many mannerisms, friendliness, and so on) actually applies more aptly to the great folks of Minnesota. That's a beautiful state full of great people, and in many ways it's more Canadian than Canada.

It's the President's Choice

A very large grocer up here in Canada is Loblaw's (which operates under a variety of brands). They generally operate huge supermarkets full of a good selection of fresh, quality products. It most certainly isn't the cheapest grocery store, but I can honestly say that I enjoy grocery shopping when it's mulling around a Loblaw's.

One of the greatest coups of Loblaws, and it's one that has brands and retailers worldwide taking notice, is the President's Choice brands. Originally begun as a rather corny "I'm the president, and this is the stuff I like!" selection of items, it has evolved into a very high quality brand (which is rare given that it's a store brand, which usually indicate a compromise in quality): If I'm looking for a product in a realm where I don't have a favourite, I'll go past all of the well-known brands and pick the PC alternative if one is available. In any given Loblaws visit, probably 30% of the non-produce items I buy now are PC brand items.

Of course Loblaws doesn't actually manufacture the brands themselves - Instead they get outside manufacturers to do it, often the people whose products it will compete against. However it seems evident that they spec out excellent products, and they demand a very high level of quality and ingredients (PC brands eliminated or minimized transfats long before that became a norm, for instance). The result is products that seldom disappoint.

Why do I mention this? I mention it because the PC brand is going so well, and they're earning so much namespace, that a good thing can't continue: Seemingly inevitably some blowhard fly-through executive will decree that if they are making $X, then they should reduce the quality of the ingredients and make $X*1.2! Perhaps I'm a cynic, but this cycle of self-defeat at the hands of short-term sacrificers is legendary when something starts doing well.

...is that they're often fact-deficient.

The rumor that's been making the rounds over the past 24-hours is speculation that Microsoft has bought, or is buying, Opera (the makers of the excellent Opera web browser). The source of this multi-hundred-million-dollar rumor, involving two publicly-traded companies, is one small, random, tech "ezine". Nonetheless it's been repeated on Slashdot, Digg, along with many other sites and blogs.

The indirect birthplace of the rumor - perhaps the source of the plot for someone's fiction - was John C. Dvorak's commentary yesterday that Microsoft should buy Opera, given that they're letting the IE browser rust on the Mac. Opera, Dvorak claimed, would provide Microsoft with a cross-platform solution.

The problem with Dvorak's hypothesis, among many other logic gaps, is that Microsoft doesn't want a cross-platform solution. Internet Explorer on the Mac wasn't abandoned because it was too difficult to maintain, and it certainly wasn't that Microsoft couldn't keep up. Instead, it was strategically abandoned because Microsoft couldn't rationalize spending the time and effort to create a browser for someone else's platform. It also brought Microsoft under additional scrutiny: It's one thing for the monopoly operating system vendor to use some of those profits to enable their own platform, but it's quite another to provide a free browser to edge out competitors on other platforms as well. Internet Explorer on the Mac undermined Microsoft's bundling proposition as well (the whole "it's a part of the operating system...that you can also run on other operating systems...").

Ultimately this rumor is so void of any logical foundation that it is an indictment of the group-think sites that it has gotten the attention that it has (though it got the originator website exactly what they wanted, which is a lot of attention). Once again I'm setting myself up for a hearty serving of egg-on-the-face, boldly proclaiming that it is very unlikely that this story is true, but that's exactly what I'm saying. At least the Google-buying-Opera nonsense of a month or so ago could be mentally rationalized to some degree, but Microsoft-buying-Opera is just over the top ridiculous.

On top of all of that, there are some legalities that are certainly going to start biting small internet papers and blogs that perpetrate this sort of rumor mongering: Making false statements about publicly traded companies in ways that can impact their valuations might seem like a harmless, fun way of boosting the hits, but there are legal restrictions on that sort of fiction. I'm not saying with certainty that this particular story is untrue, but it seems highly likely to be the case.

UPDATE: While scanning the discussion boards, I've noticed that a common technique to keep the hype alive is to focus on the mobile market as Opera's killer valuation: Opera has a micro-browser that runs on cellphones, therefore that legitimizes the purported buyout (as only the few true believers would think that Microsoft replacing IE7 with Opera is even remotely possible).

There are several problems with this.

• Microsoft already competes in the mobile space with the PocketPC OS, and a mobile version of Internet Explorer
• Even then, there is very little money to be made having your browser on a cell phone - this isn't IE versus Netscape of 1997. This is 2005, and the primary concern is to be the site that the micro-browser goes to, not the browser itself. In the case of cell-phones, there is little chance that the providers would allow Microsoft to direct it to a Microsoft property, so even that minor advantage is lost
• Many of Opera's customers (who are the hardware vendors - not Joe on the street) for the mobile browser are Microsoft competitors. They would dump it in a heartbeat if it was acquired by Microsoft

The mobile angle does nothing to rationalize the scenario.

A very merry Christmas / Happy Holidays to clients, readers, and passers-thru.

Seeing family and friends, the wonderful arts (both live and on television), and the great food and drink really makes this my favourite time of year. Soon enough it'll be the marking of a new year of challenges and goals higher than before, and I'm looking forward to it, after a very satisfying 2005.

[The static location of this piece can be found at this address]

How Ridiculous

Rediculous - Results 1 - 10 of about 3,800,000 for rediculous.

It is ridiculous that such an obvious misspelling has become so prolific (correctness by repeated assertion), yet it's a great example of how contagious an incorrect spelling can be: Given that language is largely learned by example, it is inevitable that an endless exposure to malformed spelling will eventually infect the language of others, gathering a widening net of victims.

This is more of a problem now more than ever, given that many of us have supplanted - or entirely replaced - the professional writing in our lives (newspapers, books, professional papers) with the amateur writing of bloggers and forum posters: The "good" influences - carefully authored, carefully edited professional writing - have given way to carelessly hashed-out entries by time-pressured bloggers and marginally-literate forum posters, in a domain where the accepted rules of netiquette strongly discourage pointing out spelling or grammar mistakes.

Those who point out errors in grammar or spelling are quickly marginalized as "Grammar Nazis". Ignorance rules the day, and the social pressure encouraging good spelling and grammar has dramatically declined.

English Is Non-Trivial, But Spelling is Standardized

English is a very difficult language, with a tremendous array of conflicting influences, and a byzantine array of specialized rules and conditions.

It is, for instance, very difficult to conform to all norms of grammar given that many of them are subjective and conflicting (and many self-appointed gurus have themselves made embarrassing errors). I have absolutely no doubt that this entry, for example, has over a dozen real or subjective grammar problems: From the incorrect placement of a comma, to the overzealous use of a compound adjective, to the use of a colon where a dash would suffice.

I certainly make no claim of perfection. Where I find that I've made an error (and I heartily welcome emails to this effect), I try to correct them as quickly as possible.

Nonetheless, spelling is standardized (with minor regional variations), so unless one is intentionally trying to extend or adapt the language, some effort should be exerted to check the standards references to ensure that one's usage is conformant, just as one would ensure that their CSS or HTML was compliant with the pertinent standards.

The Cost

The impact of the continued exposure to incorrect spelling and grammar can be extraordinary to observe. I've seen people corrected dozens of times, yet rediculous is so ingrained in their mind that they just can't break the habit. Soon enough other participants are perpetuating the misspelling, with the forum slowly diverging from correct English into some bizarre forum-localized lingo-ignoramus.

It might seem harmless, but this incorrect spelling starts infecting their professional writings (emails, instant messages, documents, signs, business cards - a domain where the laissez-faire attitude of the online world isn't acceptable), making them look ignorant and careless. That's if the fear of the same hasn't discouraged written discourse altogether (which is sadly very common. I've encountered plenty of professional acquaintances who avoid the written word like the plague).

It can even reduce the comprehension efficiency of written materials, as the reader's brain tries to rationalize the correct spelling on the paper with what they have stored in their memory cells.

It reduces general literacy.

If a reader's first exposure to analagous (analogous) or ancilliary (ancillary) are in a hastily written blog entry or forum post, naturally they're going to adopt the incorrect variant, perpetuating it to other entries and posts. Like a virus the misspelling infects new victims.

Of course it should be noted that language is indeed a "living" thing, and it does evolve and change over time - the English we speak today differs greatly from the English of yore - but the sort of ignorance that I'm describing has nothing to do with extending or adapting the language. Instead it's simple contagious laziness.

Showing Regard For Readers

Good form or not, I am regularly going back and rewording old entries for improved clarity and readability, and occasionally even to correct spelling mistakes that made it under the radar (I have some eagle-eyed readers that very helpfully point out some of these errors. Rather than being irritated by the "grammar nazis", I am very appreciative to have the extra sets of eyeballs).

I do this primarily to ease consumption by readers: While the initial entry might have been rushed when too little time was available - but I thought the information or perspective were useful for someone - the entries live on and see far more traffic over time than at the outset. A correction here and there, and the refinement and rewording of a paragraph or two to make it more clear and concise, takes me a few moments, yet it saves dozens or hundreds of readers time in the future (and improves their comprehension of the content).

I consider the effort very worthwhile.

Furthermore, I try to run all entries through an up to date spell-checker before the initial publishing. To make the process more palatable, I have trained the spell-checker with all of my domain-specific terminology (the false-negative rate of spell-checkers is one of the primary reasons most people avoid them).

I don't want to appear ignorant by misspelling a common word, and I don't want to save myself a little time at the cost of every reader's time. I also don't want to pollute the vocabulary of readers with believable misspellings.

Industry Solutions

Just as one eagerly sticks a W3C validation banner on their page declaring their compliance with some level of specification, it would be intriguing to advocate a "spelling and grammar" standard mark. One that simply declares that the author actually cares, and does exert some effort to meet some minimal level of correctness in spelling and grammar. It would be a public sign indicating that they are open and thankful for comments and corrections regarding the same.

Furthermore, it would be advantageous if the major search engines - including blog aggregators and search engines - allowed one to refine results by grammar and spelling, optionally scoring academically correct content higher in the results. While sloppy spelling is no guarantee that the content isn't of value, there is a noteworthy correlation between the care and concern put into the spelling and grammar of an entry and the value of the actual content contained within: If someone couldn't bother spell-checking their entry, the factual content of their entry naturally has to come into question as well.

In the forum and blogging world, it would be beneficial if more tools supported convenient and efficient automatic spell-checking (the fact that no major browser has incorporated native TEXTAREA spell-checking thus far is a travesty. Any of them could have a killer feature if they simply added Word-like squiggly underlining of suspect words, with easy alternative corrections). As it is, many tools have nothing at all, and the few that do often host a ridiculously unintuitive, hacked-in partial solution.

Let's clean up English on the internet.

[TRAFFIC NOTE: This story, one of the few general interest posts I've made on here, has appeared on reddit, sending quite a few users this way. For those who've actually read this far, if you found this entry interesting I would appreciate if you could give an arrow up to it on reddit. Alternately if you think this is a dud, please give it an arrow down. Thanks!]

Several of the presents our children received this Christmas required batteries. Not just any batteries, though, but the petite triple-A (AAA) sort.

Those batteries are, if you didn't know, the most expensive and irritating of the battery genus, often costing $8 or more for a tiny pack of 2. To add to the insult, they also feature a relatively short lifespan (given that they have less chemicals that their bulkier siblings), so they tend to run out quickly in high-consumption devices, further exacerbating the cost issue.

I'd write it off as space efficiency, but for the fact that all of the toys that require these tiny batteries are themselves physical monsters - a huge garage where the batteries power the sound and lights, and a huge train set, where the monster, forearm-sized remote requires 3 of them.

These aren't cell-phone sized television remotes, but huge toys that have no such need for space efficiency.

Two toys alone required 9 triple-A batteries. I hit the battery reserves to find that we'd stockpiled several dozen double-As, Cs, Ds, and 9Vs, but not a single unused triple-A was in sight.

An expensive trip to the department store later, the toys were operational, but I'm prone to suspecting collusion between the battery industry and the toy industry.

Rearranged the shelves over the holidays, and re-read a few sections of Fred Brooks' venerable book The Mythical Man-Month.

It's an interesting read, though it is largely obvious: Adding more people on a project naturally means more administrative, communications, and coordination overhead. If, at a particular stage in the project's progression, you have more people than you have clean project partitions, they could actually hinder rather than help. 

Many developers can personally identify with this indisputable observation, recalling situations where a manager with excess human resources dumped workers onto their project, against their wishes, while it was in an unpartitionable design stage. A co-op student assigned to me in just such a situation, many years back, started informally tagging their assigned tasks "MWPs" : Make Work Projects (they were quite capable, and recognized and disliked trivial tasks). Given that I was in a critical, non-partitionable task, and all following tasks depended upon it, the best I could do with their help was to get them to do competitive research.

Such is the nature of some projects during some stages. To use the classic analogy, nine women can't produce one baby in one month. Of course it's a fairly bad analogy given that those nine women can of course produce nine babies in nine months, effectively producing a "baby a month" if you wait the minimum period, but nonetheless it is the common phrase.

The mythical man-month title refers to the fact that many project managers take a project's estimated work (e.g. 100 man-months), and then request or assign a set number of people (e.g. 10 men), dividing the effort by the workforce and considering that the delivery date (in this case 100/10, or 10 months to completion from the start). Of course that is incredibly naïve, and is a recipe for disaster from the outset, and when the project starts slipping more people get added, slowing the project even more.

Thankfully, most shops use proper project timelines now, with critical paths, dependencies, and task assignments.

A couple of Mythical Man-Month quotes that I found enjoyable:

An ancient adage warns, "Never go to sea with two chronometers; take one or three."

...

An architect's first work is apt to be spare and clean. He knows he doesn't know what he's doing, so he does it carefully and with great restraint.

As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get sorted away to be used "next time." Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system.

The second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.

If you don't own this book, you should at least get it to stock your bookshelf (it is a required pretend-to-have-read shelf stocker). If you already understand and believe the core message of it, it's debateable if it's really worth spending the time actually reading, though: Quite a lot of it is highly specific, unique observations about the creation of OS/360, and some of it are practices that are now considered questionable. For instance, few advocate the surgical team that the book promotes (with the book example humorously including a language lawyer and two secretaries).