Scot Mcphee is an Australian software developer and architect with more than 15 years of experience coding and designing applications. Over the last eight years, he’s worked mostly within the J2EE stack.
IT’S IMPORTANT TO REMEMBER when architecting a system that maintenance will, in the long run, consume more resources than initial development of the project. Shortcuts taken during the initial development phase of a project can result in significant maintenance costs later.
For example, you may have been informed that unit tests don’t deliver direct value, and so you tell your developers to skip the rigorous application of them. This makes the delivered system much more difficult to change in the future, and decreases confidence when making those changes. The system will require far more manual testing for a smaller set of changes, leading to brittleness and increased maintenance expenses as well as a design that’s not as appropriate as a fully tested design (let alone a test-first design).
A serious architectural mistake is to adapt an existing system for a purpose that it is not fit for, on the basis that using an existing system somehow reduces costs. For example, you might find yourself utilizing BPEL architectural components coupled with database triggers to deliver an asynchronous messaging system. This might ...