Complexity Costs

I recently brought my dream motorcycle. It’s an incredible piece of engineering with all the polish you would expect for a prestigious European brand name. However, there are a number of design issues that I scratch my head at and ask what were they thinking? For example, there are 3 buttons to use the blinkers, one on the left (used to turn left) and one of the right (used to turn right) and then another to turn them off (after you have completed the turn). The other bikes I have owned in the past had one button that does all those functions. Eventually you get the hang of how it all works but it did get me thinking about engineering processes. Why do people over engineer and therefore introduce complexity? 

We know that, especially from an IT sense, complexity equals increased cost and in an economic environment of cost reduction why isn’t there a much greater focus on reducing complexity? It seems to have slowly but surely crept into all organisations as they invest more into their IT systems. More systems are being introduced into the eco-systems but few of the older ones are actually being turned off. I have read numerous articles and commentary around the subject so people do see this phenomena taking place but I see little real action on doing something about reducing it.

I understand, once the problem has been identified, things might seem a little overwhelming and difficult to know where to actually start but breaking capabilities down piece by piece will make this task a lot easier. Identification of a use case to trial new approaches is a well-trodden path and usually a less risky approach but, like most investment strategies, there is a risk versus reward balance that needs to be taken. I would approach this from my “what’s my most pressing problem” angle. For example, a common problem I am seeing across town is CIO’s getting pressure from their business around their teams’ long software release cycles. I would firstly break this issue down into a plan for further analysis. Are there metrics in place over the development lifecycle that measure the time taken in each phase? 

This is important as I have seen many organisations investing into areas which make little impact on the end result. The buzzword getting airplay at the moment is ‘devops’ and this is seen as the way that IT can improve agility but that’s not always the case. For example, improving the coding, testing and delivery phases will make little difference if the bottleneck in the process is the requirements analysis. That said, in most IT shops the creation of environments for development and testing are usually an area of pain and on-going expense. This is where environmental automation can really pay dividend and potentially where a cloud based approach could come into its own. Building a test environment with its associated hardware, software and supporting utility costs can be a big expense especially if it’s only used during an 8 week user testing cycle. Having the ability to effectively ‘rent’ that environment only when needed may be a better approach. But to leverage these types of cloud hosted capabilities, standardisation and automation of environments is a precursor and this is where the area of real investment is required. It’s an overused maxim - it is a journey but capability in this space takes time as skill-sets develop and supporting processes mature.

Over the years, IT areas have customised their computing environments for various reasons resulting in, at times, hard dependencies written into software. It will be another expense to change but this investment will likely pay dividend over time. However, this also may be the logical point to assess whether your bespoke software is still fit for purpose. Is it time to look at the market and see if another commerical software product can meet the business need instead? The Software-as-a-Service (SaaS) marketplace is maturing quickly and this reduces a lot of risks from the old days of doing IT projects. It might also provide the opportunity to engage the business in changing their business processes and leveraging the out-of-the-box SaaS processes instead.

Keep in mind not to over engineering this stuff either – it needs to be kept simple and targeted at fixing the right problem (see: Do we really understand what the problem is?). The SaaS service you buy may not meet all your needs but it may work out that it is simpler and far cheaper to compromise than to have everything you want. Just like when buying a new motorbike or car there are options which are nice to have’s that need to be evaluated against the (whole of life) cost. You also need to keep reminding yourself that if the option is going to make the system more complicated it is going to result in increased costs - albeit you may not be able to see it initially. The best advice I can provide you in this space is to keep things as simple as you possibly can.