The famous Tony Robins once said “The enemy of execution is complexity”. This is a powerful quote which is specifically relevant for software development projects as the biggest challenge, simplicity is a difficult thing to achieve. Distilling something down to its essence can take time and a great deal of thought and effort.

Now, over the last decade I’ve seen a lot of projects come and go, the one thing that has been a common theme over the last few years is that businesses know what problems they need to solve, but they also know that it doesn’t end there. In an attempt to future proof solutions and ultimately keep costs down they tend to have the opposite effect by adding unnecessary complexity which ultimately leads to increasing development costs which could have been avoided.

To bring some context to what I’m talking about let’s have a look at a scenario I come across fairly regularly –

During the early stages of engaging with customers on their new projects, you tend to hear a lot of clients mention something along these lines “It needs to work like this BUT… it must be flexible enough to adapt to our future requirements”. This seems like an obvious caveat to throw in there to make sure we can ultimately keep the costs of development down in the long run, right?

Well nothing says, “let’s save a few bucks”, adding some more time and effort at a problem that we must, probably or maybe not, cater for. Whilst it’s great to get a view of the bigger picture early on, this could send you in one architectural direction rather than another, it’s not always cost effective to try and cater for the hundreds of permutations that may or may not be required.

The challenge here is twofold – firstly, what requirements are we actually trying to cater for, and secondly, how do we know that things aren’t going to drastically change once the users start adopting the application.

Whilst the great thing about IT these days is that you can pretty much achieve anything regardless of the technology… and nothing gets a developer’s juices flowing like a bit of a challenge. The down side of IT is that you can pretty much achieve anything, oh, and the more “flexible” and “generic” the solution, the more likely the costs are going to spiral out of control and you can also forget about your deadlines.

To bring software development back to something a bit more tangible, I like to think that it’s a lot like building a house, so let’s walk through a scenario to see how this analogy plays out. As we all live in houses we’re probably experts in building them, I know I like to give my builder some top tips on, well, pretty much all aspects of the process and they tend to smile and nod a lot so I know we’re on the same page… Regardless of our level of expertise we still need to reach out to a construction company to get some of these building folk, and maybe even an architect or two involved to give us some options on what can be achieved in our landscape and within our budget. Let’s say you wanted to build a 3 bedroom, 2 bathrooms, detached house with a double garage… but it also needs to be flexible to cater for extension later on…

Well that seems pretty straight forward, but let’s dig into the requirement around flexibility a bit and have a look at some of the permutations here. Your architects might make a few bold assumptions which make perfect sense to them (at the time) that go along these lines –

  • What if they want to extend up, maybe a second or third floor?
    • Well, we would need to lay a foundation that could handle the extra weight
    • We may want to have a flat roof to make it easier
  • What if we want to extend out?
    • Hmmm… a conservatory is always a great addition but how big is this going to be and where would we put it
    • Screw it, let’s just build a concrete slab around the perimeter of the entire house to keep the options open and hopefully they don’t decide to throw in a swimming pool or grass at any point

So, that solves that problem, right? Let’s tick off that requirement and move on.

Well, the above suggestions would work and certainly would allow for future flexibility to extend but is this what we want or need?? Let’s not forget that there is going to be a significant increase in both labour and material which is all going to impact costs, I’ll give you a clue – these are going to go up not down… Most importantly what benefit is this going to give us in the short term? Hmm… all that underlying effort isn’t going to bring any value unless we’re actually planning on expanding within the bounds of the above assumptions that is…

So, what happens next, well, we will build the most technically amazing feat of engineering you’ve ever seen to be the software equivalent of the Swiss army knife in its flexibility. Next thing the inevitable happens, the family moves in. They get settled and, well, they decide to move a few things around. A wall here a door there. Then the conversation of the extension comes up and, wait for it, they’ve got new requirements, which of course our feat of engineering is ready and waiting for, locked and loaded. It turns out that a studio at the bottom of the garden is what’s needed…. Say what now? Well that’s still considered an extension I suppose but we didn’t see that coming… How did we possibly miss that in all the workshops and architectural design sessions??

Anyway, this is getting a bit long winded now and I think you get the point. The moral of the story is that similarly to building a house, you should be mindful of minimizing waste and focusing on building the minimal viable product (MVP). This will ensure that you can minimize the extent of costly rework cycles associated with any change and keep steering towards the end goal. Unlike building physical constructions, IT projects are generally more flexible for extension and change but it’s almost inevitable that some rework is going to be required along the way. Rework is a normal part of any evolving and adapting project but waste is not and can be mitigated by focusing on building what’s needed and getting feedback early and often to make sure you can pivot and adjust real time to focus on keeping waste down and maximising your ROI.

In summary, software development projects (in contrast to actual construction) replace physical holes being dug in the ground, concrete being poured and bricks being laid with a room filled with caffeine fuelled developers, coding away for all hours of the day, and probably most of the night. The fact that you can’t see the guys running around the building site and physical elements taking shape, makes it easy to forget about the amount of effort going into any project. Unlike a building site, unfortunately you don’t have a skip sitting outside every dev shop with lines of wasted code piling up which would really make you think twice when making changes.

With this in mind, below are a couple of key takeaways to think about when you get into your next project –

  • Focus on simplifying the solution to solve the problem your facing and deliver the return on investment that justifies the effort
  • It’s more than likely that your solution will either, adapt to the end users’ needs or evolve to take it to the next level. Focus on getting your solution delivered early and often to validate and learn in short increments
  • Build success on top of success – Once you got a solid foundation, you’ll have a platform or a solution to evolve from there and take it to the next level

Keep it simple and focus on doing an awesome job of the core features you need to deliver rather than chasing the dream.