I can't sleep. I'm still very sick and I'm angry and frustrated that the body sometimes just doesn't know how to recover. See my article on Self-Nonself for my thoughts on this topic. I expect more from my immune system, but it doesn't always accommodate.
Since I can't sleep, my brain is at least at 5% utilization. I've been thinking about quality a lot lately. In private email correspondence with Sean, I reiterated a simple position that I have on TDD and other methodologies that improve quality. So for the record, for those that don't know, I'm not anti-TDD. Sean and others that I know are aware that I think about axiomatic semantics and Hoare Logic and the Curry-Howard Correspondence and many other issues. I'm a fan of Intentional Software. They focus on "intent". I have enjoyed this viewpoint far in advance of any of the current MDA/Software Factories/Language Oriented Programming topics that have surfaced in the last 18 or so months. I'm a fan because Charles Simonyi is a sensible guy and thinks about these problems. Also, any firm that is in the business of software engineering and has BOTH the universal quantifier and the existential quantifier in the company name must be cool. There are other firms that also think about these sorts of problems. Ask the question "What did I intend to do here?" when constructing software and you are forced to decompose a fairly difficult problem. What language do I use to describe this intent? Is this language nothing more than part of the original language of the software construct? blah blah blah. The answers are difficult, but the process is to focus on quality.
I'm in the process of learning Sean's Zanebug and I just grabbed the latest copy 1.5 from here. Sean made Scott Hanselman's 2005 Ultimate Developer and Power Users Tool List with Zanebug and I know that he is working on further improvements. Sean strikes me as the type of developer that has his focus on quality.
That is exactly my point. Take a moment the next time that you are at work. Look at those that you work with in the professional development of software. From where I sit, nearly everyone has an eye on quality. The chief architect at my current client is constantly taking the time to assess what is best for his firm. He thinks not just about the functionality or the features or the cost, but about the quality. Quality can be measured in many ways. An easy way to think about quality is to state it as a simple optimization problem: Quality is the process that is applied to a discipline to minimize the number of defects. While defects manifest themselves in many different ways, they usually are apparent in software systems. Improvements in quality, i.e. the reduction of defects, can occur proactively and reactively.
Think about crash test dummies (CTDs) and their utility function. Sometime ago, I went to Disney World and rode on GM's ride at Epcot where you go through a simulation of GM's test center. As part of the ride, the car that you are placed in is accelerated towards a wall that opens to an outside test track at the very last moment. Talk about feeling like a crash test dummy (some would argue that I am a crash test dummy and would further argue that you could avoid the use of the terms crash and test in my instance).
So when testing for safety, the CTDs are placed in vehicles. Some catastrophic event is then perpetrated on the vehicle and the entire event is recorded. The event and all activities around the event and the results of the event on the CTDs are observed and analyzed. The vehicles are accelerated and smashed into walls. Side impact tests are done. I'll assume that a number of other tests are done. All of these tests are done in a safety lab by guys wearing white lab coats and safety goggles and pocket protectors (or so I'm lead to believe). They study the effects of engineering on the CTDs. Safety is the primary objective.
So now go back to the point that I made earlier about quality and software. Hanselman's list is a classic example of tools that are available to the .Net practitioner. We don't have to wear white lab coats (unless you have a habit of doing this) or go to a testing facility to test our vehicles. Any old PC with some good old fashioned development tools will do. We can build, test, observe, refactor, test, observe and so on. The cost associated with this practice is our time, much as the cost in the CTD labs is time. Only our PCs don't get smashed up when we test. I can improve the quality of the software that I develop. I can improve the safety of that software in its deployment environment. I can use tools to test and observe.
Software engineering gets a bad reputation for a number of reasons. People observe bad software and make the generalization that if that one piece of software is bad, then all software is bad. Y2K was not a major catastrophe because people took the time to construct reasonable software. Those that didn't have reasonable software took the time to repair any deficiencies for this problem. Software is all around us and in use in our daily lives more than we care to admit. It will become integrated to a further degree in our lives as we are able to improve the functions and features of software. So having tools around us that improve the quality of what is being built is a very good thing. That we can observe a build process and run tests on that process in an automated fashion is useful. To allow for continuous integrated builds is even more helpful in many software engineering environments. Software Factories are moving towards automation that will further our abilities to automate both the construction of the software and the measurements and metrics on that software, where quality is one of those metrics. While the models for risk, qualitative or quantitative, in software are not as sophisticated as in other disciplines, e.g. finance, time will allow for these concepts to improve the software product.
So when you approach your job today and think about the software that must be constructed and the role that you play to construct that software, whether it be architect, designer, developer, tester, documenter, etc., step back and appreciate the tools that you have at your disposal. Think about life without those tools. Think about tools that could be as well. We work in a discipline that allows for nearly immediate feedback in observations of our efforts from the comfort of our desks. We don't have to go to a lab and wreck some cars. It is only on some days that I feel like wrecking my servers . . .
Comments are inoperative. I invite you to contact me here.