Category: Software Architect

Even if your system is bleeding edge and developed in the latest technology, it will be legacy to the next guy. Deal with it! The nature of software today means things go out of date fast. If you expect your system to go into production and survive, even for a few months, then you need to accept that maintenance developers will need to fix things up. This means several things:

Clarity – it should be obvious what role components and classes perform.

Testability – is your system easy to verify?

Correctness – do things work as designed or as they should? Eliminate quick and nasty fixes.

Traceability – can Ernie the Emergency bug fixer who has never seen the code before jump into production, diagnose a fault and put in a fix? Or does he need an 8 week handover?

Try to think of a different team opening up the codebase and working out what’s happening. This is fundamental for great architecture. It doesn’t have to be over-simplified or documented to the hilt, a good design will document itself in many ways. Also the way a system behaves in production can also expose the design. For example, a sprawling architecture with ugly dependencies will often behave like a caged animal in production. Spare a thought for (usually more junior) developers who may have to debug defects.

Legacy tends to be a bad word in software circles, but in reality, all software systems should endure the tag. It is not a bad thing as it may indicate that your system is durable, meets expectations and has business value. Any software system that has never been called legacy has probably been canned before launch – which is not the sign of a successful architecture.

Every decision we make for our projects, be it technology, process or people related, can be a viewed as a form of investment. Investments come associated with a cost, which may or may not be monetary, and carry trust that they will eventually pay off. Our employers choose to offer us salaries in the hope that this investment will positively affect the outcome of their venture. We decide to follow a specific development methodology in the hope that it will make the team more productive. We choose to spend a month redesigning the physical architecture of an application in the belief that it will be beneficial in the long run.

One of the ways of measuring the success of investments is by rate of return, also known as return on investment (ROI). For example, “we anticipate that by spending more time writing tests we will have less bugs in our next production release”. The cost of the investment in this case is derived from the time spent writing tests. What we gain is the time saved from fixing bugs in the future, plus the satisfied customers experiencing better behaved software. Let’s assume that currently 10 out of 40 working hours in a week are spent fixing bugs. We estimate that by devoting 4 hours a week to testing we will reduce the amount of time spent on fixing bugs to 2 a week, effectively saving 8 hours to invest in something else. The anticipated ROI is 200%, equal to the 8 hours we save from bug fixing divided by the 4 hours we invest in testing.

Not everything need directly translate in monetary gains, but our investments should result in added value. If for our current project, time to market is essential to the stakeholders, maybe a bulletproof architecture which requires a lengthy up front design phase will not offer ROI as interesting as a swift alpha release. By quickly going live, we gain the ability to adapt to audience reactions that can form the deciding element to the future direction and success of the project, whereas not thoroughly planning can incur the cost of not being able to scale the application easily enough when the need arises. The ROI of each option can be determined by examining its costs and projected profits and can be used as a base for selection between what is available.

Consider thinking of architectural decisions as investments and take into account the associated rate of return, it is a useful approach for finding out how pragmatic or fit for purpose every option on the table is.