SAPessi

During my short yet intense career I have worked for quite a few startups and small businesses. I want to talk about a phase most startups go through – Our application is crap, lets trash it and rebuild it from scratch.

Hindsight is something few people have and wisdom is just a myth, just a fancy name we have come up with to call our mistakes.
Nevertheless when a company outgrows the chrysalis stage and starts producing revenue and growing accordingly hindsight is one of management’s favorite words. It’s widely abused in every meeting. Who hasn’t heard at least once “With the benefit of hindsight we could have…”.
This special word makes the eager-developers brain click. There’s our chance to build the perfect application. We know what to avoid, we have wasted countless hours solving all the problems we found in our path before and we’re now ready to whip out the ultimate system.

Perhaps with a bit of hindsight, wisdom, or a wee little bit of both, our developers would realize that every time they start developing an application from scratch a whole new bunch of complications will crop up and will have to be solved. While this happens the management team who has promised to deliver in time to the big bosses is obviously breathing heavily down the programmers’ skinny necks.

This happened to me once, although we didn’t go as far as actually begin the development a countless amount of hours was wasted in meetings to trying and figure out what we were going to do and how.
The issue for many startups is that very often the software is developed hastily for lack of funding or time constraints. This generally leads to a structureless applications patched together at the last minute. That’s how it is and always going to be – and in my personal experience it’s definitely better this way than running out of funding because the entire process is managed by a megalomaniac-developer with serious ego-related issues.
Once the application is ready and the product is launched there’s never going to be time to stop. Look back. Amend emissions and non-blocking bugs until it’s too late. That’s just the natural process.

After 1 year of life the initial product will most likely be completely unrecognizable and changed/badly-patched in many of its core components. This will make keeping track of what’s exactly going on inside the software harder.
So now what.
The approach I’ve found most feasible and realistic is to gradually fix and produce documentation as the development progresses. A software, especially a website, will never stop evolving and the amount of feature-requests and bugs to fix will only increase with time, stopping the entire machinery to go back and fix is just not an option. However, whilst new functionalities are being added, they will probably have to be integrated with old ones. This is where wisdom can assist you. It is definitely worth spending a few hours more on each new piece of code to patch up the old part it has to touch. Gradually your development process will fall back on track and there won’t be any more wild panic because of obsolete or faulty routines and functions.

If, on the other hand, your software is rotten to the core and cannot be rescued, well, tough sob, you should probably have thought it through more carefully before putting your hands on the keyboard.

Having said that I’d like to add that rewriting an application is not entirely impossible, but it’s most likely going to be a colossal process which will require large sums of money.

Bookmark It