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>,