Why modeling?
I've been brought into two different projects where they basically summarized it saying, "So this 'six week' project's now a real mess, and at week twenty, they're way over time and budget. We want you to go in there and model what they have so that you can point out to them what their problem is." I agree, it makes no sense. I'm just saying, it's happened to me, and on two of the three disaster projects I've been brought in to fix.
In both instances, I figured out basically what was wrong within about 2 seconds of starting to look at their code. When the first 80x24 screen full of code is
- full of code - almost no unnecessary white space.
- less than 10 virtual lines long (i.e. average line length greater than 140 characters)
- written in three different languages
- more like line noise than any non-sed program has any right to be
*and*
- full enough of semantic ambiguities such that you can, within that first two second glance, spot at least two places where the way the language parser will read some code is probably different from how the programmer expected - and possibly even variable depending on which version of the language parser is used
you know you're dealing with a fairly special project. Modeling won't help. Additional fun can be had if one of the languages is perl, with half a dozen or more command-line switches being used, none of which were -w or -T.
Unit tests, as a general rule, will help. In my case, on one of those projects, we weren't able to get any unit tests to actually pass any of the existing program - that was fine, because management wasn't watching closely enough to ensure that we used any of the existing program, and so "we" (meaning I) had it working in less than three weeks. The original programmer was either clueless enough that he didn't notice that his files, while present in the directory, were not being used, or he was smart enough to not complain, as this would've indicated that I did in three weeks what he couldn't do in twenty.
In the second project, unit tests plus stringent version control enabled the project to go forward. The first step after getting the unit tests was removing all of the testing cruft they'd added in their feeble attempts to get the program working, and the second was to actually format the code - which showed almost half of the problem, as they had indented so inconsistently that they weren't aware of what the nesting level of each portion of code was.
This having been said - as I didn't actually try modeling, I can't really state absolutely that modeling wouldn't have helped. But I can't imagine getting either of those projects finished quicker without removing management obstacles to fixing them.
I also fully admit to having failed in both cases: I was unable to relate to the earlier staff exactly what went wrong. However, in both cases, I believe my reason for failure was a management thing: management had conveyed very clearly that I was to not, under any circumstances, explain to the original teams that they were fscking incompetent morons. Given this dictate, I found it difficult to relate to them that their problem was that they were fscking incompetent morons.
Oh, and one last comment: if anyone ever tells you the best design for something is to have most of the code written in a blend of awk and perl, with a Bourne shell wrapper around them to glue them together, they're wrong. Either write it in perl or in awk. Either language should be sufficient for the job. If the job involves processing multiple files, and you're not sure how to do that in awk, either write it in perl, or write the handling for each file in separate awk scripts, and have a common script invoke them. And having the in-line perl and awk bits of your Bourne shell script making subshell escapes is just right out.
Biting the hand that feeds IT
