Bespoke Software: Build Cheap; Build Twice

We recently began working with a new client who had a web application, API, and mobile apps built for them by a tech team, who shall remain nameless, but who are based in the far-reaches of the European Union.  The client has now chosen SIGMA Technology to conduct further developments on the system – we call this an ‘inherited' project; we didn't originally build it, but it's been built with technologies and programming languages we're familiar with, and so we are confident we can provide value for the client.

For the sake of brevity, I'll refer to this project as ‘Project X', because it sounds cool, and I'm a nerd.

We always prefer to build things from scratch for clients, but this isn't always possible.  Oftentimes, a project has already been built by another team and then for one reason or another the relationship has broken down and the client asks us to take over where the previous team left off.

The purpose of this blog isn't to ‘bash' overseas development teams, but more so to consider the pros and cons of the different options available, and of course it's all based on anecdotal evidence gathered by me over the 20+ years I've worked in this industry.

Overseas Software Development – Pros and Cons

There are lots of potential options when considering using overseas development companies, but India, Sri Lanka and Eastern Europe are common hotbeds for low-cost software development resources.  Many of the companies offering these services are proxies who simply pass requests onto the real development team and take a healthy commission for the privilege.  There are often multiple layers of middlemen all taking their own cut, and the result is what little money is left over provides you, the client, with the most junior developers who are more likely to make mistakes and write low-quality code.

They're not all the same of course.  When dinosaurs still roamed the earth – when I was 24, I worked for a Swedish company who had an overseas development team based in Sri Lanka.  In my experience, they were consistently excellent at delivering what was asked of them because they were a dedicated resource with a Project Manager and people internal to that team who took their responsibilities very seriously.

And of course, this isn't to say that all UK-based software development companies are angels who provide an excellent service.  Many of them outsource some, if not all, of their development work to overseas companies as well – this is known as ‘white labelling'.  We've also inherited projects from UK companies who did all of their development work right here in Britain, and the quality of their work was objectively worse than even the most amateur of overseas companies.

Maximising Chances of Success

In my 20+ years of experience, the main indicators of success for a software development project are nothing to do with the actual code that gets written – it all comes down to accountability and ensuring as few layers of communication as possible.

This is why every client SIGMA Technology takes on receives the following guarantees:

1. All work is conducted here in the UK – we don't outsource any of our clients' development work. If we don't have direct expertise in a particular technology (as unlikely as this is), we will refer the client to another company, rather than pretending we can do it and then subcontracting it behind the scenes.
2. Every project is allocated a Business Analyst and Project Manager whose job it is to understand the intricacies of the client's business, translate operational and business requirements into functional requirements our technical team can understand, and ultimately be responsible for the successful delivery of the project.
3. Our clients can review every line of code we've written, every bug we've logged, and every issue we've resolved for them. It provides a level of transparency we believe is extremely uncommon in this industry, but it keeps us honest and removes communication barriers.

You may be wondering why Project X served as the catalyst for writing this article, so let's dive into that next.

Inheriting Software Projects – It's Rarely Easy

It's fair to say that Project X was by far not the worst codebase we've ever inherited.

Back in 2020 we took on a project that had been built by another company very close to home.  It was needlessly over-engineered, built using what I now refer to as ‘hipster-tech', and any documentation was sorely lacking.  It had all the red flags of ‘Not Invented Here Syndrome' – almost everything had been built bespoke, despite numerous open-source (and better made) options being available, and the tech stack included just about every possible option on the market.

Hold On, What Is Hipster-tech?

When I say hipster-tech I'm referring to fly-by-night frameworks, usually built using JavaScript (JS), that typically have the following characteristics:

• They do the same thing as well-established frameworks but in a slightly different way, for no apparent benefit other than to underpin the creator(s) humblebrags.
• They are usually created by, and almost exclusively used by, people sporting neckbeards, top-knots, and over-inflated egos.
• They have roughly the same staying power as a hipster's waistcoat and ironic banjo.
• The components of the framework have names like “cardigan” and “moustache” either inexplicably or because of a tenuous link to how they work behind the scenes.
• They are born and begin to die usually within an average period of about 18 months, much like most fashion trends.

