do you agree that writing software is a craft?
black
paint with too broad a brush. . .
Consider "building cars" . .
Of course what the vehicle assembler does is a craft,
and of course what the automobile engineer does is
Engineering. And what the metalurgist does may well
be science, and so on .
Similarly for "writing software", it is just that
the software field is too young to have evolved
such specializations. But where exactly do you
draw the line between original work in applied
math and everyday mathematical drudgery. Make no
mistake, most software development is drudgery for
the brain - that's why programmers play games with
their coding. There used to be an obfuscated 'C'
annual contest. There is no C++ contest, it would
be far to easy to produce something that totally
defies understanding! I suspect the computer industry
is presently at the equivalent of where the automobile
industry was around 1905.
Jon Duringer wrote in message <37279A26...@ideafarm.com>...
>i am in my mid 40's and have been writing software since 1974. i have
>come to the conclusion that writing software should be viewed as a craft
>rather than as engineering, and i see significant differences between
>the two ways of approaching our work.
>
>i would like to know whether other people have come to this conclusion.
Jon Duringer
come to the conclusion that writing software should be viewed as a craft
rather than as engineering, and i see significant differences between
the two ways of approaching our work.
i would like to know whether other people have come to this conclusion.
i would also enjoy debating the point. if you would like to join me in
a pleasant discussion of this, please reply with your own thoughts on
software as a craft.
--
Jon Duringer, Ambassador, IdeaFarm (tm) City
mailto:ambas...@ideafarm.com
---------------------------------------------------------------------------------------------------
IdeaFarm (tm) City - a city for the software craft
http://www.ideafarm.com ... fast loading ... text only ... 11,000 pages
---------------------------------------------------------------------------------------------------
J. A. Legris
>
> i am in my mid 40's and have been writing software since 1974. i have
> come to the conclusion that writing software should be viewed as a craft
> rather than as engineering, and i see significant differences between
> the two ways of approaching our work.
>
> i would like to know whether other people have come to this conclusion.
> i would also enjoy debating the point. if you would like to join me in
> a pleasant discussion of this, please reply with your own thoughts on
> software as a craft.
>
> --
But you have already posted items stating that your software is divinely
inspired and completely unplanned. That hardly counts as craftwork. Even
Michelangelo made sketches.
--
Joseph Legris
To reply, correct the x.
leonardo...@my-dejanews.com
Jon Duringer <ambas...@ideafarm.com> wrote:
> i am in my mid 40's and have been writing software since 1974. i have
> come to the conclusion that writing software should be viewed as a craft
> rather than as engineering, and i see significant differences between
> the two ways of approaching our work.
>
> i would like to know whether other people have come to this conclusion.
> i would also enjoy debating the point. if you would like to join me in
> a pleasant discussion of this, please reply with your own thoughts on
> software as a craft.
Also I am in my mid 40's and have been writing software since 1972. Also I
was taught to think of "programming" as a craft.
Although I read english frequently, and lived in an english speaking country
for a couple of years, there are many subtle nuances which may lead me to
errors, either understandig or expressing ideas. Nevertheless I'll take the
risks.
Crafts, the way I understand the term, are the application of established
tools and techniques in the building of things. Engineering, on the other
hand, is the application of knowledge and analitical methods to the solution
of problems. Curiously, in english "engineering" seem to emerge from
"engine", while in spanish "ingenieria" immediatly brings to your mind the
word "ingenio", that is, ingenuity, wit, intelligence. Probably the origins
of "engine" have some common root with "ingenio"; in XVIII and XIX century
spanish "ingenio" was used to designate engines, as well, but in the sense of
"cosas de ingenio", that is "things from the intelligence".
The development of software may be viewed as a craft at certain level, where
one is "given" a set of established tools and techniques to write equivalent
established types of applications. But it certainly is much more than that.
Computers, now, are much more powerful and ubiquitous that they were when we
first approached them. That power and pervasiveness has opened new horizons to
the application developers, that go much farther than we ever dreamed to be
practically possible almos thirty years ago. And, of course, it has brought an
increased level of complexity.
Once you have established the best approach to solve the set of problems
associated with a new application, writing the rest of it may be a craft. But
the process that leads to the establishment of that approach is engineering,
in the sense of application of "ingenio".
Also, crafts tend to characterize by a very slow change of the tools and
techniques used to achieve their ends, while engineering has to deal with
continuous change, which seems a feature of present day software development.
Of course there are very creative and innovative craftsmen, as well as there
are lousy, repetitive engineers. But both are the exception, not the rule.
Just to sum up: crafts are -to my understanding- a sort of applied
engineering, while engineering is a mainly intellectual work leading to the
discovery of new frameworks for the crafts. I like to think of myself as a
software craftsman, but definetively, there is a creative impulse in software
writing that places it above mere craftsmanship, also there is enough
formalization -as the result of a practical need- to not qualify it as an art,
finally, it is sufficiently bound to practical matters as not to be a "pure"
science. So "engineering" is a good name to qualify it (at least by sheer
elimination).
Salud!
------------------------
Solo hay calma en la perfeccion
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Jon Duringer
"J. A. Legris" wrote:
> But you have already posted items stating that your software is divinely
> inspired and completely unplanned. That hardly counts as craftwork. Even
> Michelangelo made sketches.
<chuckle>
Jon Duringer
> Consider "building cars" . .
> Of course what the vehicle assembler does is a craft,
> and of course what the automobile engineer does is
> Engineering. And what the metalurgist does may well
> be science, and so on .
> Similarly for "writing software", it is just that
> the software field is too young to have evolved
> such specializations. ... I suspect the computer industry
> is presently at the equivalent of where the automobile
> industry was around 1905.
this seems to suggest that software work today is as much craft as
engineering as science, that it really is all three because we have not yet
specialized the work into three job descriptions held by three kinds of
people.
should people who develop software think of themselves as part scientist,
part engineer, and part craftsman / craftswoman? if you had to pick one of
the three, would you refuse, insisting that all play an approximately equal
part?
Jon Duringer
> Crafts, the way I understand the term, are the application of established
> tools and techniques in the building of things. Engineering, on the other
> hand, is the application of knowledge and analitical methods to the solution
> of problems.
this makes sense to me. does it seem true to readers who have degrees in
engineering?
> Curiously, in english "engineering" seem to emerge from
> "engine", while in spanish "ingenieria" immediatly brings to your mind the
> word "ingenio", that is, ingenuity, wit, intelligence.
thank you; that is a wonderful clarification!
> Once you have established the best approach to solve the set of problems
> associated with a new application, writing the rest of it may be a craft. But
> the process that leads to the establishment of that approach is engineering,
> in the sense of application of "ingenio".
my thinking is forever changed. this is exciting.
> Also, crafts tend to characterize by a very slow change of the tools and
> techniques used to achieve their ends, while engineering has to deal with
> continuous change, which seems a feature of present day software development.
one of my objectives with IdeaFarm (tm) City (IFC) is to create a software
environment that changes slowly enough to enable people to master it, yet is
powerful enough to allow them to compete successfully with "ingenio" (engineering)
solutions. if this can be done, software work can emerge from the current state
in which everything is an ingenious solution, to a more mature state in which most
products are crafted from established and well mastered tools and techniques.
after rereading the above, i have a problem. let's say that IFC is so powerful as
a C++ environment that software development becomes a craft. when i came up with
IFC, was i a craftsman or an engineer? by your terms, i was an engineer (see your
quote above), since the creation of IFC was "a process that leads to the
establishment of [an approach to solve a set of problems]". yet i did not
experience it as "an application of knowledge and analytical methods". i did not
use any analytical methods, and the only knowledge was knowledge that resides in
my hands, not in my head. the experience for me, which spans almost 10 years and
will probably take another 5 years to be fully realized, began with a simple
inspiration. After that inspiration got me started, i have used beauty as my
compass. it is only beauty that will have guided this 10-15 year project! if i
am guided by beauty, and not by analytical methods and knowledge, am i not a
craftsman?
perhaps my claim is this: when the work is guided by knowledge and analysis, it is
engineering. when it is guided by the pursuit of beauty, it is a craft.
John D Salt
Jon Duringer <ambas...@ideafarm.com> wrote:
>
>perhaps my claim is this: when the work is guided by knowledge and analysis,
>it is engineering. when it is guided by the pursuit of beauty, it is a craft.
So why is it that engineers have the saying "If it looks right, it is right"?
All the best,
John.
--
John D Salt Dept of IS & Computing,| Barr's Law of Recursive Futility
Brunel U, Uxbridge, Middx UB8 3PH | [BLORF]: If you are smart enough
Disclaimers: I speak only for me. | to use one of these... you can
Launcher may train without warning.| probably manage without one.
james d. hunter
>
> In article <37282AC0...@ideafarm.com>,
> Jon Duringer <ambas...@ideafarm.com> wrote:
> >
> >perhaps my claim is this: when the work is guided by knowledge and analysis,
> >it is engineering. when it is guided by the pursuit of beauty, it is a craft.
>
> So why is it that engineers have the saying "If it looks right, it is right"?
Pretty much for the same reason that scientists say that.
But, the man is right. MS Windows design is -not- engineering.
It is touchy-feely, come hither with your money, neo barbarian,
cave man wall drawing. Some days I have to decide if it's
worth the agony to put with it, or follow the precedent of
Elvis Presley, and take out a 45 and shoot the monitor.
It's a tough call.
Steve Neuendorf
When discussing salary, its a profession;
When discussing Errors and Omission liability, its a job;
When discussing theory, its science;
When discussing methods and practice, its engineering;
When discussing the work and the work of others, its a craft;
When someone suggests measuring and managing it like any of the above, its
an art.
Thanks,
Steve Neuendorf
Management Consultant :)
Jon Duringer <ambas...@ideafarm.com> wrote in message
news:37279A26...@ideafarm.com...
> i am in my mid 40's and have been writing software since 1974. i have
> come to the conclusion that writing software should be viewed as a craft
> rather than as engineering, and i see significant differences between
> the two ways of approaching our work.
>
> i would like to know whether other people have come to this conclusion.
> i would also enjoy debating the point. if you would like to join me in
> a pleasant discussion of this, please reply with your own thoughts on
> software as a craft.
John D Salt
james d. hunter <jim.h...@spam.free.jhuapl.edu.> wrote:
[Snips]
> But, the man is right. MS Windows design is -not- engineering.
True. But it isn't craftsmanship, either. I'm not entirely
happy that you use the word "design" in this context. ;-)
> It is touchy-feely, come hither with your money, neo barbarian,
> cave man wall drawing.
The cave paintings at Lascaux have the power to move the spirit
thousands of years after their creators died. Please, please,
please don't let this happen with Windows.
Jon Duringer
> Pretty much for the same reason that scientists say that.
i would also claim that science is a craft. by science i mean creating a model with
which to answer a question or to understand some phenomenon. the defining activity
of a theoretical scientist is crafting models. the defining activity of empirical
scientists is crafting laboratory experiments, as well as statistical models.
this question, of whether the essential nature of the work is a craft or is
engineering, is important because it should be reflected in how the work is
compensated and managed. in engineering, it is best to approach the work as a team,
in which people are tightly coupled to each other. no one is a prima donna; instead,
each person is loosely coupled to technology by being aware of a variety of languages
and approaches so that he/she can choose the best technology to apply to the problem
at hand.
in contrast, in craftwork, it is best to partition the problem into person-sized
pieces. each piece is given to an individual who is only loosely coupled to the
other people through the external specs for the piece. that person is very much a
prima donna; he/she is very tightly coupled to a narrow range of technologies (e.g. a
single language) and brings a thorough and awesome mastery of those technologies to
bear on the problem.
in software development, i think of a prototypical engineer as someone who knows many
languages and is very good at selecting the right language for the job, but who has a
shallow, superficial grasp of each language, no eye for its beauty, and is unlikely
to solve the problem elegantly. the prototypical craftsman knows only one language,
but knows it thoroughly and deeply, has a keen eye for its beauty, and will
instinctively and unerringly solve the problem as elegantly as possible within the
confines of that language.
never entrust the choice of language to a craftsman, and never entrust the actual
coding to an engineer.
> But, the man is right. MS Windows design is -not- engineering.
> It is touchy-feely, come hither with your money, neo barbarian,
> cave man wall drawing. Some days I have to decide if it's
> worth the agony to put with it, or follow the precedent of
> Elvis Presley, and take out a 45 and shoot the monitor.
> It's a tough call.
--
james d. hunter
>
> "james d. hunter" wrote:
>
> > Pretty much for the same reason that scientists say that.
>
> i would also claim that science is a craft. by science i mean
creating a model with
> which to answer a question or to understand some phenomenon. the
defining activity
> of a theoretical scientist is crafting models. the defining activity
of empirical
> scientists is crafting laboratory experiments, as well as statistical
models.
You can take that one step further. There are math philosophers who
consider math to be largely a craft. (Theorem crafters about V).
>
> this question, of whether the essential nature of the work is a craft
or is
> engineering, is important because it should be reflected in how the
work is
> compensated and managed. in engineering, it is best to approach the
work as a team,
> in which people are tightly coupled to each other. no one is a prima
donna; instead,
> each person is loosely coupled to technology by being aware of a
variety of languages
> and approaches so that he/she can choose the best technology to apply
to the problem
> at hand.
Well, I've done it both ways. The tightly coupled team and the loose
association
with a lead member with a whip. Both work and both fail. With big
projects
the team seems to be the way to go. The overhead for that 'team
spirit'
though chews up the budget of smaller projects real quick.
> in contrast, in craftwork, it is best to partition the problem into
person-sized
> pieces. each piece is given to an individual who is only loosely
coupled to the
> other people through the external specs for the piece. that person
is very much a
> prima donna; he/she is very tightly coupled to a narrow range of
technologies (e.g. a
> single language) and brings a thorough and awesome mastery of those
technologies to
> bear on the problem.
Well there are one person-sized projects that are engineering though.
The main part of the crafting I think comes in with interface issues
between the pieces.
> in software development, i think of a prototypical engineer as
someone who knows many
> languages and is very good at selecting the right language for the
job, but who has a
> shallow, superficial grasp of each language, no eye for its beauty,
and is unlikely
> to solve the problem elegantly. the prototypical craftsman knows
only one language,
> but knows it thoroughly and deeply, has a keen eye for its beauty,
and will
> instinctively and unerringly solve the problem as elegantly as
possible within the
> confines of that language.
>
> never entrust the choice of language to a craftsman, and never
entrust the actual
> coding to an engineer.
I guess I can go along with that.
JRStern
<ambas...@ideafarm.com> wrote:
>i have
>come to the conclusion that writing software should be viewed as a craft
>rather than as engineering, and i see significant differences between
>the two ways of approaching our work.
I'm on my third fluctuation on this issue. I suppose I originally
believed in "software engineering". Then, since software engineering
doesn't seem to really mean anything, I decided it must be a craft.
But, on the other hand, if it were a craft and you wanted to pursue it
professionally -- if you want to pursue any craft professionally --
then what is it that distinguishes craft from engineering? If you
have some ideas on that topic, please say more!
These days I've moved back to the engineering side. However, I want
to make one important point. What is being engineered is software.
Many practitioners, mostly younger ones <g>, think that what is being
engineered is the application. That is, they think they're
engineering a payroll system, when what they are engineering is a
payroll software package, that may have to support many different
payroll procedures over time, as external, real-world conditions
change. I think *that* difference in focus leads one to prefer
component styles of implementation, and to truly achieve more of their
promised benefits.
Any reactions to that?
Joshua Stern
JRS...@gte.net
thi
> perhaps my claim is this: when the work is guided by knowledge and
> analysis, it is engineering. when it is guided by the pursuit of
> beauty, it is a craft.
mu.
hmm, idea farm seems to have:
- proprietary libraries
- centralized development model
- non-free source
- non-interoperability by design
- pay to play secularism
your craft is already perfected: msdn.
why not imitate those who craft rather than those who are merely crafty?
thi
Jon Duringer
> what is it that distinguishes craft from engineering?
Joshua, mailto:leonardo...@my-dejanews.com, a previous contributor to
this thread, opined that engineering is solving problems ingeniously, where
craftwork is applying established tools and techniques to a new problem
within a familiar problem domain. iow, the engineer creates new tools and
techniques on the fly in order to solve a problem, and the creative emphasis
is on creating the tools and techniques. for the craftsman, the creative
emphasis is on applying tools and techniques that are taken as a given.
Leonardo's observation fits well with my own objective, which is to encourage
the software industry to mature from its current state, in which we all must
deal with a constant torrential flow of new tools and techniques, to a state
in which we have a single, stable collection of very powerful tools and
techniques that change only incrementally over one's lifetime. this would
make possible a craftsman's lifestyle and culture, in which old people's
knowledge would be valued and one would spend ones life mastering, really
mastering, the tools and technologies.
> That is, they think they're
> engineering a payroll system, when what they are engineering is a
> payroll software package
it seems to me that this shift from monolithic, static systems, to
configurable packages, will shift us toward smaller projects. that will make
the large engineering team efforts less necessary and make small craftwork
efforts more feasible. the move toward "software parts" is very good news
for the craftwork model.
black
>black wrote:
>should people who develop software think of themselves as part scientist,
>part engineer, and part craftsman / craftswoman? if you had to pick one of
>the three, would you refuse, insisting that all play an approximately equal
>part?
I think the point is that
* some people who write software are craftsmen
* a smaller number of people who write software
are Engineers and
* an even smaller number of people who write
software are scientists.
A student may start off as a scientist doing
automata theory, evolve into an Engineer doing
firmware, thence into a craftsman producing
popular code, and then become an manager or
businessman. At each step becoming less
ideal-world (and more wealthy :-) ).
leonardo...@my-dejanews.com
Jon Duringer <ambas...@ideafarm.com> wrote:
>
> Joshua, mailto:leonardo...@my-dejanews.com, a previous contributor to
> this thread, opined that engineering is solving problems ingeniously, where
> craftwork is applying established tools and techniques to a new problem
> within a familiar problem domain. iow, the engineer creates new tools and
> techniques on the fly in order to solve a problem, and the creative emphasis
> is on creating the tools and techniques.
I rather meant "types of problems". An engineer should strive to attain the
highest levels of abstraction.
> Leonardo's observation fits well with my own objective, which is to encourage
> the software industry to mature from its current state, in which we all must
> deal with a constant torrential flow of new tools and techniques, to a state
> in which we have a single, stable collection of very powerful tools and
> techniques that change only incrementally over one's lifetime.
Once I had spent eight years in order to master MS-Dos and NetWare
internals, and developing (or adapting) fool/fail proof development methods
and support libraries, MS comes out with Win9x for desktops and Win NT
Advandced Server, and they won preeminence in the corporate market. So I
became outdated, and had to quasi retire (just supporting my working
applications, no new projects) for four more years in order to achieve an
operating level of knowledge of the new frameworks.
Software Engineering, wich is but a new academically fashionable name for
the general Computer Science, a comprehensive field of theory and practice,
strives to establish long-lasting, proven methods for software development.
Unstability comes either from the paradigm shift (as from Structured to OO),
which are unavoidable -and desired- in any evolving field, or from the
marketing needs of the big companies. They need to invalidate their own
products, in order to force customers to renew theirs each year, at least.
They grew inmensely during the boom of personal computing. Now the market is
almost saturated -even in third world countries like mine- so they need that
renewal in order not to have a monumental crash.
OO looks definite. But structured looked definite twenty five years ago.
The proliferation of new tools, each propposing a better methodology or a
better approach, will last as long as market competence is allowed (I hope it
will be forever). But the real point is that always has existed a theoretical
framework to allow consistent methods to be "engineered" (again, from
"ingenio") that allow actual practice to be considered and realized as a
craft.
Our trade evolves fostered both by its internal dynamics and by the
marketing departments of the great software corporations.
Hugin Munin
it all depends on what you (and others) mean by "writing software". In my
opinion, this phrase is too imprecise.
One single developer might simply write a program with all the specs in his
head. In my eyes, this qualifies him as a craftsman.
However, if he first analyses customers requirements by some defined method
(say, QFD) and creates design diagrams in a case tool, the he does engineering
work.
-- Hugin
------------------------------------------------------
"But the emperor has no clothes!" (unknown little boy)
------------------------------------------------------
In article <37279A26...@ideafarm.com>,
Jon Duringer <ambas...@ideafarm.com> wrote:
> i am in my mid 40's and have been writing software since 1974. i have
> come to the conclusion that writing software should be viewed as a craft
> rather than as engineering, and i see significant differences between
> the two ways of approaching our work.
>
> i would like to know whether other people have come to this conclusion.
> i would also enjoy debating the point. if you would like to join me in
> a pleasant discussion of this, please reply with your own thoughts on
> software as a craft.
>
> --
> Jon Duringer, Ambassador, IdeaFarm (tm) City
> mailto:ambas...@ideafarm.com
>
>
--------------------------------------------------------------------------------
-------------------
>
> IdeaFarm (tm) City - a city for the software craft
> http://www.ideafarm.com ... fast loading ... text only ... 11,000 pages
>
--------------------------------------------------------------------------------
-------------------
>
>
Jon Duringer
> One single developer might simply write a program with all the specs in his
> head. In my eyes, this qualifies him as a craftsman.
> However, if he first analyses customers requirements by some defined method
> (say, QFD) and creates design diagrams in a case tool, the he does engineering
> work.
each of us seems to have a different idea about what
"craftsmanship" means. i am glad to have asked for this
discussion. your note seems to come from an IT shop
perspective, or from a marketing driven (as opposed to
technology driven) software product perspective. my own
thinking comes from a "technology driven" perspective.
until i read your note, i had been thinking of code
development methodology, but we also need to consider where
the external specifications come from. the issue of
"craftwork vs engineering" in code development resembles the
issue of "analysis vs gut instinct" in the development of
product specifications. marketing people can be craftsmen,
too!
Skipjack Software
profession. When I started in the field twenty years ago, most people were
either self-taught or technical-school-taught (my case,) and their code
showed this orientation (most instruction was focused on coding tricks, not
design.) The code we produced may have worked, but it was a chore to
maintain; hence, the inspiration for the saying "If it was hard to write, it
should be hard to read, and even harder to modify."
After a few years of this nonsense, I went back and earned a B.S.C.S., and
have never looked at software development in the same light. I know
prefer to practice software development as a managed, engineering process,
not a craft. The craft approach is too unpredictable/unforgiving. I
believe it is the reason why so many projects fail.
Furthermore, one cannot produce large, high-quality, products using the
craft approach, and still meet an organization's market demands. Crafted
products take too long to produce. They also require us to use expensive
labor at the coding-level. This is the main reason why we have the
engineering sciences in the first place. Engineers make it possible to
produce goods without expensive labor by creating processes and tools to
simply production. Coding is a skill. Engineering is a profession.
In closing, it sounds like you are trying to create an atmosphere where
people do not have to move up (i.e., stagnating technical growth; so, that
older members can stay competitive with the "kids" in lower-level skills.)
However, many professions, software development included, have an "up or
out" policy. No market can handle a large population of well-compensated,
low-level employees (i.e., investors rule the roost, and will channel their
funds to where they can earn the largest return on investment.) Even unions
have felt this dynamic the last couple of decades.
Mark
Vladimir Trushkin
your work well and there is no one interested how you do call it but you.
Best Wishes,
Vladimir
Jon Duringer <ambas...@ideafarm.com> wrote in message
news:37279A26...@ideafarm.com...
> i am in my mid 40's and have been writing software since 1974. i have
> come to the conclusion that writing software should be viewed as a craft
> rather than as engineering, and i see significant differences between
> the two ways of approaching our work.
>
> i would like to know whether other people have come to this conclusion.
> i would also enjoy debating the point. if you would like to join me in
> a pleasant discussion of this, please reply with your own thoughts on
> software as a craft.
>
Hugin Munin
I split my time between being repsonsible for all things "software
engineering" at a bank and being a consultant for software quality and
process management. I would also consider myself as coming basically from a
"technology driven" approach. However, I have also looked at fields like
engineering economics, marketing and controlling and other engineering
disciplines to see what methods they are using and what is applicable to
software production.
I agree with Mark (Skipjack Software) about craft vs. engineering. The craft
approach will only work well for small projects. I see a trend that the code
generation aspect will be the final part of engineering a software system with
a case tool and will be done by the engineer clicking on the "generate code"
button. Of course, some craftsmen will remain, but they will be a minority.
-- Hugin
------------------------------------------------------
"But the emperor has no clothes!" (unknown little boy)
------------------------------------------------------
In article <372D80D6...@ideafarm.com>,
Jon Duringer <ambas...@ideafarm.com> wrote:
> Hugin Munin wrote:
> > One single developer might simply write a program with all the specs in his
> > head. In my eyes, this qualifies him as a craftsman.
> > However, if he first analyses customers requirements by some defined method
> > (say, QFD) and creates design diagrams in a case tool, the he does
engineering
> > work.
>
> each of us seems to have a different idea about what
> "craftsmanship" means. i am glad to have asked for this
> discussion. your note seems to come from an IT shop
> perspective, or from a marketing driven (as opposed to
> technology driven) software product perspective. my own
> thinking comes from a "technology driven" perspective.
>
> until i read your note, i had been thinking of code
> development methodology, but we also need to consider where
> the external specifications come from. the issue of
> "craftwork vs engineering" in code development resembles the
> issue of "analysis vs gut instinct" in the development of
> product specifications. marketing people can be craftsmen,
> too!
>
> --
> Jon Duringer, Ambassador, IdeaFarm (tm) City
> mailto:ambas...@ideafarm.com
>
>
--------------------------------------------------------------------------------
-------------------
> IdeaFarm (tm) City - a city for the software craft
> http://www.ideafarm.com ... fast loading ... text only ...
> 11,000 pages
>
black
>Who does care? Is it enough technical subject to be discused in here? Do
>your work well and there is no one interested how you do call it but you.
It matters to those thinking of making a major life decision to
invest years of their life (and much money) in becoming qualified
and proficient in software. Do these folks realize for example
that if they refuse to act unethically in their work they likely
won't have any work or pay? Building slugged products is an
example of unethical everyday behavior in the software industry.
Imagine if your doctor, teacher, nurse, civil Engineer etc.
intentionally gave you a degraded product or service - not to
save costs but to buoy the market for products/services.
Scott P. Duncan
> Who does care? Is it enough technical subject to be discused in here? Do
> your work well and there is no one interested how you do call it but you.
Some care because it is exactly the distincton between craft and science
and engineering and art and whatever which, for some, defines what
they believe "their work" should consist of and the rigor with which it
it should be pursued. What consitutes "doing one's work well" has a
bit to do with that definition then of what such work should include.
For examppe, a craft/art perspective may take a far less greater interest
in the independent opinions of others in a larger group whereas the
science/engineering perspective may consider the need for independent
review and approval to be a fact of life.
--
Scott P. Duncan
SoftQual Consulting http://www.mindspring.com/~softqual/
leonardo...@my-dejanews.com
"Vladimir Trushkin" <trus...@iname.com> wrote:
> Who does care? Is it enough technical subject to be discused in here? Do
> your work well and there is no one interested how you do call it but you.
>
Is this a show off of the "new russian ruthless cold-blooded competitive
spirit"?
There are moderated news groups where lovers of censorship and controlled
discussion may participate. I dont't see any reason to justify that grumpiness
from your part. It is a reflection about the practice of our trade. You may
like it, and participate, or dislike it, and ignore it.
In every day life there are so many instances of censorship, justified or
not, that is is disgusting to read them in this supposedly free channel.
At any rate, the propposed problem is more topical, and more technical,
than your answer.
The world is on the edge of the anihilation of any for of freedom. Please,
don't push it!
I am interested in this discussion, and your message is something like the
24th in the thread. I (and I suppose the rest agree, at least as for
themselves) am not in any way stupid. Do show some respect!
Thank you!
--
Solo hay calma en la perfeccion
-----------== Posted via Deja News, The Discussion Network ==----------
leonardo...@my-dejanews.com
Hugin Munin <hugin...@my-dejanews.com> wrote:
> <snip>
> I agree with Mark (Skipjack Software) about craft vs. engineering. The craft
> approach will only work well for small projects. I see a trend that the code
> generation aspect will be the final part of engineering a software system with
> a case tool and will be done by the engineer clicking on the "generate code"
> button. Of course, some craftsmen will remain, but they will be a minority.
>
> -- Hugin
It is true that a number of tools have been designed to help the
engineering process of software creation. But the difference, IMHO, does not
reside in the choice of tools. There was a saying in the old times stating
that "software is a state of mind".
Many shops produce crafted software, many other engineer their productions.
To produce tailored, or customized, software, you need to design a basic
product with as much of engineering (see my first post in this thread for an
illustration of the "engineering" term in spanish semantics and etimology) as
possible. Then you do mostly craftswork for the tailoring. Even when you
craft, you may do it within an engineering view, or just with an utilitarian
aim.
The difference between engineering and crafting is more an internal state
of mind than a set of practices. I have done engineering with pen and paper,
and have crafted software with CASE tools.
Laurent UHRES
When I am working on a problem,
I never think about beauty.
I think only of how to solve the problem.
But when I have finished,
if the solution is not beautiful,
I know it is wrong.
R. Buckminster Fuller
Laurent UHRES
it is not only to find a name but it also includes (and this is important) a
debat of ideas. A name stands for a set of ideas and concepts, it is not just
mere letters.
It is too early in the morning, and I am still waiting for my cup of coffee, to
have clear thoughts.
Laurent
Vladimir Trushkin
track, dear Sir.
There is something wrong with you if you think that I am trying to represent
attenders stupid. This is only your imagination made you thinking this way.
And what is it: "new russian ruthless cold-blooded competitive spirit"? Do
you consider this remarks ethic? Maybe you're still incorporated into cold
war?
BTW, this is you who looks ruthless in your words. (:-)
Best Wishes(anyway),
Vladimir
<leonardo...@my-dejanews.com> wrote in message
news:7go1b9$6t1$1...@nnrp1.dejanews.com...
Vladimir Trushkin
them.
What is the craft? Is in enough formal term to be assessed on the same level
with Engineering or Science?
Best Wishes,
Vladimir
Laurent UHRES <l.u...@rtusi.com> wrote in message
news:372FE896...@rtusi.com...
Jonathan Egre
"Software Engineering" really engineering, is it a craft, is it a
profession?
Personally, I find these discussions philosophically interesting, but
ultimately self-defeating. The people who work in other branches of
engineering and other professions do not sit around debating whether or not
they are truly "engineers" or "professionals" - they just get on with their
projects, and they just get on with improving their engineering fields and
their professions.
So, instead of asking ourselves _whether_ software engineering is a true
branch of engineering or a craft, we should be asking ourselves _what_ we
can learn from other disciplines. It's a subtle but important difference
(IMHO).
Yes, I appreciate the fact that I cannot tell anybody else to stop
discussing things on the internet, and I am not trying to stop the
discussion; I just wanted to add my own observations.
Jonathan
Vladimir Trushkin wrote in message ...
>Who does care? Is it enough technical subject to be discused in here? Do
>your work well and there is no one interested how you do call it but you.
>
>Best Wishes,
>Vladimir
>
>Jon Duringer <ambas...@ideafarm.com> wrote in message
>news:37279A26...@ideafarm.com...
>> i am in my mid 40's and have been writing software since 1974. i have
>> come to the conclusion that writing software should be viewed as a craft
>> rather than as engineering, and i see significant differences between
>> the two ways of approaching our work.
>>
>> i would like to know whether other people have come to this conclusion.
>> i would also enjoy debating the point. if you would like to join me in
>> a pleasant discussion of this, please reply with your own thoughts on
>> software as a craft.
>>
Hugin Munin
What I ment by the case tool example was that when the code is generated,
there is no longer any craft involved - simply because there is no craftsman
(craftsperson?).
The persons I admire most are the ones who have the mindset of craftsman,
engineer and artist combined (if they know in what situation which mindset is
appropriate...)
-- Hugin
In article <7go26l$7nq$1...@nnrp1.dejanews.com>,
Hugin Munin
we can apply from other engineering disciplines?
-- Hugin
In article <37302...@nnrp1.news.uk.psi.net>,
-----------== Posted via Deja News, The Discussion Network ==----------
Scott P. Duncan
> So, instead of asking ourselves _whether_ software engineering is a true
> branch of engineering or a craft, we should be asking ourselves _what_ we
> can learn from other disciplines. It's a subtle but important difference
> (IMHO).
I actually think the argument has some of this behind the scenes,
i.e., there is a predisposition to certain technques and methods
which align themselves with what can be learned from an "artistic"
approach compared to an "engineering" approach compared to a
"craft" approach compared to a "scientific" approach. So, to argue
one of thes epositions is, in a way, to suggest what someone already
thinks are important hings to be learned about software development.
But, I would agree, to be specific about what these lessons are, rather
than deal with the higher-level areas, would be instructive. For example,
at the International S/W Eng. Standards Conference held in Walnut Creek,
CA back in June of 1997, folks from the Unic. of Quebec at Montreal
presented a session on what software-specific methods and techniques
were considered most important from the perspective of a group of
"notable" folks in the S/E field. It was interesting to see that most of the
principles they identified were not really software-specific at all, but
could be applied (and were) in almost any engineering or scientific
field. (Craft and art were not specifically addressed as that was not
the focus of the research being done.)
leonardo...@my-dejanews.com
"Vladimir Trushkin" <trus...@iname.com> wrote:
> Oh no... one more unnecessary dicsusion... let's stop it. You lead us out of
> track, dear Sir.
Yep! It is unnecessary. I simply rejected (and reject) a post of yours that
sounded like censorship based on relevance. No need to argue.
> There is something wrong with you if you think that I am trying to represent
> attenders stupid. This is only your imagination made you thinking this way.
It is definitely wrong to question the validity of a thread once 24
messages have been posted to it, all of them concerning the propposed theme.
> And what is it: "new russian ruthless cold-blooded competitive spirit"? Do
> you consider this remarks ethic? Maybe you're still incorporated into cold
> war?
My fault. It is stupid to mention race, nationality, creed, or the like
when expressing disagreement with somebody. It was nonsense, and I apologize.
The cold war was a matter for super-powers, not for us third world citizens.
> BTW, this is you who looks ruthless in your words. (:-)
It takes practice! ;-)
> Best Wishes(anyway),
> Vladimir
Cheers!
-------------------------
Solo hay calma en la perfeccion
-----------== Posted via Deja News, The Discussion Network ==----------
Vladimir Trushkin
looked offensive even though it was not supposed to be such.
Best Wishes,
Vladimir
Hugin Munin
For the benefit of discussion, I've tried to list some principles and
methods that typically separate the engineer from the craftsperson (in
this context, "system" can also mean "product"):
The engineer builds a model of the system that will be created, the
craftman doesn't.
The engineer applies scientific and economic principles to the
construction of the system, the craftsman typically doesn't.
The engineer chooses among several different designs that may fit a
given problem, trying to find a solution that best satisifies given
requirements and constraints; the craftsperson normally has one
"standard" way of doing her work.
In the "engineering" approach, the construction and manufacturing of
the system is done by several people, whereas in the "craft" approach
the whole process is mostly carried out by the same person. Especially,
if a system is engineered, manufacturing is never carried out by the
engineer, and is automated in most cases.
The engineering process is highly supported by methods and tools,
whereas in the crafting of a system, the tool support is not as high.
So, if you put your question/statement in the context of those
principles, the answer/response will be: "it depends on what you do and
how you do it".
As I once read in a book on the history on technology, the typical sign
of a young and emerging technology or engineering discipline is the
wide variances in how it is performed at the same time in different
locations.
-- Hugin
------------------------------------------------------
<37279A26...@ideafarm.com>,
Jon Duringer <ambas...@ideafarm.com> wrote:
> i am in my mid 40's and have been writing software since 1974. i have
> come to the conclusion that writing software should be viewed as a
craft
> rather than as engineering, and i see significant differences between
> the two ways of approaching our work.
>
> i would like to know whether other people have come to this
conclusion.
> i would also enjoy debating the point. if you would like to join me
in
> a pleasant discussion of this, please reply with your own thoughts on
> software as a craft.
>
> --
> Jon Duringer, Ambassador, IdeaFarm (tm) City
> mailto:ambas...@ideafarm.com
>
>
------------------------------------------------------------------------
---------------------------
>
> IdeaFarm (tm) City - a city for the software craft
> http://www.ideafarm.com ... fast loading ... text only ... 11,000
pages
>
------------------------------------------------------------------------
---------------------------
>
>
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
John D Salt
In article <7hbmhj$qkg$1...@nnrp1.deja.com>,
Hugin Munin <hugin...@my-dejanews.com> wrote:
[Snips everywhere]
>The engineer builds a model of the system that will be created, the
>craftman doesn't.
Not so. Artists draw sketches, sculptors build maquettes,
architects build models.
>The engineer applies scientific and economic principles to the
>construction of the system, the craftsman typically doesn't.
In an age and place where most craftsmanship is hobbyist pottering,
maybe; but historically craftsmen have depended on their craft for
a living, which seems to argue for a need to observe economic
principles.
>The engineer chooses among several different designs that may fit a
>given problem, trying to find a solution that best satisifies given
>requirements and constraints; the craftsperson normally has one
>"standard" way of doing her work.
I'm sure crafties produce experimental pieces, too. The carpenter
who put up my bookshelves offered a choice of three diffferent
materials at different cost levels to meet my economic constraints.
[Slight re-ordering of quoted material for dramatic effect]
>The engineering process is highly supported by methods and tools,
>whereas in the crafting of a system, the tool support is not as high.
Not so, to the extent of being proverbial: "A workman is known
by his tools".
>In the "engineering" approach, the construction and manufacturing of
>the system is done by several people, whereas in the "craft" approach
>the whole process is mostly carried out by the same person. Especially,
>if a system is engineered, manufacturing is never carried out by the
>engineer, and is automated in most cases.
That sounds like a more convincing distinction to me. If correct,
it would seem to argue that software engineering as a discipline should
emphasise communication to a greater extent than construction.
>As I once read in a book on the history on technology, the typical sign
>of a young and emerging technology or engineering discipline is the
>wide variances in how it is performed at the same time in different
>locations.
I suspect that software is also too large a field to be covered
adequately by a single flavour of engineering, and that if and
when the discipline matures, it will crystallize into many
separate but related fields, the boundaries of which are not
yet obvious.
All the best,
John.
--
John D Salt Dept of IS & Computing,| Barr's Law of Recursive Futility
Brunel U, Uxbridge, Middx UB8 3PH | [BLORF]: If you are smart enough
Disclaimers: I speak only for me. | to use one of these... you can
Launcher may train without warning.| probably manage without one.
Vladimir Trushkin
John D Salt <css...@brunel.ac.uk> wrote in message
news:7hbsbu$s4j$1...@molnir.brunel.ac.uk...
> Gosh, lots to argue about here! ;-)
And what are arguments?
John D Salt
Arguments are connected series of related logical propositions
presented with the intention of convincing ones interlocutor
of the truth of some statement.
HTH. HAND.
Steve Neuendorf
> In article <eQaGBLIn#GA.241@cpmsnbbsa05>,
> Vladimir Trushkin <trus...@iname.com> wrote:
> >
> >John D Salt <css...@brunel.ac.uk> wrote in message
> >news:7hbsbu$s4j$1...@molnir.brunel.ac.uk...
> >> Gosh, lots to argue about here! ;-)
> >
> >And what are arguments?
>
> Arguments are connected series of related logical propositions
> presented with the intention of convincing ones interlocutor
> of the truth of some statement.
No they're not (Monty Python)
:) Steve>
Vladimir Trushkin
mentioned in your previous post. Not about the definition that any child may
say in her own words... ;-)
Anyway thanks for the explanation made your time be spent,
Vladimir
John D Salt <css...@brunel.ac.uk> wrote in message
news:7hea11$e2b$1...@molnir.brunel.ac.uk...
> In article <eQaGBLIn#GA.241@cpmsnbbsa05>,
> Vladimir Trushkin <trus...@iname.com> wrote:
> >
> >John D Salt <css...@brunel.ac.uk> wrote in message
> >news:7hbsbu$s4j$1...@molnir.brunel.ac.uk...
> >> Gosh, lots to argue about here! ;-)
> >
> >And what are arguments?
>
> Arguments are connected series of related logical propositions
> presented with the intention of convincing ones interlocutor
> of the truth of some statement.
>
> HTH. HAND.
william...@bigfoot.com
css...@brunel.ac.uk (John D Salt) wrote:
> >In the "engineering" approach, the construction and manufacturing of
> >the system is done by several people, whereas in the "craft" approach
> >the whole process is mostly carried out by the same person.
Especially,
> >if a system is engineered, manufacturing is never carried out by the
> >engineer, and is automated in most cases.
>
> That sounds like a more convincing distinction to me. If correct,
> it would seem to argue that software engineering as a discipline
should
> emphasise communication to a greater extent than construction.
>
Let the congregation say "Amen!"
One of the major differences between engineering and craft is scope. The
engineer designs the bridge; the craftsman field-fits the steel and
builds the arrow-straight manonry foundations. The architect/engineer
designs the building; the craftsman produces the intricate woodwork and
the leak-free plumbing. The engineer designs the software product; the
craftsman implements precise, efficient and bug-free code. In all cases
the engineer must have a clear picture of the whole (abstraction skills)
AND must precisely communicate enough of that picture for the craftsman
to produce a component that fits well into the whole.
In the software profession, "engineers" often start out as de facto
craftsmen. As they rise to a true engineering level, much attention is
placed on their craft skills (coding) and little if any is given to
possibly the most important engineering skills, abstraction and
communcation.
------------------------------------
Share your life -- be an organ donor
------------------------------------
Myles
<ambas...@ideafarm.com> wrote:
>i would like to know whether other people have come to this conclusion.
>i would also enjoy debating the point. if you would like to join me in
>a pleasant discussion of this, please reply with your own thoughts on
>software as a craft.
I think you have to take into consideration the system that is being
developed. One would argue (and quite strongly I believe) that if the
system that you are developing has "life threatening" impact (ie.
mission critical systems in aerospace, defence, health care, etc.)
then the last thing you would want to do is to throw all experience in
software engineering standards and practices away. However I do
believe, and am in the process of writing a book on the subject, that
in the case of commercial software development (ie. software houses,
etc.) that current standards and practices do NOT meet the business
requirements.
Take for example a commercial software house that has an idea on what
it wants to develop. The reality is that if they were able to
document a complete specification in a traditional sense, their
competition would be able to as well. Therefore in an attempt to be
competitive and innovative, they might wish to approach their product
from a prototyping perspective. I guess that this reflects in the
fact that none of us wish to purchase version 1 of a commercial
software product. Typically if they are able to gain market share at
that point, then a complete re-write implementing full SDLC and
engineering practices would follow. But I'm not of the opinion that
engineering practices will work for commercial software development in
the very early stages. Although we might wish that it did, it takes
away the "art" as you put it and addresses quality issues in regards
to something that doesn't yet exist.
There must be a balance between management practice, scale of
development and intended audience/risk that will drive management to
know when software engineering practices are a science vs. an art
form. On larger projects, its normally always a science.
What type of applications did you have in mind with your original
question?
Myles Wakeham
=====================================================
Myles Wakeham
Tech Solutions (Aust) Pty Ltd
Adelaide, Australia
www.techsol.com.au
E-Mail: in...@techsol.com.au
TAdamsmar
all blind.
Graham Shevlin
>Let the congregation say "Amen!"
>
>One of the major differences between engineering and craft is scope. The
>engineer designs the bridge; the craftsman field-fits the steel and
>builds the arrow-straight manonry foundations. The architect/engineer
>designs the building; the craftsman produces the intricate woodwork and
>the leak-free plumbing. The engineer designs the software product; the
>craftsman implements precise, efficient and bug-free code. In all cases
>the engineer must have a clear picture of the whole (abstraction skills)
>AND must precisely communicate enough of that picture for the craftsman
>to produce a component that fits well into the whole.
when business-focussed analysts also fail to develop those skills)
then you will have trouble...
>
>In the software profession, "engineers" often start out as de facto
>craftsmen. As they rise to a true engineering level, much attention is
>placed on their craft skills (coding) and little if any is given to
>possibly the most important engineering skills, abstraction and
>communcation.
Many of the difficulties I have experienced in the past
God-knows-how-long years of software solutions delivery have a lot to
do with the inability of software developers and their managers to
abstract and communicate. This IMHO is a significant contributor to
the often poor working relationships between software development
groups and their customers. Often I find that the customers are way
ahead of the software developers in their abstraction and
communication abilities.
Tim Ottinger
what the difference is between craft and engineering, or are we
arguing about whatever it is we feel that software *should* be?
Craft is skilled hands-on work. Craftsmen are skilled workers,
even artisans.
I think that all designers should be craftsmen, engineers also.
I don't know an EE worth his salt who doesn't hook up the wires,
run the machines, hook up the scopes, etc. Is it hands-on work?
Sure. Is it skillful? You bet. It's part intellect, part training,
part experience, part imagination.
Now should software developers be skilled, hands-on workers?
I don't have to think about that one. Yeah. Nobody should be
designing software if they can't read and write code
skillfully. It's an issue of being too far from the problem
otherwise.
You know, we always talk about how it's so darned important
to get the requirements right (get them from the people who
really know - the users, the administrators, the auditors,
etc) so that we don't make any really big mistakes, and then
we sometimes get the idea that the development of software
can/should be done by people who don't know the language
and platform. It seems like that's silly for the same reason.
Tim
--
--------- There is no craftite conspiracy -------------
Tim Ottinger Object Mentor OO Training and
otti...@oma.com www.oma.com Mentoring
-------------------------------------------------------
We can interpret a bad temper as a sign of inferiority.
-- Alfred Adler
Myles Wakeham
>You know, we always talk about how it's so darned important
>to get the requirements right (get them from the people who
>really know - the users, the administrators, the auditors,
>etc) so that we don't make any really big mistakes, and then
>we sometimes get the idea that the development of software
>can/should be done by people who don't know the language
>and platform. It seems like that's silly for the same reason.
There are extremes in all cases, but I'm not suggesting in anyway that
we jump to conclusions that if all the effort is put in getting the
requirements right, that no effort is left to program it correctly by
professionals. My experience has been with development teams between
5 and 30 people on large projects as well as smaller teams where there
are adequate resources available in both analysis, development and
testing. What I have seen is that most shops tend to weight their
expertise and resource levels higher in terms of developers and leave
the analysts and testers to a minimum so that requirements aren't
addressed adequately. Then wonder why their projects are failing.
If a heavy emphasis in requirements is stated, it doesn't advocate
that a lesser emphasis be made in development. I'd like to see a
pretty even split of resources between analysis, development and
testing on a project. I think it would be the goal of any project
manager to have this happening.
By agreeing that writing software is a craft doesn't mandate that one
throw out all the good learning of engineering disciplines that make
projects succeed. All can live together in peace and harmony if
managed well.
Myles
brill...@my-dejanews.com
Manager who would RATHER software be engineered than crafted because I
believe that if you follow engineering principles there will be more
documentation and information from which to derive test cases. With
that said....
The original question asks if we agree that WRITING SOFTWARE is a craft.
My opinion is that DEVELOPING SYSTEMS is evolving from a craft to
engineering, but WRITING SOFTWARE (at the individual module or program
level) is still a craft for the most part. Writing Software is in the
control of the individual programmer, who (usually) has not been trained
in engineering principles. When I was a developer, I had learned
nothing about software engineering, just how to use the programming
language. It was up to me to determine how to apply that programming
language to a particular business problem. I may have had a design, but
mostly I used my own style of programming to solve the problem.
DEVELOPING SYSTEMS involves the integration of written software into a
system that performs multiple functions. It may just involve software
developed in-house, but more frequently involves integration of
third-party software packages, communication with other systems on
different hardware/operating systems platforms, etc. As systems become
more complex, they require more engineering and less craftsmanship when
it comes to integration and maintenance of the system as a whole.
Craft or engineering? I think it takes a little of both to build a
strong system. And I also agree with some of the posters to this thread
that it depends on what software you are developing (life-critical or
game, business application or simple utility). As the availability of
already-built software grows and matures - I think a lot of systems will
be largely built by integrating existing software. This will
(eventually) be more like an assembly line process, more engineering
than craft. But we are a long way from having the easily integrated,
stable software packages to support an assembly line.
-Robyn Brilliant