Build vs Buy: a Developer’s perspective
8 March 2016 |
Jo Crossick | About a 5 minute read
Legacy systems: the beautiful monsters of the systems world.
Most businesses have legacy platforms of some sort – even small startups will have the monstrosity they created before they knew better, but in general, the bigger and older the company, the bigger and hairier the legacy systems. Many of those legacy platforms are beautiful monsters – ancient monoliths of codified business rules that the business themselves have long since forgotten (but still rely on), a spaghetti-like heap of integration and functionality that hold the business together like gaffer tape and frayed rope.
As a developer, I have learnt that legacy systems need to be treated with both courtesy and respect; there’s usually some good reasons why they’ve survived for so long. They become immovable, immutable blocks in the systems landscape, distorting everything nearby as people find ways to work around them. But eventually, the pain becomes too much, and the re-platforming project is born.
The starting point is usually “buy or build?” Do you build your own bespoke solution, or do you buy a platform that does most or all of the build for you? And with that, people dive into all sorts of questions around functional match and licensing costs and upgrade paths and whatnot. But these questions are premature, because the first question you should ask is “what kind of IT department do I want?”
What platform implementation does to your team/department:
- You lose the creative edge. Ask a platform salesperson what the platform implementation is like, and they’ll tell you it’s super-simple, drag-and-drop boxes, complexity hidden behind a “clean” interface. Ask a developer what platform implementation is like and they’ll tell you the bits that are as simple as the salesperson says are mind-numbingly dull, and the rest is a deeply frustrating battle with a system that doesn’t want to let you do what you want to do. This is not an environment that is conducive to getting the creative juices flowing.
- Technical innovation stops happening. Saying that technology is moving quickly is hardly groundbreaking news. But the pace of change over the past five years has been staggering. Keeping technical skills up to date in this environment is pretty much a full-time job in itself – which is one of the reasons why a huge proportion of the best developers work on personal projects in their own time. It’s partly a labour of love and partly a desperate sink-or-swim situation… keep up, or get left behind. Most of the developers I know love the job, and the biggest risk to their careers and their passion is to miss the next wave of new technology, to get caught in some backwater of increasingly obsolete or niche technology and fail to be able to escape. The most technically excellent developers are likely to see platform implementation as professional suicide.
- Recruitment becomes even harder. If you’ve managed to pick a platform that gets a lot of traction – one which has plenty of customers, and therefore the best chance of future investment for feature upgrades and long life support – then the chances are that you’ll find the job market pretty fierce. It’s a mathematical certainty that developers who are experienced in a platform that is growing quickly are in short supply. While you up your pay brackets in a desperate attempt to lure even a little bit of experience into your team, your competitors are eying up the devs that you are throwing onto platform training courses.
What are you left with?
Your devs who survive the replatforming experience are likely to feel bruised and battered as they crawl out of the change curve. An intellectually difficult time – when people have had to struggle to get to grips with a new platform that they do not love and do not believe in – is compounded by emotional struggles associated with a rapid turnover of old colleagues and friends, a nagging sense that the grass may be greener elsewhere, and panic over what they should be doing for the sake of their careers. These are tough problems to deal with.
So, I guess we’re going for build then…?
Not necessarily. There are times when a platform implementation can make a lot of sense. Here are a few examples:
- Focus on differentiating technology. If the systems area you’re looking at isn’t part of your core competency and does not impact your ability to react in your marketplace, then an off-the-shelf product might be the right choice. Even better, outsource the maintenance and development entirely and let your in-house developers focus on the technology that’s going to make a difference to your business.
- Short, sharp and specific. A common mistake is to look through the feature spec of an all-singing, all-dancing top-of-the-range platform and suddenly everyone’s bleating on about how they couldn’t possibly live without things that a few weeks ago they didn’t even know existed. But all that fancy functionality comes with complexity that’s going to weigh down your ability to execute the basics efficiently or effectively. If, on the other hand, you have a specific problem and there’s a specific product that solves your problem, then by all means buy it. In case you’re wondering, “we need a new e-commerce platform” isn’t a specific problem. “We need to add reviews to our site” might be.
- Know the difference between a platform and a framework. At a very basic level, a platform is something you configure and possibly put snippets of code within, in order to allow you to “customise” it. On the other hand, a (good) framework will not box you in but will support the application development by reducing or removing repetitive code elements and simplifying boilerplate code, freeing your developers up to work on code that delivers true business benefit.
So what should I do now?
Tackling a big piece of work as an in-house build can seem like a daunting prospect, but it needn’t be. Using agile delivery methods and the right technology choices can deliver the results that the business really cares about more quickly than you might think. We can help you build your team and train them in the skills that are needed to keep your delivery moving. And if you need to scale up, then we can provide highly-trained full-stack digital professionals to complement your delivery teams.
Read More From This Author
Tech Lead (Reading)
Bring your expert tech knowledge to the table to influence the direction of projects, whilst coaching and your team through engineering best practices.I'm Interested
DevOps Lead (Reading)
Bring your delivery expertise to the table, leading the pack as ambassador on operational requirements, influencing and continuous development.I'm Interested
Programme Lead (Edinburgh)
Bring your expert project knowledge to the table to own delivery of all our initiatives being delivered out of our Delivery Engine.I'm Interested