NOTE: As of July 12, 2009, this blog has been discontinued and replaced by the new Thought Delimited blog. All of the entries in this blog can be found there, along with new posts.
Applications Are Only as Beautiful as the Processes They Replicate
But it doesn't always work out that way (some would say it never works out that way). Most of us have had to deal with "scope creep." In fact, one could argue that most modern CFML-coding frameworks and patterns came out of the need to deal with "scope creep" and other reasons for changing our applications.
But sometimes the challenge in creating a clean application comes from the nature of the business "logic" itself, the real-world process that your application is supposed to mimic and replace. It occurred to me the other day that that is often the biggest hurdle I have to overcome with the applications that I'm asked to construct.
When I work with my clients to figure out what exactly what tasks the software needs to perform, I often discover that the processes at work are often riddled with exceptions and conditionals. Sometimes my clients are consciously aware of these exceptions, but other times I have to point them out and we have to figure out how they need to be dealt with.
We humans can handle exceptions within our thought processes very easily. Computer logic, on the other hand, doesn't handle exceptions so casually (which is probably why errors can be referred to as "exceptions"). Coding for even a single exception to an otherwise iron-clad rule can make the code involved twice as complex and perhaps a bit less than pristine.
While we do all we can as responsible programmers to deliver a beautifully-coded application, I think that sometimes there's no avoiding the touch of ugliness that comes from trying to represent and replicate an "ugly" human-driven process.
Making code bigger and uglier to handle the business exceptions "this one time" is a big part of what makes enterprises less and less flexible to their marketspace. A good example was my century of misery at a bank that offered credit cards. When they started selling them in the 1960's, there was one and only one interest rate per card. By the 1990's, there could be an infinite amount (purchase, cash, promotional, etc). Retrofitting the myriad of systems that assumed there was only one interest rate per account was a giant undertaking. (They pulled it off only because they had bazillions of dollars; but interestingly, they eventually couldn't keep up anymore and sold themselves to BofA.)
Likewise, I was told that one of the reasons AmEx lost its prominence over the years was because their IT systems were "copy-n-pasted" around the enterprise as it grew, making it impossible to maintain them effectively as the marketspace (and regulatory environment) changed. This is evident to me today when I need to do even simple maintenance on my account--every task has a separate department, none of the departments know anything about the others, and each has its own 800# with its own office hours. Once that kind of siloing is entrenched, it's near impossible to break.
So good design in an IT application has a lot of implications for the ultimate health of that enterprise. That said, it's all a trade-off. There are certainly plenty of people who overengineer things. Finding the balance is an art. But that's why they pay you the big $$$ :)
I certainly don't hesitate to advocate process changes when I think it's the best course of action, but if my customer decides that they don't want to make those changes, I don't have the clout to force the issue.
And having to accommodate those flawed processes can sometimes lead to some creative solutions that make it worthwhile, so it's not all bad.