Just Barely Good Enough (JBGE) Artifacts: An Agile Core Practice

One of the more controversial concepts introduced by Agile Modeling is that agile models and agile documents are sufficient for the task at hand, or as agilists like to say they are just barely good enough (JBGE). In this article I make the following critical points about a model or document (an artifact) being just barely good enough:

1. Just Barely Good Enough (JBGE) Is Actually The Most Effective Possible

For some reason people think that JBGE implies that the artifact isn’t very good, when in fact nothing could be further from the truth. When you stop and think about it, if an artifact is JBGE then by definition it is at the most effective point that it could possibly be at. Figure 1 depicts the cost and benefits curves for creating an artifact. There are several critical things to understand:

The dashed line is parallel to the cost curve. The dashed line touches the benefit curve at the point where the slope of the benefit curve equals the slope of the cost curve.
Point of maximal value. The point of maximal value is where the incremental cost of adding more to the artifact exceeds the incremental value being added. This is the point at which the angle of the benefit curve is the same as the angle of the cost curve. Anything effort to the right of this point removes net value from the artifact because the cost expended is rising faster than the benefit gained. It is at this point the artifact reaches the state of being JBGE. By definition, JBGE artifacts maximize value.
The depicted cost curve is ideal. Figure 1 shows the cost curve being a straight line, which is “ideal”. In reality, the cost per unit of effort varies to reflect the cost of the people doing the work. For the sake of argument we’ll assume the cost of people doesn’t vary (there’s a single “charge out” rate). In reality the cost line should be jagged, not smooth.
The depicted benefit curve is ideal. Similarly the benefit curve of Figure 1 is also ideal in that it assumes that any effort you put into an artifact adds benefit. The means that the person(s) working on the artifact are capable of doing the work and don’t make mistakes when doing so, assumptions that aren’t realistic in practice. In reality the benefit curve should be bumpy, not smooth.

Figure 1. The cost and benefit curves for creating an artifact (click to enlarge).

Figure 2 is summarizes the value curve for an artifact being just barely good enough. Value refers to the net benefit of the artifact, which would be calculated as benefit – cost. The dashed line is at the point where the point of maximal value has been reached, which is where the artifact is JBGE. Anything to the left of the JBGE line implies that you still have work to do, anything to the right implies that you’ve done too much work. When you are working on something and it isn’t yet sufficient then you can still invest more effort in it and gain benefit from doing so (assuming of course you actually do work that brings the artifact closer to it’s intended purpose). However, if an artifact is already JBGE (or better) then doing more work on it is clearly a waste: once an artifact fulfills its intended purpose then any more investment in it is simply busy work. Interestingly, the diagram shows that value of an artifact follows the law of diminishing returns.

Figure 2. Value curve showing when an artifact is just barely good enough (click to enlarge).

Ideally all of your artifacts should be JBGE, as you see in the diagram. Unfortunately, it isn’t an ideal world. There are three common reasons why you’ll likely overshoot the ideal:

Accidental. You’ll often put too much effort into an artifact, unintentionally overshooting the mark as you work on it. For example, do I really need the arrowhead on the rightmost end of the value curve in Figure 2? If not, then the diagram is more than just barely good enough.
Purposeful. When you’re new to the concept of JBGE it’s a bit scary at first. It can be comforting to purposefully overshoot, to do more than is required, just in case you’ll need it later on. However, the reality is that if later on you do realize that you need something more, or something else, you can likely create it at that time.
Change. Sometimes you create an artifact that is JBGE and then the situation changes and you discover that your artifact now contains extra material, out of date material, or is missing material.

Agile modelers are only human and they are not always going to do a perfect job, so realistically some artifacts are going to be more than just barely good enough. The secret is to learn how to detect when you’ve reached the point of something being just barely good enough and then to stop working on it. Easy to say, hard to do.

2. Just Barely Good Enough (JBGE) is Situational

