Poor or inexperienced developers can break the ‘rules’ and not even realise it. The symptom is often an app that is “nearly working” but never quite seems to get the kinks out, where you fix one thing and it breaks two others. Where you’re in an endless cycle of bug fixes and those new features you talked about months ago are still just an idea on a piece of paper. Sound familiar?

In many cases this can be fixed, and after conducting a code review we can work with you to get your project completed quickly. You should expect that new developers will require some time to learn the code for a new application, even if it is well written, but you will see solid consistent progress within days of commissioning a new project.

If you’ve had a bad experience with previous developers then there may be fundamental problems in the code you have had developed. In extreme cases after a particularly damning code review, we need to talk to clients about the fact that they have purchased an expensive prototype, and that there is no single line of code in their app that should ever be used when you rewrite the app properly.

We would never recommend a complete rewrite of an application lightly. There is normally a significant cost to software development, and where possible previous efforts must be salvaged. But consider what happens when you get a bad developer. We see apps that store unencrypted credit card details in databases (really bad, possibly illegal). We see server function that aren’t encrypted and don’t require authentication (anyone can call server functions from anywhere in the world without even logging in). There are of course a lot more examples, but the thing these two scenarios highlight is:

• You can have very serious problems in your app that you would have no way of seeing.
• You should expect more hidden flaws in code with this kind of problem (a code review doesn’t attempt to document all problems in code, so read the signs in what is discovered).
• Even serious flaws can sometimes be remedied quickly (the examples described previously could perhaps be fixed in hours or days respectively, rather than weeks or months).

Whether you need to resurrect, rebuild, abandon or plough on – we’re happy to discuss your situation in as much detail as you feel comfortable to see if there is a path forward that allows you to release a product within your budget, and what that product might look like.

You can learn more about how we work with the section why we are agile, or if you’re ready to go then let’s get started!

Back to Dapper Academy