There are a number of reasons why your application may need to be rescued. But the way out is often not to continue with your current practises, especially if they are the cause of this predicament in the first place.
This is nicely captured in Albert Einstein’s quote
Insanity: doing the same thing over and over again and expecting different results.
Having some outside perspective can be instrumental in getting your application back on track.
Reasons why you may need to consider an application rescue:
- No software maintenance has been undertaken, to keep it up-to-date.
- Performance or stability problems seem to plague your application
- Initial short-cuts, while building the prototype, are now slowing down development.
- The amount of code has become too unwieldy.
No maintenance was undertaken, to keep it up to date.
An old Swedish saying
“If it ain’t broke; don’t fix it,”
While the above is good advise for a lot of things, it isn’t for on-going software maintenance. The reason being is that web technologies are constantly under development with the latest libraries offering new features, bugs and security fixes. These fixes don’t usually extend back to previous versions of the software.
The consequence of not updating:
- Coding examples and documentation doesn’t apply as they are based upon the latest version of the library
- Known vulnerabilities are in the public domain. These quickly get fixed in the latest version software. That’s like having a lock door to your house, but having a note attached saying, “the key is under the mat”.
Performance or Stability Problems
Your application provides a terrible “user experience” as is too slow to respond to requests. Often the application has not been written with real-world traffic and database size in mind. This often comes as a surprise to managers as the application performed well in development but that was with few records and virtually “no” users.
Solution
Firstly, the application performance is measured. This will identify the slow areas in the application that are acting as performance “bottle necks”. These “bottle necks” are then optimised. The process is then simply repeated.
Using a Prototype in Production
A prototype is often developed to validate the business “idea”. This usually gets refined a number of time, adopting users feedback.
The problem occurs when the prototype becomes the “actual product”. The reason being is that the prototype was created with speed in mind and was never expected to last. Here the developer would be cutting corners, and selecting the quickest solution to implement even at the expense of being harder to maintain and more prone failure.
Now is the time to go back and correct mistakes, remove redundant code and temporary or sub par solutions.
What’s the next step?
Usually it is pretty obvious that you have a problem. It is what to do next that is difficult.
Having a second opinion on your project is a great next step. Especially, if that person has worked on a number of projects. If you think that you are in that category, I am happy to talk more fully with you.
Lets chat!
I shuttle between Tauranga, Hamilton and Auckland so I am available to meet in any of those locations. Alternatively, I am available for virtual meetings via Skype or Google Hangouts.
Subscribe to What is it like to work with me
If you are not ready to chat but would like a short 4-week introduction of what it is like working with me, and my development approach then please sign up with the form below.
You will be asked to confirm you email address and then you will get the first of four emails