Any company who embraces hipster-tech without critically analysing its potential longevity is doomed to fail, and any company who uses it to build clients' projects is – often unintentionally – committing the software to an early grave, because when the hipsters who made the tech move onto ‘the next big thing' there will be no support or security updates, the entire thing will have to be rewritten in HipsterJS Version 497, and the cycle then begins again.

At SIGMA Technology, we don't use hipster-tech, and we advise anyone who is thinking of doing so to avoid it like the plague.

Back to Project X…

So, it wasn't the worst codebase, but after getting our hands dirty with trying to get the projects to run on our infrastructure, the usual suspects associated with overseas development were found, namely:

1. It had been built using reliable technologies and frameworks but using old versions.

So old in fact that when one part had finished being built it the underlying framework was already insecure.  The insecurities had been fixed in later versions of the framework, but the version used was no-longer receiving security updates.

2. The software was riddled with spelling and grammatical errors.

Let me be clear, I'm not blaming the overseas developers here – their grasp of English is still way better than my grasp of literally any other language, but that doesn't stop 6,840 typos and 458 grammatical errors from making the software look comical at best, and unprofessional at worst.

3. Some aspects of the User Interface / User Experience were objectively awful.

Call me a stickler for good design, but there aren't many things that annoy me more than when I'm on my phone, filling in a number input field on a form, and up pops the general keyboard instead of the number pad, so you've then got to change the input mode to numbers yourself.

“Maybe it takes a lot of code to do this,” you might be thinking.  Well, if you're using a phone right now, tap into the input fields below:

And the rest is handled by the phone automatically.  There's even an email type that will give you the @ symbol as part of the usual keyboard and hide some invalid characters.  It's so simple and easy to do that it makes my blood boil when a developer hasn't bothered to do it.

This, amongst some other terrible UI and UX decisions, are currently being rectified by our internal development team who take much more pride in their work.

4. The code often violated coding best practices.

Large blocks of code had often been copied and pasted instead of turning them into reusable functions.  This violates one of the most important coding principles we hold dear – “Don't Repeat Yourself” (DRY).  Amongst a plethora of other benefits, ensuring code is DRY ensures the software runs faster and is less prone to errors when changes are made in the future.

Such a flagrant disregard for DRY is a major indicator that the code was created by a junior developer, and whilst this doesn't inherently mean it is ‘bad' code, Project X processes financial transactions and so allowing junior developers to write code for important parts of this system is a huge risk.

5. There was no automated testing built into the system.

We get it, automated testing (AKA Unit Tests) can be a pain to set up and can take a disproportionate amount of time to write, and if they're working well the client doesn't even know they're there.  It can seem like a waste of development time to some, but the short-term investment bears huge fruits in the longer-term.

Any system that processes financial transactions objectively needs Unit Tests to ensure compliance with legal and regulatory requirements.  They also protect against potential reputational damage caused by misbehaving code and bugs that could cause financial transactions to be miscalculated or sent to the wrong place.

Migrating Project X

To give them their due, getting hold of the source code from the previous developers was mostly painless.  However, trying to get the mobile apps transferred to our control, and getting hold of other critical security information proved to be less so.

I suspect the mobile apps had been further subcontracted by the development team, as is often the case when they don't have the expertise in house.  The problem was that it didn't appear the main contractor had tight control on critical aspects of the intellectual property involved with the project and this only became apparently when we started asking questions which nobody knew the answers to.

What's Next for Project X?

The client did their due diligence and managed to choose an overseas development team that, on balance of everything, weren't all that bad.  However, once the basic requirements of the project had been delivered and the client started asking for extras that's where things started to go south.

The team who developed the original project were now working on other projects and/or didn't have the expertise to develop the much more complex aspects of the project that were now required to take their business to the next level.

That's where SIGMA Technology come in. Once we had finished correcting the near 7,000 typos in the codebase, we began working on the extra tools and integrations that will save the client hours of time every day and enable them to expand their business.

Please, if you're in the process of getting quotes from overseas development teams then contact us for a no-obligation quote as well. Our prices are very competitive as we keep our overheads to an absolute minimum, and having the work done right here in the UK will almost certainly save you a lot of time, money, and pain in the long run.

5 September 2023