http://blogs.modularity.net.au/thenextbigthing

So how can we protect our software designs from such a seachange in required functionality? In addition to accepted practices and methodologies, we should try to incorporate the following principles into our architecture:

• Think Small Usually when we design architectures the components tend to be large and provide support for a multitude of features. It is not uncommon to even have a single component representing the front end, back end, or business rules of a system. Combined with the principle that a good design will explicitly identify each component’s roles and responsibilities, we find our components are too rigid and not really amenable to changes in these roles and responsibilities. The solution to this problem is to build smaller, more specific components. Rather than components handling many different tasks, we should design the architecture in such a way that each component is responsible for handling a single task. Such tasks may include support for a specific protocol or data format, a service used to access an external or legacy system, or even data structures specific to a particular feature in the system. The important thing to remember is that a component should only handle a single task rather than a collection of them as is the popular approach.

• Separate APIs from Implementation Another recognised good practice is the use of Interfaces when designing an API allowing components to communicate with each other. By using interfaces we are effectively defining the contract a component holds with the rest of the system, irregardless of the implementation details. Whilst this allows us to provide alternate implementations of the API without further changes to external components, we still generally need to provide an entirely new version of a component – even if the API itself has not changed. Although the API is not bound by the implementation, usually the entire API (interfaces and implementation) are bundled together anyway. The solution then is to separate the API definition from the implementation and provide them as two distinct components. By doing this the API specification does not require updating where only the implementation requires changes. Additionally, alternative implementations of the API may also be deployed independently, thus maximising the possible re-use of a component API.

• Loose Coupling A major contributing factor to the complexity of software are the dependencies each component has on its peers. Aside from the careful design decisions required to ensure no two components are dependent on each other (i.e. cyclic dependencies), typically where even a single dependency is not resolved the entire system will fail. To avoid architectures easily susceptible to such a catastrophic failure we need to maximise decoupling of components. This does not necessarily equate to minimising dependencies across components, but rather is more concerned with ensuring that such dependencies impose as little restrictions as possible. This is the promise of Loose Coupling, whereby individual components may operate independently or as a part of a larger system constructed of similarly loosely coupled components. One popular approach to incorporating Loose Coupling in software design is the Inversion Of Control pattern (also known as Dependency Injection). A number of frameworks based on the Inversion Of Control pattern are now available, which assist in the “wiring together” of individual components to construct a complete system. This encourages greater encapsulation in components and simplifies other aspects of quality assurance such as unit testing.

By adhering to these principles we are able to design software that can adapt to just about any change in direction required of it. No longer do we need to throw away an entire system and start from scratch, as we will be able to incrementally upgrade and replace individual components without detriment to the rest of the system. This approach also enables us to extend the functionality of the system by “wiring in” new components as required. Best of all, these principles ensure that the software architecture is built from clearly defined design contracts and encourages maximim re-use.

In the consumer software industry the quality of software has not been the primary differentiating factor in consumer choice. As end-users we cannot see how a software title was built, what development patterns were employed, or even what language was used to build it. More importantly we cannot see how many unresolved bugs there are, for which we leave it to the discretion of the software developer to inform us (if they are even aware themselves!).

And so in the absence of a qualitative analysis of software (excluding user interface design), we must rely on a quantitative assessment, or a comparison of features. Software features have come to be known as innovation in the software industry, possibly as it conveys some kind of magical ability to invent something entirely new. In reality much of this innovation is not in fact entirely new, but rather a rehash of old ideas or, more likely, a feature copied from someone else. Now contrary to so much of the discussion surrounding software, there is nothing at all wrong with this. In fact it is in the very nature of software development to recognise a good idea and re-use it. Perhaps it is the common approach of claiming innovation, without due credit to the originator of the idea that creates so much hostility. Whatever the cause of this slightly misguided animosity, we should not deny that re-use of innovation, whether it be an idea or an actual implementation, is an integral part of software development.

Recognising that features are the differentiating factor in software, many companies have adopted a two-fold approach of adding as many features as possible, and protecting those features from getting into the hands of the competition. Now of course noone can stop another from reimplementing a feature found in competing software (although they do try!), but you can protect your own implementation, which at the very least makes it more difficult for others to duplicate. Or at least it used to. Nowadays we find large companies have vast teams of developers that can implement anything that you ask for. The hard part is knowing what you want to implement, and when all else fails, just look to a competitor for inspiration.

So whilst this feature arms-race continues amongst the largest companies, we see the intended effects of feature dominance becoming more neutralised. There is however another, possibly unintended, effect, which is that smaller companies and individuals are becoming increasingly locked out of the competition. If you cannot afford an army of programmers to keep up with the feature sets of the most popular software, how will you ever compete in a feature-dominated industry?

In the face of such marginalisation many have now put their faith in Open Source. Open Source provides individuals and smaller companies with that “army of programmers” needed to compete with the larger companies. But perhaps a more interesting aspect of Open Source is that it does not discriminate. The largest of companies are also able to incorporate Open Source software into their business model, which then begs the question, is Open Source really changing anything? To which the answer is an emphatic yes. If Open Source software is able to keep up with the feature arms-race of the largest companies, putting such features in the hands of everyone, there will no longer be a feature arms-race, or at least not on the scale that it is today.

So what does this mean for the future of software? Well for a start it means less emphasis on features, leaving room for a more qualitative analysis of software. Aside from giving equal access to feature implementations, another driving factor of Open Source is the qualitative analysis that goes with it. As financial reward is less of a concern when developing Open Source, we place greater emphasis on writing better code, so as to gain the reward of respect, recognition and popularity of our software. With quality being such a major emphasis of Open Source, proprietary software developers will be compelled to prove a similar quality of software in order to compete.

Some larger companies have suggested that by neutralising their competitive edge through feature dominance, Open Source is stifling innovation. On the contrary, by giving everyone a level playing field Open Source has once again made it possible for anyone to innovate. These larger companies seem to have the idea that they are the leaders of the industry and as such should be responsible for all innovation. In reality, as we are shown time and again, real innovation in software comes from individuals, not from task groups and think tanks. Such individuals may work for large companies, small companies or no company at all. Wherever they may be, we cannot force, or even predict, who will innovate next. All we can do is create the best possible environment for encouraging such innovation, and the best possible environment today includes Open Source.