By Tom Ollar
Steelray Software
The software industry is still young – and contention regarding every aspect of the development process reigns supreme. With one man’s method decried by another as madness, it is sometimes difficult to see the forest for the trees; one thing is certain, customers like software that works – they even appreciate that mysterious quality computer scientists sometimes refer to as ‘robustness,’ though isolating it in the lab can prove difficult. In short, quality is hard, but achievable and certainly desirable. My story of one small quest for quality follows . . .
In 2003 I sold my half of Digital Metaphors Corporation, acquiring the rights to iSpace. iSpace was nothing more than the design for a new kind of Office application, one focused on 'end-user reporting.' iSpace was targeted to do for reporting what Visio had done for diagramming. The 'end-user designer,' long a strength of ReportBuilder, had received continuous feedback from developers and their customers over the years, pointing to a potential market for a totally stand-alone version, albeit one toned down for 'real' users.
Consisting of over 300 Design Plates and a 40-page document describing every aspect of the application, the iSpace design was daunting. The user-interface itself was simply not possible using stock controls, and yet the key competitive advantage of the product was this very interface. So Jim Bennett and I (the other lead engineer that left DM with me), dove deeply into the UI area. We desperately wanted to use C# in lieu of Delphi, as we felt the managed aspects of the environment would far outweigh the performance hit. Ultimately this would prove incorrect, but at the time, it seemed oh-so-compelling.
Our first crack at it was .Net WinForms - even with liberal doses of 'CustomDraw' we hit roadblock, after roadblock - our 'prototypes' were ugly and misbehaved. It looked like the UI, our key competitive advantage, was going to elude us. Then one day, as we mulled over a garish, Win 3.1 style scrollbar, Jim mused 'why don't we do our own scrollbar, I mean, how hard could it be?' That phrase 'How hard could it be?', though the answer again and again was 'Really, really, really hard', became our siren song as we proceeded to knock off control after control. A year and a half later, we had a state of the art UI platform that supported 15 different controls, including a fully-virtualized ListBox and ListView (read virtualized here as 'unlimited rows - still scrolls').
We built the platform painstakingly, unit test by unit test - only, these were not your typical unit tests, these tests literally ran each individual piece of a control, asserting the resulting offscreen bitmap for correctness. If even a single pixel was off, the test would fail. At the end we had over 15,000 such tests, and even when run in 'full-speed playback' mode, these took over 3 hours to complete on our best machine.
Technically then, we were in rare air. How many other developers in the world had built a full-fledged UI platform? How many had done this much unit testing? How many had ever done any unit testing with UI - period? Indeed, when we started talking with other developers it seemed most didn't see the need for unit testing, much less UI unit testing. And yet, with only two developers, in less than a two year period, with no public or private beta, we had built a complete, shippable, production quality UI platform.
Though we did not ultimately build iSpace (the original dream application that guided our work), blix (the resulting UI platform) went into production at various clients around the world. Not only has it performed amazingly well, we have, on occasion, returned to enhance it, add a few tests, and re-release. It's hard to describe the feeling you get watching 15,000 tests go green - but 'good' certainly applies.
From a business standpoint, quality meant that we had something more than code – we had an asset that could be used and re-used. All too often code bases are tempered against the back, neck and foreheads of poor ‘users’, and whether suspecting (beta) or unsuspecting (release), it’s often hit or miss and never as nice as a simple cheer from the crowd. That such a cheer might be achievable using engineering methods for QA might be brilliant. Then again, it might be madness too . . .
---
Steelray offers a free trial of the leading Microsoft Project viewer. Download a copy today!
Comments