Tag: Architect

When choosing software frameworks as a basis of your system, you must consider not only the individual quality and features of each framework, but also how well the set of frameworks that make up your system will work together, and how easy it will be to adapt them to new software you may need to add as your system evolves. This means you must choose frameworks that do not overlap and that are humble and simple and specialized.

It will be best if each framework or 3rd party library addresses a separate logical domain or concern, and does not tread into the domain or concern of another framework you need to use.

Make sure you understand how the logical domains and concerns addressed by your candidate frameworks overlap. Draw a Venn diagram if you need to. Two data models that overlap substantially in domain, or two implementations that address very similar concerns but in slightly different ways, will cause unnecessary complexity: the slight differences in conceptualization or representation must be mapped or patched with kludgy glue code. Chances are you’ll end up not only with complex glue, but also with the lowest-common-denominator of the functionality or representative power of the two frameworks.

To minimize the chance that any given framework will overlap with another framework, choose frameworks that have a high utility to baggage ratio, in the context of your system requirements. Utility is the functionality or data representation that your project needs from the framework. Baggage is the framework’s sweeping, all-encompassing, I’m-in-charge view of the world. Does it insist on mixing data representation and control? Does its data model or set of packages and classes extend well beyond what your system needs? Do you have to become a fundamentalist in the framework’s religion, and limit your choices of other frameworks to those of the correct denomination? Does its excess complexity limit the kinds of things you can mix with it? If a framework comes with lots of baggage, then that it had also better be providing 75% of the functionality value in your project.

Your system should be comprised of mutually exclusive frameworks, each of which may be a master of its domain, but which is also simple, humble, and flexible.

It will never look like that. It is all too easy to fall into the trap of investing large amounts of time in a design and being confident that the implementation will come out the same. A detailed design can easily fool you into believing you have every angle covered. The greater the detail and the more in-depth the research the greater your confidence in it. But it is an illusion: it will never look like that.

The truth is no matter how in-depth, how well researched and how well thought out your design it will never come out looking the same as in your head. Something will happen, an external factor may effect the design: incorrect information, a limitation, an odd behaviour in someone else’s code. Or you may have got something wrong: an oversight, an incorrect presumption, a subtle concept missed. Or something will change; the requirements, the technology, or someone may just find a better way(TM).

Those minor alterations in the design soon stack up and lots of minor alterations soon require that one big one has to be made. Before long your original concept is on the floor in pieces and its back to the drawing board. You decide what you needed was more design, more detail, so back you go and the next architectural vision is clearer, more radical, more perfect than the last. But before long the same thing happens, those changes start to appear and shift your design and developers keep shoving in more and more stuff trying their best to work around the broken design but just breaking it more and you end up screaming “of course it’s got bugs; it was never designed to do that!”.

Design is a discovery process, as we implement we discover new information, often impossible to know up front. By accepting that design is an ongoing and empirical process in a forever changing world, we learn that the design process must be flexible and ongoing too. Clinging onto your original designs and trying to force them through is only going to end up with one result so you need to learn to understand that it will never look like that.