Have you ever had to compromise the quality of your work in order to meet a strict deadline?
This is a challenge we meet on a daily basis and finding the right compromise is never easy! Writing ‘less than perfect’ code will result in significant technical debt. This has to be fixed further down the line, so it’s never a good idea to write dirty code in the first place.
On the other hand, providing the perfect technical solution to a company that has since gone bankrupt whilst waiting for your delivery is obviously even worse.
When trying to find the right compromise, we usually ask the following questions:
What is the lifetime of the code I am writing?
This is usually overlooked, however, if the code you’re developing will be thrown away (or made obsolete by another system) in a year or so, any ‘shortcuts’ you take would not affect maintenance for a long while.
How critical is early delivery?
Do we have an equivalent system that is running right now? Can we afford to leave that working a bit longer in order to do a better job while delivering a new system? If the answer is no, then we must abandon ‘good practices’ and start coding. Obviously, one needs to make sure that everyone is aware that a re-write would be required if we require long-term maintenance.
Can I deliver in stages?
With agile practices, we tend to split system design into smaller deliverable modules. Instead of spending 6 months developing an application and delivering at one go, one can split the system into several modules (or iterations). This can help us go live with a minimalist version of the application within a few weeks instead.
Do you require help with delivering something on time? Get in touch!