Ultimately, everyone who’s working in IT has to deliver business value. Sometimes business value means battle-tested, hardened, audited software. This is probably the case for your bank’s software.

Sometimes it means delivering something that looks nice, fast. When there’s an important launch coming up, for example. This blog post is about doing this safely.

When you’re building software in a hurry, you’re going to take shortcuts. This is fine, under strict circumstances:

• Get everyone on board: everyone should acknowledge that we’re taking a shortcut. This doesn’t mean everyone should agree (many developers are keen on software quality, luckily), but everyone should know we’re 1. taking it, 2. why we’re taking it and 3. we’ll fix it later.
• You take a calculated risk (chance × impact), and it should be accepted.
• The business (the one who’s paying for inevitable fixes later on) should be aware that we’re taking shortcuts (to meet business goals), which MUST be fixed later on.
• The choices you make are in line with the architecture of your system. Architecture is “Stuff that’s hard to change later”, so don’t make choices which are expensive to fix.
• Document the shortcuts you’ve taken, so you don’t forget what to fix later on.

Tip: don’t skip on writing tests with a high ROI (Return On Investment), like integration tests which are easy to write but often hit 70-80% of your code. It’ll greatly speed up your development cycle.

Conclusion

Building software in a hurry should never be your normal modus operandi, but is sometimes necessarry to meet business goals or achieve greatness. Use it with care.