Do not use technology for technology’s sake
All too often, both developers and architects fall into a trap of using technology for its own sake. In many cases this happens because the technology in question is a new, shiny toy they want to play with and learn it, but in some cases it is for purely political reasons.
I clearly remember one particularly bad example of the latter. We were working on the content management system for a large and well-known travel booking web site, using brand new web content management solution from a major vendor for content authoring and publishing.
For the most part, the system worked: authors were able to create new content, and publishing of that same, manually created content, worked just fine. Unfortunately, the architect on our team decided that in order to “impress the client” and show them how great the proprietary CMS we were using was, we had to use it to manage the syndicated content as well. This syndicated content included the weather data, which we had to update every hour.
Even though a few of us pointed out that it makes no sense to import content that will never be edited by a human into the repository and that it would be much more efficient to push it directly to the web site, the architect insisted that we do it his way, so we did. And boy, did we impress the customer by doing so…
Problem was that the CMS we were using simply wasn’t designed to push that much new or modified content at once. The import into the repository alone was taking more than three hours, with publishing to the web site taking another three or four. It was clear to everyone on the team that we will never be able to update data on a web site on hourly basis this way, but the architect still insisted on doing it his way and tried several micro-optimizations that didn’t work.
In the end, he had to give up and we ended up implementing the solution we were originally proposing and cut the total time to under 10 minutes. The customer was happy, the team was happy, but nobody had much respect left for the architect.
This work is licensed under a Commons Attribution 3
Back to 97 Things Every Software Architect Should Know home page