Manage code rework amid changes

Customers are driving the requirements for products and have the ultimate authority to validate the same. In such scenarios it becomes critical to get feedback from the customer as soon as any functionality is ready. This is where Agile methodology comes in handy, guiding the product development centred around customers and has become the most practised methodology. 

Agile uses incremental development principles, where after every time interval a functional deliverable is expected and this deliverable goes through a quick customer feedback. This time interval is termed as a sprint cycle. At the end of every sprint cycle new functionalities are delivered and customer feedback is incorporated. Since we work in incremental design and coding fashion, not all requirements are designed and coded in a sprint but evolved. This indicates that there could be a lot of re-work in terms of designing, coding, testing etc if not handled properly. Rest of the article talks about a few things which can help you manage re-work better.

Design and PoC : Let's say you want to start with an application development, would you expect some working software, post the first sprint? If, so then it might lead to a mess going forward, because as a natural tendency you would continue to build on top of it until a road block is hit which could be quite late or requires a complete revamp. First sprint typically should be used to define the boundaries, evaluate various technologies to use, their maturity, scalability etc. and then go about building a design around it. Once things look convincing then go about implementation and incremental development of the product. During this design phase one could do some quick PoCs for evaluation only but be ready to throw away code. On similar lines for any feature the first few days of a sprint should be used to design and PoC, and the last few days to integrate with main line code. Some of the outcomes of this design and PoC should be data points describing alternate solutions, impact of change in future to this feature code and to dependent parts of the product.

Managing design options : During the design and PoC phase there will be multiple options encountered. Some could be due to following reasons:

1. Technologies to use
2. Frameworks which could be used
3. Number of concurrent users of application
4. Amount of data retrieved and processed at any given action
5. Duration of data processing leading to synchronous v/s asynchronous based design

  These options pose a challenge on how to evaluate these and take an informed decision.

Some of the parameters which can be used are:

• Clarity of implementation - Are there any unknowns to implement or does it depend on any technology feature which is not clear. If, so they get lesser points.
• Time to implement - Typically brute force approaches are simpler to implement and get more points.
• Performance impact - Does this degrade the performance significantly considering minimal, medium or heavy load. Solution with better performance gets more points
• Rework impact - If, for any reason we would need to redesign, restructure or add more parameters, what is the amount of rework will be required in other modules. More the rework in other modules lesser the points.

If we are looking for a solution as a stop gap solution, it's okay to pick the simplest to implement solution. Otherwise, the option with most points gets a shot for implementation.

Implementation : Once we have a reasonable design in place it's about implementing. During the implementation as well we can take care of a few things to minimise the rework needed. Few patterns frequently followed are:

• Argument passing and returning - should be dict, json, struct etc. i.e. grouped wherever possible else you will add up passing each variable
• Separation of work - Modularise as much as possible and define contracts among them such that in future its easy to refactor anything
• Logical separation - Keep the logically independent code in separate functions as much as possible so that refactoring anything would cause minimal impact. One can also try the design pattern such as driver or plugin based implementation.

Conclusion

“Change is the only constant, be prepared for it to sail smooth”

Change in requirements will continue to happen and these will continue to impact on assumptions and design drafted for code. In such an environment it is important for the developers to carefully plan and use innovative methods in order to minimise the rework.