Duncan MacKenzie posted a link to a great
WSJ article that took me back to some thoughts I had after reading
Code Complete 2nd Edition. Basically the meat of the story is that Jim
Allchin who runs the platform products at MS (and has a doctorate in computer
science) has always wanted a very disciplined approach in developing code. The
Windows code-base wasn't flexible enough to allow for easy enhancements and
plugging in new functionality. Plus it was buggy and to susceptible to worms,
hackers, viruses, etc. A couple of gurus were brought in and they decided to
throw out years worth of code and start with a fresh code base. They also
introduced new quality control standards and automated testing. Here's a quote
that I can really appreciate regarding this issue:
If a feature had too many bugs, software "gates" rejected it from being
used in Longhorn. If engineers had too many outstanding bugs they were
tossed in "bug jail" and banned from writing new code. The goal, he says,
was to get engineers to "do it right the first time."
I kinda like this idea of the "bug jail", but the concept of unit testing and
automated system testing cannot be overemphasized. Some of the engineers didn't
agree with the new approach which leads to another of my favorite quotes:
"Is your code perfect? Are you perfect? If not, you should shut up and
support this effort.."
This reminds me of discussions we many years ago when I worked part-time
during college at a
software company. The company made tons of improvements just during the one year
that I worked before I graduated. When I first arrived at my first software
developer job, we had no source
control (which sounds crazy) and they implemented VSS within the first 90 days I
was there. Also, they had gone from
letting the testers run wild, to having a formal bug tracking system and a
detailed test
plans for feature areas. Interestingly enough, we were also faced with a huge
dilemma at the time: the code had
reached the 5-10 year mark which IMO is about as long as a v1 code base can last
and be extended. There are simply times when you have to capitulate and
re-design the software because ultimately, requirements change, bugs are patched
and re-patched, etc. Additionally, we were having to
port a ton of 16-bit code to 32-bit
code which was a significant endeavor. I am positive that since I left, they have re-designed
(and renamed)
their applications several times. Why? Not only were the lead devs that I worked
with were some of the brightest guys that I've been fortunate enough to have as
co-workers and mentors, but the platform (AutoCAD) has gone from using the
C++-only AcadApi and/or AutoLISP to COM to .NET over the years. So, my point is:
you are lucky if your code base can actually last 5 years and it is amazing if
it can live 10 years. Furthermore, if Microsoft is running into these problems,
imagine what other boxed software companies end up going through. In most
companies it is constant battle balance between getting things
done quickly and getting things done correctly.
Most shops lack processes for
design (which
"adds value faster than it adds cost"), documentation, and testing. Period.
So, five years in software is a pretty long time. So, on July 27th, Microsoft
pushed a beta of Windows Vista expecting tens of thousands of bug reports, but
there were a few thousand instead. This is a pretty significant difference if you ask me.
