I talked last time about why I’m suspiscious of standardized practices. The fundamental objection is that they lack context. However, sometimes someone manages to come up with an idea that’s useful in no contexts whatsoever. We’re talking anti-pattern bad. The following story is true. The names have been changed to protect the guilty.
GUI Design Methodology
John Developer joined a software consultancy. They seemed pretty cool, had some interesting projects in the pipeline and used tech he’d got experience in. Being pretty much a one man hacker at his previous firm, he wanted to improve his skills and work on bigger projects. So it was something of a shock to discover that he was being referred to as “The Guru” after his first week.
Now, having stared at the code for a while, he couldn’t understand what code like the following was for
Const f_S017_c = 17
Yes, this was VB3. That is absolutely no excuse for bad design. He couldn’t understand what all of the switch statements were for, either. It was then that, for possibly the first time in his life, he decided to read the documentation. The documentation was pretty standard at first: you’d see a screen shot of what the UI was meant to look like. There’d then be a quick explanation of what each control on the form did, along with the standard redundant explanations of what “OK” and “Cancel” did.
The next page was a spider’s web of a flow chart. He asked his manager what it was: “Ah, that’s the state machine.”.
Flow Charts as Standard Practice
Here’s how you were meant to design a screen:
- Mock up what the screen should look like (an old RAD design practice)
- Identify the modes and transitions the screen should have. (e.g. which tab is showing, whether you’re adding or modifying data)
- Build a flow chart that demonstrates how the screen works.
- Implement the flow chart.
Yeah, you remember flow charts. You probably saw some when you first learned to program. Do you remember how to do a subroutine in them? Of course you don’t because you can’t. Flow charts and state machines are goto writ large. And as soon as you gain any complexity, your state machine gets huge. Imagine a screen with three tabs. Imagine it can be used for adding or updating data. That’s six states right there. Imagine if one field is sometimes disabled. That’s twelve. State is a good concept and appropriate in many circumstances, but orthogonality is important. There’s a reason classes are allowed multiple fields.
Step 3 was where the true brain damage occurred, but the implementation was, if not as bad, hilariously funny. Bear in mind that this is all implemented on top of VB3, an environment in which event handling was the dominant idiom. Each item in the flow chart was numbered. Now, it’s bad to have magic numbers in code, so constants were used. So, if you take a look at our code above, f_S017_c can be read as “field representing state 17 which is a constant”. I hope that’s clear now…
Then, of course, when you actually need to branch, you need one of those huge switch statements. Of course, you only put in the states which are possible. Unfortunately, John quickly discovered that impossible states ran through the switch statements with alarming regularity. These resulted in exactly the sort of code fragility you’d expect if you decide to ignore pretty much every serious thinker since 1968.
It wasn’t just the screens either. Entities were designed in the exact same way.
Burn It
There are uses for flow charts, but in general terms I’d use them in informal, not formal contexts. There are definitely uses for the goto statement (as I seem to have to explain every time I use one). What made this particular practice exceptional was its cargo cult ability to impose out of context ideas from software engineering 101 and ruin developers lives. But what’s really interesting about it is the way it was exactly the same as other standardized practices.
- It seemed perfectly sensible and plausible to non-technical people. (It used all the right words.)
- It was inconsistently applied. (Because sometimes you couldn’t get work done with it.)
- Despite the phenomenal amount of documentation produced, it never exactly corresponded to the actual code. (The only people who knew this, of course, were the coders, and they knew better than to mention it.)
- When a production bug was found, it was inevitably found that some deviation from the system had occurred. That violation, and the violator, got the blame.
- Even given all of that, quite a lot of people wouldn’t hear a word suggesting that you should violate the process.
Luckily, this story has a happy ending. Six months after this, with some fairly patient and low-key lobbying, John got asked to a meeting to discuss what they should do with their development methodology. He said “Burn it and bury the ashes”.
They took his advice; he got a raise. He hadn’t actually solved the problem of Big Upfront Design, but it was a start…
Colour Coding 