I try my best to get things right the first time. So often, correcting a mistake or bad choice is costly: more costly than it would have been to take the time to do it right the first time. However, as SQL Server MVP Andy Leonard points out, sometimes you can't correct an issue.
He starts with the example of a camera and taking a picture out of focus and then brings it around to development. His example is great: you can't provide up to the second updates to a system than only collects data every five seconds. Well, you can, but the data is only going to change ever five seconds. This raises the question often asked by learning styles expert, Cynthia Tobias, "What's the point?" What's the point of refreshing every second if the data is changing only every five seconds? There isn't one. It's just a waste of resources.
In architecture, whether it be application or database architecture, as Andy speaks about, or infrastructure architecture, design choices have far reaching impact. If we have to change some of these choices in the future, the cost can be great. Andy's analogy of deflecting an asteroid is extremely appropriate: the sooner you realize you need to make a change, the less it typically costs you. Wait too late and you may not be able to do anything about it at all.
Going back to my days as primarily a web developer, I remember that where I was working at the time there was a strong push to put as much application logic as possible in ActiveX .DLLs. The web site would be built in ASP code and the amount of traffic (concurrent usage was probably going to be 25-50 users) wasn't expected to be terribly high. It was an application internal to the organization with no sensitive data. In addition, much of the logic was relatively simple: query from the database the metadata for the site and build the HTML code (simple things like tables, links, and lists) to structure it. There weren't complex calculations; result sets were often < 50 rows and at worst were no more than about 500-600 rows. Finally, there was an unspoken requirement to be able to change code out quickly without taking the system down.
If you're keeping score at home, this is a lightweight web application with a requirement to be extremely flexible for updates while the system was up and running. In other words, that ActiveX .DLL was not the right way to go. However, because the technical lead insisted on using ActiveX .DLLs, we did it that way. The better architectural decision would have to been to write the application logic in the ASP pages themselves.
Fast forward to the first time we had to make a significant change to the application. We made the changes and compiled the .DLL. No problems there. But then we went to deploy it. IIS had references to the ActiveX DLL and that meant in order to change it out, we had to stop IIS. Remember that requirement about making changes without taking the system down? That wasn't possible. We minimized the downtime to a few seconds but wouldn't you know it? The extremely short outage for this web application, though the app didn't have a lot of concurrent users, though we chose to stop IIS at lunch time when most workers are browsing ESPN if they're looking at web sites, and though the app wasn't mission critical, was noticed.
We were asked to remedy the situation and ended up doing a partial rewrite of the application. All the code that was in the ActiveX .DLL was moved out and put into the ASP pages. And while we made a few other optimizations and improvements, the bulk of our time was spent on stripping the ActiveX .DLL out. That took the better part of a few months, almost as much time as was spent on developing the application in the first place. Had we decided to forego the ActiveX .DLL in the first place, we wouldn't have added any time to the initial development effort. On a related note, after the changes were made, there was no noticeable performance loss now that the code resided in ASP pages rather than in a compiled .DLL.
This was a relatively simple example of where a decision had a later and more costly impact. Andy points out the issue with losses over time and the impact of inefficiencies which occur early on. Getting it right (or as right as possible) as early as possible saves us tremendously in the long run.
Technorati Tags:
