Hurlyburly.
Complicated business, this software development.
So many things.
So much stuff.
You're making a web front-end for your business? Fine, then you'll be needing a programming language or two. Every front-end needs a back-end, see. Compilers, versioning tools, IDEs, automated test environments, dependency management tools, deployment tools, application-servers, hot updates, internationalization. Web, you said, right? No problem. HTML, CSS, JavaScript, ASP.NET, DQT, EJB, AJAX, RSS, CRM, IIS, insane browser ridiculousness, cloud fiddliness, relational database, SQL, ORMs. To name but a few. And we haven't come to the hardware yet. (And DQT was just made up.)
Take all the above and put it all in a large pot of boiling water on a huge stove in some flash, restaurant kitchen. No, make that a cauldron on a log fire in the woods. With those three witches from Macbeth. You remember, eye of newt, toe of frog? Anyhow, put all of the above in the cauldron and have one of the witches stir it for a few hours. Ladle off the scum once in a while. Evaporate away all the impurities. Boil it down to its essence.
What would be left behind?
Your answer to that will probably reflect your particular trajectory through the technology stratosphere but are there any core concepts upon which all might agree?
When shall we three meet again?
Here's one proposal: the three-box model. (Eeuuww, a technology stew boiling down to three boxes ... a metaphor angel weeps somewhere.)
The three-box model is almost entirely un-new and is one of those horribly faffy, hand-wavy gizmos that already clutters the web, but it has a point, which we shall address later. It says that there are three important concepts in software development:
- User-experience capture.
- User-experience realisation.
- Structure.
User-experience capture means figuring out what your customer wants.
User-experience realisation means building what you think your customer wants.
Structure means the structure of the program you have built to deliver what you think your customer wants.
All three have been around since software began. User-experience capture includes most of what they called (way) back in the 90s, "Requirements analysis." If you're lucky, you can probably knock on your customer's door and ask her what she wants. You're probably not, though, so you might have product managers and key-account managers to do metaphorical knuckle-rapping.
User-experience realisation includes the design, implementation, verification and deployment of the software that will bring all the promised goodness to your appreciative customer.
Structure means the sets of program parts, and their inter-relationships, that contribute to the product you've just delivered, no doubt on-time and under-budget.
Again, not much new here.
Things become a little more interesting, however, when we think of quality.
Of course, "Quality," and, "Interesting," seldom rub shoulders in the same sentence but this might just be one of those times when putting on our quality-goggles brings us a refreshing perspective shift on what we do.
We are used to thinking of quality as a rather monolithic edifice. Towering and singular. Good quality: good; bad quality: bad.
The three-box model, however, invites us to smash this quality facade and pull from the wreckage three separate components of quality. For each of the three boxes of the three-box model manifests its own quality, a quality which most clearly exposes itself when things go wrong.
Dwindle, peak and pine.
When we have poor quality during user-experience capture we either fail to capture the right user experience or we successfully capture the wrong user experience. The resulting product will either fail to do what the user cares about or does what the user doesn't care about. Or, when try really hard, both.
Poor quality during user-experience realisation means building a product that does not deliver the captured user experience.
Note the trap. Even excellent quality in user-experience realisation box cannot guarantee happy customers. If quality during user-experience capture was low then you will simply build a great implementation of something your customers didn't want. Your customers, tempest-tossed, will drift into the harbours of others.
So, what of the third box: structure?
Let's say you've captured the right user experience and you've successfully realised the user experience with a product. A user using the product actually says, "This is so good I'm going to redefine my entire life around it. Here's a blank cheque, my home and my dog, Rupert." Why should we care about bad quality in the structure box if our users say this?
Here we discover the essence of structure and its role in software development.
Bad quality during user-experience realisation is generally seen as a bug, a run-time manifestation of an underling problem. Your application's inopportune crashing gives your user immediate and distasteful feedback. Your user feels the bad quality viscerally.
Your user never has this visceral, immediate reaction to low-quality structure because this structure is never delivered to your user.
Structure is a property of the source code not the run-time object code that furnishes the user's experience. Structure has nothing to do with the immediacy of user experience.
Structure, instead, concerns the cost of change.
If the quality if your structure is good then a small change made to your source code will entail low probability of high cost. If the quality of your structure is bad then a small change to your source code will not entail a low probability of high cost.
Of course, this will indirectly affect your users. With low-quality structure and high change-costs, your source code will admit new features only slowly and your users will have to wait a long time before they can pay for, and play with, these new features. This, however, is not the immediacy of user-experience realisation low-quality; it is a long-term force that your users will neither appreciate nor acknowledge.
Structure only affects users indirectly but we must not not confuse indirectness with unimportance. Unsatisfied customers will simply switch to someone else's product, puzzled that the company that once delivered their dreams have decided not to bother delivering anything.
Sadly, low quality in the structure box rarely results in bug-reports.
Where noticed it is often considered an inevitable consequence of software growth. Yet some would argue that not only should bad structure be reported as bugs but it is conceivably more important than any user-experience realisation bug. User-experience realisation bugs, after all, enjoy the use of immediate and clamorous feedback channels. Structure bugs enjoy none. In matters of structure, the programmers themselves are the last line of defence.
Summary
The three-box model claims that software development can be viewed through three lenses:
- User-experience capture.
- User-experience realisation.
- Structure.
Yes, software is complicated. New buzzwords and techniques pile upon us daily. It is easy to ridicule any model that attempts to boil the broth of software modernity down to just three concepts. The value of any such strange intelligence must be judged on whether it reflects the fundamentals that remain otherwise obscured by technology's fog and filthy air.
|
