When full time employees build software it is in their best interest to make sure that the project is successful. So they work hard to make sure the project is delivered on time, built as efficiently as possible and perhaps most importantly, is easy to maintain moving forward.
What About Consultancies and Contractors?
Often in the early stages of a specific project there is no need (and therefore no plan) to maintain the project going forward. Without oversight, the short term motivations of consultancies can lead to disastrous consequences for dealing with the app in the future. Let me share a story I have heard many times from people who tried to build a complex application on the cheap using a consultancy or contractor:
Brand New Thang Inc wanted a new app built and found a consultancy who charged half the price of another consultancy they found. Brilliant! Both consultancies promised the same outcome but one was half the price, however, the consultancy who wanted to charge more for the project mentioned something about doing “test driven development”. It seemed like a no-brainer budget-wise, so Brand New Thang Inc commissioned the cheaper consultancy for the project.
Everything was going great for the first few months; multiple developers were thrown on the project immediately and features seemed to be rolling out continuously. Everyone was happy and it looked like the project would ship on time and on budget. Great! A few more months passed by and the rate of features being rolled out started slowing down then the developers started becoming unresponsive then one day there is only silence, no response and no new features being shipped.
Worse still, when you then engage a more expensive company to fix the problem, their developers complain that the code is very complex with “missing tests”, whatever that means.
What Happened?
To understand what went wrong it is good to reflect on what is needed to make a software development project go right. One thing that is very important in modern software development is an automated test suite. Sadly, an automated test suite is the first thing that gets discarded when trying to meet a time or budget deadline. The reason we use an automated test suite is that as a software project becomes more and more complicated it takes longer and longer for a developer to manually test for broken code in other parts of the application whenever he ships a new feature, and often testing gets so time consuming that it gets skipped in favour of deadlines, resulting in broken code often making it into production.
An automated test suite removes the need to manually test every part of the application as the test suite makes sure that features that have been implemented previously have not been broken by the new code. Writing tests takes time so features are shipped more slowly at the beginning, but over time a continuous rate of shipping features is achievable. The qualitative graphs below outline the two development paths:
And without a test suite: * Once the peak feature delivery rate is reached, new development slows down and eventually becomes so slow that new features take weeks to deliver. * Early in the project, features are delivered at a faster rate when no test suite is implemented, however, this is a short term benefit that will severely impact the project’s rate of delivery into the future as features start to break without warnings from the test suite. * Multiple developers can’t work on the code base at the same time because they don’t know if they will break each other’s work without tests in place. * Broken code often gets deployed into production because there is never enough manual testing done due to the time constraints of manual testing.
So What Happens if You are Stuck in This Situation?
What do you do if you have an application without a test suite, and production has ground to a halt and you want to get your development happening again? Well, the good news is that it is possible to add a test suite to an application at a later date, but management often has a hard time understanding why developers are spending weeks coding without any new features being delivered.
Sometimes applications without tests can be so poorly written that it is cheaper to rewrite the app rather than untangle the mess; one thing we often find when working with applications initially developed by other consultancies is that applications that don’t have any tests are often poorly written in general. It is best to get a skilled and reputable development shop to take a look at your code and estimate the condition your app is stuck at and work out the best way forward: Do you fix and implement a test suite or rebuild straight away; what’s more economical and efficient for the long term? Because you don’t want further problems cropping up later.
While new tests take time to implement and features take longer to develop initially (as each feature needs accompanying tests written with it) the result of using tests is that the development of features can carry on almost indefinitely. The only slow down in feature delivery rate comes from the inevitable growing complexity of the codebase. Spending time and money on a test suite from the start of the project are resources very well spent because:
- The result of using tests is that the development of features can carry on almost indefinitely, as developers can be sure that new features aren’t breaking or conflicting with old ones.
- The application is much more stable with a far lower likelihood of broken features making it into the production system.
- More developers can work on the code base simultaneously without fear of breaking each other’s code.
Building a test suite costs time and money but the benefits quickly outweigh the cost. If you want your application to be maintainable, reliable and extendable you will benefit greatly by investing in a well written and extensive automated test suite for your application, helping to ensure that your resources aren’t going into a black hole. The next time you build a software project insist on building an automated test suite. If you would like more insights about how to get the most value out of building applications please check out the case studies at reinteractive here.
