Four Cornerstones of Development
In the late 1990s through 2010s when working with development and product teams the four cornerstones of development were always at the tip of the tongue or as a small poster on a wall somewhere. I know I wrote this up somewhere before and likely presented it in the late 1990s and/or early 2000s. Working in enterprise environments where people would get involved in product and development, but don’t have background these cornerstones were essential to bring up as basics.
The last few weeks and months I’ve been thinking of this a lot and wanting to point to it, but realized it isn’t really on line other than a quick mention in a 2003 post of mine – Needs When Running a Service. Actually, it is something I am always wanting to point to. With the increase of vibe coding and people creating products for “unique” purposes, but then people are sharing these more widely than personal use, the need for understanding and considering what they are getting into is really needed.
The Four Cornerstones of Development
These four cornerstones were initially called out for information application development, but applied to all user-centered development and product management. If a team building didn’t focus on all four of the elements from the beginning to make the right decisions early (or have them framed and adaptable) the product was really going to struggle.
The four elements are: Usable; Reliable; Maintainable; and Repeatable.
In the current state of quick development by non-developers using LLM coding tools the only one of these cornerstones that is known or partly handled is the first cornerstone, usable. What is made may be usable, or mostly usable, but that won’t really last and when selling it, sharing it widely, or having others rely on it. The reality means the person developing and shipping has unintentionally signed up for things they don’t have background in and often the LLMs aren’t that helpful with. Much of what is coming out as apps are proof-of-concept level of completion, which doesn’t get into any consideration of the other three cornerstones.
Usable
Usable is the first hurdle and focusing on the user and their needs. If things aren’t usable the offering doesn’t really have much. The other cornerstones don’t really matter, if the offering isn’t usable. But, usable and not having the other cornerstones will be problematic.
To be usable, even if it is a single simple use case, how adjacent use cases that aren’t supported are handled or avoided should be as clear as possible. The capabilities and limitations being clear help with the ease of use and understanding something when someone hasn’t touched it in months.
Reliable
The reliable cornerstone is what starts making the offering stable, secure, and enduring. The bugs have been remediated and it works as intended continually. Security and levels of privacy considerations have been put in place and consistently work as intended. But, so do the core myriad of use cases that were intended to work and also be supported, continue to work.
Lacking reliability you have something that breaks at various stress levels and use cases (core uses cases or edge cases). Building and shipping requires setting bounds for what is supported and how, but also how well the edges of what is supported are handled.
Maintainable
Maintainable gets to the reality that products and shipping them doesn’t mean something is done when shipped, it is the beginning. When planning out what is being built how it will be maintained over time and supported is essential. How will the product be updated to support changes to the coding language and/or operating system, and device updates. How do the regular changes in languages and operating systems get handled where security patches are made and break apps and services for users that use apps and services that aren’t updated.
User / customer support and how this is handled also falls into the maintainable cornerstone. Planning for maintainability and how that will be handled needs to include support as the two are often tightly related. When something breaks or doesn’t work as expected, that becomes support work. The support work is often related to considerations and steps (or not making them) the area of the maintainable cornerstone.
Repeatable
Repeatable is one that often gets left of consideration and one that is essential if what you built gets popular and scale. It is often thought of as something that may happen in the future, but understanding early on how to handle repeatability means it should be easier when the time arrives. Repeatability is needed when a server or service built on crashes and is not available or you need to replicate server backends for supporting the service as it scales (there are a lot of needs for repeatability, including building sandboxes to test and develop).
Everything changes as it scales and understanding that at the start of everything (product, organization creation, shared simple scripting project, etc.), gives a decent foothold to when growing and scaling hits. Planning not to scale is also an option, but often that can take just as much work as scaling and you need to be prepared for not scaling when others really want what you’ve made.
Not planning for this early and accounting for how to design the development of the app and/or services for this will lead to painful issues with growth or the reality of moving from one supporting backend server / service to another as things change (often more quickly than we expect).
Wrapping the Cornerstones to Help Make Decisions
The cornerstones were really helpful 20 to almost 30 years ago for a quick reality check for early early-stage planning and building something to ship. Building something and shipping it is the start, not the end. All four cornerstones will provide stability once things are shipped if you have planned understanding and using the cornerstones.
Today, much like early-ish web thinking of how far you want to open something up for use by others comes from considering the cornerstones. If all that is considered is just use and there is no interest in the other corner stones or just partial interest or capacity, it is likely good to keep the use of it limited to friends and or family, similar, or perhaps tighter.