Posts by Vincent Manis 54 publicly visible posts • joined 26 Jan 2008
No, it really was difficult to write a compiler that complied completely with the Report, because there were strangenesses and no permissible restrictions. I need only mention the difference between the roman and italic dot (yes there really was a difference), or the fact that the compiler my friends worked on had to have an entire pass devoted to deterining how parentheses were used. Make reasonable restrictions, and ALGOL-68 became not much more difficult to implement than any other modern language.
People writing compilers in those days didn't have the Dragon Book, because it didn't exist yet. However, they all knew about the latest and greatest parsing techniques, which eventually went into the first edition of Aho and Ullman. I remember learning about LR(k) and LALR(1) parsing from the papers that introduced these techniques.
I never used IBM OS/360 ALGOL-60, but I was recently looking at its language manual on Bitsavers, and it too required apostrophes around key words. I did use an ALGOL-60 system on the IBM 7044 in the late 1960s; it too required apostrophes, but also the keywords were in French, as the compiler was written at the Université de Grenoble. One said 'DEBUT' X := X+1; Y := Y/2 'FIN'.
I should point out that lower case in those days was not an option. The character sets used prior to the mid 1960s, such as BCD and Fieldata, were generally 6-bit, and simply didn't have room for iit. And even the world moved to 8-bit bytes (7-bits on PDP-10), the printers couldn't handle them: a 63-character print train on an IBM 1403 printer could print substantially faster than a 95-character train. I remember well into the 1970s having to specify special job status, and worse turnaround, for jobs requiring lower case.
Although I was never actually involved in the ALGOL-68 effort, my grad supervisor was one of the Editors of the Report, and so I know a fair bit about it. It was not “hell” to write a compiler for it, as long as you made a few minor restrictions, none of which really harmed any real program. The compiler my friends were working on was never finished, because it refused to make any of these restrictions, so for example, it had to compile “(...50-pages-of-code...)” correctly. Not only that, but that compiler was written in Wirth's horrible worse-than-assembly-language PL360!
There were two major blunders in ALGOL-68: first, the ghastly two-level syntax used for description was impenetrable to anyone trying to learn the language, resulting in syntax rules with names like “SOID NEST2 out CHOICE STYLE clause” (I picked that one at random from the Report, and, yes, capitalization was significant), and second, there was no concrete syntax, meaning that programs were almost automatically not portable between implementations. The former was remedied by Lindsey and van der Meulen's “Informal Introduction to ALGOL-68”, the latter was never remedied.
One additional blunder was only apparent several years later. ALGOL-60 had no I/O, which everybody realized was a disaster (implementations from Univac, CDC, Burroughs, and IBM added their own custom I/O). So the designers of ALGOL-68 created an elegant “transput” library (they did like to speak in neologisms), which was firmly anchored in punched cards and line printers: a file was a 3D array of characters. This at a time when operating systems, starting with Unix, began treating files as a 1D array of bytes. A very uneasy fit!
Even with all these mistakes, ALGOL-68 was a significant contribution to programming languages, and doesn't deserve the condemnation and contempt sometimes heaped upon it. Still, even though I somewhat disagree with the authors of the Minority Report (Dijkstra, Wirth, Hoare, et al) about ALGOL-68, I do agree with Tony Hoare that ALGOL-60 was “not only an improvement on its predecessors, but also on nearly all its successors”.
It's instructive to read the original Ken Thompson Unix 6ed kernel (in the Lions commentary). It's full of fixed-size arrays, linear searches, and obscure code, complete with the famous comment “You are not expected to understand this”. I am sure that if he'd had to go through elaborate PR vetting, Unix would have ended up on the dustheap of history.
As for “using proper (datastructure) tools”, I taught data structures at the university level for 10 years. Making a copy of a datum, rather than just using a reference, can make dangling pointer and unexpected mutation errors go away. It's defensive programming at its best. In this case, the engineer found that the copy was unnecessary, and perhaps that could have been determined when the original code was written...but at least this story isn't about using eBPF to find why code was smashing memory.
Back around 1980, our University Computer Centre decided that it existed for the purpose of solving differential equations, not word processing. So the Centre's newsletter ran an article entitled “The Computer Centre Is Not A Print Shop”, explaining that using the central computer for word processing was a misuse. I was teaching an introductory CS course at the time; the first assignment was typically some version of “Hello, world!”. My first assignment was for the students to write a paragraph explaining their reason for taking CS, and use the (then quite wonderful) Michigan Terminal System to format it. I fully expected to receive a blast from Centre management (with whom I was on friendly terms), but there was nary a query or comment when a hundred or so of these jobs rolled off the university's IBM 3800 laser printer.
Being a born rebel, I was disappointed.
I like taking the occasional swipe at Microsoft, but I think this article somewhat misses the mark. My first encounter with “deprecated” in software came via the Bell Labs Unix crew, who would mark something as deprecated to mean that (a) it is going away at some point in the future, and (b) there is another, presumably better, way of doing the same thing. For example, one might mark the description of tmpnam (a C library procedure that computes the name of a temporary file) as deprecated in favor of mkstemp (a C library procedure that avoids a race condition between computing the name and opening the file). Because many programs still use tmpnam, unfortunately, this procedure will go away only far in the future. In fact, if some implementation found a bug in tmpnam, they would produce an update.
So “deprecated” means nothing more than “don't use this, there's a better way of doing it, and this might vanish someday.”
As I recall (and the last time I used Fortran in anger was something like 1973, so my memory is vague), the REWIND statement takes a logical unit number. So you have a subroutine, called at the beginning and the end of the run, that contains REWIND statements for all of the logical units used in the program).
It's a common mistake, but JCL was only used in IBM operating systems. There's no indication that this problem occurred on an IBM system.
We at least had an obsolete IBM 407 accounting machine, with a plugboard that just echoed cards onto the printer. You could get as many free listings as you wanted, and we were invited to do as much “desk-checking” as we liked. Only problem was, there were no desks in that noisy hut where one could check carefully. Of course, you could take your listing away and come back later with corrections marked on it, and submit that run. Nobody I knew ever did that.
I was friendly with the on-site IBM staff, both customer engineers and systems engineers. But that strategy wouldn't have worked with the “Student Area”, as that was the Place Where Keypunches Went To Die, and rarely was heard a servicing word there. I never had a card saw, but often a blank card cut in half would do the job. And when it didn't, I moved on to another machine.
When I took my first computer science course, in 1967, our computing equipment was a fleet of IBM 026 keypunches (the kind with vacuum tubes). Card decks were taken to some mysterious place, and the next morning, a printout would appear stating that the IBM 7044 computer had objected to a missing comma. The keypunches were balky at best, and often jammed. Since there was no mechanism to report a jammed punch, fewer and fewer working machines were available over time, meaning that we'd have to stand in the rain waiting to get into the WW2-era hut containing the keypunches. After a while, I discovered that it was relatively easy to unjam one of these machines, and I started to do so, so as to shorten my wait (and thus my deck was ready to go off to the computer, which would then object--the next day--to a missing right parenthesis). I have no idea how much I shortened the lifetimes of those keypunches, but my waits in the rain were certainly less.
Note: every word of the previous paragraph is literally true. Any resemblance to the “Four Yorkshiremen” sketch is purely coincidental.
I run Linux. Most times, with a new machine, it will boot into Windows, offering no options. So nowadays, with a new computer, I let it start Windows, then I use the `shrink windows partition' option to set it to a minimal size, then turn off Fast Start. On the next boot, I can start the Linux boot medium, and do a regular install. And Windows is still there, in the event that I need it. I never do.
I don't know who the “you” is, but if you're referring to me installing GNU/Linux, that's not because of some risk avoidance thing. I've been a Unix guy since the late 1970s, and that's the OS I prefer to use. As for people who wipe Windows and reinstall it from Microsoft media, that's because, as was said, of bloatware. Blame Microsoft and computer manufacturers for that.
I have bought a number of Lenovo machines over the years, in fact I have a Yoga 9i on order right now. I always do the same to each, installing GNU/Linux (typically Debian or Ubuntu, but on the new machine I'm planning on Manjaro). While I do leave a shrunken Windows partition behind, I don't leave any actual data on it, and never boot it. (I run Windows 11 on VirtualBox when I have to run it). I consider the risk to me by such a system identical to or less than the risk of anybody else's made-in-China machine.
Lenovo is certainly an odd company, in that they have a fair bit of former IBM staff and management. I couldn't say what percentage of the company is owned in or outside China, but until such time as we can find equipment of comparable quality and price made entirely in a Western country, from Western made components, Lenovo is no worse than its competitors.
Actually, TeX has quite a following in the humanities, because of things like good footnoting, figure placement, bilingual parallel texts, and bibliographies. I can't speak to why a philosopher might find it useful, but no doubt he had his reasons.
I think you misunderstood my comment. I mentioned that WYSIWYG existed at PARC then (I visited PARC in 1974, and saw what I think was an early version of Bravo). I suspect that Knuth knew something about it, given the distance between Stanford's CS building and PARC, but he was trying to build a program that would typeset his books the way he thought they should look, and WYSIWYG just didn't cut it in those days. I suspect he also knew about the Bell Labs pic/eqn/troff toolchain, too. The guy does encyclopedic research.
As for writing a paper versus shipping copies of software, we were looking at when these various tools were designed, in other words, the intellectual roots, as shown in papers, etc. If that makes me an academic, guilty! I'm retired now, but taught software engineering not only in universities, but also to industry. But shipping things has nothing to do with what's possible: a lot of defunct word processors shipped lots of copies, but really were not very good. Re WriteNow: I'm glad it satisfied your needs. Many people find MS-Word or FrameMaker satisfies theirs. But I doubt that WriteNow, in 1986, could have produced a paper that, say, the American Mathematical Society or the Association for Computing Machinery would have accepted as camera-ready copy. That was Knuth's goal, even though it may not have been yours.
As for that document I produced with it, it was a user manual for a simple programming environment I wrote for first-year students. No math at all, but lots of structured text (e.g., command reference descriptions). I can confidently say that no other software accessible to me at the time could have done the job, as at that time TeX could drive a laser printer and nothing else I had could. Admittedly, I wasn't using TeX for the purposes Knuth intended, but it satisfied my needs.
I can also say that LaTeX at that time did not satisfy my needs, primarily because its font support was primitive. I co-authored a book in the early 1990s, and used a format I developed that looked LaTeX-like, but handled my font needs (I too was aware of Scribe). However, font handling has vastly improved in LaTeX, and I stopped using my custom format long ago.
As for 10x the work, I was forced to use FrameMaker for one project when I worked for $BIGCOMPANY. I found it adequate for the job, but it took me about the same amount of time as a comparable job done in LaTeX. Any of these systems (even MS-Word) has a significant learning curve. I used to give my students the task of creating a style sheet in Word for their documentation; they found this a real challenge. But once one has the tools, actually knocking out documents is quite easy.
I did not understand your comment about flakiness. Knuth is famous for logging every bug ever found in TeX; I found even the prereleases fairly solid, and once it went into release, it was very solid. LaTeX may have been buggy in those days, though I never used it until the late 90s. Even if it was, my reply is simple: Windows 3.0 shipped a lot of copies, and it had a few bugs.
I fully understand that you perceive no need for TeX, and agree that it has limited domains (e.g., you wouldn't do newspaper layouts with it).On the other hand, it has been used to typeset many books. Pandoc uses it as a backend when you convert HTML or Markdown into PDF. It has been used in industry for everything from railway timetables to producing telecom bills. There is a real difference between “I don't need this” and “this is useless”.
Some corrections. LaTeX (notice corrected capitalization) is a macro package that runs on Donald Knuth's TeX system, which he started developing in 1977. At that time (Xerox PARC and a few other places aside), people did word processing on character terminals, and printed the result out to see what it looked like. The Mac did not exist; in fact, the Apple ][ went on sale a month after Knuth's original notes on what would become TeX. Furthermore, LaTeX itself is based upon an earlier typesetting program called Scribe, by Brian K. Reid, circa 1980.
TeX itself has quite modest memory requirements, and has not grown substantially in many years, though nowadays I and many use the LuaTeX engine, which is a bit larger than Knuth's classic. It is true that a modern TeX distribution would overflow a CD (about 5.5GiB currently), but that is all the macro packages, ancillary programs, fonts, and other miscellanea provided. You do need a text editor and a PDF viewer for actual work, but nowadays those are pretty much provided with a base OS.
My own view of modern TeX/LaTeX systems as tools for writing long-form, complex documents with math and embedded code echoes Winston Churchill's comment on democracy: “the worst form ... except for all those other forms that have been tried from time to time”.
I like ultra-thin laptops, but I also prefer mechanical keyboards. So I've tended to get 2-in-1 convertibles, and use a mechanical keyboard with the computer in tent mode; currently that's a Dell Inspiron 7445 with a Keychron K1 Max keyboard. This is arguably less convenient than replacing the keyboard, but doesn't involve any hardware surgery. 2-in-1s have an accelerometer, so they automatically rotate the display when you put the computer into tent mode (at least that happens in Ubuntu Linux), so all I do to set up is open the computer in tent mode, turn on the keyboard (and my trackball), and I'm all set.
I have had a couple of Intel/nVidia machines over the years, running Debian or Ubuntu. I generally never got adequate graphics performance out of them, even when running the proprietary drivers. I recently acquired a Dell 2-in-1 with an AMD/Radeon CPU and GPU, running Ubuntu. I get decent graphics now; while I would never use this machine for serious gaming, it satisfies my needs. And, I can run the Sway window manager, whose principal developer refuses to support nVidia (even though you can make it sort-of work).
Windows users probably don't care about this, but as things stand, I'd be very reluctant to buy another nVidia-based machine, at least until Linus changes his mind.
Actually, the DEC OSes that CP/M and MS-DOS were based on used / as an option character. Both / and - have about the same amount of history: - was used (I think) in at least some programs in CTSS (1960s), whereas DEC was using / only a few years later. Since MS-DOS was based upon CP/M, it's no surprise that they would use the same flag character. Apparently, when DOS 2.0 was designed, they actually wanted to support / in pathnames, but that would have been too great a change for DOS 1.0 users. I believe that DOS 2+ all silently accept / as a directory separator in pathnames.
So not “change for the sake of change” but more “we don't want to make incompatible changes”.
I visited the Community Memory storefront in Berkeley back in 1974. They had a Teletype connected to a remote Xerox Data Systems machine (possibly a Sigma 2 or 5), and it was running what we would now call BBS software. The CM folks wanted to use it as a tool for connecting community groups and individuals. I don't know what happened to the project.
A couple of observations. First, ALGOL 68 did not succeed, but its complexity has been overstated. Partly due to the horrendously un-understandable 2-level grammars of the Report, and partly due to language features that were not yet understood (parallelism and semaphores, among others), it got a reputation as unimplementable, even though there were almost-complete subsets built in the 1970s, and ALGOL68 Genie flourishes to this day. Wirth and Hoare had very good reasons for rejecting it, but I would argue that modern C++ is at least as complex as ALGOL68, if not more so.
Second, during his California stay, if not afterwards, Wirth had the nickname`Bucky'. At one point he suggested an Edit key to set the 8th bit of an ASCII character on a keyboard. This was the base for the Meta, Super, and Hyper keys of various Stanford and MIT keyboards, and the modern Alt, System Logo, Command, and Option keys of modern keyboards. The bits these keys set are known as `bucky bits' to this day.
This week, I bought a really nice ultraportable, a Lenovo Yoga 6. I had to experience Windows long enough to turn off fast boot (which involved logging into my Microsoft account), I attempted to install Debian. No luck there, needed some custom wifi drivers. Rather than mess around doing that, I installed Ubuntu. It installed flawlessly, and (although I'm not a Gnome fan) came up with an entirely usable user interface (which I'm replacing, of course). I don't think Ubuntu is the sole choice (though it makes sense for me as a Debian user), but there are a number of very polished distros that install cleanly and are usable by non-experts...and cost nothing.
I don't know, on a Chromebook, I just go to Settings > Developer, and enable the Linux environment. This gives me an almost complete Debian system (there are a few limitations) on which I happily run Emacs, TeX, Inkscape, Gcc, and Chez Scheme. Chromebooks are admittedly not powerful machines, and I can point to various defects and limitations of this setup, but it works for me. In fact, a Lenovo Chromebook tablet with an external mech keyboard and trackball is my preferred travel/writing setup.
There are definitely things I don't care for in ChromeOS (like having to use a Google account), but the ability to run Android programs, Linux programs, and Chrome itself, along with the fact that Google promises updates to that machine until 2031, count for a lot.
I can't demand that a phone survive a wash cycle; if I could, my original post would have been pointless. That said, all reputable device manufacturers provide a statement about environmental factors. I randomly picked Samsung, and found https://www.samsung.com/ca/support/mobile-devices/galaxy-phone-dust-and-water-resistance-rating. There they show the Ingress Protection ratings of (some of?) the Galaxy range of phones.
I am profoundly not fond of my iPhone and its horrible OS. But I'll give it credit: it survived an entire wash/rinse/spin cycle. The washing machine in question locks when started, so all I could do was to stare and weep when I inadvertently loaded it along with the laundry. When it came out, it functioned flawlessly, and was unmarred except for a tiny scratch at one edge. I very much doubt I'll buy another iPhone,but The experience has taught me to demand that my next phone will be similarly sturdy.
Dyadic (binary) only was a design decision. I did this on an IBM System/360, and addressing arbitrary bytes wasn't something you needed. So in w%o, you start with a word pointer w, and add a byte offset o. I also had in mind word-addressed machines (which still existed in those days), where accessing an arbitrary byte in memory was nonsensical. (As much as I can capture my thoughts from 50 years ago.)
*Grumpy* note. I invented the % operator for byte subscripting, and made the changes to the compiler and System/360 code generator to make it work. This work was communicated to Martin Richards without my name on it, and he in good faith incorporated it into his distribution.
Sorry, I just had to vent. :)
It actually stands for “Basic CPL” where CPL was a language that Christopher Strachey and his colleagues worked on during the 1960s and early 1970s. It would have been an excellent language, had its developers ever converged on an actual final specification for it. Martin Richards noticed that a small subset would be ideal as a systems programming language; he developed a highly portable compiler that could be ported by writing about 100 lines of Fortran/assembler/whatever for the target machine. As well, backends could be written to produce good-quality code for a range of machines. (I benchmarked it in the early 1970s as producing code for a couple of problems that ran about 1/3 faster than the same code on IBM's Fortran G (non-optimizing) compiler.
BCPL's downfall came because it worked best on a word-oriented machine, such as the IBM 7090/7094 on which it was first implemented. There was only one type, the word; you needed to add a minimal notion of data types to make byte or double-precision data work well. (This was exactly the reason that B was replaced by C.)
I too have eyesight that makes decoding emojis at normal text size very difficult. Further, I can't be bothered to learn the input methods for emojis. I have a compose key set up for typing accented letters, and so I can type <compose> : ) for a smiley. Apart from that, the whole emoji business leaves me cold, and therefore my response to it is <compose> p o o.
Back when I was a university teacher, I often included the instruction `Write the word OKAPI at the top of page 2 for an extra mark’ in my midterm exams. Less than half of students did this. Some who didn’t said afterwards that they had read it, but thought I was joking! Life sometimes makes me sad.
MVCL was always interruptible.On an interrupt, the hardware would update the registers; on return, the machine would just re-execute the MVCL.
A much more interesting way of swamping a 360 or 370 with virtual memory was to process a huge matrix along rows, not knowing that Fortran stored arrays by columns. This could bring our university's 360/67 running a time-sharing OS to its knees, as the offending process ended up having to swap in a new page for each element access.
Intelligent people know that no source can be trusted completely, and that any worthwhile research uses a multiplicity of sources. I often use Wikipedia as a starting point, often finding its references and external links the most useful part of the article.
While there have been many accounts of individual Wikipedia pages that contain slanted or biased information, I have no reason to believe that the overall site's error rate is substantially higher than any other encyclopdia.
Shoddy journalism is the journalist's fault. Uncritically cutting and pasting a Wikipedia article is no different from a school student copying a passage from a book without acknowledgement in a school report.
Finally, I look forward to seeing a link to Mr Orlowski's list of the 16,000 pages he claims are false.
I'm a fan of the Fargo film and TV series, which depict decent people going to hell through a series of really bad decisions. Similarly, programming ended in the early 1960s, when FARGO, the programming system was created. [https://en.m.wikipedia.org/wiki/FARGO_(programming_language)]. Not!
Of course, people don't write mortgage programs anymore, they use spreadsheets. We don't need to keep writing the same programs over and over.
Software development has changed many times over the decades. What hasn't changed is the need to have smart people create solutions to problems that nobody has solved before, and other smart people evolve those to meet changing needs. Intelligent programming assistants can definitely be a part of that.
systemd-free Devuan hits stable 1.0.0 status
I selected No because the choice of init system really makes almost no difference to me. I've been using Unix since 1975, and taught courses on Unix programming and system administration, so I find the issues relating to init systems interesting, but they have very little effect on me on a day-to-day basis. I've survived BSD init, SysV init, upstart, and now systemd, and none of those changes has made an appreciable difference to me, other than some minor modifications to scripts. Obviously, some sysadmins might find that such changes necessitate a great deal of work; but that hasn't applied to me.
Now do I find systemd's design offensive? Yes, I do. But then I find most features in modern distros kind of offensive (the cat and true commands are exceptions ☺) . I tend to like systems that are consistent, have as little clutter as possible, and match my notions about workflow. I would personally have liked it if Plan9 had been modernized and made a solid OS. But it wasn't, and Ubuntu and Debian do a fine job for me.
So what about Devuan? I hope the developers can produce a solid system. If it's easier to use, or more robust, or more scalable than Debian, good for them; maybe other distros will pick up on their ideas. The computer scientist in me finds such matters interesting; the computer user in me is happy with what he has.
systemd free Linux distro Devuan releases second beta
Peter is of course correct, it was a brain fart on my part. In fact, by the time 7th Edition came out, I no longer had access to the 11/45 in question.
Reiterating my earlier point, much of present-day Linux distros (all of them) isn't the way I'd do it, but I have a life, and I just use what I have to get the job done. Linux/Unix on desktop, laptop, or server looks downright great compared to the Redmond alternative.
Some other posters have referred to disembowelment or the like. I prefer to judge software on its merits or demerits, without ad hominem comments.
My first Unix system was 7th Edition on a PDP-11/45, back in 1975. Since then, I've seen Unix (and now Linux) grow from an elegant, small, sparse system to the furry, ungainly creature it is today. In part, this is due to increasing performance, reliability, or functionality. In part, it's creeping featurism. Most of a modern Linux system isn't done the way I'd do it, ranging from duplicated functionality to unwanted applications, not to mention hit-and-miss documentation.
I suppose if I really cared, I'd use one of those distro generators to roll my own. But frankly, life's too short. I fire up my various Debian or Ubuntu systems, and for the most part, they just work. I haven't really noticed any decline in stability with the advent of systemd (which is definitely not done the way I'd have done it).
So I wish the creators of Devuan success, but frankly neither the presence nor the absence of systemd really makes much difference to me. I just use whatever I have to get whatever I need done.
If you are referring to the claims of pedophilia lobbed against Clarke, no evidence was found to support them (other than some claims in some tabloids). While those accusations were current, Clarke's knighthood was in abeyance. When the Sunday Mirror apologized for publishing those claims, the knighthood was granted. Clarke was definitely either gay or bisexual (regardless of what he said on the subject), and he may well have enjoyed the company of younger men, but there's a world of difference between that and pedophilia.
Actually, the USNS Harvey Milk is the second ship in the John Lewis class, which are being named after civil rights leaders. And the `long, hard, and full of seamen' comment is about as courteous in discussing this matter as a reference to watermelon in a discussion of Obama's foreign policy would be. Both the article and the headline are seriously misleading.
I don't like the one-button mouse, but I will say that it does make using the mouse simpler to explain. I have taught several seniors how to use computers, and the whole `left-click/right-click' thing is actually quite difficult to get across. I don't think the one-button mouse is a good idea, but it is true that Apple actually had a case in favor of it. (I really like my Lenovo laptop with its TrackPoint and three mouse buttons, and a touchpad I disable.)
As for inaccuracy, mice have always been inaccurate. I was told in a graduate-level HCI course I took circa 1975 that the original SRI mice were built from miscellaneous electronic scrap, and that getting perfectly linear potentiometers was essentially impossible. As a result, to move the cursor in a straight line, the user had to move the mouse in a curve. Apparently, users adapted very quickly, and were genuinely unaware of this phenomenon.
In my experience, government IT projects often don't come in on time/under budget, for several reasons. 1) Requirements creep, often triggered by political considerations (and often from the same sources as later outrage about increasing costs); 2) lack of coherent oversight by the client (instead of having a small review committee with both technical and other members, approvals are often distributed among a large, diffuse, and ever-changing group of individuals); 3) significant amounts of out-of-band communication between contractor and client, often necessitated by the first two factors, and resulting in a loss of institutional memory (`where did that requirement come from'); 4) poor life-cycle models, veering towards waterfalls, and away from iterative/agile practices (and I am not carrying the agile banner here, just pointing out that waterfall development often produces gargantuan monsters that don't satisfy client needs); 5) lack of end-user involvement (e.g., a senior program manager who thinks he can speak for clerical users of the system); 6) lack of clearly identifiable milestones that relate to the actual project (e.g., `the Frobozz infrastructure is complete', rather than `the system can correctly perform transactions X, Y, and Z'); 7) emphasis on delivering milestone products, rather than ensuring the products meet specified reliability and performance requirements; and 8) lack of proper audit procedures (e.g., looking at numbers of closed and unclosed bugs in the bug database). I could go on and on.
Of course, many private-sector projects go south in exactly the same ways. But government IT projects seem particularly susceptable to these dangers. As someone who has taught software engineering practices to industrial practitioners, it disturbs me greatly how easy it is for large organizations to ignore their own history, and make the same mistakes over and over again.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
