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, 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.

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 track record of seamless cut-over in these cases.

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 groups within the public or available online, but not at your primary domain
  • Launched: Your app may not be 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 verifies that a given feature works, from end-to-end. This also ensures that new features do not unexpectedly change or break existing ones.
  • Acceptance Testing: Typically paired with System tests to customer specifications, augmented with additional automation as needed.
  • Smoke Testing: These are included to ensure the testing tools are, themselves working as desired.
  • Sanity Testing or QA Testing: A manual quality check of an application. Ensures that key aspects of the software are tested.
  • Automated QA: A scripted review of site functionality, done either through recorded scripts or generating video artifacts for review by QA personnel.
  • Canary Testing: Advisable to release new code to a small fraction of your users. Ideal canary testing is done with tens or hundreds of thousands of users representing small percentages of your user base.

Trustworthy Code

Breaking something when you’re trying to fix something else is the worst.

Being able to modify your software is essential to correcting issues, fixing bugs, and meeting market demands on a reasonable timescale. However, the greatest risks come from changing code when its purpose and function are unknown. Automated testing is one of the best ways to ensure that the purpose of code is maintained and that subsequent versions don’t lose this purpose. Continuous integration (or CI) systems can ensure that nothing enters the codebase in a known-bad state, and that developers can always begin work from a known-good state.