Software Craftsmanship by Pete McBreen
Robert C. Martin
CxOs, VPs, Directors, Mangers, and Software Engineers. It will change
the way you think about the software development industry and
profession.
In Software Craftsmanship, McBreen exposes the weaknesses of our
current system of software engineering, and proposes an alternative
model based the older apprentice/journeyman/master model. McBreen
makes the point that building a software project is not akin to
product manufacturing. We don't have factories that stamp out
software. Rather we have groups of people trying to massage software
into place. McBreen likens successful software development to
blacksmiths, or silversmiths. To McBreen, software is a craft that
takes years to learn, and more years to master. The only way to
properly learn the craft is to be taught at the side of a master.
McBreen's thesis emphasises something that is missing from software
development today: attention to quality, and attention to expertise.
The dotcom frenzy saw thousands of startup firms throwing young
untrained bodies at complex software projects. The idea was that a
programmer is a programmer is a programmer. The more you have, the
faster you get done. McBreen counters this concept by showing that
large software systems are better built by small teams comprised of
masters, journeymen, and apprentices, than by large teams of plug
replaceable programming units.
Robert C. Martin | "Uncle Bob" | Software Consultants
Object Mentor Inc. | rma...@objectmentor.com | We'll help you get
PO Box 5757 | Tel: (800) 338-6716 | your projects done.
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python|
"One of the great commandments of science is:
'Mistrust arguments from authority.'" -- Carl Sagan
Charles Marcus Durrett
posting as a fair representation of the book "Software Craftsmanship".
Your summary has it that "...we have groups of people trying to massage
software into place" like "...black smiths, or silversmiths". You then
supply McBreen's recommendation that an "...alternate model based on the
older apprentice/journeyman/master model" be adopted.
I disagree. The reason that so much software development consists of
filing and filling to "fit" is because the parts aren't standard. (You may
call the parts "components" if you wish.) One of the unrevealed causes of
this is that programmers would seemingly rather develop parts than deliver
solutions.
A set of standard parts would permit the delivery of solutions using
"...teams of plug replaceable programming units." Such a set of standard
parts would be like a software alphabet that could be easily taught and
used - even by what we call a "user" today.
This analogy between an alphabet and software components has a (perhaps)
coencident numerical resonance in Von Neumann's "Theory of Self-Reproducing
Automata". The English alphabet has 26 letters which we use to record all
that we wish to record and to say all that we wish to say. Von Nuemann's
automata has 29 "letters" in its "alphabet" of different kinds of cellular
automata to achieve self-reproduction.
My windy point is that the solution to the rampant software
failure/cost/quality problems lies over in the area of standard parts, the
component alphabet, knowledge of which can be acquired and used by the
"literate" in fairly short order. No, I can't tell you what the letters of
that alphabet contain but I know it is out there awaiting someone brighter
than myself to bring it into the light. Then we can all slap our heads and
say "Of course! That's obvious."
Chuck
"Robert C. Martin" <rma...@objectmentor.com> wrote in message
news:3baf55a3...@news.supernews.com...
John Roth
"Charles Marcus Durrett" <cdur...@hotmail.com> wrote in message
news:C8Jr7.94133$Hm.10...@typhoon.mw.mediaone.net...
> At the risk of not "mistrust[ing] arguments from authority" I'll take your
> posting as a fair representation of the book "Software Craftsmanship".
>
> Your summary has it that "...we have groups of people trying to massage
> software into place" like "...black smiths, or silversmiths". You then
> supply McBreen's recommendation that an "...alternate model based on the
> older apprentice/journeyman/master model" be adopted.
>
> I disagree. The reason that so much software development consists of
> filing and filling to "fit" is because the parts aren't standard. (You
may
> call the parts "components" if you wish.) One of the unrevealed causes
of
> this is that programmers would seemingly rather develop parts than deliver
> solutions.
>
> A set of standard parts would permit the delivery of solutions using
> "...teams of plug replaceable programming units." Such a set of standard
> parts would be like a software alphabet that could be easily taught and
> used - even by what we call a "user" today.
I suspect that you've missed the point. The "plug replacable component"
panacea has been around for a good while now, and it hasn't worked. All
that it does is to move the focus from a lower level to a higher level. At
some
point, you still have to hand craft your solution.
If you look at the notion of 'business process', you'll see this point quite
clearly. With few exceptions, all business processes are hand crafted by
people called managers. The fact that business processes are hand
crafted means that the automated parts of those processes must likewise
be hand crafted by someone, and it really doesn't matter what you call
that someone.
The other problem with the "standard components" argument is that there
are vast libraries of pre-packaged components, and many of them get used on
a regular basis. Most projects do not rewrite graphics components like
checkboxes and buttons. Likewise, scientific and engineering projects
do not rewrite their sine routines every time.
On the other hand, many projects do rewrite date routines. Why? You
may learn something by looking at the difference between how dates are
handled and how trigonometric functions such as sines and tangents are
handled. I have yet to see a pre-packaged library for handling dates that
did what I needed in an application without more bother than it was
worth, unless, of course, the application didn't need anything very
sophisticated in the way of date handling.
The market has spoken on this issue, and it has said that the reusable
component philosophy works quite well in some domains, and fails
miserably in others.
John Roth
Michael Feathers
> filing and filling to "fit" is because the parts aren't standard. (You
may
> call the parts "components" if you wish.) One of the unrevealed causes
of
> this is that programmers would seemingly rather develop parts than deliver
> solutions.
No way. I've had my back against the way enough times to look at external
solutions for many parts of what my teams have written. It always comes to
down to a few things:
1) Vendor lock-in is a real issue, and there is little incentive to
standardize across vendors except in the most horizontal markets.
2) Platforms often change quicker than vendors can respond.
3) The time it takes to learn what a component is capable of is often less
predictable than the time it takes to write what you need.
4) If the component does not come with source, you are trapped into the set
of extensions that the vendor allows, not necessarily those your customers
want.
5) There is real business value in being able to extend in ways your
competitors can't.
One client of ours was able to get a healthy lead in foreign markets because
they were used to developing software in-house and their competitors were
trapped with third party software they couldn't modify.
Off-the-shelf software has its benefits, but the cost side is larger than
most people imagine.
Michael Feathers
www.objectmentor.com
Pete McBreen
>"Robert C. Martin" <rma...@objectmentor.com> wrote in message
>news:3baf55a3...@news.supernews.com...
>> McBreen hits the nail on the head! This book is a MUST READ for all
>> CxOs, VPs, Directors, Mangers, and Software Engineers. It will
change
>> the way you think about the software development industry and
>> profession.
>
your
>posting as a fair representation of the book "Software Craftsmanship".
>
>Your summary has it that "...we have groups of people trying to massage
>software into place" like "...black smiths, or silversmiths". You
then
>supply McBreen's recommendation that an "...alternate model based on
the
>older apprentice/journeyman/master model" be adopted.
>
>I disagree. The reason that so much software development consists of
>filing and filling to "fit" is because the parts aren't standard.
(You may
>call the parts "components" if you wish.) One of the unrevealed
causes of
>this is that programmers would seemingly rather develop parts than
deliver
>solutions.
My take on this is different. The software engineering metaphor allows
us to forget that most really effective software developers have a
really deep knowledge of there software development toolkit. The
Software Craftsmanship metaphor allows us to acknowledge that it takes
considerable time to develop mastery and learn this deep knowledge.
Until developers get to that point it is often easier to (re)write a
small component than it is to find and learn how to use a standard
component.
The last time I checked most mainstream OO development environments had
well over 2000 standard classes, some a whole lot more when all of the
ancilliary packages/toolkits are considered. The software engineering
mindset does not seem to enable developers to really develop the deep
skills and mastery of actually using what is in their toolkit. If they
are really lucky(?) they might get a 5 day sheep dip course in a new
environment, but more often they have to get an "EJB for Dummies" book.
No wonder developers keep on reinventing the wheel.
>My windy point is that the solution to the rampant software
>failure/cost/quality problems lies over in the area of standard parts,
the
>component alphabet, knowledge of which can be acquired and used by the
>"literate" in fairly short order. No, I can't tell you what the
letters of
>that alphabet contain but I know it is out there awaiting someone
brighter
>than myself to bring it into the light. Then we can all slap our
heads and
>say "Of course! That's obvious."
Standard parts are a great help - it is one of the reasons I prefer OO
development environments, but I think that you are drastically
underestimating the time it takes to get really skilled at using the
standard components. It is relatively easy to pick up enough to get by,
but developing mastery takes a long time. The closest analogy I can
think of comes from several years ago. Beginning Smalltalk programmers
claimed to know the class library well after 6 to 12 months. Some really
productive Smalltalk veterans with over 10 years experience said they
were still learning the finer nuances of the class library. Guess who I
would recommend for a project:-)
Pete
----
Pete McBreen, McBreen.Consulting , Cochrane, AB
email: petem...@acm.org http://www.mcbreen.ab.ca/
Author, "Software Craftsmanship The New Imperative"
Addison-Wesley (C) 2002
http://www.amazon.com/exec/obidos/ASIN/0201733862
Lieven Marchand
> In Software Craftsmanship, McBreen exposes the weaknesses of our
> current system of software engineering, and proposes an alternative
> model based the older apprentice/journeyman/master model. McBreen
> makes the point that building a software project is not akin to
> product manufacturing. We don't have factories that stamp out
> software. Rather we have groups of people trying to massage software
> into place. McBreen likens successful software development to
> blacksmiths, or silversmiths. To McBreen, software is a craft that
> takes years to learn, and more years to master. The only way to
> properly learn the craft is to be taught at the side of a master.
What implications does this idea have for the tools we use to build
software? Craftsman have an array of well made tools, each optimized
for a specific purpose and intented to be used by a specialist. A lot
of the modern software engineering/building tools remind me of the
multivalent power tool, adequate for a wide range of things but
excellent for none.
--
Lieven Marchand <m...@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Pete McBreen
>rma...@objectmentor.com (Robert C. Martin) writes:
>
>> In Software Craftsmanship, McBreen exposes the weaknesses of our
>> current system of software engineering, and proposes an alternative
>> model based the older apprentice/journeyman/master model. McBreen
>> makes the point that building a software project is not akin to
>> product manufacturing. We don't have factories that stamp out
>> software. Rather we have groups of people trying to massage software
>> into place. McBreen likens successful software development to
>> blacksmiths, or silversmiths. To McBreen, software is a craft that
>> takes years to learn, and more years to master. The only way to
>> properly learn the craft is to be taught at the side of a master.
>
>What implications does this idea have for the tools we use to build
>software? Craftsman have an array of well made tools, each optimized
>for a specific purpose and intented to be used by a specialist. A lot
>of the modern software engineering/building tools remind me of the
>multivalent power tool, adequate for a wide range of things but
>excellent for none.
Agreed. Many of the software development tools we have right now seem to
be targeted towards ease of use/ease of learning but in the process they
do not cater to the "power user" developer.
Maybe we could say that emacs comes close to being an effective tool for
a master craftsman, since many fantastic extensions have been built on
top of emacs, but the problem with using this as an example is that few
developers have had the time to learn enough about emacs to appreciate
its power. [I also don't want to fan any flames either.]
For me the big question is - How do we raise the skill level and
experience of developers so that we can make much better use of the
tools that we have available?
Charles Marcus Durrett
"John Roth" <john...@ameritech.net> wrote in message
news:tquu0bq...@news.supernews.com...
What is wrong with moving it to a higher level? As you point out, someone
would still have to assemble a solution. (See manager section below.)
>
> If you look at the notion of 'business process', you'll see this point
quite
> clearly. With few exceptions, all business processes are hand crafted by
> people called managers. The fact that business processes are hand
> crafted means that the automated parts of those processes must likewise
> be hand crafted by someone, and it really doesn't matter what you call
> that someone.
Why don't we aim for being able to "call that someone" a "manager" too? In
fact it could actually be the manager if what the manager had to work with
was more akin to an alphabet and dictionary rather than per-team/technology
ad hoc hieroglyphics of today.
>
> The other problem with the "standard components" argument is that there
> are vast libraries of pre-packaged components, and many of them get used
on
> a regular basis. Most projects do not rewrite graphics components like
> checkboxes and buttons. Likewise, scientific and engineering projects
> do not rewrite their sine routines every time.
>
> *SNIP*
>
> The market has spoken on this issue, and it has said that the reusable
> component philosophy works quite well in some domains, and fails
> miserably in others.
The market hasn't yet fallen silent - it still speaks.
>
> John Roth
>
>
Arved Sandstrom
The current misuse of titles by almost all companies is an indication of how
wrong things really are: senior engineers with 5 years experience? Who is
kidding who? And let's face it - most of the "programmers" out there are not
even particularly good programmers, let alone software developers.
I buy into this craftsmanship idea 100%, because it rings true. And I think
the apprentice/journeyman/master model is more literally apt than maybe was
originally intended, because I think there truly are credentials that can
and should be earned as one progresses in software development. One
fundamental part of that model is that the reputation of one reflects on the
reputation of all, and the credentials convey trust - a customer can look at
journeyman's papers or a master's papers and know that they are getting the
goods, without necessarily knowing the individual. And a professional
society establishes a mechanism by which standards can be maintained and
made known.
We have a lot of technicians at present, basically. They have little
interest in professional development or in the art of software development,
and I can't say I like having my efforts lumped with theirs. You can observe
that I may be talking through my hat, but let's face it - if a system such
as what I propose were instituted, then I would have to prove myself also.
I mention all of this because I think it is a prerequisite to raising skill
levels. Take someone with 3-5 years experience, and call them a senior
analyst or an architect, and what did you just do? You convinced that person
that they know way more than they really do, and remove any incentive to
continue learning at the journeyman level. Why, we had XML 'experts' popping
up like daisies within 6 months of the Recommendation being finalized, and
the same goes true for a bunch of other technologies. Out of the last 20
years I've been doing software for 12-13 of that, and I'll be damned if I
have the gall to call myself an expert in anything. I think I am just
getting pretty good, and I'd call myself a senior journeyman.
I am going to have to read the book. :-)
Regards,
Arved Sandstrom
"Pete McBreen" <petem...@acm.org> wrote in message
news:vHNr7.10131$oa2.5...@news2.rdc1.ab.home.com...
Phil Malin
<cdur...@hotmail.com> wrote:
> At the risk of not "mistrust[ing] arguments from authority" I'll take your
> posting as a fair representation of the book "Software Craftsmanship".
>
> Your summary has it that "...we have groups of people trying to massage
> software into place" like "...black smiths, or silversmiths". You then
> supply McBreen's recommendation that an "...alternate model based on the
> older apprentice/journeyman/master model" be adopted.
>
> I disagree. The reason that so much software development consists of
> filing and filling to "fit" is because the parts aren't standard. (You may
> call the parts "components" if you wish.) One of the unrevealed causes of
> this is that programmers would seemingly rather develop parts than deliver
> solutions.
>
> A set of standard parts would permit the delivery of solutions using
> "...teams of plug replaceable programming units." Such a set of standard
> parts would be like a software alphabet that could be easily taught and
> used - even by what we call a "user" today.
While I strongly agree with you that having non-standard parts goes a long
way to making the problem of software development difficult, standardisation
isn't going to solve it by itself either.
To me it's like designing and building an electronic circuit where the parts
are specified in great detail, ranging from voltage and current behaviour to
effects of temperature variation, etc. The point is that standardising the
components just etches away at the complexity the creator has to deal with.
There's still the problem of designing and building a system which meets
whatever the requirements be and that is (usually) hard enough in itself.
--
Phil Malin
p...@turms.com
(m) 0405-133-537
Robert C. Martin
>My windy point is that the solution to the rampant software
>failure/cost/quality problems lies over in the area of standard parts, the
>component alphabet, knowledge of which can be acquired and used by the
>"literate" in fairly short order. No, I can't tell you what the letters of
>that alphabet contain but I know it is out there awaiting someone brighter
>than myself to bring it into the light. Then we can all slap our heads and
>say "Of course! That's obvious."
I doubt it. Not that standard components aren't beneficial, they are.
For example: i = i + 1; is a standard component. It works just the
same in many different computers. It is much better than
cla; ior i; iac; sca i;
So, compilers have already given us a vast panoply of standard parts.
And that has been very beneficial. And yet, it hasn't solved the
problem. Other languages and libraries may give us even more standard
parts; but they won't solve the problem either. The problem is not in
the parts so much as the problem is in the relationship between the
parts. It is that relationship that can never be standardized.
Robert C. Martin
>rma...@objectmentor.com (Robert C. Martin) writes:
>
>> In Software Craftsmanship, McBreen exposes the weaknesses of our
>> current system of software engineering, and proposes an alternative
>> model based the older apprentice/journeyman/master model. McBreen
>> makes the point that building a software project is not akin to
>> product manufacturing. We don't have factories that stamp out
>> software. Rather we have groups of people trying to massage software
>> into place. McBreen likens successful software development to
>> blacksmiths, or silversmiths. To McBreen, software is a craft that
>> takes years to learn, and more years to master. The only way to
>> properly learn the craft is to be taught at the side of a master.
>
>What implications does this idea have for the tools we use to build
>software? Craftsman have an array of well made tools, each optimized
>for a specific purpose and intented to be used by a specialist. A lot
>of the modern software engineering/building tools remind me of the
>multivalent power tool, adequate for a wide range of things but
>excellent for none.
Have you worked with IntelliJ? It's very nice.
Richard Riehle
> I doubt it. Not that standard components aren't beneficial, they are.
> For example: i = i + 1; is a standard component. It works just the
> same in many different computers.
Robert,
Have you ever found it amusing that every programming language has
a different compound symbol for "not equal?" I have seen,
<>, |=, /=, not =, and other variations.
So much for standard components here. :-)
Then there are the peculiar C family languages with their odd
variations of the example you cite.
But this should not present a problem for the experienced programmer. Some
readers play Chess. Others play Go. Some play both games along with
Othello, Checkers, Backgammon, and Cribbage. The notations are different.
The strategies are different. Somehow we learn to play all of them with
varying degrees of skill.
However, when I look at the complexity of Chess versus the complexity of Go,
my first impression is that Chess is more complex because of the variation
of moves allowed by the different pieces. My old Judo Sensei, a Go Master,
quickly relieved me of that misconception. The artifacts of Go, although
simple, lead to extraordinarily complex combinations. I mention this because
someone brought up the Von Neumann machine. In its most refined form, the
Von Neumann machine is a Go board. It can be represented with CISC or
RISC instruction sets.
McBreen's point, that we need a journeyman system may be right on target. When
I learned Chess and Go, it was from Masters of the Game. Yes, I read some
books, but ultimately, it was those Masters who led me through the learning
process with their unmerciful habit of trouncing me soundly day-by-day. Yes,
I learned the book strategies. But one day, one of those Masters, playing white
to my black, looked at my defense and said, "Aha. The Petroff defense. It's a
long time since I've seen the Petroff defense." I was reusing a defense, a
standard component that I'd read, but it was the Master player who made it
real for me. He did, by the way, trounce me soundly, yet again.
Software is not easy, unless we are writing toy programs. Sometimes even those
are difficult. We can learn from the books. We can learn from our mistakes.
We
can also learn from those who have written the books and made those same
mistakes before us. I hae been programming for a very long time, and still find
myself apprentice to someone who is working on a new set of problems I may
not have seen before. In my mind, there is so much to learn in this field, that
"round trip gestalt" applies to career progress as much as it does to system
development.
A hundred years from now, those who are doing the equivalent of what we today
consider software development will look back on what we are doing and regard
us with the same respect we give to mathematicians in the time of Charlegmagne.
It is important that none of us become to smug about what we think we know lest
history find us out to be more the object of laughter than of reverence.
Richard Riehle
univ...@nospamradix.net
> On Mon, 24 Sep 2001 16:26:10 GMT, "Charles Marcus Durrett"
>
>>My windy point is that the solution to the rampant software
>>failure/cost/quality problems lies over in the area of standard parts, the
>>component alphabet, knowledge of which can be acquired and used by the
>>"literate" in fairly short order. No, I can't tell you what the letters of
>>that alphabet contain but I know it is out there awaiting someone brighter
>>than myself to bring it into the light. Then we can all slap our heads and
>>say "Of course! That's obvious."
>
> I doubt it. Not that standard components aren't beneficial, they are.
> For example: i = i + 1; is a standard component.
In what way is this like a software component?
> It works just the
> same in many different computers.
There's more to being a software component than running on multiple
machines.
> So, compilers have already given us a vast panoply of standard parts.
> And that has been very beneficial. And yet, it hasn't solved the
> problem.
What are the standard compiler parts in the way of software components?
What do you mean here?
> Other languages and libraries may give us even more standard
> parts; but they won't solve the problem either. The problem is not in
> the parts so much as the problem is in the relationship between the
> parts. It is that relationship that can never be standardized.
Yet there standards for how parts of systems relate. There are design
patterns, books on complexity, the UML/OML modelling relationships between
parts - aggregation, composition, has-a, is-a - relationships between
layers as parts of systems as in my published article: "OO Layered
Architecture and Subsystems" at my web site. Maybe you just wish we
weren't able to understand relationships between parts. Then one of your
greatest desires would be realized and the piece meal, seat of your pants,
XP like approach to things would just be the bee's knees.
Elliott
--
http://www.radix.net/~universe ~*~ Enjoy! ~*~
Hail OO Modelling! * Hail the Wireless Web!
@Elliott 2001 my comments ~ alt.*/comp.*/bitnet may quote
Stephen Baynes
> I doubt it. Not that standard components aren't beneficial, they are.
> For example: i = i + 1; is a standard component. It works just the
> same in many different computers. It is much better than
I would expect it works in many different ways on different computers.
However the end result is much the same on most.
--
Stephen Baynes CEng MBCS Stephen...@soton.sc.philips.com
Philips Semiconductors Ltd
Southampton SO15 0DJ +44 (0)23 80316431
United Kingdom My views are my own.
Thomas Gagne
too many programmers keep rewriting stuff that doesn't need to be rewritten.
I'm going to assume most businesses have been around for a while, and have
amassed a lot of code already. I'm curious:
* when older code was created was it modular?
* were the functions implemented in such a way as to be as independent of
their environment as possible?
* are these functions written so that other languages can access them?
* are these functions available in a library to link with?
* are they in a runtime library to dynamical load?
* are they documented?
* if they aren't documented, are they at least listed somewhere people can
find them?
* if they're architecture specific, are they callable via RPCs of some
sort?
Components don't have to be third-party. There are plenty of them where most
people work already. The problem is people keep writing new code in the
language de'jour. How much code that already existed in other languages do
you think was rewritten (or reimplemented) in Java in the last 4-5 years?
Since it was a new language, what ratio of experienced programmers (with the
problem domain, not the language) to inexperienced ones do you think were
writing the new Java stuff? What do you suppose that cost companies?
I'm not against switching languages, but I am against reimplementing stuff
that already works. Personally, I wouldn't accept many excuses here. I've
been involved in projects that took previously unreusable 16-bit code and
wrapped it up so as to be accessible to modern (then) 32-bit languages
(different stack frames and everything).
--
.tom
Daniel T.
> rma...@objectmentor.com (Robert C. Martin) writes:
>
> > In Software Craftsmanship, McBreen exposes the weaknesses of our
> > current system of software engineering, and proposes an alternative
> > model based the older apprentice/journeyman/master model. McBreen
> > makes the point that building a software project is not akin to
> > product manufacturing. We don't have factories that stamp out
> > software. Rather we have groups of people trying to massage software
> > into place. McBreen likens successful software development to
> > blacksmiths, or silversmiths. To McBreen, software is a craft that
> > takes years to learn, and more years to master. The only way to
> > properly learn the craft is to be taught at the side of a master.
>
> What implications does this idea have for the tools we use to build
> software? Craftsman have an array of well made tools, each optimized
> for a specific purpose and intented to be used by a specialist. A lot
> of the modern software engineering/building tools remind me of the
> multivalent power tool, adequate for a wide range of things but
> excellent for none.
I think we also have an array of well made tools. They range from very
general to extremely specific. They are called class libraries. The
computer and text editor equate more to the work-bench and clamps used
by blacksmiths or silversmiths. Just a thought.
Dan L. Pierson
> Lieven Marchand wrote in message ...
> >What implications does this idea have for the tools we use to build
> >software? Craftsman have an array of well made tools, each optimized
> >for a specific purpose and intented to be used by a specialist. A lot
> >of the modern software engineering/building tools remind me of the
> >multivalent power tool, adequate for a wide range of things but
> >excellent for none.
>
>
> Agreed. Many of the software development tools we have right now seem to
> be targeted towards ease of use/ease of learning but in the process they
> do not cater to the "power user" developer.
A good example here may be the increasing popularity and near
universal acceptance of the windowed debuggers in common IDEs.
Features like continually visible call stack windows and, to a lesser
extent, variable value windows do make things easier and are distinct
help over that aspect of older command line tools. BUT...
The better command line debuggers were starting to evolve in a
different direction that could have been much more useful to the
master developer -- a programmable and customizable debugger. Non
trivial programs involve non trivial datastructures and component
relationships. It is frequently much more valuable to be able to
customize the debugger to show, or even probe or exercise, the
critical aspects of these data structures and relationships than to
repeatedly manually expand and walk through a graphical tree widget to
get to them. It is especially valuable to be able to do this
interactively in the debugger instead of going through a complete
edit-compile-rerun-to-point-of-problem loop to add an inspection
function which must then be called by some inconvenient and weak
method such as entering a strange watchpoint definition.
The end goal of this direction in debugging is best seen in the
facilities available in environments such as Smalltalk and Lisp where
the "debugger" is the complete programming environment operating
interactively at the point of error. This sort of thing is harder to
do in less flexible languages, but it has been done.
I write this not to plead for different IDE debuggers but to point out
a fundamental difference between tools designed for masters and tools
designed to appeal to novices.
Dan Pierson
Daniel T.
> [To Mr. Martin]
> Your summary has it that "...we have groups of people trying to massage
> software into place" like "...black smiths, or silversmiths". You then
> supply McBreen's recommendation that an "...alternate model based on the
> older apprentice/journeyman/master model" be adopted.
>
> I disagree. The reason that so much software development consists of
> filing and filling to "fit" is because the parts aren't standard. (You may
> call the parts "components" if you wish.) One of the unrevealed causes of
> this is that programmers would seemingly rather develop parts than deliver
> solutions.
>
> A set of standard parts would permit the delivery of solutions using
> "...teams of plug replaceable programming units." Such a set of standard
> parts would be like a software alphabet that could be easily taught and
> used - even by what we call a "user" today.
Most auto makers construct their cars out of a set of standard parts.
Even the newest designs are often simply re-assemblies of various
standard parts covered in a new skin. Although there are many who can
fix a car to varying degrees, very few can be trusted to create a new
kind of car, and they almost always need at least some specialized parts
for their creation.
Clothing and furniture designs are mass produced. In both cases, the
designers take basic materials and combine them in new ways. There are
many who can make a piece using the design of a master, many more who
can fix a piece if it breaks, but no mere "user" will ever progress to
designer simply by knowing the tools and materials.
> This analogy between an alphabet and software components has a (perhaps)
> coencident numerical resonance in Von Neumann's "Theory of Self-Reproducing
> Automata". The English alphabet has 26 letters which we use to record all
> that we wish to record and to say all that we wish to say. Von Nuemann's
> automata has 29 "letters" in its "alphabet" of different kinds of cellular
> automata to achieve self-reproduction.
Isaac Asimov once said, "[Shakespeare] and I know the same words. It's
just a matter of putting them together right. Why can't I do it as well
as he does?" Many other writers over the years (including Keats) have
had the same (or similar) lament.
My wife happens to be an English major and a writer. Her and I know the
same alphabet, we even have a comparable vocabulary, yet she is able to
craft prose which I can only read, never create. She uses the same
words, she has a basic stock of idioms many of which I use as well, she
even has "patterns" developed by others that she takes advantage of. In
other words her craft comes with the same tools that ours relies upon.
Yet in both cases, that is simply not enough.
Before anyone misunderstands, I'm not saying that the analogy between
the English alphabet and programming constructs is flawed, on the
contrary I feel it is highly accurate. My wife writes a word, I write a
statement. She sometimes starts with an outline, I sometimes start with
a design document. She sometimes starts with a few simple sentences,
which she expands upon iterativly until she has a short story, then
later a novel, I sometimes do the same with a program. She develops
characters in ways that may never show up in the story but help to
define them, I do the same with classes of objects.
Mr. Durrett,
My "windy point" is that there is a fine line between art and craft, and
the job done by a competent programer does more to blur that line rather
than bring it into focus. And art will never be componentized.
Keith Ray
(Dan L. Pierson) wrote:
[...]
Have you see Apple's debugging facilities in MacOS X? They have a good
GUI built on top of gnu tools, so the command-line and the IDE are both
available...
Charles Marcus Durrett
"Thomas Gagne" <tga...@efinnet.com> wrote in message
news:3BB0860A...@efinnet.com...
> There are lots of reasons reusable components aren't reused. Among them
is
> too many programmers keep rewriting stuff that doesn't need to be
rewritten.
>
> The problem is people keep writing new code in the
> language de'jour. How much code that already existed in other languages
do
> you think was rewritten (or reimplemented) in Java in the last 4-5 years?
> Since it was a new language, what ratio of experienced programmers (with
the
> problem domain, not the language) to inexperienced ones do you think were
> writing the new Java stuff? What do you suppose that cost companies?
>
> I'm not against switching languages, but I am against reimplementing stuff
> that already works.
This is one of the major reasons I am more optimistic about language
independent platforms (like .NET) than I am about platform independent
languages (like Java). And if this new platform is cpu and OS independent
then so much the better.
> ...
> --
> .tom
>
Chuck
Topmind
> There are lots of reasons reusable components aren't reused. Among them is
> too many programmers keep rewriting stuff that doesn't need to be rewritten.
AKA Job security. There is no incentive and a re-use cop would be
expensive and hard to validate.
-T-
Lieven Marchand
> Lieven Marchand wrote in message ...
> >What implications does this idea have for the tools we use to build
> >software? Craftsman have an array of well made tools, each optimized
> >for a specific purpose and intented to be used by a specialist. A lot
> >of the modern software engineering/building tools remind me of the
> >multivalent power tool, adequate for a wide range of things but
> >excellent for none.
>
>
> Agreed. Many of the software development tools we have right now seem to
> be targeted towards ease of use/ease of learning but in the process they
> do not cater to the "power user" developer.
They hinder more than they help for the "power user" developer. They
are designed to allow anyone to draw and click a toy application
together but they have a huge scalability problem. Books like The
Pragmatic Programmer and others counsel against things like wizards
and GUI drawing tools and favour a more declarative programmatic way
of doing GUI design for exactly this reason.
> Maybe we could say that emacs comes close to being an effective tool for
> a master craftsman, since many fantastic extensions have been built on
> top of emacs, but the problem with using this as an example is that few
> developers have had the time to learn enough about emacs to appreciate
> its power. [I also don't want to fan any flames either.]
I've been using emacs the last 10 years and I discover new things
regularly. For an environment really designed for the craftsman
programmer I was thinking about Lisp environments, especially Genera
but I didn't want to fan flames too.
Lieven Marchand
> The end goal of this direction in debugging is best seen in the
> facilities available in environments such as Smalltalk and Lisp where
> the "debugger" is the complete programming environment operating
> interactively at the point of error. This sort of thing is harder to
> do in less flexible languages, but it has been done.
Beginning Lisp programmers often complain about the lack of a line per
line stepping debugger in CL. Experienced programmers use trace,
advise around functions etc. and don't feel the need for such a
debugger at all.
univ...@nospamradix.net
Is this a tyoe? ;-}
Elliott
>
>> ...
>> --
>> .tom
>>
>
> Chuck
>
>
Charles Marcus Durrett
news:MPG.161a90552...@news.earthlink.net...
That's too easy a charge and probably not true. If job security were really
the motivator one would expect to see more successful projects (we fail
about 70% of the time) and better quality (whatever you mean by that) code.
It must be something else.
>
> -T-
>
Chuck
Simon Smith
univ...@NOSPAMradix.net wrote:
Not quit.
See
http://www.go-mono.com/ for the cross-platform bit.
Last I heard there were 18 or 22 languages being ported or in beta for
.net
--
Simon
si...@quintuslink.com
Topmind
> news:MPG.161a90552...@news.earthlink.net...
> >
> > > There are lots of reasons reusable components aren't reused. Among them
> is
> > > too many programmers keep rewriting stuff that doesn't need to be
> rewritten.
> >
> >
> > AKA Job security. There is no incentive and a re-use cop would be
> > expensive and hard to validate.
>
> That's too easy a charge and probably not true. If job security were really
> the motivator one would expect to see more successful projects (we fail
> about 70% of the time)
I don't see 70% of all programmers getting fired.
Oddly enuf, it takes about 2 years for large projects to come to
fruit, and that is about the average employee turn-around.
Besides, this is an issue with *first* projects, and not
necessarily related to reuse.
I suppose you could argue that if reuse was acheived, then
projects would be more successful because they would be
using successful components.
However, most would probably agree that
it is the integration and coordination which is the tough
part, and not just the existence of building blocks.
> and better quality (whatever you mean by that) code.
>
> It must be something else.
>
> >
> > -T-
> >
>
> Chuck
>
>
>
-T-
Charles Marcus Durrett
"Daniel T." <notda...@gte.net> wrote in message
news:notdanielt3-6945...@paloalto-snr2.gtei.net...
But many can be trusted to actually assemble the car once it is designed.
And how often do we change the design of our letters?
BTW, the assembly line as a software development metaphor isn't viable
(though I have tended to favor it in the misty past) IMO.
>
> ...
>
> > This analogy between an alphabet and software components has a (perhaps)
> > coencident numerical resonance in Von Neumann's "Theory of
Self-Reproducing
> > Automata". The English alphabet has 26 letters which we use to record
all
> > that we wish to record and to say all that we wish to say. Von
Nuemann's
> > automata has 29 "letters" in its "alphabet" of different kinds of
cellular
> > automata to achieve self-reproduction.
>
> Isaac Asimov once said, "[Shakespeare] and I know the same words. It's
> just a matter of putting them together right. Why can't I do it as well
> as he does?" Many other writers over the years (including Keats) have
> had the same (or similar) lament.
Exactly! The (my?) point is that he could write the words if he had the
same ability. (And Isaac was not a shabby writer himself). In other words,
as a literate person, it was only the want of talent that kept him from
doing what Shakespeare could do. If he wasn't literate then the talent
would have perished unrealized.
Another way of saying it is that literacy enabled him to do what Shakespeare
had done though he may not have had the talent to do it. He had the
opportunity though he couldn't exploit it. Also what Shakespeare had done,
without Asimov's own literacy, would have been inaccessible to him (literacy
in this case encompassing the understanding of the spoken words on a stage).
So literacy in this sense would be an equal opportunity kind of thing
whether or not the opportunity was exploited.
> ...
>
> Before anyone misunderstands, I'm not saying that the analogy between
> the English alphabet and programming constructs is flawed, on the
> contrary I feel it is highly accurate. My wife writes a word, I write a
> statement. She sometimes starts with an outline, I sometimes start with
> a design document. She sometimes starts with a few simple sentences,
> which she expands upon iterativly until she has a short story, then
> later a novel, I sometimes do the same with a program. She develops
> characters in ways that may never show up in the story but help to
> define them, I do the same with classes of objects.
And while you and I would never write a novel (excuse the presumption) we
have the same opportunity to write one that your wife does. Perhaps if we
took the time and effort to absorb more of the discipline and patterns of
novel writing we might even be able to produce one but it is not likely that
I ever would take that time and effort.
The activity of "programming", if reduced to a level of difficulty and
complexity equivalent to basic written literacy, would give the opportunity
to novelists to then make "programs". To achieve wide spread componacy
(letter-liter-literacy, component-componacy) the hieroglyphics of today
would need to be replaced with some sort of alphabet.
As I've mentioned, I don't know what this would look like. But I suspect
these components could be assembled into "objects" and the objects then
assembled into other objects and "sub-systems".
(Speculating further I suggest that as componacy relates to literacy so the
web relates to paper.)
>
> Mr. Durrett,
>
> My "windy point" is that there is a fine line between art and craft, and
> the job done by a competent programer does more to blur that line rather
> than bring it into focus. And art will never be componentized.
Again, exactly! I would see the craft accessible to all with the art
expressible by any with the inclination and talent to do so.
I would point out though that most words written today fall under the
heading of craft (business plans, status reports, news, letters, screeds,
etc.) and not art. Just like I feel that at some future time componacy
will reveal that what we produce today when we program is mostly all craft.
The art would be left to the artists - hopefully not starving ones :-) .
The alphabet arose some 4700 years ago in the Sinia and the printing of that
alphabet only a bit under 500 years ago. Now we have the paper and
printing press - the web - before we have the alphabet. If componacy
happens it whould spread very quickly.
(Partially in response to another poster on this thread, I am more than
willing to let the "market speak" on this.)
Chuck
rossb
Hi,
Sorry, but I cannot answer your questions. Over the last 20 years of
my software development career, I have never been in a situation where
there was any useful, pre-existing code. The only time there was
pre-existing code, it was written in assembler for a completely
different machine and environment!
Every project I have been on has been a project that was pulled
together to develop something completely new. They had to do
everything from scratch.
Once the project is completed, the development staff leave. They
generally do not have any rights to anything that was developed for
the project, so they cannot even build a personal library of reuseable
components.
I have been lucky in that nearly all the projects were Unix based, and
hence, stuff I learned many years ago still applies. I feel sorry for
developers in the MS world, where your knowledge is only useful for a
few years at most.
There is also a point to be made for developing a lot of what might
appear to be reuseable stuff for each project. The aim is to make
components which are a good fit for the particular application domain.
For example, a general purpose Date object [eg the Java Date and
Calendar classes] is actually quite complex to use. If the
organisation has a standard for dates, then a simple class, tuned to
that standard will be worthwhile.
Similarly, wrapping the system provided UI classes in simpler ones can
have a dramatic benefit in development effort, and lead to a
consistent look and feel for the organisation's applications.
Just thought I would point out that your assumption about existing
code bases is not akways valid.
Brenton
S Perryman
> I think we also have an array of well made tools. They range from very
> general to extremely specific. They are called class libraries. The
> computer and text editor equate more to the work-bench and clamps used
> by blacksmiths or silversmiths. Just a thought.
Class libs are more like resistors and capacitors to EE bods.
You need the s/w equivalents of things like RF filters, switching ASICs etc
in order
to get more 'macro' scale s/w components.
Fortunately some of us are able to do this for the subject domains and
industry
sectors in which we work, so much of Robert Martins' rhetoric is just swept
away.
Regards,
Steven Perryman
Pieter Nagel
> I think we also have an array of well made tools. They range from very
> general to extremely specific. They are called class libraries. The
> computer and text editor equate more to the work-bench and clamps used
> by blacksmiths or silversmiths. Just a thought.
I disagree. The project, at source code level, should already be a
living entity with lots of repetitive processes automated. We try and
generate boilerplate code and verify conventions automatically as
much as possible. Whenever we delete a method, and in the process
create dead code which that method used to call, our system tells us.
We made it do so.
There's a whole world of things that can, and should be done at a
totally different level than the mere source text in the file.
Tools and editors that are merely work-benches and clamps will not
let you get there.
--
,_
/_) /| /
/ i e t e r / |/ a g e l
Thomas Gagne
written/ported even if .NET delivered on everything?
That's the problem! Whenever a piece of new technology comes out too many
companies with too many programmers run out and starting moving their software
'cause some consultant or vendor tells them they can't use what's sitting
inside their existing systems.
Some of that may be true enough if their business logic is tightly coupled
with presentation logic and can not be easily isolated or wrapped with a
network-accessible API. The problem in many of these cases is the cure is
worse than the illness. Rather than fixing the first problem they simply
recreate the problem using new technology that deserts older technology for
which small investments can return huge returns.
But of course, that brings us back to experienced vs. inexperienced
programmers, art or science, craft or discipline, etc.
--
.tom
Thomas Gagne
> <snip>
> That's too easy a charge and probably not true. If job security were really
> the motivator one would expect to see more successful projects (we fail
> about 70% of the time) and better quality (whatever you mean by that) code.
>
> It must be something else.
Ignorance.
They just don't know better, and neither does management. How many CIOs do you
suppose there are that really know what it takes to maintain software? How
many are in denial about how much software they're really
developing/maintaining? How many of their lieutenants do you think know?
--
.tom
John A. Byerly
news:VP7s7.16162$Aa.1...@typhoon.mw.mediaone.net...
It is. I think most programmers re-write as opposed to re-use because they
don't understand what was written and how to use it. This in turn is due to
poor documentation of the component. There is a better chance of reuse if
the code is available to examine, but that chance is only marginally better.
For any degree of complication, the code is difficult enough to understand
that the programmer resorts to rewriting it in order to show progress.
JAB
--
--------------------------------------------------------
John A. Byerly
Engineered Software Solutions, Ltd.
H. S. Lahman
> There are lots of reasons reusable components aren't reused. Among them is
> too many programmers keep rewriting stuff that doesn't need to be rewritten.
While there are many reasons why components aren't reused, I think the
principle ones are that they weren't properly defined and they weren't
properly encapsulated in the first place. To get proper component level
reuse there are several necessary conditions:
(1) They must have a cohesive subject matter.
(2) The subject matter must be readily identifiable in the problem space
independently of particular applications (i.e., an invariant definition
of semantics).
(3) Their implementation must be at a consistent level of abstraction.
(4) Their requirements must be defined through client/service
relationships.
(5) They must be encapsulated within a highly disciplined, pure message
interface (preferably event-based).
(6) A communications model must be available for dealing with syntactic
mismatches between interface expectations of client and service in
different reuse contexts.
The first four are essential to long-term stability in the partitioning
of an application. The fifth, in conjunction with the first four,
provides long-term maintainability for an application by providing
'firewall' interfaces. All six are necessary for large-scale reuse.
The sixth is interesting because it acknowledges the facts that (a) the
component must have a single semantics that is agreed across reuse
contexts, (b) there can be many ways to syntactically access a
particular semantics, and (c) though client/service relationships are
one-way requirements flows, they represent two-way communications flows
(i.e., interfaces are two-way).
> <snip detailed legacy problems>
>
> Components don't have to be third-party. There are plenty of them where most
> people work already. The problem is people keep writing new code in the
> language de'jour. How much code that already existed in other languages do
> you think was rewritten (or reimplemented) in Java in the last 4-5 years?
> Since it was a new language, what ratio of experienced programmers (with the
> problem domain, not the language) to inexperienced ones do you think were
> writing the new Java stuff? What do you suppose that cost companies?
I agree, it is a serious cost. It is also amplified when extended
beyond languages to the technology de jour. All the world loves a
straight man and these questions provide an opportunity that I can't
possibly pass up.
One way around this problem is to separate the concerns of the problem
space and the computing space. If one solves the customer problem
abstractly in an implementation-independent manner, then one can
implement that abstract solution in any language or computing
environment without changing it.
One way to do this is to employ abstract OOA solution models that are
also rigorous (i.e., complete and unambiguous) specifications for the
implementation. One can then focus on the technical issues of changes
in the computing space by creating and application-independent
translation engine that optimizes for a particular computing
environment.
Then the OOA model can then be translated into any computing environment
by selecting the appropriate translation engine. Not only can different
languages be accommodated, but different technologies (DCOM vs. CORBA),
different operating systems, different persistence mechanisms, different
optimization strategies, different... All quite transparently without
any changes to the OOA model that solves the customer's problem.
And one has a solution description that is an order of magnitude more
compact than an OOD model and several orders of magnitude more compact
than code, which makes it far easier to maintain when problem
requirements change. Since the translation engine can translate any OOA
model for a given computing environment, one also gets complete reuse of
the implementation environment across applications and requirements
changes. One can also upgrade the translation engine for computing
environment changes independently of the applications.
All in all, a very agile solution. B-) [The devil makes me do these
things.]
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindersol.com
Pathfinder Solutions -- We Make UML Work
http://www.pathfindersol.com
(888)-OOA-PATH
Topmind
One of the problems with re-use is granularity. It is almost impossible
to make something that can be used *as-is*. It likely needs tweeking, and
before you tweek it you have to inderstand it. It is just often easier
to just write something new rather than learn the old one, tweek it,
test the tweek, etc.
Plus, the old thing might carry baggage of features that are not
used in the new one.
My best re-use comes from smaller units instead of Grand
Generic Thingies.
> JAB
>
> --
> --------------------------------------------------------
> John A. Byerly
> Engineered Software Solutions, Ltd.
>
>
-T-
Marc Gluch
>Class libs are more like resistors and capacitors to EE bods.
>You need the s/w equivalents of things like RF filters, switching ASICs etc
>in order
>to get more 'macro' scale s/w components.
>
>Fortunately some of us are able to do this for the subject domains and
>industry
>sectors in which we work, so much of Robert Martins' rhetoric is just swept
>away.
I don't see a contradiction.
Yes, new, larger components are developed as time progresses
(even domain-specific languages).
Yes, the dominant trend in the industry toward has been toward
treating developers as generic, replaceable components
in a methodology-driven software development process.
Mc Breen, agile methodologies in general, and (to some extent) XP
in particular are trying to reverse the latter trend.
I believe that is a *good* and *important* thing.
On one hand, no matter how wonderful the components,
human ignorance can easily lead to their misuse.
On the other hand, we will not run of new problem domains
requiring human skills (aka craftsmanship) anytime soon.
Marc Gluch
Mindtap Inc.
Robert C. Martin
Curling anyone?
Robert C. Martin | "Uncle Bob" | Software Consultants
Object Mentor Inc. | rma...@objectmentor.com | We'll help you get
PO Box 5757 | Tel: (800) 338-6716 | your projects done.
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python|
"One of the great commandments of science is:
'Mistrust arguments from authority.'" -- Carl Sagan
Eric Renouf
> There are lots of reasons reusable components aren't reused. Among them is
> too many programmers keep rewriting stuff that doesn't need to be rewritten.
Sadly one of the reasons that I do not do more reuse myself is that my
company seems to be fairly set against using anything that we didn't
write ourselves. We're still a small enough company that the CTO is on
a first name basis with everyone in development, and so he still makes a
lot of the hands on decisions, for better or worse. He seems to be very
mistrusting of anything that we didn't write, even if the complete
source code is available. This has caused me no end of frustration as
you may well imagine.
I am still a very inexperienced I realize (I only graduated about a year
ago), but this has been one of the more disappointing things that I have
encountered, and I hope that this is not the norm throughout the
industry. I also find it extremely ironic that at the same time that
they discourage this type of reuse they complain about the quality of
the system. While reuse would certainly not be a panacea for the
problems, I for one think it is at least likely to help.
The reason that I don't reuse some of the things that we have written is
because of a lot of unwanted side effects of the functions or modules
available. The poor handling/reporting of error conditions in others
discourages me from using those. There are also, I'm sure, several
modules out there that I don't even know exist, so naturally can't use
those. Everytime I get a moment to go poking around and looking for new
"goodies" I find something, but I am so discouraged by all the other
things above that I don't often get excited about them anymore.
Perhaps the worst case with third party solutions not being reused is
that the CTO will see them, think that they're good ideas and come up
with his own scheme for us to implement it, while seemingly adding a lot
of extra complexity. So not only do we not get the benefits of being
able to reuse code that other people have already spent a lot of time
writing, optimizing and testing, now we have to divert already scarce
development resources to writing it, as I said with added complexity for
no real reason that I have ever seen. It is a reacurring pattern at
this company though!
Perhaps it's time to think about moving on I guess, and hopefully things
will not be the same wherever I end up next.
Eric
Robert O'Dowd
>
> Thomas Gagne wrote:
>
> > There are lots of reasons reusable components aren't reused. Among them is
> > too many programmers keep rewriting stuff that doesn't need to be rewritten.
>
> Sadly one of the reasons that I do not do more reuse myself is that my
> company seems to be fairly set against using anything that we didn't
> write ourselves. We're still a small enough company that the CTO is on
> a first name basis with everyone in development, and so he still makes a
> lot of the hands on decisions, for better or worse. He seems to be very
> mistrusting of anything that we didn't write, even if the complete
> source code is available. This has caused me no end of frustration as
> you may well imagine.
Welcome to the real world. The NIH (not invented here) syndrome is
incredibly common. And it is one of the main factors preventing
effective reuse. It happens at all levels in many organisations.
The problem is, it is fairly easy to justify rolling your own solution
even if a solution exists.
>
> I am still a very inexperienced I realize (I only graduated about a year
> ago), but this has been one of the more disappointing things that I have
> encountered, and I hope that this is not the norm throughout the
> industry. I also find it extremely ironic that at the same time that
> they discourage this type of reuse they complain about the quality of
> the system. While reuse would certainly not be a panacea for the
> problems, I for one think it is at least likely to help.
This is just the NIH in another guise. A common reason for not
reusing something is a belief that your team *must* be able to
do it better, because they understand your problem domain.
Catch is, once they get caught in the details of crafting a
solution, they realise it's harder than they thought. But then
there's been an investment of effort: people are unwilling to let
go of that system their team has crafted so lovingly.
>
> The reason that I don't reuse some of the things that we have written is
> because of a lot of unwanted side effects of the functions or modules
> available. The poor handling/reporting of error conditions in others
> discourages me from using those. There are also, I'm sure, several
> modules out there that I don't even know exist, so naturally can't use
> those. Everytime I get a moment to go poking around and looking for new
> "goodies" I find something, but I am so discouraged by all the other
> things above that I don't often get excited about them anymore.
Unwanted side effects and poor error handling are classic signs that
a component has been written for a particular purpose, with little
thought of reuse beyond the current project. Hence, lots of short
cuts to "get the job done".
>
> Perhaps the worst case with third party solutions not being reused is
> that the CTO will see them, think that they're good ideas and come up
> with his own scheme for us to implement it, while seemingly adding a lot
> of extra complexity. So not only do we not get the benefits of being
> able to reuse code that other people have already spent a lot of time
> writing, optimizing and testing, now we have to divert already scarce
> development resources to writing it, as I said with added complexity for
> no real reason that I have ever seen. It is a reacurring pattern at
> this company though!
>
> Perhaps it's time to think about moving on I guess, and hopefully things
> will not be the same wherever I end up next.
>
I wouldn't bet on it. I've seen it in companies that pride themselves
on reuse. However, the number of organisations who actually do it well
is a lot smaller than the number who claim they do.
The ones who truly do reuse well, are truly outstanding. Regrettably,
they're quite rare. And the main problems are cultural, because
effective reuse takes a lot of planning, agreement among all the
players, and effort to keep things going smoothly. And all it takes
is one person, at any level to put a spoke in that wheel.
Peter van Rooijen
news:3BB2AD41...@nonexistant.com...
> Eric Renouf wrote:
> >
> > Thomas Gagne wrote:
> >
> > > There are lots of reasons reusable components aren't reused. Among
them is
> > > too many programmers keep rewriting stuff that doesn't need to be
rewritten.
> >
> > Sadly one of the reasons that I do not do more reuse myself is that my
> > company seems to be fairly set against using anything that we didn't
> > write ourselves. We're still a small enough company that the CTO is on
> > a first name basis with everyone in development, and so he still makes a
> > lot of the hands on decisions, for better or worse. He seems to be very
> > mistrusting of anything that we didn't write, even if the complete
> > source code is available. This has caused me no end of frustration as
> > you may well imagine.
>
> Welcome to the real world. The NIH (not invented here) syndrome is
> incredibly common. And it is one of the main factors preventing
> effective reuse.
Robert,
People who you might say suffer from the syndrome, may tell you something
else. The stuff they have access to for reusing, sucks. I am sorry that that
is the case, but it is true.
Consider these points:
1 Most software that is being shared was never built for being reused (you
already said that).
2 Effective reuse must be systematic and requires a reuse architecture,
which simply is not available (I have one, but I am unwilling to share it
with the world at this point in time, as I imagine is the case with others
who have one as well).
3 Even if the reuse architectures were available, they would be
incompatible, and reusable components are tied to the reuse architecture
they were designed to work in.
4 If NIH was really a syndrome, and it was harmful, the people and
organizations that suffer from it would have been selected out. They have
not. So perhaps blaming non-reuse on NIH is not that accurate an analysis
after all.
5 The reusable components that my organization creates may very well suck in
the eyes of others. The coding style and design standards we use may not
appeal at all to others. There is simply too much variation in what is
considered good style and design in the industry.
6 We would want to get paid for the quality reusable stuff we have made.
There is no good economic model for supporting a marketplace for components,
that I am aware of.
7 Most software is of mediocre quality if just evaluated in the context of
the specific purpose that it was developed for. Since the standards for
reusability are much higher, it is no suprise that they are, by and large,
completely inadequate for that.
> It happens at all levels in many organisations.
> The problem is, it is fairly easy to justify rolling your own solution
> even if a solution exists.
Maybe some of the points I made above help explain why that seems to be the
case.
Finally, I have no doubt that all this will change over time, as our
industry matures. Look to wait for a few generations of developers to come
and go before reuse and reusability is the norm, though.
Regards,
Peter van Rooijen
John A. Byerly
news:9ousk7$e1e$1...@news1.xs4all.nl...
A few comments:
> Consider these points:
>
> 1 Most software that is being shared was never built for being reused (you
> already said that).
Unfortunately, some of the new methodologies being pushed are encouraging
this type of behavior. Developing classes to satisfy a single feature
without considering the ramifications on the entire system leads to
well-written classes that get the job done for that specific feature only.
> 2 Effective reuse must be systematic and requires a reuse architecture,
> which simply is not available (I have one, but I am unwilling to share it
> with the world at this point in time, as I imagine is the case with others
> who have one as well).
I am not sure I agree with this. While it has difficiencies, I have resued
the CString class (for example) in MFC a bunch. Developers of such a class
can anticipate certain requirements and develop the class accordingly. My
main complaint with many of the MFC classes is that they didn't seem to
anticipate thier extension.
I believe that, to some extent, reuse is possible for a framework of classes
as well, given that the design is solid.
> 3 Even if the reuse architectures were available, they would be
> incompatible, and reusable components are tied to the reuse architecture
> they were designed to work in.
I think that this is a design flaw, in many cases.
> 4 If NIH was really a syndrome, and it was harmful, the people and
> organizations that suffer from it would have been selected out. They have
> not. So perhaps blaming non-reuse on NIH is not that accurate an analysis
> after all.
I am not sure I agree with this either. I believe that it depends on the
industry. I happen to be working in two different domains that are behind
the curve when it comes to the application of software technology. Since
the whole industry appears to be slow in coming up to speed, mistakes like
NIH philosophy may be damaging, but not fatal.
> 5 The reusable components that my organization creates may very well suck
in
> the eyes of others. The coding style and design standards we use may not
> appeal at all to others. There is simply too much variation in what is
> considered good style and design in the industry.
If the components were truly reusable, only the interfaces and good
documentation would be required. The coding style and standard then are
mostly irrelevant.
> 6 We would want to get paid for the quality reusable stuff we have made.
> There is no good economic model for supporting a marketplace for
components,
> that I am aware of.
This has been my experience as well. I suppose that companies could create
a repository for reusable components that would be "bought" by the projects
that use them. That way, the cost of development of the component could be
recovered, at least partially.
> 7 Most software is of mediocre quality if just evaluated in the context of
> the specific purpose that it was developed for. Since the standards for
> reusability are much higher, it is no suprise that they are, by and large,
> completely inadequate for that.
This is a problem with the component, and varies from component to
component. Natural selection should take over and the mediocre components
will become extinct.
Thomas Gagne
company reuse is something that could be practiced internally. Also, the
definition of what can be reused may require a little imagination, and
possibly even a little coding to get it right, but much less than had the
component not been refitted.
Has anyone ever seen the show Junkyard Wars? I've seen several commercials
for it but have only seen the show once. Cracked me up. It does remind me of
software development though, especially in established companies.
Imagine you're a programmer at one of these shops (junkyards) surrounded by
old MVS, CICS, Oracle, DB2, TopSecret, Sybase, DG, AOS/VS, SunOS, Lotus Notes,
Novell Netware, NT 3.51, 4.x, W2K, PowerBuilder, VB, and a combination
TCP/NetBIOS/TokenRing/and-that-funny-SDLC-IBM-SYNC-thing-that-requires-voodoo-to-work
network (feel free to add your own junk). Obviously, all these thing are
being used for valuable business purposes, but your team has just been given
the task of developing some kind of web thing.
What did (I suspect) 90% of companies do? The brought in a new everything
(language, app server, paradigm, training, consultants, hardware, service
contracts, contractors, experienced? programmers, project management tools,
RationalRose, you name it) and constructed a rampart of technology with only
tenuous bridges to the old world.
Now the next project can add to its list of junk all the "new" stuff. Except
now instead of servlets they'll add beans and other J2EE stuff. Instead of
using CICS they'll use JTS. Instead of being online with DB2 they'll export
it to SQL/Server.
Sometimes these decisions are made because the stewards of the old junk place
too many obstacles to their ward's use outside its original charter.
So as always, companies are their own worst enemies, and their CIOs/CTOs
shoulder the responsibility.
--
.tom
Peter van Rooijen
news:tr683f7...@corp.supernews.com...
> "Peter van Rooijen" <pe...@vanrooijen.com> wrote in message
> news:9ousk7$e1e$1...@news1.xs4all.nl...
>
> A few comments:
>
> > Consider these points:
> >
> > 1 Most software that is being shared was never built for being reused
(you
> > already said that).
>
> Unfortunately, some of the new methodologies being pushed are encouraging
> this type of behavior. Developing classes to satisfy a single feature
> without considering the ramifications on the entire system leads to
> well-written classes that get the job done for that specific feature only.
Hi John,
That is not unfortunate in all (or even most) cases. If we believe (as I do)
that systematic reuse is too difficult in most settings, trying to achieve
it is foolish. An approach like XP, which is geared toward succesful
execution of continuous product creation projects, does well to emphasize
software creation based exclusively on identified current needs.
> > 2 Effective reuse must be systematic and requires a reuse architecture,
> > which simply is not available (I have one, but I am unwilling to share
it
> > with the world at this point in time, as I imagine is the case with
others
> > who have one as well).
>
> I am not sure I agree with this. While it has difficiencies, I have
resued
> the CString class (for example) in MFC a bunch. Developers of such a
class
> can anticipate certain requirements and develop the class accordingly. My
> main complaint with many of the MFC classes is that they didn't seem to
> anticipate thier extension.
Hah, a simple class! And you couldn't even reuse *that* in the way you
wanted, because the environment did not allow you to extend the class (i.e.,
the reuse architecture that it fit in was inadequate)!
> I believe that, to some extent, reuse is possible for a framework of
classes
> as well, given that the design is solid.
Your assertion is surrounded with so many conditions, that it has become
meaningless.
> > 3 Even if the reuse architectures were available, they would be
> > incompatible, and reusable components are tied to the reuse architecture
> > they were designed to work in.
>
> I think that this is a design flaw, in many cases.
Wow, explain how that would be the case, please. What exactly is the design
flaw, and in which cases?
> > 4 If NIH was really a syndrome, and it was harmful, the people and
> > organizations that suffer from it would have been selected out. They
have
> > not. So perhaps blaming non-reuse on NIH is not that accurate an
analysis
> > after all.
>
> I am not sure I agree with this either. I believe that it depends on the
> industry. I happen to be working in two different domains that are behind
> the curve when it comes to the application of software technology. Since
> the whole industry appears to be slow in coming up to speed, mistakes like
> NIH philosophy may be damaging, but not fatal.
That's all very nice to say, but how does it help? My analysis is useful
because if you accept it, even tentatively, it directs you to look for other
reasons than NIH why reuse hasn't taken off, and if they exist, you are in a
much better position to identify them. What do your remarks teach the
reader?
> > 5 The reusable components that my organization creates may very well
suck
> in
> > the eyes of others. The coding style and design standards we use may not
> > appeal at all to others. There is simply too much variation in what is
> > considered good style and design in the industry.
>
> If the components were truly reusable, only the interfaces and good
> documentation would be required.
What do you mean by that, and why do you believe that it is the case?
> The coding style and standard then are
> mostly irrelevant.
Would they still be irrelevant, even if only the interfaces were important,
if coding style and standards found expression in the interfaces (which they
do)?
> > 6 We would want to get paid for the quality reusable stuff we have made.
> > There is no good economic model for supporting a marketplace for
> components,
> > that I am aware of.
>
> This has been my experience as well. I suppose that companies could
create
> a repository for reusable components that would be "bought" by the
projects
> that use them. That way, the cost of development of the component could
be
> recovered, at least partially.
Yes they could do that, but it still wouldn't work.
What *would* work is when a company keeps a reusability architecture and
component creation project (that also organizes reuse workshops and writes
reuse manuals) running over many years, and charges all other projects 30%
of their software development budget as a tax to fund the reuse project,
whether or not those projects reuse any components. Fat chance of that
happening in a lot of shops, but it would work.
> > 7 Most software is of mediocre quality if just evaluated in the context
of
> > the specific purpose that it was developed for. Since the standards for
> > reusability are much higher, it is no suprise that they are, by and
large,
> > completely inadequate for that.
>
> This is a problem with the component, and varies from component to
> component. Natural selection should take over and the mediocre components
> will become extinct.
How does that help if there aren't any survivors? Your reasoning (as evident
from your post) is somewhat simplistic. Please rethink.
Regards,
Peter van Rooijen
John A. Byerly
> "John A. Byerly" <jbyerly@ess-quality_remove.com> wrote in message
> news:tr683f7...@corp.supernews.com...
> > "Peter van Rooijen" <pe...@vanrooijen.com> wrote in message
> > news:9ousk7$e1e$1...@news1.xs4all.nl...
> >
> > A few comments:
> >
> > > Consider these points:
> > >
> > > 1 Most software that is being shared was never built for being reused
> (you
> > > already said that).
> >
> > Unfortunately, some of the new methodologies being pushed are
encouraging
> > this type of behavior. Developing classes to satisfy a single feature
> > without considering the ramifications on the entire system leads to
> > well-written classes that get the job done for that specific feature
only.
>
> Hi John,
>
> That is not unfortunate in all (or even most) cases. If we believe (as I
do)
> that systematic reuse is too difficult in most settings, trying to achieve
> it is foolish. An approach like XP, which is geared toward succesful
> execution of continuous product creation projects, does well to emphasize
> software creation based exclusively on identified current needs.
That is a very "head in the sand" approach. For little or no extra effort,
a reusable component could have been developed, but since the developers
don't know about other requirements (even the ones on their own project),
they simply produce something that meets today's requirements. Not very
forward looking. (What am I saying? It is not forward looking at all!)
> > > 2 Effective reuse must be systematic and requires a reuse
architecture,
> > > which simply is not available (I have one, but I am unwilling to share
> it
> > > with the world at this point in time, as I imagine is the case with
> others
> > > who have one as well).
> >
> > I am not sure I agree with this. While it has difficiencies, I have
> resued
> > the CString class (for example) in MFC a bunch. Developers of such a
> class
> > can anticipate certain requirements and develop the class accordingly.
My
> > main complaint with many of the MFC classes is that they didn't seem to
> > anticipate thier extension.
>
> Hah, a simple class! And you couldn't even reuse *that* in the way you
> wanted, because the environment did not allow you to extend the class
(i.e.,
> the reuse architecture that it fit in was inadequate)!
And such is my opinion of the developers of MFC. But that does not change
the fact that it is quite reusable, even in its current state. I have been
successful in extending it as well, it was just a bit more difficult than it
should have been.
> > I believe that, to some extent, reuse is possible for a framework of
> classes
> > as well, given that the design is solid.
>
> Your assertion is surrounded with so many conditions, that it has become
> meaningless.
I don't understand how you can say that. I was trying to point out the
importance of the design and its relationship to the development of reusable
components.
I haven't seen a lot of easily reuseable frameworks. But that doesn't mean
that they don't exist, or even that they are impossible to create. My
assertion is that it is possible to create reusable frameworks. However, to
do so requires a good amount of design work.
> > > 3 Even if the reuse architectures were available, they would be
> > > incompatible, and reusable components are tied to the reuse
architecture
> > > they were designed to work in.
> >
> > I think that this is a design flaw, in many cases.
>
> Wow, explain how that would be the case, please. What exactly is the
design
> flaw, and in which cases?
Please read the post by H. S. Lahman in this thread. He gives a good
explaination of what is necessary for a component to be reusable (in rank
order, IMO). The design flaw, then, is the failure to meet these
requirements.
> > > 4 If NIH was really a syndrome, and it was harmful, the people and
> > > organizations that suffer from it would have been selected out. They
> have
> > > not. So perhaps blaming non-reuse on NIH is not that accurate an
> analysis
> > > after all.
> >
> > I am not sure I agree with this either. I believe that it depends on
the
> > industry. I happen to be working in two different domains that are
behind
> > the curve when it comes to the application of software technology.
Since
> > the whole industry appears to be slow in coming up to speed, mistakes
like
> > NIH philosophy may be damaging, but not fatal.
>
> That's all very nice to say, but how does it help? My analysis is useful
> because if you accept it, even tentatively, it directs you to look for
other
> reasons than NIH why reuse hasn't taken off, and if they exist, you are in
a
> much better position to identify them. What do your remarks teach the
> reader?
They teach the reader that, just because the syndrome has not been fatal (as
you imply NIH is if it is a syndrome), doesn't mean that it isn't a
syndrome. You state that if NIH was a syndrome and harmful, natural
selection would kill it. I am saying that NIH is a syndrome, and it is
harmful, but natural selection is not killing it for other reasons.
Does that help?
> > > 5 The reusable components that my organization creates may very well
> suck
> > in
> > > the eyes of others. The coding style and design standards we use may
not
> > > appeal at all to others. There is simply too much variation in what is
> > > considered good style and design in the industry.
> >
> > If the components were truly reusable, only the interfaces and good
> > documentation would be required.
>
> What do you mean by that, and why do you believe that it is the case?
I mean that good, reusable code should not require the developer to delve
into it to discover what it does. Hence, only the interfaces and
documentation (and the libraries, of course) are necessary. The more I have
to delve into code to figure out what it does, the less likely I am to reuse
it. While I am coming up to speed on it, I discover problems with it, and
figure that I could rewrite it faster and better.
Incidentally, this is why I am so opposed to throwing away documentation in
favor of keeping up to date.
> > The coding style and standard then are
> > mostly irrelevant.
>
> Would they still be irrelevant, even if only the interfaces were
important,
> if coding style and standards found expression in the interfaces (which
they
> do)?
That is why I said "mostly".
> > > 6 We would want to get paid for the quality reusable stuff we have
made.
> > > There is no good economic model for supporting a marketplace for
> > components,
> > > that I am aware of.
> >
> > This has been my experience as well. I suppose that companies could
> create
> > a repository for reusable components that would be "bought" by the
> projects
> > that use them. That way, the cost of development of the component could
> be
> > recovered, at least partially.
>
> Yes they could do that, but it still wouldn't work.
>
> What *would* work is when a company keeps a reusability architecture and
> component creation project (that also organizes reuse workshops and writes
> reuse manuals) running over many years, and charges all other projects 30%
> of their software development budget as a tax to fund the reuse project,
> whether or not those projects reuse any components. Fat chance of that
> happening in a lot of shops, but it would work.
The problem with your suggestion is that the project is totally overhead
cost. Most companies like to minimize their overhead.
The advantage with what I suggest is that the development cost of the
components would be borne by the project for which they were developed. If
the components are not reused, fine. If they are, the "purchase" by the
other projects can offset the cost of the other project. If the project is
defunct ... well, I didn't say that it was a perfect solution :-)
> > > 7 Most software is of mediocre quality if just evaluated in the
context
> of
> > > the specific purpose that it was developed for. Since the standards
for
> > > reusability are much higher, it is no suprise that they are, by and
> large,
> > > completely inadequate for that.
> >
> > This is a problem with the component, and varies from component to
> > component. Natural selection should take over and the mediocre
components
> > will become extinct.
>
> How does that help if there aren't any survivors? Your reasoning (as
evident
> from your post) is somewhat simplistic. Please rethink.
There will be survivors as long as there are other engineers like myself
that believe that this can be done and are willing to make it happen. As I
said, just because I haven't seen something doesn't mean that it is
impossible. Heck, it doesn't even mean that it is difficult.
Keith Ray
<pe...@vanrooijen.com> wrote:
> "John A. Byerly" <jbyerly@ess-quality_remove.com> wrote in message
> news:tr683f7...@corp.supernews.com...
> > "Peter van Rooijen" <pe...@vanrooijen.com> wrote in message
> > news:9ousk7$e1e$1...@news1.xs4all.nl...
> >
> > A few comments:
> >
> > > Consider these points:
> > >
> > > 1 Most software that is being shared was never built for being reused
> (you
> > > already said that).
> >
> > Unfortunately, some of the new methodologies being pushed are
> > encouraging
> > this type of behavior. Developing classes to satisfy a single feature
> > without considering the ramifications on the entire system leads to
> > well-written classes that get the job done for that specific feature
> > only.
>
> Hi John,
>
> That is not unfortunate in all (or even most) cases. If we believe (as I
> do)
> that systematic reuse is too difficult in most settings, trying to
> achieve
> it is foolish. An approach like XP, which is geared toward succesful
> execution of continuous product creation projects, does well to emphasize
> software creation based exclusively on identified current needs.
I think XP's Simplicity Rules, Test-First Design, and Merciless
Refactoring lead to re-usable code in a way that is better than trying
to design ahead for it.
My team has written GUI code for Mac and Windows and refactored it into
set of cross-platform GUI classes... but just those classes that we
need. So we have cross-platform list views, buttons, pop-up menus,
edit-text-fields etc., but don't have a cross-platform toolbar because
we don't need that.
We have classes that are used in multiple projects. Since each class and
each project has unit tests, we can find out if modifying a shared class
breaks anything very quickly.
To enable using Mock Objects in Unit Testing, many of our concrete
classes take Interfaces or Abstract Classes as parameters instead of
referring directly to other concrete classes, and we avoid using global
variables or singletons. This allows re-using a chosen concrete class
without having to drag in other concrete classes.
http://c2.com/cgi/wiki?XpSimplicityRules
http://c2.com/cgi/wiki?MockObject
http://c2.com/cgi/wiki?RefactorMercilessly
Peter van Rooijen
> > > This is a problem with the component, and varies from component to
> > > component. Natural selection should take over and the mediocre
> components
> > > will become extinct.
> >
> > How does that help if there aren't any survivors? Your reasoning (as
> evident
> > from your post) is somewhat simplistic. Please rethink.
>
> There will be survivors as long as there are other engineers like myself
> that believe that this can be done and are willing to make it happen. As
I
> said, just because I haven't seen something doesn't mean that it is
> impossible. Heck, it doesn't even mean that it is difficult.
John, that is absolutely right. It may not be difficult. It *is* a lot of
work. You could start to do what you can to create 'survivors' by publishing
a reusable component, then see if it survives. That will be much more
meaningful than saying things about what others need to do to create
reusable software, or how dumb they are that they aren't doing that.
Best regards,
Peter van Rooijen
John A. Byerly
> [snip]
> > > > This is a problem with the component, and varies from component to
> > > > component. Natural selection should take over and the mediocre
> > components
> > > > will become extinct.
> > >
> > > How does that help if there aren't any survivors? Your reasoning (as
> > evident
> > > from your post) is somewhat simplistic. Please rethink.
> >
> > There will be survivors as long as there are other engineers like myself
> > that believe that this can be done and are willing to make it happen.
As
> I
> > said, just because I haven't seen something doesn't mean that it is
> > impossible. Heck, it doesn't even mean that it is difficult.
>
> John, that is absolutely right. It may not be difficult. It *is* a lot of
> work. You could start to do what you can to create 'survivors' by
publishing
> a reusable component, then see if it survives.
Count on it.
> That will be much more
> meaningful than saying things about what others need to do to create
> reusable software,
Not necessarily. The XP folks continue to tell me how successful XP is.
However, I remain unconvinced because I do not agree with several points.
If I can resolve these points, I will be convinced, in spite of the failure
or success of the people preaching it. IOW, I do not believe that an idea
should be trashed just because no one has been sucessful at implementing it.
If the idea is good, the problem may be with the implementation.
Conversely, just because some people have been successful with an idea does
not mean it is a good one.
> or how dumb they are that they aren't doing that.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Would you please point out to me where I even *implied* this?
None of this discussion has to do with the intelligence of the developer.
If you wish to stoop to this level, please take your discussion elsewhere.
I am here to discuss issues and to learn. I (apparently incorrectly)
assumed that you were here for that reason as well.
:-(
Peter van Rooijen
Thanks for the quick reply.
> > I
> > > said, just because I haven't seen something doesn't mean that it is
> > > impossible. Heck, it doesn't even mean that it is difficult.
> >
> > John, that is absolutely right. It may not be difficult. It *is* a lot
of
> > work. You could start to do what you can to create 'survivors' by
> publishing
> > a reusable component, then see if it survives.
>
> Count on it.
Good! Let us know when you publish the first one.
> > That will be much more
> > meaningful than saying things about what others need to do to create
> > reusable software,
>
> Not necessarily.
That is incorrect. Publishing reusable components _is_necessarily_ much more
meaningful than telling what others need to do to make them available,
without you ever having done that yourself.
> The XP folks continue to tell me how successful XP is.
> However, I remain unconvinced because I do not agree with several points.
> If I can resolve these points, I will be convinced, in spite of the
failure
> or success of the people preaching it.
Do you need to be 'convinced' as you say, to try it out and benefit from
actual experience?
> IOW, I do not believe that an idea
> should be trashed just because no one has been sucessful at implementing
it.
Trashing or not trashing is not the issue. Practicing or not practicing is.
> If the idea is good, the problem may be with the implementation.
Do you believe there is a problem? If so, where?
> Conversely, just because some people have been successful with an idea
does
> not mean it is a good one.
Why are you kicking in open doors (as we say in Dutch)?
> > or how dumb they are that they aren't doing
that.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Would you please point out to me where I even *implied* this?
Do you believe it? If yes, there is no reason to point it out to you. If no,
it doesn't apply to you.
> None of this discussion has to do with the intelligence of the developer.
> If you wish to stoop to this level,
To which level is that?
> please take your discussion elsewhere.
Boy, am I glad you are not the Internet police :-).
> I am here to discuss issues and to learn.
Wonderful! I would encourage that.
> I (apparently incorrectly)
> assumed that you were here for that reason as well.
I would not encourage you to assume things about me, or anyone else for that
matter. It's not very useful in general. Better to ask if you want to know
about someone's motivations.
> :-(
What are you unhappy about?
> JAB
Regards,
Peter van Rooijen
Tom Sanders
learning from the masters, failure of component technology etc.
I haven't read McBreen's book but, by the sound of things, I would
broadly agree with it. Personally, it has taken me years to, er, master
programming (my colleagues may disagree!). Use of OO (or not),
application of patterns, handling concurrency, selecting
technologies... I also like Rapid Development by Steve McConnell
Anyway, all this experience has gone into the philosophy and
production of Inq (http://www.inqwell.com/tech/toc.htm) over
the years. Readers may disagree, but we think it is a radical
solution to the problems pervading the development of
what many typical systems have to do.
--
Tom Sanders
Inqwell Ltd
http://www.inqwell.com
Robert C. Martin <rma...@objectmentor.com> wrote in message
news:3baf55a3...@news.supernews.com...
> McBreen hits the nail on the head! This book is a MUST READ for all
> CxOs, VPs, Directors, Mangers, and Software Engineers. It will change
> the way you think about the software development industry and
> profession.
>
snip
Daniel T.
>We are very close to agreement I think. See in line comments.
I guess we are. In this case, the tools are alread there, the "alphabet"
already exists. It doesn't take much for a person to learn and use BASIC
for example.
Mike Mohr
> Hi,
> Sorry, but I cannot answer your questions. Over the last 20 years of
> my software development career, I have never been in a situation where
> there was any useful, pre-existing code. The only time there was
> pre-existing code, it was written in assembler for a completely
> different machine and environment!
>
Aw, come on! Over the 28 years of my development career, I managed to accumulate tons of
paper and disks containing components I knew I would need somewhere else. We all do it. It's
just that less than 15% of what we hoard is re-useable.
>
> Every project I have been on has been a project that was pulled
> together to develop something completely new. They had to do
> everything from scratch.
>
> Once the project is completed, the development staff leave. They
> generally do not have any rights to anything that was developed for
> the project, so they cannot even build a personal library of reuseable
> components.
If you can demonstrate that the information you have in your possession is not in violation of
the security directives, or the non-disclosure agreement, the library routines you developed
are yours. This is a fine point of copyright law that has been argued in a number of courts
throughout the world. A company DOES NOT have total rights to your intellectuality. If that
were the case, they would have to maintain you on staff throughout your lifetime (fat chance
of that happening).
>
>
> I have been lucky in that nearly all the projects were Unix based, and
> hence, stuff I learned many years ago still applies. I feel sorry for
> developers in the MS world, where your knowledge is only useful for a
> few years at most.
>
I agree with you regarding UNIX, but I think you are optomistic regarding MS. From what I've
seen lately, the average lifetime of a MS product is 3-4 months.
>
[The rest was snipped for brevity.]
================================================================
Mike Mohr, Systems Administrator === Email: Mike...@aut.ac.nz
Information Technology Group === Phone: 64 9 917-9999 x8133
Auckland University of Technology === Fax: 64 9 917-9901
PO Box 92006, Auckland, New Zealand =
http://home.aut.ac.nz/staff/mmohr/
================================================================
Chaos reigns within. Repent, reflect, reboot. Order shall return.
Software Scavenger
> One of the problems with re-use is granularity. It is almost impossible
> to make something that can be used *as-is*. It likely needs tweeking, and
Impossible is very much the wrong word. Granularity is not really a
problem, but more a clue to what is needed. There is a lot of high
quality reusable software being reused extensively. People who want
to make and/or use reusable software should pay attention to it.
Grep, printf, emacs, and internet explorer, are all extensively reused
software. Each is used in different situations, but what they all
have in common is that they're good examples of how to make software
reusable.
First, invest a lot into making it good. Then publish it widely. If
it fills a need, it will be reused.
Software development is an art, like writing novels is an art. Most
novels are not bestsellers, because most authors are not masters of
their art. Grep, printf, emacs, and internet explorer, are
bestsellers. Large numbers of other resuable software components are
also best sellers. But most components, like most novels, are not
bestsellers, and in fact most of them are a waste of time.
That's really all there is to it. That's the real answer to the
puzzle so many people seem to be puzzling over. There is no magic to
making reusable components. Just make them good, make them relevant,
and publish them widely. It only seems impossible because it's a lot
of work and takes a lot of skill and talent. It's no more impossible
than writing a bestselling novel. It's done constantly by those with
the skill and motivation to do it.
Charles Marcus Durrett
(And I look for an expansion of the population that could write bestsellers
by advocating what I call "componacy" (an analog to literacy).)
Chuck
"Software Scavenger" <cubic...@mailandnews.com> wrote in message
news:a6789134.01100...@posting.google.com...
Richard MacDonald
reusability (and why it is so hard) is at
http://www.research.microsoft.com/users/cszypers/cop-links.htm
Its a fantastic resource.
P.S. OO is *not* the answer, its just a tool.
Panu Viljamaa
> ... This analogy between an alphabet and software components has a (perhaps)
> coencident numerical resonance in Von Neumann's "Theory of Self-Reproducing
> Automata". The English alphabet has 26 letters which we use to record all
> that we wish to record and to say all that we wish to say. Von Nuemann's
> automata has 29 "letters" in its "alphabet" of different kinds of cellular
> automata to achieve self-reproduction.
How about the Chinese alphabet with 40,000 characters ? It takes a good
teacher and a lot of study to allow you to draw them properly. To learn the
way the meaning varies according to the context. Not everyone can learn to read
them, much less to write.
I believe if things go right, after 2010 there might 40,000 generally reusable
software components available. But even then being able to pick the right ones
for each job, and to combine them appropriately, will take a lot of study.
It's a bit like chess. There's so many combinations and only few of them win
each particular game.
-Panu Viljamaa
Charles Marcus Durrett
character rankings go something like:
Heiroglyphic, thousands of characters.
Syllabaric, hundreds of characters.
Alphabetic, tens of characters.
(The word "alphabet" comes from the names of the first two characters in one
alphabet - alpha and beta.)
I'm holding out hope for a componancy 'alphabet'.
Chuck
"Panu Viljamaa" <pa...@fcc.net> wrote in message
news:3BBBEF87...@fcc.net...
Daniel T.
> Formally Chinese is not alphabetic it is hieroglyphic. The rough type/#
> character rankings go something like:
>
> Heiroglyphic, thousands of characters.
> Syllabaric, hundreds of characters.
> Alphabetic, tens of characters.
>
> (The word "alphabet" comes from the names of the first two characters in one
> alphabet - alpha and beta.)
>
> I'm holding out hope for a componancy 'alphabet'.
We already have them. They consist of relitvly few "componants" that can
be combined in many ways, most of which are nonsence but some of which
will produce desired results, and a very few of which will be considered
"art". They are called a programming languages. Anybody with desire can
download Python (for example) learn it, and start creating programs for
himself or others.
Dave Aronson at a t t dot net or big foot dot com
"Daniel T." wrote:
>
> "Charles Marcus Durrett" <cdur...@hotmail.com> wrote:
>
...
> > I'm holding out hope for a componancy 'alphabet'.
>
> We already have them. They consist of relitvly few "componants" that can
> be combined in many ways, most of which are nonsence but some of which
> will produce desired results, and a very few of which will be considered
> "art". They are called a programming languages.
There is an even better example, especially of that "most of which
[combinations] are nonsense".
They are called bits. There are two of them. B-)
--
Dave Aronson, Sysop of free public Fidonet BBS Air 'n Sun, +1-703-319-0714.
All the opinions above are MINE ALL MINE, but for rent at reasonable rates.
See my web site, at http://listen.to/davearonson (last updated 2001-06-27).
MurrayS
One of the major points Clemens Szyperski makes in that book:
Implementation inheritence = bad
Interface inheritence = good
(this of course when we are talking about inheritence across component
boundaries - in the OO world of course implementation inheritence is a
neccessary evil)
Unfortunately Clemens' own employer has ignored his advice - .NET
allows for implementaion inheritence. This is going to create a lot of
ugliness and put up even more barriers to reuse - presumably the
opposite of what Microsoft were trying achieve.
Murray
Richard MacDonald
news:3bbe8b29...@nsw.nnrp.telstra.net...
> On Wed, 03 Oct 2001 21:06:36 GMT, "Richard MacDonald"
> <macdo...@att.net> wrote:
>
> >The best book I know on component
> >reusability (and why it is so hard) is at
> >http://www.research.microsoft.com/users/cszypers/cop-links.htm
> >Its a fantastic resource.
> >P.S. OO is *not* the answer, its just a tool.
>
> One of the major points Clemens Szyperski makes in that book:
>
> Implementation inheritence = bad
> Interface inheritence = good
>
I kneejerked:
That is an oversimplification. Interface inheritance as in Java
is nice for the compiler and a pain for those of us who hate
to type. Implementation inheritance is very useful.
I know what you're saying, but if implementation inheritance
was bad we wouldn't have one of the most powerful tools
in our OO toolkit and we might as well be using VB.
> (this of course when we are talking about inheritence across component
> boundaries - in the OO world of course implementation inheritence is a
> neccessary evil)
And then I re-read that you were talking about
ACROSS COMPONENT BOUNDARIES.
Ok :-)
I just thought I would put that in caps in case anyone
else makes the same mistake I did.
> Unfortunately Clemens' own employer has ignored his advice - .NET
> allows for implementaion inheritence. This is going to create a lot of
> ugliness and put up even more barriers to reuse - presumably the
> opposite of what Microsoft were trying achieve.
Does dot.net have some kind of component "chunkability"
as part of its syntax? I'm interested. I think Java's
package is a disaster because I cannot extend it, i.e., define
another package that adds a method to a class from the
former package.
S Perryman
> On Wed, 03 Oct 2001 21:06:36 GMT, "Richard MacDonald"
> <macdo...@att.net> wrote:
>
> >The best book I know on component
> >reusability (and why it is so hard) is at
> >http://www.research.microsoft.com/users/cszypers/cop-links.htm
> >Its a fantastic resource.
> >P.S. OO is *not* the answer, its just a tool.
>
> One of the major points Clemens Szyperski makes in that book:
>
> Implementation inheritence = bad
> Interface inheritence = good
>
> (this of course when we are talking about inheritence across component
> boundaries - in the OO world of course implementation inheritence is a
> neccessary evil) .
The above is an oxymoron.
Interface conformance shields you from impl considerations by default.
Regards,
Steven Perryman
Krishna Cheemalamarri
I totally agree with you and McBreen.
>To McBreen, software is a craft that takes years to learn, and more years
>to master. The only way to properly learn the craft is to be taught at
the side
>of a master.
This is absolutely true.
>The idea was that a programmer is a programmer is a programmer. The more
you have, the
>faster you get done.
I think this is the main reason for the dot.com failure. Bunch of kids
with no realworld
experience trying to put together some thing using quick and dirty
methods.
>McBreen counters this concept by showing that large software systems are
>better built by small teams comprised of masters, journeymen, and
>apprentices, than by large teams of plug replaceable programming units.
Yeah.. this has been my experience for years...
"Robert C. Martin" wrote:
> McBreen hits the nail on the head! This book is a MUST READ for all
> CxOs, VPs, Directors, Mangers, and Software Engineers. It will change
> the way you think about the software development industry and
> profession.
>
> In Software Craftsmanship, McBreen exposes the weaknesses of our
> current system of software engineering, and proposes an alternative
> model based the older apprentice/journeyman/master model. McBreen
> makes the point that building a software project is not akin to
> product manufacturing. We don't have factories that stamp out
> software. Rather we have groups of people trying to massage software
> into place. McBreen likens successful software development to
> blacksmiths, or silversmiths. To McBreen, software is a craft that
> takes years to learn, and more years to master. The only way to
> properly learn the craft is to be taught at the side of a master.
>
> McBreen's thesis emphasises something that is missing from software
> development today: attention to quality, and attention to expertise.
> The dotcom frenzy saw thousands of startup firms throwing young
> untrained bodies at complex software projects. The idea was that a
> programmer is a programmer is a programmer. The more you have, the
> faster you get done. McBreen counters this concept by showing that
> large software systems are better built by small teams comprised of
> masters, journeymen, and apprentices, than by large teams of plug
> replaceable programming units.
Michael Feathers
"MurrayS" <m...@NOSPAMbucks.net> wrote in message
news:3bbe8b29...@nsw.nnrp.telstra.net...
>
> Implementation inheritence = bad
> Interface inheritence = good
> Unfortunately Clemens' own employer has ignored his advice - .NET
> allows for implementaion inheritence. This is going to create a lot of
> ugliness and put up even more barriers to reuse - presumably the
> opposite of what Microsoft were trying achieve.
I think that Clemen's book is interesting, but it provides more questions
than answers. I tend to think that black box reuse can be useful, but in a
sense it is a false goal. Too often, a black box is a "lock-in" when
requirements change. Behavior specification of interfaces separate from the
code the implements them is an open research question as well.
Microsoft held back on the use of implementation inheritance for a long
time. IIRC, COM was designed as an interface-centric specification because
of early bad experiences with implementation inheritance... fragile base
class problem, etc.
The fact remains that implementation inheritance is a useful way of evolving
code bases in response to requirements changes, and it does not demand
absolutely correct foresight about what the extension points will be in a
design. When you really think about it, the requirement for that kind of
foresight is absolutely brittle criteria.
I think that software reuse is really be best served by distributing source
with unit tests for each class. The code and tests act as a complete
specification, and they do not limit the economic value of reuse in the way
that black boxes do.
Michael Feathers
www.objectmentor.com
Universe
wrote:
>Robert,
>
>I totally agree with you and McBreen.
>
>>To McBreen, software is a craft that takes years to learn, and more years
>
>>to master. The only way to properly learn the craft is to be taught at
>the side
>>of a master.
>This is absolutely true.
Balderdash, it is backward old man tripe, which ignores the advances
of modern production techniques.
>
>>The idea was that a programmer is a programmer is a programmer. The more
>you have, the
>>faster you get done.
>I think this is the main reason for the dot.com failure. Bunch of kids
>with no realworld
>experience trying to put together some thing using quick and dirty
>methods.
What do you think about the garbage practice of RMartin who places the
interface of a server hierarchy with a single, or even every client?
You don't think that's a disgrace?
>"Robert C. Martin" wrote:
>
>> McBreen hits the nail on the head! This book is a MUST READ for all
>> CxOs, VPs, Directors, Mangers, and Software Engineers. It will change
>> the way you think about the software development industry and
>> profession.
>>
>> In Software Craftsmanship, McBreen exposes the weaknesses of our
>> current system of software engineering, and proposes an alternative
>> model based the older apprentice/journeyman/master model.
RMartin is a Ronald Reagan lover and it shows in his garbage code
practices and system theory as well as in his neanderthal lauding of
the feudal master/journeyman/apprentice guild system.
We need to be about "IC" software, gobs of reuse, modern engineering
techniques and an industrial /academic approach to training software
engineers.
But hey, now more can see why I call RMartin, Meijring, Jeffries,
Logan, MacDonald, Philp, Featherstone, and others:
"Craftites".
Elliott
--
http://www.radix.net/~universe ~*~ Enjoy! ~*~
Hail OO Modelling! * Hail the Wireless Web!
@Elliott 2001 my comments ~ alt.*/comp.*/bitnet may quote
Universe
wrote:
RMartin wrote:
>>The idea was that a programmer is a programmer is a programmer. The more
>you have, the
>>faster you get done.
>I think this is the main reason for the dot.com failure. Bunch of kids
>with no realworld
>experience trying to put together some thing using quick and dirty
>methods.
Think again. The main reason for the dot com bust was the main reason
for booms and busts for 500 years - capitalism.
It's part of a capitalist boom/bust cycle. Capital went into dot
coms, and they overproduced for what the economy could consume.
Although in reality society needs more output from dot coms, the
parameters of the capitalist economics is such that there can
overproduction for the limited production it can handle due to its
profit driven nature. This is one more example of why capitalism has
outlived it's usefulness. The only way to move forward is to place
people above profits.
Ron Jeffries
<univ...@NOdirectvSPAMinternet.com> wrote:
>But hey, now more can see why I call RMartin, Meijring, Jeffries,
>Logan, MacDonald, Philp, Featherstone, and others:
>"Craftites".
Could you consider raising the discussion level a bit and actually
talking about software development instead of ad hominem remarks?
Thanks,
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
Richard MacDonald
news:153923FA1E813AEF.F072C995...@lp.airnews.net...
> On Sat, 06 Oct 2001 13:59:07 -0400, Universe
> <univ...@NOdirectvSPAMinternet.com> wrote:
>
> >But hey, now more can see why I call RMartin, Meijring, Jeffries,
> >Logan, MacDonald, Philp, Featherstone, and others:
> >"Craftites".
>
> Could you consider raising the discussion level a bit and actually
> talking about software development instead of ad hominem remarks?
Actually, I get a kick out of being included in such stellar company.
I thought I was being complimented :-)
Daniel T.
>>To McBreen, software is a craft that takes years to learn, and more
>>years to master. The only way to properly learn the craft is to be
>>taught at the side of a master.
>
> This is absolutely true.
I don't agree. The above is certanly what consultants like Mr. McBreen
and Mr. Martin would *like* to be true, but it's not even logicly
consistant. If it really was true, then no one has *ever* properly
learned the craft and so there are no "masters" to learn from.
With the invention of mass comunication devices (including this forum)
we have progressed way beyond the old journyman/master system. One is
quite capable of becomming a master without ever bonding himself to
someone and because of the free exchange of debate, one is *more* likely
to become a master than someone who bonded himself to a single
individual. Unfortunatly, we haven't figured out how a layman can guage
a practitioner's ability to determine if his claims at being a master
are true.
As to the dot-com failures, I believe that had less to do with
programming ability and more to do with the "lemming effect".
Robert C. Martin
<univ...@NOdirectvSPAMinternet.com> wrote:
>Krishna Cheemalamarri <krishnacR...@netzero.netREMOVETHIS>
>wrote:
>
>RMartin wrote:
>>>The idea was that a programmer is a programmer is a programmer. The more
>>you have, the
>>>faster you get done.
>
>>I think this is the main reason for the dot.com failure. Bunch of kids
>>with no realworld
>>experience trying to put together some thing using quick and dirty
>>methods.
>
>Think again. The main reason for the dot com bust was the main reason
>for booms and busts for 500 years - capitalism.
The main reason for the dot com bust was greed and stupidity. A whole
group of people convinced themselves that the value of a company was
related to how much it spent as opposed to how much it made.
Yes, there is a capitalist element to this. There is also a stupidity
element to this.
John Roth
> On Sat, 06 Oct 2001 14:31:30 -0400, Universe
> <univ...@NOdirectvSPAMinternet.com> wrote:
>
> >Krishna Cheemalamarri <krishnacR...@netzero.netREMOVETHIS>
> >wrote:
> >
> >RMartin wrote:
> >>>The idea was that a programmer is a programmer is a programmer. The
more
> >>you have, the
> >>>faster you get done.
> >
> >>I think this is the main reason for the dot.com failure. Bunch of kids
> >>with no realworld
> >>experience trying to put together some thing using quick and dirty
> >>methods.
> >
> >Think again. The main reason for the dot com bust was the main reason
> >for booms and busts for 500 years - capitalism.
>
> The main reason for the dot com bust was greed and stupidity. A whole
> group of people convinced themselves that the value of a company was
> related to how much it spent as opposed to how much it made.
>
> Yes, there is a capitalist element to this. There is also a stupidity
> element to this.
Isn't that what capitalism is all about - greed and stupidity? Any
enterprise
has five responsibilities: to its employees, to its customers, to its
vendors,
to the society around it, and to the people who furnish the resources to
get it started. We don't require people to be forever indebted to their
parents, why should we require enterprises to be forever endebted to
the people who provided startup capital to the exclusion of their other
responsibilities?
As has been said, greed and stupidity.
John Roth
Robert C. Martin
wrote:
>Krishna Cheemalamarri <krishnacR...@netzero.netREMOVETHIS> wrote:
>
>>>To McBreen, software is a craft that takes years to learn, and more
>>>years to master. The only way to properly learn the craft is to be
>>>taught at the side of a master.
>>
>> This is absolutely true.
>
>I don't agree. The above is certanly what consultants like Mr. McBreen
>and Mr. Martin would *like* to be true, but it's not even logicly
>consistant. If it really was true, then no one has *ever* properly
>learned the craft and so there are no "masters" to learn from.
I overstated my case. I, for one, was never trained at the side of a
master. I had to learn the trade for myself. So, clearly, I should
not have used the word 'only' in my description. So let me rephrase:
A very effective way to learn the craft is to be taught at the side of
a master.
Robert C. Martin | "Uncle Bob" | Software Consultants
Steve Merrick
news:3bbe8b29...@nsw.nnrp.telstra.net...
> Unfortunately Clemens' own employer has ignored his
> advice - .NET allows for implementation inheritence.
Why is it that people arguing against the introduction or use of some
feature will deliberately confuse "allows the use of" with "forces the
use of"? To me, it says that the proponent has no real argument to shore
up his/her position, but perhaps I'm too cynical. :-)
C++ allows the use of goto, and yet (IME) it is generally reserved for
those few occasions when it is the optimal solution to a problem. I see
no problem with *allowing* for the use of implementation inheritance.
--
Steve Merrick
"Who cares, wins"
Russell Wallace
>Krishna Cheemalamarri <krishnacR...@netzero.netREMOVETHIS>
>wrote:
>
>>I think this is the main reason for the dot.com failure. Bunch of kids
>>with no realworld
>>experience trying to put together some thing using quick and dirty
>>methods.
I don't think so. The technology did for the most part live up to its
promises; the reason for the dot-com failure was people were so
entranced by the technology, it didn't occur to them to ask "how are
we actually going to make money out of this?".
>Think again. The main reason for the dot com bust was the main reason
>for booms and busts for 500 years - capitalism.
>
>It's part of a capitalist boom/bust cycle. Capital went into dot
>coms, and they overproduced for what the economy could consume.
>Although in reality society needs more output from dot coms, the
>parameters of the capitalist economics is such that there can
>overproduction for the limited production it can handle due to its
>profit driven nature. This is one more example of why capitalism has
>outlived it's usefulness. The only way to move forward is to place
>people above profits.
If that's what you want, go and live in North Korea where they
practice what you preach. You'll find you were right - that country is
indeed blissfully free of dot-com boom-and-busts.
--
"How many roads must a man walk down?"
mailto:rwal...@esatclear.ie
http://www.esatclear.ie/~rwallace
Universe
North Korea is *state capitalist*, like the Brezhnev Soviet Union, and
like them they falsely mouth they are for the people. That's what
extreme pragmatism saying it's "Anarchist" like the Agility folk do is
like. (How can avowed "Reaganauts" like RMartin be true real
"anarchists" like they claim to be? In actuality they are "selfish"
because they want to do what old man prima donnas want to do, not
what's best for software engineering at large.)
Elliott
---
*For Cultless, Internationalist, non-Mechanist Dialectics Revolution*
Russell Wallace
<univ...@NOdirectvSPAMinternet.com> wrote:
>North Korea is *state capitalist*
Then you're just redefining "capitalist" to mean "bad". Fine, I agree
bad is bad - duh! I also realize you're a nutcase and further attempts
at discussion are completely pointless. Bye.
Pete McBreen
>Krishna Cheemalamarri <krishnacR...@netzero.netREMOVETHIS> wrote:
>
>>>To McBreen, software is a craft that takes years to learn, and more
>>>years to master. The only way to properly learn the craft is to be
>>>taught at the side of a master.
>>
>> This is absolutely true.
>
>I don't agree. The above is certanly what consultants like Mr. McBreen
>and Mr. Martin would *like* to be true, but it's not even logicly
>consistant. If it really was true, then no one has *ever* properly
>learned the craft and so there are no "masters" to learn from.
>
>With the invention of mass comunication devices (including this forum)
>we have progressed way beyond the old journyman/master system. One is
>quite capable of becomming a master without ever bonding himself to
>someone and because of the free exchange of debate, one is *more*
likely
>to become a master than someone who bonded himself to a single
>individual.
I continue to be amazed at the various cultural assumptions that exist
around the idea of Craftsmanship.
To answer the first paragraph first, my contention is that learning from
a master craftsman is probably the most effective way of picking up the
skills and knowledge necessary for software development. Obviously there
are many other ways of learning software development, but daily
interaction with a supportive, skilled practitioner works really well.
(See "Situated Learning" by Lave and Wegner ISBN: 0521423740 and /or
"Communities of Practice" for detail information on how this works in
other fields).
As for whether consultants would like this to be true, it depends on
whether they can see the real implications of the Software Craftsmanship
idea. The way I see it, Software Craftsmanship does not support the
typical guru lead consultancies, since a master can really only handle
one new apprentice a year. Assuming an apprenticeship takes 4 or 5 years
and a few journeymen stay around after completing their apprenticeship,
a Master will have 6 to 10 co-workers. This doesn't come close to the
size of typical consultancy operations, where even a small regional
consultancy has 100+ "consultants". Yes, several master craftsmen could
band together for marketing purposes, but the key idea is that customers
hire a specific master craftsman to develop an application. It is not a
case of putting blind faith in an organization, the customer hires the
master craftsman to do the work and expects the master to devote
themselves full time to the job. In contrast the typical guru lead
consultancies might roll out the guru for the negotiations and the kick
off meeting, but then the bulk of the work is done by new hires who were
recruited after the contract was awarded.
Some consultants like the idea of Software Craftsmanship, buit only to
the extent that they still actually enjoy working on real projects. :-)
As for the second paragraph, maybe the word "bonding" is getting in the
way. I'm sure you know of someone in our field of software development
whom you admire and would willingly seek out an opportunity to work
together with them on a series of projects for a few years. Now imagine
that you had known about them at the start of your career and had signed
up as an employee for four years to work with them on projects and had
them coach and mentor you through those projects. My guess is that this
kind of "apprenticeship" would be a fantastic start to anyone's career
in software development.
None of this devalues mass communication or libraries, but personally I
meet few people who have taken the time to really study the fantastic
material that is available in libraries (Bentley's "Programming Pearls"
or the recent Hunt and Thomas book "The Pragmatic Programmer").
Self-directed study works for some people, but for many they will only
really pick up a book and study it is someone they respect recommends it
and relates what is in the book to what they need to learn right now.
That for me is the value of having a long term mentor/coach (using the
word "master" crafstman in this context seems to be too loaded).
>Unfortunatly, we haven't figured out how a layman can guage
>a practitioner's ability to determine if his claims at being a master
>are true.
I answered this in detail in my book. The issue is not whether the
layman can judge the claims, it is whether other master craftsmen can
recommend a craftsman for your particular project. Master craftsmen
develop reputations, both with customers and with other master
craftsmen. Jump starting this reputation based evaluation may be hard,
but we are not starting from a blank sheet. Most customers know at least
one or two good developers who they trust. Most developers know other
good developers in their area who they would trust fill in for them and
would do a good job for one of their customers. See pages 141-146 for
the detailed answer:-)
Cheers, Pete
----
Pete McBreen, McBreen.Consulting , Cochrane, AB
email: petem...@acm.org http://www.mcbreen.ab.ca/
Author, "Software Craftsmanship The New Imperative"
Addison-Wesley (C) 2002
http://www.amazon.com/exec/obidos/ASIN/0201733862
Robert C. Martin
<univ...@NOdirectvSPAMinternet.com> wrote:
>How can avowed "Reaganauts" like RMartin be true real
>"anarchists" like they claim to be?
I have never said anything at all about my political leanings. I
don't think this is an appropriate forum for political advocacy.
>In actuality they are "selfish"
>because they want to do what old man prima donnas want to do, not
>what's best for software engineering at large.)
Whereas you are unselfish, altruistic, and know what is best for
software engineering.
Steve Merrick
> On Mon, 08 Oct 2001 14:04:59 -0400, Universe
> <univ...@NOdirectvSPAMinternet.com> wrote:
>
> [the usual]
Be strong, Uncle Bob, and ignore him. ;-)
--
Steve Merrick - (too) often unable to keep quiet in the face of
provocation! ;-)
John Roth
"Pete McBreen" <petem...@acm.org> wrote in message
news:weuw7.42073$_q1.2...@news1.calgary.shaw.ca...
> Daniel T. wrote in message ...
> >Krishna Cheemalamarri <krishnacR...@netzero.netREMOVETHIS> wrote:
> >
> >>>To McBreen, software is a craft that takes years to learn, and more
> >>>years to master. The only way to properly learn the craft is to be
> >>>taught at the side of a master.
> >>
> >> This is absolutely true.
> >
> >I don't agree. The above is certanly what consultants like Mr. McBreen
> >and Mr. Martin would *like* to be true, but it's not even logicly
> >consistant. If it really was true, then no one has *ever* properly
> >learned the craft and so there are no "masters" to learn from.
> >
> >With the invention of mass comunication devices (including this forum)
> >we have progressed way beyond the old journyman/master system. One is
> >quite capable of becomming a master without ever bonding himself to
> >someone and because of the free exchange of debate, one is *more*
> likely
> >to become a master than someone who bonded himself to a single
> >individual.
>
This misses two different points. One is that different people have
different
learning strategies. I personally learn very well from printed material and
less well from watching what other people do. The idea of learning from a
"master craftsman" is directed toward people who are the exact opposite -
they learn best from a practitioner, in the daily interaction of working on
a
joint project.
The average person uses a mix of both strategies. The master/student
relationship is best used at the beginning, when the student is still
confused about the structure of the domain. After that, the practitioner
is best off using a mix of both strategies: study and discussion on one
hand,
and joint projects with people who have skills they admire, or can regularly
achieve outcomes they desire.
The other is the notion that printed material will ever completely cover
what
a competent practitioner knows. It just doesn't happen, as anyone who
practices the craft of unpacking an 'expert's knowledge for expert systems
can tell you.
A third issue is the phrase 'bonded to a single individual'. Its a very good
way
of learning what the other individual knows. However, eventually, the
student
must break the bond and go on, otherwise, there is no further professional
growth.
John Roth
Daniel T.
>Daniel T. wrote in message ...
>>Krishna Cheemalamarri <krishnacR...@netzero.netREMOVETHIS> wrote:
>>
>>>>To McBreen, software is a craft that takes years to learn, and more
>>>>years to master. The only way to properly learn the craft is to be
>>>>taught at the side of a master.
>>>
>>> This is absolutely true.
>>
>>I don't agree. The above is certanly what consultants like Mr. McBreen
>>and Mr. Martin would *like* to be true, but it's not even logicly
>>consistant. If it really was true, then no one has *ever* properly
>>learned the craft and so there are no "masters" to learn from.
>>
>>With the invention of mass comunication devices (including this forum)
>>we have progressed way beyond the old journyman/master system. One is
>>quite capable of becomming a master without ever bonding himself to
>>someone and because of the free exchange of debate, one is *more*
>likely
>>to become a master than someone who bonded himself to a single
>>individual.
>
>I continue to be amazed at the various cultural assumptions that exist
>around the idea of Craftsmanship.
My first mistake was equating your ideas with actual medieval practices.
:-) I also took exception to Mr. Martin's use of the word "only" which
he backed off on.
>To answer the first paragraph first, my contention is that learning from
>a master craftsman is probably the most effective way of picking up the
>skills and knowledge necessary for software development. Obviously there
>are many other ways of learning software development, but daily
>interaction with a supportive, skilled practitioner works really well.
I'll agree with that, at least in the initial/apprentice stage. I
suspect that the initial stage is quite short however, on the order of 1
to 2 years for our industry.
>As for whether consultants would like this to be true, it depends on
>whether they can see the real implications of the Software Craftsmanship
>idea.
The comment I made about what consultants would like was out of line.
Sorry.
>As for the second paragraph, maybe the word "bonding" is getting in the
>way. I'm sure you know of someone in our field of software development
>whom you admire and would willingly seek out an opportunity to work
>together with them on a series of projects for a few years. Now imagine
>that you had known about them at the start of your career and had signed
>up as an employee for four years to work with them on projects and had
>them coach and mentor you through those projects. My guess is that this
>kind of "apprenticeship" would be a fantastic start to anyone's career
>in software development.
There is no way I could have known him/them at the start of my career, I
wasn't knowledgeable enough to accurately gage who to admire.
>None of this devalues mass communication or libraries, but personally I
>meet few people who have taken the time to really study the fantastic
>material that is available in libraries (Bentley's "Programming Pearls"
>or the recent Hunt and Thomas book "The Pragmatic Programmer").
True, there are many people in every industry who just want to learn
enough to "get by".
>Self-directed study works for some people, but for many they will only
>really pick up a book and study it is someone they respect recommends it
>and relates what is in the book to what they need to learn right now.
>That for me is the value of having a long term mentor/coach (using the
>word "master" crafstman in this context seems to be too loaded).
I feel that self-directed study works for anyone who is both
intrinsically motivated and intelligent. A master/apprentice approach
would allow those who are less of either to achieve more than they
otherwise would have. Without self-directed study, without expanding
one's knowledge base to include more than just one master's ideas, one
can never be a master himself.
Masters don't produce masters, they produce Journeymen. IMO, in this
industry progressing from Beginner to Journeyman isn't that hard. We
don't have thousands, or even hundreds, of years of knowledge to absorb
before we can build on it.
>>Unfortunatly, we haven't figured out how a layman can guage
>>a practitioner's ability to determine if his claims at being a master
>>are true.
>
>I answered this in detail in my book. The issue is not whether the
>layman can judge the claims, it is whether other master craftsmen can
>recommend a craftsman for your particular project. Master craftsmen
>develop reputations, both with customers and with other master
>craftsmen.
I am looking forward to reading your book. (I'm always happy when a
master is willing to share his knowledge and opinions with me. :-) I
can't help but wonder some things though. So often, reputation has less
to do with ability than with marketing.
Universe
>"Pete McBreen" <petem...@acm.org> wrote:
>>I continue to be amazed at the various cultural assumptions that exist
>>around the idea of Craftsmanship.
>My first mistake was equating your ideas with actual medieval practices.
>:-) I also took exception to Mr. Martin's use of the word "only" which
>he backed off on.
But that is PRECISELY what the ideas are *FEUDAL*. The
master/journeyman/apprentice setup came about during feudalism and is
a relic of that period, where it currently exists. Most intelligent
people know that off the bat.
McBreen and RMartin want us to go back to major FEUDALIST social
relations, no doubt about it. And it's harmful and inexcusable,
period.
Elliott
--
http://www.radix.net/~universe ~*~ Enjoy! ~*~
Hail OO Modelling! * Hail the Wireless Web!
@Elliott 2001 my comments ~ alt.*/comp.*/bitnet may quote
John Roth
"Universe" <univ...@NOdirectvSPAMinternet.com> wrote in message
news:gca9sto5g1bnr3j8e...@4ax.com...
> "Daniel T." <notda...@gte.net> wrote:
>
> >"Pete McBreen" <petem...@acm.org> wrote:
> >>I continue to be amazed at the various cultural assumptions that exist
> >>around the idea of Craftsmanship.
>
> >My first mistake was equating your ideas with actual medieval practices.
> >:-) I also took exception to Mr. Martin's use of the word "only" which
> >he backed off on.
>
> But that is PRECISELY what the ideas are *FEUDAL*. The
> master/journeyman/apprentice setup came about during feudalism and is
> a relic of that period, where it currently exists. Most intelligent
> people know that off the bat.
Not exactly. The guild system was a mainstay of Middle Ages European
culture (frequently called Feudal because that is the name of the political
system.) In that system, there was a fairly rigid hierarchy, where masters
had to be certified by the guild before they could take on apprentices. It
was
more of a tight control of the labor market than anything else.
In most guilds, the certification was the creation of the "masterpiece,"
which
was simply a work that demonstrated all of the various skills that were
required for the craft, and the accompanying oral examination to show that
the candidate truely knew the skills, and how to teach them. "Masterpieces"
were usually pretty awful; they were intended to demonstrate skills, not
produce
something useful.
In that culture, self-study was essentially impossible, since printing
hadn't been
invented, and literacy was corresponding low - nothing to read made it a
useless skill except for the intellectual elite.
The fact is, skills have always been passed down from master to student
in every human culture that has ever been studied. It's still one of the
most
effective ways of learning.
John Roth
>
> Elliott
> --
Thomas W. Clay
mean that they are invalid. During World War 2, some of Hitler's chemical
engineers and scientists made some wonderful discoveries working with
synthetic fuels and oils. Just because it came from the Nazis doesn't
invalidate the research (other areas of research, though...)
So, why is a practice that was used during "feudal" times bad?
Tom
"Universe" <univ...@NOdirectvSPAMinternet.com> wrote in message
news:gca9sto5g1bnr3j8e...@4ax.com...
Universe
>"Universe" <univ...@NOdirectvSPAMinternet.com> wrote in message
>> But that is PRECISELY what the ideas are *FEUDAL*. The
>> master/journeyman/apprentice setup came about during feudalism and is
>> a relic of that period, where it currently exists. Most intelligent
>> people know that off the bat.
>>
>> McBreen and RMartin want us to go back to major FEUDALIST social
>> relations, no doubt about it. And it's harmful and inexcusable,
>> period.
>Just because the ideas or practices are from a feudal time period doesn't
>mean that they are invalid. During World War 2, some of Hitler's chemical
>engineers and scientists made some wonderful discoveries working with
>synthetic fuels and oils. Just because it came from the Nazis doesn't
>invalidate the research (other areas of research, though...)
>
>So, why is a practice that was used during "feudal" times bad?
Because there are more recent and better ways of training people
today. It would seriously cut the output of sufficiently trained sw
engineers to predominantly adopt Master/Journeyman/Apprentice. That
feudal practice also seems to be inefficient and uneconomical compared
with today's academic/school/experiential means of training. The
whole thing reeks of elitistism, dilletantism, and of being plain old
medieval.
Richard MacDonald
> "Thomas W. Clay" <tc...@xmission.com> wrote:
>
> >Just because the ideas or practices are from a feudal time period doesn't
> >mean that they are invalid. During World War 2, some of Hitler's
chemical
> >engineers and scientists made some wonderful discoveries working with
> >synthetic fuels and oils. Just because it came from the Nazis doesn't
> >invalidate the research (other areas of research, though...)
> >
> >So, why is a practice that was used during "feudal" times bad?
>
> Because there are more recent and better ways of training people
> today. It would seriously cut the output of sufficiently trained sw
> engineers to predominantly adopt Master/Journeyman/Apprentice. That
> feudal practice also seems to be inefficient and uneconomical compared
> with today's academic/school/experiential means of training. The
> whole thing reeks of elitistism, dilletantism, and of being plain old
> medieval.
>
from a little apprenticeship. Do you really want to drive over
a bridge built by a graduate fresh out of school? Do you
really want to work in a chemical plant built by a new grad?
(In the latter field, a new grad is considered a potentially lethal asset
for at least 2 years. And a PhD without practical experience
is even more of a "handicap".)
So tell us, Ell, does software engineering require *experience* ?
(P.S. Not the kind that comes out of a book.)
Robert C. Martin
wrote:
>I am looking forward to reading your book. (I'm always happy when a
>master is willing to share his knowledge and opinions with me. :-) I
>can't help but wonder some things though. So often, reputation has less
>to do with ability than with marketing.
True enough. It's important to look under the covers.
Robert C. Martin
wrote:
>I feel that self-directed study works for anyone who is both
>intrinsically motivated and intelligent.
Since that is primarily the method I have used in my career, I'd have
to agree with you. On the other hand, it has taken me thirty odd
years to learn things that I can now teach to my apprentices in just a
few years. Not that the apprentices would then be masters; but they
would have learned things from me that I had to struggle long and hard
to figure out for myself; and which simply cannot be taught in school.
Robert C. Martin
<tc...@xmission.com> wrote:
>Just because the ideas or practices are from a feudal time period doesn't
>mean that they are invalid. During World War 2, some of Hitler's chemical
>engineers and scientists made some wonderful discoveries working with
>synthetic fuels and oils. Just because it came from the Nazis doesn't
>invalidate the research (other areas of research, though...)
GODWIN'S LAW!
Thread over, you lose.
Thomas Gagne
> <snip>
>
> Because there are more recent and better ways of training people
> today. It would seriously cut the output of sufficiently trained sw
> engineers to predominantly adopt Master/Journeyman/Apprentice. That
> feudal practice also seems to be inefficient and uneconomical compared
> with today's academic/school/experiential means of training. The
> whole thing reeks of elitistism, dilletantism, and of being plain old
> medieval.
So going to school is more economical than learning the trade from someone
already practicing it? Four years in college spending fewer than eight hours
a day working on the discipline as well as the tuition expense is more
economical than hands-on learning? I suspect 22-year olds with a four-year
sheepskin can't program as well as high-school graduates with four-years
experience working in the field.
--
.tom
Thomas W. Clay
law was meant to be used when someone compared someone else (or their idea)
to the Nazis.
Although, I admit I had to look up Godwin's Law (to refresh my memory).
What scares me is you seem to know about it already ;)
"Robert C. Martin" <rma...@objectmentor.com> wrote in message
news:3bc60aaa...@news.supernews.com...
Jonas Kongslund
wrote:
> I suspect 22-year olds with a
> four-year sheepskin can't program as well as high-school graduates with
> four-years experience working in the field.
I think you're right.
I'm 22 years old and partly self-taught. I spend 20 hours per week working
as software developer and another 20 hours per week studying mathematics
and computer science at Aarhus University. It's only a part time study -
officially I have 3,5 years left if I started to study full time but why
should I do that? I learn much more by working as software developer and
I'm much more experienced than the average newly educated comp.sci when it
comes to practicing software engineering. Most of my colleagues consider me
as one of them regardless of my age and job title and I'm often asked
questions about esoteric technical subjects.
Yes, my salary is not as high compared with the newly educated comp.sci's
but who cares? Knowledge and practical experience is IMHO worth more than
money and it is much more satisfactory.
Followup-To: comp.software-eng
--
Jonas Kongslund <jo...@kongslund.dk> XNS: =Jonas Kongslund
Digital Rights - raising awareness of rights in the digital world
http://www.digitalrights.dk
univ...@nospamradix.net
> on Thursday 11 October 2001 22:56, Thomas Gagne <tga...@ix.netcom.com>
> wrote:
>
>> I suspect 22-year olds with a
>> four-year sheepskin can't program as well as high-school graduates with
>> four-years experience working in the field.
>
But the university education probably concentrates, and ranges over a
number of essential theortics, and summaries of proven prior experience,
the working high schoolers don't get. Some areas of software theory and
practic would be impossible without university dissemination. Better for
those capable to combine a university computer science, or software
engineering degree with part time work, as below. And yes high schoolers
should work part time also, and if they desire, or have it they can
progress to university along with continued part time work. But no
medieval guilds please.
Elliott
--
http://www.radix.net/~universe ~*~ Enjoy! ~*~
Hail OO Modelling! * Hail the Wireless Web!
@Elliott 2001 my comments ~ alt.*/comp.*/bitnet may quote
> I think you're right.
Shinji Ikari
> In comp.object Jonas Kongslund <ga...@post.tele.dk> wrote:
> > on Thursday 11 October 2001 22:56, Thomas Gagne <tga...@ix.netcom.com>
> > wrote:
> >
> >> I suspect 22-year olds with a
> >> four-year sheepskin can't program as well as high-school graduates with
> >> four-years experience working in the field.
> >
>
> But the university education probably concentrates, and ranges over a
> number of essential theortics, and summaries of proven prior experience,
> the working high schoolers don't get.
Damn right!! For example, I have seen some really horrendous
databases created by people with only "working in the field"
experience and no knowledge of normalization, entity-relationship
diagrams, or even much SQL.
(BTW: Perl seems to be a really popular language amongst these sorts
of people).
Shinji Ikari
> On Wed, 10 Oct 2001 19:04:13 GMT, "Daniel T." <notda...@gte.net>
> wrote:
>
> >I feel that self-directed study works for anyone who is both
> >intrinsically motivated and intelligent.
>
> Since that is primarily the method I have used in my career, I'd have
> to agree with you. On the other hand, it has taken me thirty odd
> years to learn things that I can now teach to my apprentices in just a
> few years. Not that the apprentices would then be masters; but they
> would have learned things from me that I had to struggle long and hard
> to figure out for myself; and which simply cannot be taught in school.
Excellent point! Its a great experience to be able to work alongside
a highly skilled and knowledgable developer and learn from their
experience. You can then go on and struggle long and hard in new
directions, pushing the frontier.
Chris Twiner
> wrote:
>
> >I feel that self-directed study works for anyone who is both
> >intrinsically motivated and intelligent.
>
> Since that is primarily the method I have used in my career, I'd have
> to agree with you. On the other hand, it has taken me thirty odd
> years to learn things that I can now teach to my apprentices in just a
> few years. Not that the apprentices would then be masters; but they
> would have learned things from me that I had to struggle long and hard
> to figure out for myself; and which simply cannot be taught in school.
>
>
Just out of interest do you have any examples of "which simply cannot
be taught in school."?
I'm not after a slanging match, I didn't do the uni thing, couldn't
see the point in a computer sciences degree. (I did do a degree, just
not related).
I'm just curious as so what can't be taught in school.
Chris
Daniel T.
wrote:
>In comp.object Jonas Kongslund <ga...@post.tele.dk> wrote:
>> on Thursday 11 October 2001 22:56, Thomas Gagne <tga...@ix.netcom.com>
>> wrote:
>>
>>> I suspect 22-year olds with a
>>> four-year sheepskin can't program as well as high-school graduates with
>>> four-years experience working in the field.
>>
>
>But the university education probably concentrates, and ranges over a
>number of essential theortics, and summaries of proven prior experience,
>the working high schoolers don't get. Some areas of software theory and
>practic would be impossible without university dissemination. Better for
>those capable to combine a university computer science, or software
>engineering degree with part time work, as below. And yes high schoolers
>should work part time also, and if they desire, or have it they can
>progress to university along with continued part time work. But no
>medieval guilds please.
Your not taking these very newsgroups into account. A high-schooler who
has been working for 4 years and following these newsgroups (as well as
reading lots of books) will be better educated than someone who "just
gets by" in a college. The only down side for the self-taught person
will be that the grad will have a farther ranging eductaion, he will
know more cocktail party trivia than the self-taught person.
Daniel T.
>On Wed, 10 Oct 2001 19:04:13 GMT, "Daniel T." <notda...@gte.net>
>wrote:
>
>>I feel that self-directed study works for anyone who is both
>>intrinsically motivated and intelligent.
>
>Since that is primarily the method I have used in my career, I'd have
>to agree with you. On the other hand, it has taken me thirty odd
>years to learn things that I can now teach to my apprentices in just a
>few years. Not that the apprentices would then be masters; but they
>would have learned things from me that I had to struggle long and hard
>to figure out for myself; and which simply cannot be taught in school.
I read your book, I read your posts here. I hazzard to guess that you
have taught me almost as much as you have shown your apprentices. That
which you haven't covered with me, I probably picked up from other
sources. Can your apprentices say the latter? Not if they don't have at
least some self-motivated education.
I have also had a healty dose of desenting information, something your
apprentices would not be privy to unless they were self-motivated
learners. This last point is the more important. In a field where
reasonable experts can disagree, it is important that the apprentice
period be very short compaired to the journeyman period.
In my case, the apprentice period was one semester, just enough to teach
me how to use the tools to do my own experimentation.
Daniel T.
rma...@objectmentor.com (Robert C. Martin) wrote:
>On Wed, 10 Oct 2001 19:04:13 GMT, "Daniel T." <notda...@gte.net>
>wrote:
>
>>I am looking forward to reading your book. (I'm always happy when a
>>master is willing to share his knowledge and opinions with me. :-) I
>>can't help but wonder some things though. So often, reputation has less
>>to do with ability than with marketing.
>
>True enough. It's important to look under the covers.
Which is something you can't do unless you know the field in question.
Am I qualified to judge the ability of two doctors and decide which one
to treat my brain tumor?