Should you develop your software in-house?
When choosing software, it can be tempting to consider developing it in house. Surely creating your own software is cheaper and faster than buying off the shelf, and the product can be tailored to your exact needs. After all, who knows your business better than you do?
In reality, things are not always so straightforward. Your new in-house software might seem miraculous at first, offering many of the features that you need along with some attractive dashboards and visualisations. But have you really thought through the full implications of this decision?
Is in-house software really in your control?
Here’s a scenario that may be familiar. After a few days’ work, a talented member of your technical team creates a great looking tool. This was so easy, why do we need to spend £1000s on an off the shelf software that doesn’t do everything we need? So, you request your new “developer” to build in some more features.
They manage to get one of the three key features you requested, but the other two will require some better underlying architecture. Don’t worry, this can be solved by investing time in developing this core piece – it’s a one off, you are assured everything will be better and development will be faster after this is done.
The new version finally arrives – it doesn’t quite cover all your original requests, but at least you’re moving forward. It’s been built in Microsoft Azure, and you’re using a great framework of tools, this should now be simple going forward.
However, you are still hitting a few issues. Your team are struggling to understand how the Microsoft permissions work – simple things seem very difficult. How can you ensure a project manager can only edit info for their own sites? And why are you still uploading data by emailing a spreadsheet to your developer?
You also realise that you are becoming heavily reliant on the person who set it all up, as no one else quite knows how it all works.
Then they hand in their notice.
There’s no reason to panic just yet. You decide to hire a new engineer who has strong systems experience. They are extremely knowledgeable, but they have their own ideas about the direction of the development. They want to migrate everything over to a new platform offering from Microsoft – this will take a while, but it will be worth it. So you get started.
Before too long, you find yourself using a combination of the old and new systems. Rather than simplifying things, you now have two setups, each with their own set of features and problems. Part way through the migration, your new engineer gets a job offer and leaves.
With nobody left who fully understands the software left in-house, mistakes are bound to happen. Someone tweaks a setting on the backend, which breaks a report – this causes your whole reporting cycle to be delayed while your team look into the issue. You realise that you need to start testing new features better before you implement them in order to avoid such errors. You need separate staging environments, and ways of copying data between them. Maybe some sort of version control? And how will you seamlessly release new features to production? All this means hiring new people or reassigning more of your staff, creating new software processes as well as ensuring the knowledge is retained on how to operate the whole thing.
Before you know it, your quick “in-house” effort is turning into a major software project that needs a team to manage it, and still your system has issues and is missing key features. You dread to think what the cost to date has been. As you bring on more people to project manage, test and implement new features, you may find yourself wondering why you didn’t go down the third-party route in the first place.
A tangled mess
The problem here is not the individual decisions, but their cumulative effect. With each of these steps, you are adding another layer of complexity. Your software becomes a knot that is impossible to untangle. Influential software engineer Robert C. Martin describes the pitfalls of approaches like this in his 2008 book Clean Code: A Handbook of Agile Software Craftsmanship:
‘Every addition or modification to the system requires that the tangles, twists, and knots be “understood” so that more tangles, twists, and knots can be added. Over time the mess becomes so big and so deep and so tall, they cannot clean it up. There is no way at all.’
This is where resentment can start to grow. Newer team members won’t remember the early excitement that the software inspired and won’t be shy about expressing their frustrations. As the office becomes more divided, those who were involved from the beginning will start making excuses for why you went this way. Surely no third-party software could have met your exact needs? On the other side, you will have people wondering aloud why you didn’t just choose an off the shelf option.
A better way – where off the shelf meets bespoke
At Sennen, we have experienced this situation first-hand. We know how easy it is to slip into this routine. Tempted by a bit of early success, you may ultimately end up feeling overwhelmed and trapped by your decision.
There is far more to building a successful software system than just achieving the features you need. You need to have senior, trained software engineers who can architect a system to keep the complexity down. You need strong, version controlled, testing and release processes (we follow SCRUM and Continuous Integration practices). Software needs to be architected for future expansion and growth, and ease of long-term maintenance, not quick feature wins.
Sennen’s software engineers have developed our platform from the ground up following industry best practice. Coupling this with highly experienced engineers from the renewables industry, we ensure our off-the-shelf modules have a very close fit to the needs of our clients. And we pride ourselves on being able to customise our offering and develop bespoke modules to meet individual client requirements where our standard modules fall short, all the while sticking to our vision and rigorous architecture rules. And finally, the economies of serving multiple clients means we’ll always have experienced engineers on hand to help.
Don’t let your software become a burden. Get in touch today to request an information pack, and discover how Sennen can build a system that works for you.
