Uncategorized

STARTUPS – 5 THINGS TO IMPROVE PRODUCT SUPPORTABILITY

A very common scenario at most technology startups – a couple of releases have already been shipped and you are now juggling between the delivering features for new releases and managing customer escalations. But you do not have a separate support channel and escalation team, and so it’s your engineering team that ends up spending time to resolve customer escalations and support issues. As a result, ongoing delivery of the new releases takes a hit. You know that your competitors are waiting for this very moment. If only you had given product supportability it’s due earlier.

It’s known that between the need for agility and faster delivery, supportability often gets step motherly treatment. Designing and implementing supportability in the product early on can help the engineering team save precious bandwidth. Focus on supportability during initial stages can pay long term dividends. Let’s see how:

1. Setting up a Dependent Task more effective than a ‘Repro’

When a tester reports a bug/ issue during the product development phase, developers often ask for a reproduction of the issue (repro) so that they can go to the root cause faster. When an application is deployed in production and has a bug, the customer provides only the logs and the developers has just these logs to analyse and find the issue to come up with a fix. Now if the logs are insufficient, to identify the problem it increases the mean time to repair (MTTR) for support. One way to address this is if during internal testing, developers who need a repro setup, create a dependent task for getting better logs in the affected area and get it addressed.

2. No shortcuts in Uniform Logging

Almost all the products use standard logging frameworks which have log levels like info, warning, error, debug, etc. however, over a period of time developers tend to deviate to meet delivery deadlines. In most of the cases even though standard logging framework is available, developers sidestep it. Products which have multiple components / modules / sub-products often end up using different logging frameworks and this adds more complexity in analyzing logs as it becomes difficult to co-relate information coming from different modules in different formats. For improving supportability of any product, it is important to use product logging effectively.

 
3. Telemetry / Production monitoring is a must

Telemetry as it helps in gathering information relevant from the systems and this can later be used in decision making. So, enabling the monitoring of application in production can help understand how the application is performing in real world. It helps to uncover real world problems, identify common areas where the application has errors and also highlight performance bottlenecks.

 
4. Just one branch of code, that’s it.

In their early stages, startups are focused on adding new customers and often tend to make certain compromises to tailor their product to meet certain customer requirements. To achieve this, they end up creating multiple branches of code for specific customers. At this stage, most of them do not realize the complexities they end up creating from a maintainability perspective. Specific branches for different customers either for features or fixes can very quickly become unmanageable and end up needlessly engaging a lot more of your engineering resources. It is advisable to try to maintain just a single branch of code.

 
5. When it comes to Product Supportability don’t be pennywise.

You need to be prepared to maintain the product through its life. This means not only adding new features but also allow the engineers to invest in technically evolving the architecture. This requires a conscious effort, both from product engineering and product management teams. Investment also needs to be done to fully replicate production environment for pre-release testing. Supportability design and development needs to be prioritized accordingly.

Author

admin

Leave a comment

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