One of  the most significant challenges as a developer – especially when working as a consultant (though not mutually exclusive) -  is the need to understand a completely alien software system very very quickly, and to be productive in adding new functionality to that system, consequently value, to whatever the project may be. One must cultivate procedures and practices that allow for the rapid addition of development requests that are fit for purpose.

Probably the biggest hindrance in all software development is developers that suffer from “not invented here, I didn’t write it” syndrome. Frequently, I encounter developers that cannot work on a piece of code without completely re-writing it, frequently either ending up with exactly the same functionality as the code they replaced or reinventing a square wheel i.e. one finds that one is actually are worse off from a code maintainability standpoint.

The role of any Software Architect or Team Lead, is primarily to ensure that the overall architecture of  a software system is sound i.e. well designed and robust, lending itself to the addition of new functionality without breaking or changing existing code. This is by no means easy, and the challenges of building software systems are well known, but software architecture is now no longer in the dark ages, established design patterns that resolve most system issues are abundantly available. This most important part of any software application, I cannot but help but to draw attention to that fact, getting this wrong, with the knowledge that you will have developers of varying abilities and skills during the lifetime of the application, is all but a recipe for failure.

Design

The architecture of the application must be a policy and this must be enforced. The architecture must make it difficult for developers to just do what they want by requiring that they have to either take a few extra steps in their algorithm or think differently (but the same for everyone else) in resolving whatever they are tasked with. This however, must be a justified design decision, and not loose coupling just for the sake of loose coupling i.e.using interfaces between layers for example, usually forces composability from developers where they would usually use direct call backs. I have seen systems quickly turn into big balls of mud because of this, and the larger the system that bigger the ball of mud.

Since the overall architecture has been formalised, what remains is in adding the functionality of different rooms. The Drawing Room in the home above, must have all the features and components that allow it to function as such. This is analogous to any feature in a software system. It is difficult for your typical programmer to see a software system in its completeness like the house above, so it is the Architects responsibility to ensure they are aware of what is required of them. Most developers don’t like being restricted in how they are allowed to solve a problem, because most developers are not Architects, and are seldom able to design a coherent and robust system. Rewriting code someone else has written for the most part is usually an exercise in absolute futility. One cannot count the times that programmers habitually duplicate functionally that already exists, and how negatively this impacts a projects progression. It is very easy to lose weeks and even months of development time, all because developers were unable to augment existing code that was already working.

Sawdust

If you task a typical programmer to design and develop a piece of functionality in an application, that has specific functionality, the results are often surprising. Requirements for software usually result in a single piece of functionality, lets take a chair for example.

I am certain the audience knows what the prime functionality of a chair is so I shall not elaborate, why should software be different? The objective for any programmer is to get the requirements realised in as short a time, but as functional as possible. Most programmers never create a chair that is simple and functional but end up with this.

Really skilled developers will give you something like a Futon

Most developers spend and incredible amount of time creating sawdust, separating logic and creating loosely coupled components when a lot of the time this is not required. Developers often try and use their glass ball imagining future use cases and try to always create components that can be extended to have dual or many other uses e.g. the Futon above. This is wrong! Oftentimes, all you want is a chair. All the requirements in the software specification ask for is a chair and the developer ended up creating a Futon, then are perplexed when they receive lukewarm responses or even complaints that they have designed something that was not required.

Single responsibility is frequently misunderstood, and is a prime reason that programmers rewrite existing code a lot . Usually the argument is that “I had to split the code into this class, and that class, and the other class because I wanted to create a software component where single responsibility was as clear as possible”. The result almost always is sawdust, and fine grained sawdust at that, because well architected software systems usually just need software components like the chair. It is sometimes hard for intelligent developers to accept that a lot of the code they write at times can be solved very simply, their overactive minds end up creating a software system that is bloated with classes and code that will never ever be used because you aren’t going to need it.

The Graduate

It seems almost unfair to include graduates as prime candidates for reinventing wheels, but they almost always are the people that do this the most, including Masters up to and including PhD students.

In any software team, you need bright and talented individuals, especially where you are solving domain specific problems. Their importance cannot be overstated here, but with this comes a lot of baggage. It can be very challenging managing a team of incredibly gifted developers. Inexperienced developers of any academic background can also be a drain in resources. A simple problem is usually solved by using the most complex algorithm, when something simpler was required. It seems inconceivable, but most of the hardest problems to manage in complex software systems are usually a result of the smartest people in a teams undue influence. If people are very smart they are hardly ever questioned to justify their choices. I have encountered software where you are told that users hate using the application because “you require a PhD to use the software”. This complexity invariably stems from the source code, thus, it is important to accept that smart individuals always find ways of solving the most difficult problems, but can also be the reason why some problems in complex software systems are difficult to solve because simplicity is seldom a prerequisite in resolving issues.

The long-and-the-short-of-it is that the goal of any software is for people to use it, and most success is based on simplicity and easy of use, which also is true for maintainable software systems. Working software seldom needs to be completely re-written because it works. Improvements can always be made to any software because there are no perfect software systems, so save yourself the time and effort by learning other peoples code rather than rewriting it, this will allow you to solve more problems, add more features and provide real value to a project.