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.

About: Shawn Jackson

I’ve spent the last 12 years in the world of Information Technology on both the IT and Development sides of the isle. I’m currently a Software Engineer for Paylocity. In addition to working at Paylocity, I’m also the Principal of Resgrid, a cloud services company dedicated to providing logistics and management solutions to first responder organizations, volunteer and career fire departments, EMS, ambulance services, search and rescue, public safety, HAZMAT and others. My focus is building better businesses through the use of applied, targeted and tactical software development and infrastructure implementation. My passion is solving real world business problems with technology and constant learning, in the fields of technology, business and law. I hope you enjoy reading as much as I do writing. Although I may not post as often as I would wish when I do I try and have something useful to say. Although programming is a great creative outlet it sometimes is far to technical and detail oriented to be a stress free outlet for me. So I write on this blog and sometimes a couple others. I also write fiction stories in my spare time, when I have some!


Leave a Reply

Your email address will not be published. Required fields are marked *