It’s natural that Occam-optimality is mostly focused on software. But it applies to everything from requirements to architecture and design, QA and testing, documentation, support and the endless round of changes software tends to have.
Requirements occamality
Are Occamal principles just being applied by the programmers who code up the application? If they are, that’s good, but there are steps in the software cycle before the programmers start their work, and if those steps are conducted without Occamality in mind, even if the programmers program a perfectly Occamal program, there will end up being many more lines of code than there could have been. This is easiest to see in the requirements process. Suppose one group writes up requirements for an on-line credit card application and another group writes up requirements for an on-line application for a term loan. The requirements are likely to be similar because the same kind of data needs to be collected in both cases. But what if one group takes a very matter-of-fact approach, while the other emphasizes fancy graphics, visuals and user interaction? Once those requirements come to the programming group, unless that group is amazingly perceptive and aggressive, the two sets of requirements will be treated as wholly unrelated projects. In other words, business as usual.
Imagine, on the other hand, that the people thinking about requirements are familiar with Occamality and want to apply it. Rather than starting from scratch, they may look for places where the data they need is already being collected – maybe this new project is an opportunity to unify some existing code, and bring it into the Occamal world. In any case, the two groups will decide that they’re really one group with a couple of minor differences between the two applications, and they’ll also realize that the styles of user interaction will change over time, so they’ll take some effort to separate that out from the actual data gathering. The net effect is likely to be a set of requirements that are “pre-occamized,” that should not take much transforming for the software group to implement in an Occamal way.
If software requirements aren’t Occam-optimal, the software may be occamal in some abstract way, given the requirements, but the requirements themselves may demand a solution that feels like there are all sorts of special widgets and do-hickey’s that could just as well be dispensed with. In other words, Occamality is best achieved if it is a conscious goal from the very start of the requirements process to the end.
Here are some reasons why it’s important to think Occamally in the requirements:
- Redundant requirements or ones with trivial variations normally result in needless redundancy in all the following steps.
- A set of requirements that are similar in principle but different in detail are frequently over-defined and over-refined, creating work that delivers no value.
- People who create requirements frequently know a great deal about their subject and have thought about it long and hard – and the more they know and think, the more extensive their requirements are likely to be, which is often a problem.
Software requirements people frequently resemble the washing machine designers I have described who optimize what they do over a very narrow domain. The result is screens and functions that are highly customized to the job for which they’re intended. Every bit of customization adds that much more to what has to be programmed, tested, documented, taught, learned, used and maintained. This is typically a very large cost for an assumed benefit that often isn’t even there, because people find uniform programs easier to learn and use.
The consequences of applying Occamality as broadly as possible in the requirements will roll down the line of testing, documentation, roll-out, training and support, saving time and money each step of the way.
Software scope occamality
If you look at 100 lines of code, you may be able to find some redundancy, but probably not too much. If you look at 1,000 lines, 10,000 lines or 100,000 lines, there are likely to be whole gobs of redundancy.
When you cross the line from one officially-designated “program” to another, you greatly increase the odds of finding redundancy. Within a single program or project, there is only so much you’re like to find. But particularly within a single business, the same things come up over and over, and get solved over and over again, each time in slightly different ways.
Things begin to get interesting when you cross traditional software boundaries, like from user interface to application programming to network to database. In each case, there are frequently specialists who do things in their own way. If, as is likely, they have caught the “object orientation” bug, they each attempt to create their own little worlds of nicely designed classes/objects. But when you look at the project as a whole, and you think of something like “account number,” think of the number of times and places and ways that concept has been defined. Even within one of those domains, like the application, an account number data element will be defined as part of each class, and will appear every time account number crosses to or from the database, and again every time account number crosses to or from the user interface. You’ll find that “account number” is all over the place! If you have any question about this, just try to change the data type, label and error checking for it, and see how many places you have to touch to make it work.
Software architecture Occamality
Occamal thinking is crucial in the architecture and design of the software:
- Achieving Occamality frequently involves introducing a strong but appropriate amount of abstraction into the program design. Simply translating requirements with minimal abstraction into objects, schema designs, etc. typically leads to huge amounts of redundancy.
- If you just focus on the text of the code, you may find little redundancy. But you may also be able to achieve substantial code reductions by taking a whole different approach.
Software QA Occamality
The usual approach to QA is highly redundant and un-optimal. When QA automation is normally performed, it is highly redundant, and leads to a system that doesn’t have better quality but is even harder to change. Typical script-based automation ends up having the effect of copying variables already present in the program in a different environment (the QA one), and creating logic that reflects and is derived from the base program. This approach to quality automation clearly reduces the quality of the overall program, and certainly reduces its occamality of the overall software effort The ideal approach is highly automated, fully supports occamal software, and indeed is occamal itself. See this for more details.
Later stage Occamality
Post-coding software steps benefit indirectly from smaller code and less redundancy, but in addition, Occamal thinking can benefit them directly.
- Occamal thinking applies to documentation and help text. The arguments about redundancy making documentation more difficult and error-prone to change apply fully.
- Let’s not forget the users! Chances are excellent that additional code is the direct result of input from some users, but most users will suffer as a result. Every concept, field and command you eliminate is one more thing users don’t need to worry their little heads about.
It is important to focus on Occamality in the code. Extending it to encompass the entire life cycle of software is what delivers big benefits. Post-hoc design as described here is a practical approach to accomplish Occamality in waves, without going too crazy trying to do everything perfectly.
Comments