Apology Driven Development
Stop me if you’ve heard this. The company you work for comes to you and asks you to create a super simple, rapid prototype of a new product, or whole new version of an existing product.
“We just want to play around with it a bit, get these few features working end to end so we can play with the concept. Don’t put a lot of time into it as it’s throw away work”
At this point in my career, I’ve heard that more times then I can count and I’m sure you all are or will be, in the same boat. Depending on the company, how much they understand the benefits of setting up your development foundation, it may actually be true that it’s throw away, but that is something we should never bank on.
It’s happened to me, it’s happened to developers I worked with and I’ve seen it a lot when I did some consulting work. Looking at a project and wondering why a good developer has such a horrid workflow, a mess of spaghetti code, no separations, no SOLID, no testing? One answer I hear, “It was a prototype, never meant to go into production”.
Which is why I have a rule: “All code written, should be written in such a way it can easily be updated and tested to go to production“.
This means I start all projects with a SOLID foundation, using DI, separation of concerns, applicable patterns for the system and hiding implementations behind interfaces that can be swapped out. When I’m doing a prototype I most likely won’t do a lot of unit or integration testing, and I almost never TDD a prototype. There are plenty of ways you can rapidly prototype without investing a ton of time, without sacrificing the foundation.
Once you commit your code, no matter how good it is, it’s technical debt. But not all technical debt is created equal. For any spike, prototype, test, experiment ensure that the structure and foundation would be able to go out to production and that other developers could easily go in and make changes.
Even if your a 1 person shop, and your pretty positive you’ll be the only one ever working on the code, always build it so that you wouldn’t be ashamed, or apologizing, if another developer had to go in and maintain it. We can call that an ADD (Apology Driven Development) style. You should never commit code that you know at the time of the commit you would apologize to another developer who had to maintain it.
If you’re a First Responder or part of a Disaster Response Org, or know someone who is, check out Resgrid which is a SaaS product utilizing Microsoft Azure, providing free logistics, management and communication tools to first responder organizations like volunteer fire departments, career fire departments, EMS, search & rescue, CERT, public safety, security and disaster relief organizations.
