TeX - Knuth - Software quality - Re: Bug-Free Software,

It was thus said that the Great Tony Duell once stated: I've read up on literate programming (I even own a copy of "Literate Programming" by Knuth) but even so, I never liked the idea all that much, because it seems even *more* work than regular programming. For instance, I have a program I wrote between 1999 and 2001 that I still use to this day [1] and in that time, I merged what used to be two programs into one, replaced the IO system twice (I'm now on the third iteration) and just this month I replaced the configuration code [2]. Had this been a literate program meant that not only would I have changed about half the code, but half the verbiage would have had to change as well. At work, I deal with just a small portion of a project that involves at least half a dozen programs. One program (which doesn't actually do all that much) is 131,000 lines of code [3]. And since I've been on board (about a year) there have been at least two major architectural changes because of "issues" not forseen [4]. As it was, we barely finished on time [5]; having to rewrite sections of a "book" would have been dropped as soon as we missed the first milestone (given the push we were on to finish). Heck, just look at the difference between Linux 1.0 and 3.0. Imagine if that was done via literate programming, and how much work it would take to keep the verbiage up to date. Literate programming is just too much work. -spc (And frankly, after seeing some of the "documentation" we produced at work [6], literate programming would still be a failure) [1] http://boston.conman.org/about/technical.html [2] I replaced the configuration file, which was basically an RFC-822 format (since I had to parse RFC-822 style lines anyway) with Lua. The file looks much nicer, I can have real comments; I was able to remove a bunch of code that was replaced with several Lua modules so over all, I think it was a win. [3] Most of the code is a webserver to control the program, and another large portion is code to talk IS-41 over SS7. [4] One issue---one vendor's SMS stack took too long (on the order of half a minute or more) for what we needed to do. So out went the SMS and in went a hack^H^H^H^Hcustom protocol to implement the functionality. Another issue---one vendor's hardware didn't do what they claimed it could do, so we had to "fix" that by implementing what the hardware didn't do. And it goes on ... [5] Amazingly, we did finish on time. That's because we kept pushing back as much as possible. [6] Skipping the 1,000+ pages of non-documentation that makes up the SS7 stack, our own documentation is rather ... lack luster ... in spots. So much so that I've felt I've had to reverse engineer some of our own protocols we devised, and that's from looking at the soure code!