Opinion.

When tech goes bad - the dangers of technical determinism in development

by Philip Bennison - Technical Director

When tech goes bad - the dangers of technical determinism in development

I admit… I am a big fan of tech. The clue’s in the title.

The developer inside me relishes using the latest frameworks, refactoring existing code to use best practice design patterns, and creating systems that automate and facilitate. There’s a big part of me that wants to use cutting edge technology to deliver an innovative solution to a business problem, even (or especially) when the business doesn’t know it needs solving.

But there’s another part of me that knows that this sort of pure tech-led process only really works in a world where there are no such things as budgets, time constraints, and legacy code.

In the real world it makes sense to build a system used tried and tested methods and deliver a solid solution that does the job without metaphorical bells-and-whistles.

You see, tech for tech’s sake can be dangerous. Tech is a tool and a means to an end but, more and more, we seem to see it as a goal in-and-of-itself. We celebrate tech and digital without focussing on the end goals. Left to our own devices we can often over-engineer things and produce bloated and often unwieldy solutions.

Here are three key questions to consider when scoping out a project.

Do you really need it?

During a short scoping session with one of our clients we say there while they mapped out a bewildering array of applications, libraries and processes they had in mind for their business. They had already decided on an array of systems that would support their product and let them scale.

I stopped them half-way through their presentation and asked them why. After all, their core idea wasn’t particularly complex. It wasn’t even tech related. Sure, there were parts of it that could be facilitated by a good technical build, but they had no investment and this stage and the validation process they were embarking on really just needed a few people to subscribe and the product could be monetised without an array of overly complicated solutions.

So the first question you should ask yourself is do you really need the tech? We live in a world where tech is everywhere and we often assume that we’ll have some sort of app, system, or online store to be a success.

But do you really need tech to get your product up and running? Could you benefit from doing a little more leg-work to begin with before investing in the development that would allow you to scale?

Do you have the budget?

It is really important to set a budget for your project.

Now this may sound like a super obvious thing to say, but for many internal development projects this gets overlooked.

Set your goals for the project and then decide on a budget. Communicate this budget to your team. Workshop the solution with the architects and developers and make sure everyone understands what’s involved in meeting these goals – what sort of existing systems are in place you may need to work with (or around), what the load is likely to be, what would be the ideal tech stack, the expertise of your development team, and any potential issues or blocks to the process.

If it turns out that the goals aren’t achievable within this budget, either increase the budget or adjust the goals. Either way, at the end you should have architected a realistic solution.

If you don’t make sure everyone understands and accepts the budget and the goals of the project then there are two likely scenarios – your development team works long hours to deliver something that could have taken half the time if they’d really understood what you were trying to achieve OR the project overruns (and overspends) and might even fail completely.

Can you maintain it?

Having the perfect system developed using the latest languages within optimised frameworks is really only half the battle. Even the best system quickly becomes worthless if you don’t have the ability to update and maintain it in the short of long term.

So when you’ve decided on a technical solution to a project make sure you’ve got the team in place to support it in the future. Be confident that the code is easy to update and maintain. Make sure you’ve used frameworks, languages, and solutions that are supported by a community and are widely considered to be industry standards.

If you do this then if the worst happens and your development offices are hit by a meteor (happened to me once) then you can take some solace in the fact that you should be able to find other developers who can manage and support your platform.

What we do

Here at Fablr we have a detailed scoping process which aims to understand the requirements of a project before we get anywhere close to suggesting a technical solution. We make sure we understand what existing systems are in place, as well as the budget and organisational constraints and requirements connected with the project.

But we’re always learning and growing as a company – development new business analysis tools, learning about scalable technologies, expanding our knowledge of existing frameworks, and working with other organisations to refine our toolset.

We’ve got a good feeling about your next project. Tell us about it.

Get in touch