Just Sufficient Implementation
Just Sufficient ImplementationAnother development goal closely related to YouArentGonnaNeedIt and DoTheSimplestThingThatCouldPossiblyWork. This is a frequently (and hotly) debated topic on the DoIt team.
It is also related to the EinsteinPrinciple.
We were originally exposed to this principle by JamesCollins; it was originally expressed in the EpisodesPatternLanguage developed by WardCunningham.
The idea is that you should constantly drive for the simplest, basic solution that will just exactly meet your customer's requirements for a piece of software.
Here is the JSI page from the DoIt development approach website (internal to FirstUnionNationalBank):
Just Sufficient Implementation produces a solution that is architectecturally sound, employs proven development techniques, satisfies the requirements that are most important to the customer (as documented in the Work Queue), and provides a high return on the investment made.
Just Sufficient Implementation (JSI) adds value to the development process, because it focuses on what is most needed, what is most important, what the user recognizes as valuable technology to support his business. Because it endeavors to meet the business requirements "and nothing but the business requirements", it results in a higher return on investment and is easier to justify for purposes of funding and resource approval. JSI affirms the adage: "It is hard enough to guess what we DO need, much less what we're GONNA need." Most importantly, JSI gets the job done.
JSI introduces its own set of risks and drawbacks. One of the most critical factors for the success of a team that practices JSI is the need to establish a robust object model. Without this, the long term viability of the product will be compromised. In the "heat of the moment", its absence will lead to an under-engineered - patchwork approach to code development.
Because JSI focuses more emphasis on user-recognizable functionality, it is easy to overlook production-level, operational-code issues. Furthermore, people have different opinions regarding the meaning of "just sufficient"; having a "Narrow" view of JSI can lead to missing environmental complexity - can cause in-sufficient implementation. It can lead to cheap short-cuts, and become an excuse for "doing the wrong thing". In an effort to make a deadline, the temptation can arise to adopt a "don't touch" mentality - leaving bugs in underlying utilities.
In short, JSI is never and excuse for "low quality"; it is not a license for foolishness.
While the risks and drawbacks to JSI are real, there are several factors that contribute to its successful application within a Work Group.
Refactoring is cheap. JSI moves complex changes to later development episodes. At the design level, this recognizes that some of the key intellectual content of a component may need to be redesigned as new Implied Requirements that are within the scope of the Product Initiative emerge. Refactoring code from one form to another functionally equivalent that is more maintainable or more efficient is generally a fairly straightforward matter.
While the focus on user recognizable requirements will always be the a cornerstone to JSI, the experienced Work Group will maintain a "mature", explicitly documented view of internal operational requirements that provide a common understanding throughout the group.
Another factor critical to the successful application of JSI is to clearly express known product limitations to customers when a product is delivered. This is particularly important when Implied Requirements have been deferred or deprecated during the course of a development episode. Akin to the need to cultivate close Work Group to customer communication, the maintenance of close communication among members of the Work Group within the context of a Development Episode is essential.
Developing software with the JSI approach is a continual learning experience. To facilitate this learning within a Work Group, particularly one made up of individuals from diverse backgrounds, the group should define rules of engagement when "mining" patterns, lessons learned, etc. The group must be able to move beyond Rehashing past experiences to Learning from past experiences.
Just Sufficient Implementation may not work in all organizations.
The list below identifies some of the hindrances to the successful application of JSI:
EditText of this page
(last edited March 4, 2007)
or FindPage with title or text search