The fundamental challenge with JBGE is situational. For example, I often draw a UML Sequence diagram on a whiteboard to explore complex logic and then discard it once I’m done with it. In this case the whiteboard diagram is fine because it helps me to solve the issue which I’m thinking through with whomever I’m working. But, what if we’re in a situation where we’ll need to update this logic later on AND will want to do it via the diagram instead of via source code? Clearly a hand-drawn sketch isn’t good enough in this case and we’ll want to create a detailed diagram using a sophisticated software-based engineering (SBE) tool. We’d still create an agile model even though it is much more sophisticated than a sketch because JBGE reflects the needs of the situation (remember, agile modelers Model With A Purpose).

To determine if an artifact is JBGE you must actively work with the direct audience of that artifact. In the case of system overview documentation that would be the maintenance programmers, in the case of a user manual that would be the end users, and in the case of a sketch sequence diagram that would be the programmer implementing the corresponding code. Without knowing what the audience wants, you cannot realistically create something which is JBGE, putting you in a situation where you’re motivated to put far more effort into the artifact than you need to. This often proves to be wasted effort, because chances are very good that the artifact will fall prey to the they aren’t going to read it (TAGRI) principle. To ensure that you know what the audience of an artifact wants, you need to ensure good communication with them and better yet strive for active stakeholder participation.

3. Just Barely Good Enough (JBGE) Does Not Imply Low Quality

Some people seem to think that artifacts which are JBGE will be of low quality. The reality is that they are of sufficient quality for the job at hand. This isn’t an excuse for doing a poor quality job because quality is in the eye of the beholder: the audience for an artifact determines if it is sufficient, not the creator of it. If your stakeholders require an excellent, detailed artifact then it is JBGE when it reaches that point of being excellent and detailed.

4. Just Barely Good Enough (JBGE) Changes Over Time

An artifact can move along this value curve in both directions throughout it’s lifecycle. Your needs may change, becoming either more complex or less so, and therefore you may choose to update your artifact(s) accordingly. If the artifact becomes less than good enough then you will need to consider updating it.

If an artifact is more than good enough should you rework it? Only if it is harming your efforts elsewhere. For example, a hand drawn diagram would have been sufficient for Figure 1 although at the time that I drew it I didn’t have easy access to any writing materials (such as paper or a whiteboard) so I used Microsoft Visio instead. Later, when I did have access to such materials I didn’t bother to replace the diagram because that would also have been useless busy work. Yes, I invested too much effort when I created the diagram because it took me almost 15 minutes to draw it with Visio yet I could have drawn this diagram on a whiteboard, taken a picture of it, and cleaned it up with software in less than five minutes. But, investing an additional five minutes to change the format of the diagram wouldn’t make any sense.

For a second example, let’s say I don’t like the current heading along the X axis and believe that Expenditure would be better. Would it be worth the effort of starting up Visio, reading in the document, updating it, generate the GIF, upload the image to my ISP, edit the HTML for this page to rework the text to match the diagram, upload the HTML, open up my browser and look at this article to ensure that I got it right, do any necessary fixes and subsequent uploads, and then commit the changes to version control? Sounds like at least five to ten minutes of effort for almost no value. Agile modelers Update Only When It Hurts , and the current X axis heading doesn’t hurt enough to warrant this investment (actually, I think the current heading makes sense). In fact, this sort of update would actually decrease the value of this article because the cost is greater than the benefit.

5. JBGE Comes Sooner Than You Think

Figure 3 depicts a more realistic version, specific to modeling, of the ideal graph shown in Figure 2. It shows two value curves, the dashed one indicating the theoretical value of modeling according to traditional/heavy approaches and the solid line which I believe to be the actual value curve. Traditionalists seem to assume that significant investment in modeling, and corresponding specification, will continue to add value over time. Practice, however, shows that the value in modeling comes through improved communication and a bility to think things through, and that this value peaks rather quickly. For example, for initial up-front modeling this typically occurs after several days or a couple of weeks (naturally for high-risk initiatives you may want to invest a bit more time with initial modeling). Even for enterprise architecture you still only want to invest a couple of weeks on initial modeling. For sprint/iteration modeling it’s even shorter, usually just an few hours, and for model storming on the order of minutes.

Figure 3. The value of modeling (click to enlarge).