{"id":143,"date":"2006-12-01T16:27:14","date_gmt":"2006-12-01T21:27:14","guid":{"rendered":"http:\/\/bitpost.com\/news\/the-n-habits-of-highly-defective-windows-applications\/"},"modified":"2007-03-29T10:24:07","modified_gmt":"2007-03-29T15:24:07","slug":"the-n-habits-of-highly-defective-windows-applications","status":"publish","type":"page","link":"https:\/\/bitpost.com\/news\/the-n-habits-of-highly-defective-windows-applications\/","title":{"rendered":"The n Habits of Highly Defective Windows Applications"},"content":{"rendered":"

This is an ugly dump of the html from this nice writeup<\/a>… I just didn’t want to lose it…<\/p>\n

OK, so it’s a pun on "The 7 Habits of Highly Effective People". But
\nthere are a number of programming techniques that I’ve found virtually instantly
\nidentify a defective program. In addition, there are a number of techniques that
\nmark a program as deeply suspect, and likely to break. Finally, there are a
\nnumber of techniques which represent poor style, some exceptionally poor, which
\nviolate principles of modularity and which result in programs that are clumsy to
\nconstruct, difficult to debug, and impossible to maintain.<\/p>\n

Many of these are simple well-known programming issues; for example, the use
\nof constants where a #define<\/b> is more appropriate. For some reason, I find
\nthat there is a tendency of programmers to assign certain integers, such as control
\nIDs, to random hard-coded values. This is a serious problem. But there are a number of
\ntechniques that also indicate serious flaws in a program. I will summarize these
\nhere, and clicking on one will link to a discussion of it.<\/p>\n

Generally, when I get a program from a client who is having problems, I can solve most of the problems by looking for the
\nitems I describe here. My track record is that I have been shown code on a page, or on a screen, containing one or more of the
\ntechniques I discuss here, and I point to it and say “There’s your problem!”, usually within the first 30 seconds. It sometimes takes another ten or twenty minutes to explain to the programmer what has gone wrong as a consequence, and demonstrate exactly what can go wrong in the future, but thus far I’ve never been wrong in my assessment. On one recent consulting trip, I spotted a
\n Sleep()<\/b> inside a WaitFor…<\/b>, and said “there’s the problem”, and then explained “Your program will fail under the following conditions (a), (b), (c) and the behavior it will exhibit on failure will be (d), (e) and (f)” and they said “Yes, that’s exactly where and how it is failing!”. As it turned out, there was nothing wrong with that part of the program that a complete rewrite wouldn’t solve. And the implications on
\nthe rest of the program architecture were significant, so they now have several weeks’ work to fix the problem, but they now understand why it couldn’t possibly have worked, except by a great miracle.
\nI’ll talk more about the failure mode details later.<\/p>\n

I have a little awk script I run on *.cpp<\/font>, and it locates these “hotspots”. Usually in less than half an hour I can locate more problems than I have been asked to solve just by studying the code near the hotspots. (I consider this a seriously good revenue generator, since instead of the 1-day or 3-day fix expected, I often get a week or more out of it, since the client, like the one described above, says “Yes, we never did figure out why that was failing…” followed by “go ahead and fix that while you’re in there”<\/p>\n

I’ve put some Severity notifications in these descriptions. My rating of
\nthese is<\/p>\n