4 Often Ignored Software Development Tactics

All enterprise technology initiatives share a common primary objective of automating and optimising business processes. Effective enterprise applications don’t just help businesses to be efficient and cost effective but they also enable transformation and agility. Focus, therefore, needs to be not just on delivering this technology within budget and on time but on its efficient and economical operation and also its flexibility and extensibility in responding to emerging opportunities.

So, building effective technology requires a cultural and technological rigour within the organisation. Agile and responsive project management, effective DevOps (Developer Operations) and strong talent management are well known for strengthening confidence in successful delivery and operations of enterprise technology.

DevOps, Talent Management and Agility: Keys to Successful Project Delivery

But they alone do not guarantee delivering technology that is economical, efficient and effective. Following, often ignored, tactics enable management in steering projects to deliver business value, economise development and operations and support transformation and disruption.

Focus on the Core Value

Each system aims to deliver a core value to the business it supports. It then also has peripheral functions that may support or augment that core value. Imagine a web or mobile app that enables people to pay local government fees and taxes online. A utility to launch surveys on public sector performance is a useful value added feature but is not essential for the core functionality.

Building technology with an uncompromising “all or none” strategy possess risks of diverting attention from the core purpose or value that technology should aim to deliver. An incremental or phased approach of building and releasing systems favours proportionate application of effort and focus to the core and peripheral functions.

It is important to understand that any value add is only effective when there exists value to add to.

Cover the Last Mile All Along

The difficult last mile: Only if there wasn’t the last mile.

Any long distance runner will confirm that the last mile is always the longest and the hardest. In technology projects, the last mile may involve setting up production infrastructure and support structures.

But here the last mile need not be covered right at the end. As the system is developed incrementally, infrastructure requirements for the final release are also refined helping the engineers to provision and build the infrastructure incrementally.

Mission critical systems should ideally require little support. All systems should have considerable level 0 support enabling users to recover from exceptional circumstances. Where this is not possible, systems should be supported proactively with a focus on failure prevention as opposed to failure recovery.

By incorporating supportability into the requirements, no feature can be delivered without developing the corresponding support mechanisms.

Let the Lightning Strike — Early

Majority of projects build technology incrementally. Once a feature or functionality is completed, it goes through a round of functional and non-functional (performance, security, resilience etc.) testing usually conducted by the QA. Passing these tests does not mean that the functionality is now production ready. It only means that the QA have validated that the functionality meets the requirements and specifications as understood by QA and development teams. Requirements can be erroneous or misunderstood. Both the functionality and the tests can be also implemented incorrectly such that tests are validating incorrect functionality as correct functionality.

Hence, the only way to truly validate the delivered functionality is to test it with real data or traffic. This is known as production-parallel testing. This usually involves loading the system being developed with the real world data in real time and observe its behaviour. Hence, building a production-like environment in parallel for the system under development enables production parallel testing from the very beginning.

High-level Description of Production Parallel Testing

Production parallel testing is possible where the projects extend, replace or renovate existing technology. Here, data feeds can be taken from existing systems in production and fed to the systems under test. Systems being developed to automate processes where automation does not exist pose a challenge. However, such scenarios are increasingly rare.

Production parallel testing is usually done near the end of a development project. That is a risky approach because issues discovered then are more expensive to resolve and can jeopardise the release. It is prudent to perform such testing as soon as the first demonstrable feature has been completed and QA passed. Any issues discovered then will be easier and economical to resolve. This will also highlight infrastructure shortcomings.

Build for Longevity and Agility

Most system require substantial changes during their lifetime. Bugs are discovered that need to be fixed. The business and the domain evolve and systems need to be adapted. Emerging and disruptive business opportunities require extensions to the applications. Last but not the least, dependencies change. Operating systems, infrastructure, frameworks and libraries are upgraded requiring depending applications to upgraded as well.

Software should be built so that it can accommodate changes efficiently, economically and without introducing side effects of increased complexity, reduced reliability and adverse performance. Adverse side effects tend to be additive resulting in reduced longevity of the application. Technological agility allows efficient and economical adaptation of systems to support disruptive and transformative business changes.

DIPSy is a set of development principles that enhance an application’s longevity and agility. DIPSy stands for,

Domain focus, i.e., building system that have a strong alignment with the target domain.

Independence, i.e., building the application decoupled from its dependencies and the infrastructure.

Patternise pragmatically, i.e., use appropriate architectural, design and implementation patterns.

Simplify aggressively, i.e., eliminate accidental and optional complexity while managing the irreducible essential complexity to enable efficient incremental development and subsequent maintenance.