What's Wrong with Custom Development? A personal perspective.

What is custom development anyway?

When I talk about 'custom development' in this blog, I'm talking about developing something on a one-off basis for a specific customer need or request. Custom development in this context varies considerably from 'product development' where you have a technical team in place with a clear development roadmap. 

I feel that custom development vs product development has some problems which I'm going to outline in this blog.

So what are these problems?

You might think that the problem with custom development lies with the, well... development. But actually, that's not the case. Software development used to be difficult 20-30 years ago but now with advancements in technologies, tools and high-level programming languages it's a lot easier. There are all sorts of books, tutorials, vlogs and forums out on the market that people can get their hands on and there's been a real shift in the number of interested people too.

So if the problems not with the development itself, then what is the problem?

I believe the problem these days has moved from developing software, onto maintaining and supporting it,  and this is where custom-developed software falls short.

But you have to maintain and support product development driven software as well, don't you?

Yes, you do. But the lifecycle and budget of the two types of software development is very different.

How do the two differ?

Let's compare the two approaches point-by-point and look at the advantages and disadvantages.

LIFECYCLE 

Product

A product usually has a long and continuous lifecycle, which means there are regular new versions or at least updates released over the lifetime of the product.

The advantage here is that there will be multiple developers, testers and engineers who are deeply familiar with the code and the functionality of the software, because they work on it everyday.

Custom development

Very often, a custom development software will not see any updates after the first release (this can cause other issues, but we'll talk about that later). And even if it does receive an update, it's usually a long time after the initial development which can be problematic; people who worked on the software in the first instance can be busy with other projects, or might even have left the company.

If this happens, you'll be in a position where none of your team has a deep understanding of the code or functionality, or worse still, don't even know the code at all. There will probably be some kind of documentation left behind, but in most cases, it will be hard to follow for someone who has little or no understanding of the development history.

BUDGET 

Product

In line with the lifecycle of a product being continuous the budget is also usually continuous - meaning it's not tied to a particular feature, it's there to improve the whole product.

This gives a lot of freedom on how the budget is spent; resources can be distributed evenly and don't just have to be allocated to things that are related to user experience (UX). For example, replacing a legacy technology in the back-end - it will improve the product and can reduce costs in the long term but won't affect the UX.

Custom development

As I mentioned at the start of this blog, the driver behind custom development software is customer requests. In terms of allocation of monies, this means budget will only be given for very specific features that have been requested, and nothing else.

Typically, a customer will not want to allocate budget to make a change that has no impact on UX. So if there's something that needs doing in the back-end (unless the providers willing to pay for it, which they have no incentive to) it will end up getting left.

CODE QUALITY 

Product

Because a product has a long lifecycle, it's obvious that it's in the best interest of the development team to use high quality code. If they produce bad code in the beginning it will affect all other developments based on that code later. So it's a no-brainer that spending a little more time and care implementing each feature will return costs later.

Custom development

Because of the lifecycle differences, code quality for a custom developed software doesn't usually matter as much. Going back to the fact that the software usually won't see any further work after the first release, it's arguable whether it matters at all. As long as it does the job reasonably well without too many bugs it's good enough, and no one cares which architectural choices and design patterns are used.

TOOLS & DEVOPS

Product

The past decades in software development yielded a lot of awesome tools and methodologies that help in developing and managing software. Just a few examples of these are: source code repositories, collaboration management tools, automated tests, and automated deployment pipelines.

These tools and concepts are analogous with product development. For example manual testing takes a lot of time, while automated tests can save a lot of resources. The more releases you make, the more time it saves, which gives you even more time to work on the next release. The same is true for deployment pipelines, with a few clicks, the new version of your software is ready to be published for live use by customers, just after the development and tests are done. Another important thing is to mention, is that people make a lot more mistakes than automated tools do, and less mistakes equals happier users.

Custom development

It's really difficult to argue for the usage of these tools for custom developed software, again, because of its lifecycle. Creating automated tests can eliminate a lot of bugs, but it takes time to implement them. And running them only once or twice after the first few releases isn't worth the effort, it's cheaper (and takes less skill) to do these tests manually. Similarly, with deployment, it's cheaper to write a simple installation and configuration guide and do these steps manually than to implement a whole pipeline.

FOCUS 

Product

Usually products are big solutions with a lot of components and features. Development of this scale needs the work of several people at the same time. This means that you can only focus on a smaller amount of products at the same time (unless you have a giant enterprise with thousands of employees of course). While at first this might sound like a disadvantage, it's actually an advantage, it means the team aren't too stretched and they can focus more easily.

Custom development

Custom development software is often much smaller in terms of architecture than in the case of product development because you're working on something specific to solve a single problem. This means that timescales are smaller and companies can work on a lot more projects at one time. In my opinion, this fragments the focus and is harder to manage from a resource perspective than having bigger projects.

So you're saying custom development should never be done?

No. Custom development is a necessary evil. You cannot avoid it. What you should do is try to reduce it to a minimum.

If you need to create a custom integration component for a product, change the product and give it an API that enables you to do the integration without any wire twisting under the hood.

If you need to create a feature that can be generalised, put in the additional budget and generalise it, make a product from it. It will solve all of the problems we covered in this blog.
 
And most importantly, when you do choose to use custom development, make sure you choose a provider that is reputable, like Geomant that will provide a good service and offer the best advice. As a systems integrator with two-decades worth of experience, Geomant has loads of pre-made connectors and out-of-the-box solutions that might just help solve your problem without custom development. And if custom development is still required, they'll work closely with you to get the best end result. 

On a final note, it's worth mentioning that custom development has many levels, this article is specifically about custom development where a feature needs to be added but sometimes when you integrate two or more core systems this can also be classed as custom development and is not so much a 'necessary evil' as it is a custom deployment for the sake of reaching a more efficient end solution. 

If you have any questions, feel free to reach out to Geomant for help.