Rescue and Recovery
Have Technology? Wish it was better?
Did your last partner drop the ball? Did you get what you wanted? Do you have a codebase that doesn’t meet your needs and you’re trying to figure out how to pick up the pieces?
Our greatest impact has been for companies who already have a technology solution that isn’t working for them. Whether it’s something you’ve built yourself or an outsourced project that never quite became what you hoped it would, this sentence is too long. We’re the right partner to map your way out of the problem.
First, if your project in launched or in beta, we have to make sure that any changes we make won’t impact your customers, so ensuring we have effective end-to-end testing is the first step. We’ll work with you to analyze the code you have and use automated testing to codify your product design so that, no matter what changes we make, your project will still perform as expected.
A trustworthy codebase is essential to improvement and meeting your goals.
Next, we’ll work to refine your codebase, remove duplication, simplify logic, and overall: set you up for success.
Finally, we’ll begin to ramp up development to meet your key goals, knowing we are working with a trustworthy codebase.
While the cost of a rescue project can vary substantially – sometimes as little as $50,000 – we recommend you budget $400,000. Sometimes, though rarely, a complete rewrite is necessary. Our process plus the product definition work we’ll do in step #1 ensures that we can deliver feature-for-feature and with the same UI. We can do it cost-effectively and, in most cases, we take the risk of building the replacement codebase before we even broach the subject with you so we can be sure. We have a solid trackrecord of seamless cut-over in these cases, as well as projects where platform transition was the fundamental goal, so taking this step is as normal as doing any other kind of work.
State of Your Codebase
Your codebase may be in a number of states:
- Pre-development
- You don't yet have a domain and/or the state of your codebase is unknown
- In Development
- An existing vendor or internal developer has built some functionality that you may or may not have seen in a demo
- In Alpha or available internally
- You have seen a demo of your app and may be able to access it but it is not available to the public in any form
- In Beta or available as a staging environment
- Your app is available to select group within the public or available online, but not at your primary domain
- Launched
- Your app may not feature-complete but it is broadly available to the public and/or on your domain
- Transferred
- You have unrestricted access to the codebase or the code, the deployed app, the domain your app is deployed to, and can transfer that access to others
Testing
Testing is non-negotiable. We now have roughly 50 years of data that shows that testing results in more reliable outcomes, smaller codebases, fewer bugs, and fewer security problems. Perhaps more importantly, writing tests first actually improves the efficiency and lowers the time of development for a feature. Not only does it ensure that complex repetitive work to test a feature is automated, it also helps to reduce the creation of unnecessary, sometimes called “speculative” code.
Kinds of testing
- Unit Testing
- Tests abstract business logic to ensure that it is correct. Experts recommend that this be the majority of tests
- Integration Testing
- This ensures that software internals work together as expected.
- System Testing or End-to-End Testing
- This is the most common kind of test we write as it verifies that a given feature works, as implied, from end to end. This also ensures that new features do not unexpectedly change or break existing ones.
- Acceptance Testing
- Typically we pair System tests to customer specifications, but at times, additional testing automation is added to ensure that each deliverable is consistent and complete.
- Smoke Testing
- You may have heard of this type of test. Typically these are included to ensure the testing tools are, themselves working as desired.
- Sanity Testing or QA Testing
- This is a manual quality check of an application. We write testing instructions and key aspects of the software are tested. We added to these scripts over time. It is helpful to ensure that human eyes are evaluating product to ensure that there are no undesirable facets developing in the experience.
- Automated QA
- As above this is a scripted review of site functionality, but is not done manually. This may be a recorded script or may only result in video artifacts that are reviewed by QA personnel.
- Canary Testing
- When possible, it is advisable to release new code to a small fraction of your users. Ideally, the best canary testing is done with tens or hundreds of thousands of users representing small percentages of your users.
Trustworthy Code
Breaking something when you’re trying to fix something else is the worst.
Being able to modify your software is essential to being able to correct issues, fix bugs, and meet market demands on a reasonable timescale. At the same time, one of the greatest risks is changing code where the purpose and function is unknown. If your code is being written by a single developer, the code can be as trustworthy as the memory of the developer, but since serious development is done not only by multiple people, sometimes, multiple teams, there is no way to create the relevant memory. The code must have a way to remember its own purpose. Automated testing is one of the best ways to ensure that the purpose of code is kept and that later versions do not lose this purpose. This also allows appropriate changes when the purpose changes since the alternative is to keep code the same when its purpose is unknown, even when the intent is no longer consistent with the code.
Because the expectation that developers will always run tests is based on the idea that developers never make mistakes or skips steps, a continuous integration (or CI) system can be implemented to ensure that nothing enters the codebase in a known-bad state. This also ensures that developers can always begin work from a known-good state of the code.