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 is a diminishing returns
graph which 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 artifact is JBGE: anything to the left of the
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.
The diagram is a little naive because it is clearly
possible for the value to be negative before the
artifact becomes barely good enough although for the
sake of argument I'm going to assume that you do a good
job right from the beginning.
Figure 1. Cost analysis of
just barely good enough.
Ideally all of your artifacts should be JBGE, as you see in the diagram.
Unfortunately, it isn't an ideal world. 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 1?
If not, then the diagram is more than just barely good
enough. 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 is
The fundamental challenge with JBGE is situational. For example, I often drawn
UML Sequence diagrams 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
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).
is JBGE you
In the case
in the case
of a user
would be the
and in the
case of a
would be the
put far more
proves to be
prey to the
to read it
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.
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
It shows two
the value in
or a couple
may want to
invest a bit
only want to
on the order
The value of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
architect, and then
design your system in an agile manner.
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around.
We actively work with clients around the world to
improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer. A full
description of what we do, and how to contact us, can be
found at Scott W.
Ambler + Associates.