Re: Simples Rules make creating Big Balls of Mud impossible.
- From: "Nick Malik [Microsoft]" <nickmalik@xxxxxxxxxxxxxxxxxx>
- Date: Sun, 14 Jan 2007 10:00:06 -0800
"Ed" <iamfractal@xxxxxxxxxxx> wrote in message
news:1168787053.864475.83470@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
John Carter skrev:
It has always amazed me.
I have finally put my finger on why I don't, nay can't build such a mess.
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@xxxxxxxxxx
New Zealand
Reading the responses you've received, it's easy to get the impression
that
balls of mud are not the norm, and are somehow the prerogative of the
novice
programmer alone. I'm not so sure. So let's get some figures, shall we?
Now, let's also be clear.
(a) I don't think many people said that BBoM is uncommon. I scanned the
thread. I did say that I don't experience it (much) in my work environment,
but that is a very controlled environment that is fairly atypical of
corporate IT departments. Do you think that folks are finding this pattern
to be diminished? If so, I'd be happy, but perhaps I'd wonder if this board
were all that typical of the level of resources that one would find in a
typical dev team.
(b) The "perogative of the novice" is an interesting statement. There are
two groups: junior and hobbyist. I know hobbyist developers who have
worked their way into positions in IT and product group teams. Many of
those developers have been employed for long periods of time in their
respective companies. There are also junior developers who have been
assigned design tasks but have not been properly supervised or guided,
allowing them to make decisions that a more professional developer would
have known to avoid. Do you include both in your notion of the "novice?"
Those hobbyists, many of whom I know, most of whom no longer write
production code, still consider themselves to be capable professional
developers.
Of course, ball-of-mud-ness is subjective (at least to some degree) and
thus
not machine-recognizable, but your comment on, "Cyclic dependencies,"
does
give us a litmus test, if a crude one.
Let's say that a program with inter-namespace circular dependencies is
a ball
of mud. Yes, that's a pretty harsh definition, but let's run with it.
(We'll
ignore intra-namespace circular dependencies for this poll.)
I agree that this indication is not a healthy sign in code, but I'm not
convinced that there is a strong coorelation between this particular
indicator and BBoM-ness. Unfortunately, the existence of a subjective
definition is a problem typical of many of the named anti-patterns, as you
pointed out.
Some time ago, I downloaded loads of open source Java projects at
random from
(mainly) sourceforge: let's pour them into an analysis tool and see how
common
balls of mud are in the open source arena.
Do these figures necessarily reflect professional software? Is Java
more or
less prone to balls of mud than any other language? Is sourceforge
representative of all software respositories? These important questions
are left glaringly unanswered by this post.
The following gives the project name, the number of classes in the
project,
and the number of inter-namespace circular dependencies:
AOL source: 341, 37.
Blue Marine: 3840, 76.
Fretts: 129, 0.
Eclipse (platform): 12001, 594.
Gant project: 3658, 190.
GenfwUtil: 2290, 23.
HSQLDB: 362, 12.
InfoGlueInstaller: 3851, 566.
JabRef: 669, 5.
JavaHMO: 7788, 352.
JBoss: 16073, 647.
MantaRay: 1749, 514.
MegaMek: 362, 13.
Tyrant: 178, 2.
OpenWFE: 5508, 94.
Quartz Web: 3447, 53.
XPlanner: 7601, 163.
JGraph: 58, 10.
So, there we are. Open source is composed of 95% balls of mud.
Well, sort of.
I think you recognize that the correlation is breaking down. You need some
better indicator than simply the existence of inter-namespace circular
dependencies. If you were to investigate these dependencies in some of
your "low-scoring problem children" (like MegaMek or HSQLDB) instead of
focusing on the worst cases, you may find simply that one of the
contributors was unclear about the correct use of a namespace and therefore
wrote code in multiple namespaces that was tightly coupled. I would expect
that this investigation would reveal that many of these open-source examples
are not BBoM.
On the other hand, open source may be more succeptable to this kind of
problem for two reasons:
1) Most contributors to open source are not paid to make that contribution.
Therefore, they are contributing "for the joy and love of coding" and
perhaps some recognition. While there are a very large number of
professional developers who are contributing to open source, I would suggest
that there is a propensity for hobbyist developers to also be attracted to
these kinds of efforts, and that this has the tendency to increase the
liklihood of poorly designed code being added to the code base.
2) Many contributions to open source are performed solo. That is, a
developer, working from the privacy of their home, checks in a change to the
baseline. Other developers may open it up and look at it, but if the change
appears to add needed functionality, there is often little concern for
whether the code is "well written" because the reviewer and the contributor
are peers (in a loose sense). In other words, a completely honest and
effect code review would run the risk of alienating members of group that is
writing the code. In this environment, it is quite easy for a developer to
make a mistake and for that mistake to end up in the production code.
So you've taken a measurement that may not coorelate to BBoM'ness, and
you've run that measure against a body of code developed in an environment
that attracts hobbyists and where junior developers have little or no
supervision. The fact that you found errors should be seen as expected, not
surprising.
I don't question that BBoM exists, or that it exists in open source
software.
I am concerned only that this measure is an ill one to use, and that the
body of code you selected is not indicative of the code that most
professional developers are paid to maintain. It is therefore not the most
useful finding in light of the OP's concern, who was finding himself
maintaining code in a paid setting.
--- Nick
.
- Follow-Ups:
- References:
- Prev by Date: Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
- Next by Date: Re: Simples Rules make creating Big Balls of Mud impossible.
- Previous by thread: Re: Simples Rules make creating Big Balls of Mud impossible.
- Next by thread: Re: Simples Rules make creating Big Balls of Mud impossible.
- Index(es):
Relevant Pages
|
