Think of Production Support now, not later!

Developers just love to get into the code as soon as possible. Some might also like skip writing any specs, just start and finish the fuckin code and impress your manager, and get an appraisal. Wohoo. For what they might not realize that this is a proven recipe for disaster.
So you and your team are hired by a really big fat organization to build a software product. The client really wants this done in 5 months, or else he is screwed, and consequently you too. This is what generally happens,
- Numerous white board sessions understanding what is required and different approaches to implement it.
- All developers in your team including you are super excited to work on this from scratch. Your team creates a sleek POC which showcases how this would work. Everyone goes home happily and drink beer.
- Development work starts and the developers crazily slap the keyboard punching thousands of lines of code.
- The product is ready in 4 months, testers have no clue what the heck this is all about, but they are asked to test it.So they do!
- With a go ahead from testers, it finally reaches on the desk of Production Support. As a developer you are asked to explain in brief the overall architecture and usage of the product.
- And they say, What the fuck is this!!!!!!!!!%^%&^%&^.

You might say, Production Support guys are dumb, the developers could understand the system so well, why can't they? There lies the first mistake. You assumed all along that you or your kind, are the users of the product. As a matter of fact, when the shit hits the fan, the Production Support guys will be the real users of this product as they would have to solve issues in real time. So, how to avoid this fiasco? Well, the only time to resolve this would be the initial stages of design. Put yourselves into a Production Support role and try using the product.
- Try answering questions like, if someone calls about something not working in the product, how would you as a support guy, troubleshoot the
- Can we remote into the users machine and overhaul the product.
- Can the product automatically send logs and crash dumps when something wrong happens.
- Can it make lunch. What?
- May be try involving a production support team lead or someone who accounts for their team and try to get their ideas too.

If you do not think of these things, your product will be usable only from a developer's perspective and not from someone who this product was really made for. So, please think about supporting the product while designing the architecture, or else down the line, it might be the developers who will be asked to support the product all along!

Happy Programming!


Post a Comment