The Truth as I See It: Part 4
In Part 1 of this series, we talked about why maintainable code was important, and how it compares to other priorities in the software development cycle. In Part 2, we talked about the concept of code decay, not as an effect of bad coding practices, but as an effect of changing environments. In Part 3, we talked about the concept of how user expectations can affect the phenomenon of decay.
In Part 4, I want to start looking at measures you can take to fight decay.
If decay is created by changes in context, one way to fight decay is to never change your context. If you're still running Notes v3, for instance, then your v3 apps probably have not been eclipsed by the underlying platform. You still don't have Lotusscript or Java available to you to address new problems.
That might sound like a ridiculous example, but I guarantee you that you know organizations that do this. They're the shops that are still running Notes 5 because "it's too expensive to upgrade because we'd have to retest all our apps." What they're really concerned with isn't the expense of testing -- it's the risk factor of NOT testing combined with the difficulty in addressing problems that might arise in the new context. They fight decay by not moving.
Of course, we know the consequence of this. Users don't live in a vacuum. They see Apple and Cisco ads on TV, or look at stuff on the web, or read a magazine and go "wow, look at all these cool things that other people are doing with computers. Why don't we have this?" And if that user happens to be a C-level executive, then the migrations begin.
So if standing still is a losing strategy, what's the alternative?
(continued...)
I think it's to design in a way that's more maintainable. What's maintainable? That which can be adapted by a competent developer to address user expectations and technology advancements at a fast rate and minimal cost. In other words, designs that are easy to change, even if you weren't the one that built them in the first place.
In achieving maintainability, technology choices matter. The most important choice is standards, and where open standards really prove their value is in maintaining systems. If you design to an open standard, then the portability of your code becomes dramatically improved. Language choice is also very important, as it will tend to dictate both the amount of code you need and the redundancy of logic required.
As it turns out, Notes/Domino is terrible for language consistency at the moment. Because there is no single persistently available language, you cannot create a single set of logic for all aspects of your application, if you expect to support all the run environments that the platform addresses. The closest you can get is some combination of Lotusscript and Javascript. (One of the reasons I was excited to mention the forthcoming Java UI stuff recently is because that plus Xpages means we'll finally be able to put every single bit of business logic we ever need in Notes and Domino into CLASSes. Since you'll be able to call them from the Eclipse UI, and call them from Xpages, you'll be able to use them everywhere. I intend to run head first towards this new opportunity.)
Deployment strategies count, too. As I pointed out last time, Domino is a great platform for rapidly deploying application changes, as the replication, inheritance and flexible data models pretty much remove the complexity of human involvement in deployment. You can rollout basically as fast as you can test.
Improving maintainability is also why smart architects emphasize the division between logic and UI. There are many excellent reasons to accept tight bundling between them in a given design, mostly related to time-to-market and cost. But make no mistake, if you're not segregating data from logic from UI, you are decreasing the maintainability of your code, and therefore accelerating its decay.
And let's not forget stylistic elements of your coding. I recently saw an application at a customer site where the application was loaded into a frameset, which contained a frame that submitted a form on it's onLoad, which then ran a WebQuerySave, which built some values into fields of another document, which was then rendered using inline pass-thru Javascript combined with computed for display fields that refered to JS libraries from ?OpenPage references that were written in @formula in the HTMLHeader formula of the form, and used those pass-thru values to then do document.write calls against the resulting output on the screen.
Does that seem like it's maintainable? If there's a bug, how to you trace something in that context? But this is common practice in the Domino world. And no wonder people fear upgrading the platform version with such tangled designs running on them in the first place.
Maintainable designs require good standards for how you write them. (eg: Options Declare) Even better are when those standards are enforced by tooling. Any time you can enforce good standards by tooling, you create a leverage effect.
In Part 5, I'll talk about why this leveraging is so vital to a design's success, and give some concrete examples of how we use tools at Lotus 911 to maximize the effectiveness of developers (and how you can too!)
Comments
I think there are users like this but there are others too. For example, I created and administer a web site that is used by people who submit their papers to an annual conference. This system has been in operation for about seven years. It's not the prettiest web site nor does it use Web 2.0 jazz. It is pretty easy to use and get's the job done.
Do you think the users really care much about how it looks or if it uses Ajax? I don't think so. I think all they care about is can they get there paper uploaded and find out if their paper was accepted.
Peace,
Rob:-]
Posted by Rob At 02:27:14 PM On 09/16/2008 |