Outsourced software development is one of the largest gambles a company can take. Some companies deliver excellent results while others fall short, and still others less fall off a cliff than jump off - with (allegedly) outright fraudulent practices. There are some who will defend their failure to deliver results in court with the claim that their contracts never promised to deliver working software (more than one, and these statements are in court records - including for companies that are still active).
Customers looking for development rarely have the skills in-house to understand what they’re asking for, evaluate the difficulty (or ease) of delivery, or push back when being repeatedly drained of funds.
So, how can we fix this with ₿?
What are Smart Contracts?
Self-executing contracts that run on a blockchain, with terms written directly into code, are called smart contracts. Basically, a smart contract can automatically release payment once set conditions are met.
An analogy: imagine a contract with Amazon that automatically pays for shipping your item only when you actually switch on the genuine gadget at the other end (instead of getting a fake, or never receiving your item).
The biggest limitation of smart contracts is that the terms must be definable in software, and in any case, where there’s a degree of subjectivity or interaction with physical reality, the terms come down to the parties agreeing when they’re completed. Mainly, they’re used for exchanges of virtual assets such as NFTs and little else.
What is Functional Testing?
Testing of software can include:
- Unit testing: looking at individual components of the software
- Integration testing: ensuring components work together
- System testing: testing the system as a whole
Functional testing is a particular approach where the software tests have pre-defined success and failure criteria. As an example, if a component is meant to add two numbers together, then a functional test would be to hand it two numbers and check that the result (calculated beforehand) matches what’s expected.
Just as importantly, functional testing can look at abuse cases and potential attacks. With the case from earlier, we could define a functional test in which the component should cleanly reject any non-numerical input.
These are simple examples, but the important fact is that functional testing can be defined entirely in software. You might see where this is going.
Functional Smart Contracts
For software development, it would be possible to make sure that functional requirements and tests are clearly defined upfront and can be integrated into the contract for payments. Even the best of escrow services can suffer from disputes, while contracts are at risk of interpretation (going back to the developer claiming they never promised to deliver software that works), and this is a case where smart contracts would come in.
Setting those functional requirements does take effort, but plenty of independent specialist testing companies exist that could offer the test design as a service.
Tie those functional tests into the contract and any other terms (lower payments for late delivery maybe, bonuses for early delivery, discretionary payments, and so on), fund it, and let the developer do the rest. Ideally, the customer would use that smart contract as part of the tender process, building the requirements for suppliers to meet and funding it when they agree on payments.
Suddenly, the dispute about whether the software is working is gone. The risk of a supplier taking your money and failing to deliver or hiding what they’re doing behind technobabble and obfuscation to keep draining money is gone. Yes, it’s still possible for a supplier to fail, but it costs you nothing if they do - and if they succeed, they’re guaranteed payment.
The Good
Shifting to this model for development contacts means that any software developed and paid for will be functional. The work upfront to define the tests does add design time, but the payoff compared to gambling on whether a developer knows what they’re doing is huge.
Both the customer and the supplier clearly understand how payment will work, meaning less scope for disputes to arise (having been the mediator in these disputes, it’s work I would be more than happy to avoid in the future). Better still, for the supplier, no risk of late payments (except with late delivery).
The Bad
Defining and developing the contracts does require technical knowledge, and many customers looking to outsource development lack this knowledge. I can see a role for third parties specializing in creating and setting up these agreements as a sort of smart contract functional development assurance supplier (needs a better acronym than SCFDAS - I’m open to ideas since it’s similar to work I already do and I’d like snappier branding), but it still needs customers to understand the benefits and be willing to invest the upfront work.
For larger projects, there are costs, although, with functional design and testing, larger systems can easily be split into smaller components and divided out. Scaling this approach is a potential challenge.
There’s also a legal question, although in the UK contract law would cover smart contracts in other places the legal status can be uncertain. Whether this matters, given that payment and terms are built-in and indisputable, is another question.
The Ugly
The sad thing is that this is never likely to happen.
It’s not because the technology doesn’t exist or the idea isn’t viable. It won’t be because many aren’t familiar enough with the possibilities of Bitcoin, blockchain, and smart contracts. It won’t even be due to fears around the security and reliability of the contracts.
The reason I don’t see it happening is that the world of software development is cursed with poor applications of agile pipelines, which rely on constantly shifting requirements instead of carefully thought-through upfront design. It’s the same reason the cyber security landscape is full of holes and pitfalls, that cybercrime is one of the largest and fastest growing industries, and why software quality is on a steady downward trend.
Do It Anyway
Just because it won’t be popular doesn’t mean it’s not worth exploring. This is potentially a use case for blockchain that could provide a level of security and protection for software development customers, which currently does not exist.