JAE (Just About Enough) software development

Technological advancements in cloud and CI/CD have reduced time for hosting and managing an application. The time-to-market for a product is now significantly dependent on product development time. This has built up a pressure on various teams to deliver in a considerably less time frame. In order to address this, various organisations adopt different software development methodologies. Whichever methodology one picks, the question remains what is Just About Enough (JAE) to be done. 

Product team worries about what are JAE features to be delivered to keep customers engaged on platform, Infrastructure team worries about JAE capabilities for the software to run seamlessly, software development team worries about JAE functionalities to be added with quality. While on a good day everything works fine, we need to be equally prepared for what unveils on a bad day. This is something that bloats up the JAE list of everything. Some of the things from development perspective to take care about are error handling, technological changes such as infrastructure, frameworks, scalability, high availability, configuration, debugging and security.

Every software needs to ensure that all the error conditions are handled and meaningful messages with recovery hints are provided. This is not beyond JAE, however, if we try to build fancy system to handle and recover such erroneous cases is probably an over-do. However, this is subjective to kind of software and intended use of the software and the time it is being built. In some cases, this could turn out to be an additional advantage and helps you to capture the market further, but no customer will come to a product only because it has a state-of-art recovery mechanism. So, software should have JAE error handling which is sufficient to keep the customer engaged, informed and help him/her achieve the intended tasks. For instance consider if a submit action fails, it is enough to display the error message and ask the user to retry the same operation if, possible. Depending upon the action one can think of caching data to avoid user re-entering the same data during retries.

The technology is ever changing, and software should be ready to adapt to it for the benefits it brings with its advancements. These changes could be in terms of infrastructure layer, open source modules or frameworks, modes of communication between modules etc. At the same time, it is critical to preserve the business logic because it is perfected with great effort and takes a great deal to alter it when the product is in the field. So, what is JAE in this regard while developing a software? It is a good practice if, the software has a driver-based or plugin-based framework developed around the core business logic, such that, if, any external entity changes there is no to minimal impact to business logic. However, For performance critical software such a layer might not be desirable. Some of the best practices are to use ORM to support database operations, use of driver layer to talk to any messaging bus etc.

During the proof-of-concept phase scalability and high-availability may not matter much because the intention is to evaluate the idea. However, in the production phase it is expected that a software provides scalable and highly available services. Depending upon the initial addressable market segment and expected load on software this could be delayed. It is advisable to test the software on these parameters to know your limits. At the same time while we delay this, we add technical debt. This debt could be less or more depending upon how big a change scalability and high availability brings in. There have been times when the software has fallen deep such that a complete revamp was needed. So, as JAE for this would be to consider these factors during design and implement such that bringing these capabilities in should be simple. Consider having threads, arrays, lists from day 1 or try to de-couple the code in a way which can be converted into threads, micro services, go routines etc.

While it is critical to ensure that something works, it is imperative to have JAE configurable parameters, and debugging tools. The scope of this is to have enough knobs in the software to turn on and off the features and fine tune them. There should be enough APIs to manual retry or fix the issue in case of emergency fix. At the same time, there needs to be as much debug logs as possible, scripts to debug issues in various environment even in production.

Security is another area, though we all admit that it is must and needed, but easily forgotten for the initial few releases. It is this time when the software is sitting on ticking time bomb. Depending upon the sensitivity of the data being transferred across, the impact could be down to zero. This is not to be about only software security but infrastructure as well. Today there are shared services ecosystem namely cloud, containers etc. over which we don’t have a direct control but forms the basis of our software security. It is not enough to have https based urls, however, we need to consider data at rest and data in transit security as well. Moreover, any sensitive information being transmitted through APIs should be encoded. There are various standards, testing methods, best practices etc. which should be implemented and utilised to validate the security practices of the software and stand tall in the competition.

Conclusion

“Don’t just solve today's problems, solve some of tomorrow's as well”

In today's pace, we look for quick solutions to get things going, such things later can lead to huge technical debt. Just About Enough of anything is subjective to the context it is applied in. It is typically constrained by the time to achieve a feature and resources at hand. It is the responsibility of feature designer, developer and the team as a whole to ensure that each feature has JAE of everything to make the software more secure, maintainable, usable, repairable.