Overview
A product company having a successful run with many large corporate customers across India, wished, naturally, to sustain its success and grow with a next-generation product. A new generation of a product is attempted due to some dissatisfaction. SwanSpeed consulting engages with clients at three different levels of increasing involvement: Tell, Show and Do. We were called in to tell them what to do and show them how-to on a critical sub-system. We started with an overall assessment of the product and development/management practices (glimpses of the actual report in appendix). A significant section of the product (a large, crucial and complicated stored procedure) was replaced by a modern business object centred system to dramatically reduce complexity of code corresponding to that functionality, i.e reduction of technical debt. This enabled easy addition of new features, and in one such case without any additional coding. So, in effect, a small expansion of functionality on top of cleaner design/code. To be fair the old part of the system incurred many changes made under the pressure of urgent client demands, which over time, lead to mounting technical debt (a classic progression of cause and effect in the s/w world) which gradually resulted in a lot of unsavoury side-effects, the main one being a congealed swamp of code which slows new feature added to a snail’s pace. Our intervention showed conclusively that the product could be carried into a new generation with improved scalability, performance and lowered technical debt.
Telling the ‘what’ and ‘why’
Modern systems have significant validation of data-input at the front end, more effectively implemented in JavaScript and the current preference being an Angular SPA. Also, the need for multiple browser compatibility recommended Angular.
Showing ‘how-to’
This is a vertical slice of re-architected functionality, from business logic to persistence. The secondary goal was a demonstrator of quality code and good design. However, we had to define in code, the full entity model so that other parts of the systems to be transitioned in the near future have the base ready. A large part of this entity model was used in the implementation of the said functionality. We used .Net and a Redis in-memory database with Jason for exchanging data. We had improved performance via easy object creation and processing holding almost all of the data in-memory.
This exercise also included significant auxiliary documentation, automated tests and code quality reports (SonarQube) to meet a Definition of ‘Done’:
DEFINITION of DONE
- 80%+ coverage (Unit test and API tests range between 600 and 900 tests)
- All current functional tests of SP pass with new architecture
- Technical Documentation and Class relations
- Inner Functions or SP also to be covered
- Scheduler adjustments to be included
- Coding standards are met (SCA and code reviewed)
The original sub-system was created over a few years, and we developed the re-architected version in about three person months, over six calendar months (one person part-time). We finally gave a master script to run 1080 API tests. This excluded a few other unit tests with the effective coverage being 95%.
We never had more than a couple of bugs outstanding at any point, usually fixed within 36 hours. This meant a bug tracking tool and the overhead was simply absent; we have no use for Jira, or such like. A suitable CI setup within SwanSpeed environment, including over 1000 tests, meant that any fix/change could be tested for regression in a jiffy; a jiffy being approximately 12 mins. Since we were not expanding this sub-system in the near future, we didn’t attempt to lower the build plus test times further.
A final demonstrator for delivery was a ‘small’ change: A new stock exchange and relevant information was to be handled in the new system. This needed just a configuration change, followed by some testing effort (a dozen automated tests) and all went smooth as silk; We had it ready for production without a hitch.
APPENDIX
Some actual snapshots of the Engagement

R1: Glimpse of report

Fig A: Recommended and largely implemented Architecture

Fig B: Code Duplication Picture (If it were bad one would see Yellow/Red)

Fig C: Code Quality report snapshot (65% coverage for total code, the business logic forms under 70% of total code)