3 Standards of Software Quality
Prototype, Usable, and Complete
Software Prototypes are built for growth.
Poorly built small applications and software prototypes are not the same. A poorly built small application can have the appearance of being close to usable and at the same time be difficult to maintain, hard to iterate on, and time-consuming to debug. A software prototype can have the appearance of being close to usable and are…
built for additional functionality
A prototype’s purpose is generally to experiment with design and performance without building out all of the necessary infrastructures required to make the application fully usable. This is achievable by making highly prioritized features demonstrable. In the example of a mass-market consumer application, demonstrable properties will likely include look-and-feel as a priority. For an internal enterprise application, demonstrable will likely contain all actions to get a business process completed.
Once the definition of demonstrable is determined, then the prototype is built to allow those benefits to be realized by extending the application. Extending the application means writing a new code to complete the functionality more than rewriting existing code to fix shortcuts.
thoughtful, same as a production application
A software prototype is built to grow. That’s why thoughtful development must be at the heart of the build. A commonly significant phase during the application development process is the data modeling stage. Simply, an application fundamentally relies on data to be output to the user. The model and the shape of that data informs the complexity of the final application. Data modeling during the application's prototyping gives the application a faster development velocity than starting from a prototype. This is because the functionality of the application is tightly glued to the way it works with data.
When the data model is altered, many parts of the application have to be altered to accommodate the change. Thoughtful modeling of the data is only one part of prototyping. Managing the flow of data, managing the application's state, managing the complexity of the components that the application is built from, all of these practices and more are fundamental at the earliest stages of prototyping.
without many debugging needs
A prototype that has a high need for debugging is most probably going to lead to a completed application that has a codebase that is near impossible to debug. Prototypes provide simple demonstrations of core functionality, and because of their simplicity, there is not much to debug. At the prototyping stage, what is seen as a bug is generally a feature that has not been implemented. That means when a user interacts with the prototype and provides comments that the login is broken, it’s likely because they have made no effort to authenticate users.
An easy-to-understand example of how developers achieve this is that when demonstrating functionality to save a comment on a post, they will use mocked (hard-coded) comment data instead of connecting to a database of comments. That decision allows them to connect to the database later and show comments in the prototype near-identical to real comments to demonstrate how commenting works.
Usable applications deliver user’s stories.
Wine gets better with time. Software gets better with usage.
A delay in getting an application in front of users means a delay in completing an application. It matters that an application is ready in as many ways as possible before making it available to the entire addressable audience. For an enterprise expense management application, the application might start in the finance department for a trial period before it is made available to the sales teams incurring expenses.
Before getting the first user on an application, a development team is limited to their own intelligence and assumptions as the sources of information to make the application usable to the intended customers. Making an application usable happens by finding the users who will rely on the application whether it is complete or not, correcting code where users have falsified assumptions, and developing functionality that has been overlooked.
Find the users who are going to rely on the application, whether it is complete or not.
No easier place than corporate settings to find these users. The application users are going to be paid as a part of their job to use the application. Consumer applications can benefit from paying intended users to trial the application; it can be an inexpensive alternative to marketing the application as if it is completed. Under the surface, the goal is to find users who are motivated to use the application for reasons other than its intended purpose.
Correcting code where users have falsified assumptions.
An assumption is falsified when the application’s best-informed guess at how users will behave is proven to be false based on the response from actual users.
Making the application usable means correcting assumptions, and correcting assumptions does not mean completely re-writing the application. When the rare situation occurs that users are suggesting the entirety of what has been built is not working for them. Probably the developers are not going to be in a position to provide a usable solution. When the much more common case occurs, users suggest that interactions with the application are not perfectly delivering on their expectations, then developers can rewrite existing code to align better interactions with what the users need.
Developing functionality that has been overlooked
Users can point to needs that are not at all addressed by the application. When that happens, the developers and the stakeholders that organize them come together to determine the priority of those needs when weighed against already identified features that remain to be built. The options they have are either to incorporate the overlooked needs into the completed release of the application or to release the application intentionally excluding those needs and deciding to address them later or with an alternative method, such as implementing third-party integrations.
Complete applications only require maintenance.
When an application is being used by the intended audience and meets their needs day-to-day, it is complete. There are ways of providing new features and new life to the application, often with new features and new releases. From the moment the application is complete, the option exists to move to a level of development that is maintenance-only. That means fewer developer-hours being applied to the application overall, fewer budget dollars being spent on development in any given time period, and higher levels of focus on both related and unrelated projects.
Fewer Developer-Hours
The application is completed to the users' satisfaction, and now the developers are left without new problems to solve or enhancements to deliver. It is time to reduce the hours. Depending on the project's size, we can either fully remove developers from the application or reduce developers from full-time to part-time. The hours that are applied to the application now are almost exclusively bug fixes and keeping technology up-to-date. There will inevitably be bugs in the application that were not discovered until after a full release. They can be trivial; they can be critical; they are always present. Keeping some amount of time and attention from the developers means that they have the capacity to fix those bugs quickly. Almost as fast as the application is marked as completed, technology will improve.
Underlying dependencies will be updated, performance enhancements will be applied to the broader environment the application lives in, and more. Project Managers can then commit developer hours to maintain the application’s fitness to the technology of today. This provides the aforementioned performance enhancements, and beyond that, security is maintained. Often underlying dependencies are updated to provide fixes to newly discovered attack vulnerabilities. It is prudent to apply those updates to the application from the time it is complete until it is obsolete.
Fewer Budget Dollars For Development
Hand-in-hand with fewer developer-hours comes fewer budget dollars for development. As a result of application completion, budget dollars can be re-allocated to customer support, marketing, sales, and any other endeavor that complements the application. There are some caveats. When the application is complete, and there is a cost associated with each user, this causes the budget dollars to grow to accommodate the larger infrastructure needed to provide the application to more users.
Focus on both related and unrelated projects
A completed application can provide the basis to begin a new application. There may now be a codebase in related applications that can be applied to adjacent market segments, and use-cases are not useful to the original application. In the case of unrelated applications, you now have a team of developers that are no longer actively building your application. This frees them up for new projects. When the relationship with the developers is strong, there is an opportunity to engage them with new ideas.
