Software Architect

Your system is legacy, design for it.

Book: 97 Things Every Software Architect Should Know
Publisher: O’Reilly Media
Author: Richard Monson-Haefel
97 Things Every Software Architect Should Know – 65/97

'Coz sharing is caring

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.

'Coz sharing is caring

By Swatantra Kumar

Swatantra is an Open Source evangelist, a technologist and researcher. Professionally, he does software development, software architecture, server administration and project management. When he's not writing software, he enjoys building web entities and servers, reading about and working with new technologies, and trying to get his friends to make the move to open source software. He's written, co-written and published many articles in international journals, on various domains/topics including Open Source, Networks, Computer Organization, Mobile Technologies, and Business Intelligence. He made a proposal for an information management system at University level during graduation days.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.