Are we "naturally selecting" the wrong types of programmers?
Adam.Sroka
Bjarnason suggested that I might get a lot of interesting discussion
if I reposted it here (Thanks, Olaf):
I've had an opportunity to go on a number of programmer interviews in
recent years. I'm starting to notice some trends in the way we
interview programmers that disturb me. A couple of observations:
1) Most interviewers seem to assess object-orientation skills with
canned questions like: "What is polymorphism?" I would prefer to see
them ask things like, "Given this description of the domain, can you
build a model?" Using CRC, or UML, or a simple block diagram. Very few
do.
2) Most interviewers ask about testing in very canned way as well,
e.g. "What perl modules do you use for testing?" They don't ask you to
write tests, or even to explain how/why you would write them.
3) Nearly every technical interviewer expects candidates to implement
some data structure and/or algorithm from memory on a whiteboard. This
is a fairly good way to determine that a person a) has memorized what
the structures and algorithms are and how they work, b) can write
basic procedural code, and c) can write code without tools.
4) Nearly every technical interviewer expects candidates to write SQL
queries involving complex joins on the whiteboard from memory. This is
a reasonable way to determine that a person a) has memorized the
majority of the SQL language, and b) can write queries with complex
joins (And therefore probably will.)
It seems to me that if we interview this way we are "naturally
selecting" our teams for good procedural programmers who can write
complex queries and know very little about testing or object-oriented
programming. Further, it seems to me that many of the programmers I
encounter when I consult somewhere as a programmer or coach, or that I
encounter on various groups asking lots of questions about
TDD, refactoring, basic OOP stuff, etc, share these qualities.
Are we, as an industry, expecting the wrong things from programmers?
Are we exacerbating a gap in knowledge that starts very early in a
programmer's career? If so, what should we, as an industry, do to fix
this?
Joe Fiorini
our industry that complex problems require complex solutions. Since
they think they need a complex solution, they're going to find
programmers to give them what they need. We really need to fight the
formerly mentioned mindset, and the rest will come. This tweet says it
best: http://twitter.com/jonathanpenn/status/3448647266
- Joe
joe fiorini - software craftsman & technologist
bio - http://joefiorini.com
thoughts - http://faithfulgeek.org
Curtis Cooley
> 4) Nearly every technical interviewer expects candidates to write SQL
> queries involving complex joins on the whiteboard from memory. This is
> a reasonable way to determine that a person a) has memorized the
> majority of the SQL language, and b) can write queries with complex
> joins (And therefore probably will.)
>
I've actually fallen victim to this. One position I applied for sent
me a test they wanted back within one hour. The test's first question
was a complex data model that I was to write DDL for then write two
queries for. I don't DDL or SQL, I use RAILS :)
I've yet to hear back, because although I'm, sure I aced the rest, I
completely botched the SQL and DDL sections.
I should have generated a rails app for the data model then dumped the
DDL, but that would have been cheating. I wouldn't want to go into a
job with them thinking I actually know that stuff.
Bu really, with ActiveRecord or Hibernate, does EVERY programmer have
to be a SQL guru anymore?
--
Curtis Cooley
curtis...@gmail.com
===============
Once a programmer had a problem. He thought he could solve it with a
regular expression. Now he has two problems.
Dave Hoover
understand SQL at a low level. I used to believe that I'd never have
to think about SQL as a Rails developer. And then I started dealing
with enormous data sets as MadMimi.com scaled. And then I wrote my
first (gasp) stored procedures under the guidance of an experienced
DBA.
So, I don't think you need to be a SQL guru, but do I think every
developer should be working toward becoming a guru at learning new
technologies.
Sukant Hajra
Hi,
I just wanted to throw in some hope. When I interviewed for my current job, I
pretty much paired through Robert Martin's "bowling game" kata [1] with my
current manager. Honestly, it wasn't completely smooth sailing because I
hadn't done TDD before, but I established a degree of technical confidence and
enthusiasm about TDD and progressive project management styles (Agile/Lean, XP,
etc.). Also, he got some sense of what it would be like to code with me. As I
was coding with him, I noticed an "Extreme Interviewing" whitepaper [2] on the
desk.
[1] http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata
[2] http://www.menloinnovations.com/freestuff/whitepapers/extremeinterviewing.htm
So there's definitely good interviews out there. However, I will say this
much. When I was interviewing for jobs using the university career center, I'd
hear things like "80% of jobs are obtained through networking," but the value
of that comment didn't really sink in. I think I dismissed the notion as
depressing cronyism flying in the face of the meritocracy I wanted to promote.
But since I met my current boss through some Agile technical lunches here in
Austin, I have a very different opinion on finding job leads through
professional contacts. Now I regard it as just part of the interview process.
It not only helps employers better find me, but helps me find the right kind of
employers.
I understand your frustration, though. Telling job seekers to essentially
"seek better," is an unfortunate concession to an industry that hasn't quite
figured out how to hire good talent and translate that talent effectively into
a good product.
I'm not sure where my next job will be. For now, I'm getting a lot out of my
current job. But I'm subscribed to this list because I'm interested in seeing
how far people can go with software craftsmanship.
-Sukant
Esko Luontola
http://3.bp.blogspot.com/_iY1LxW6Q7ks/Si0S_ltRUKI/AAAAAAAAABo/M8n5VST5f_M/s400/What+Is+Skill.png
On Aug 21, 3:27 pm, Joe Fiorini <j...@faithfulgeek.org> wrote:
> Great post! I think part of the problem is that there is the belief in
> our industry that complex problems require complex solutions.
Herb Nowell
>
> Are we, as an industry, expecting the wrong things from programmers?
> Are we exacerbating a gap in knowledge that starts very early in a
> programmer's career? If so, what should we, as an industry, do to fix
> this?
>
Yes, yes, and as for the later:
We need to stop thinking we're an engineering field. We're not, we're
a trade or a craft. Consider the division of labor in a traditional
engineering field. Engineers sit at a desk and consider a problem
then design a solution using standard parts and mathematical models of
how things work. Engineering techs interface with machinists,
electricians, ect in a controlled environment to build prototypes and
test item. Then once the issues are worked out an assembly crew turns
out copies.
Yes, that's over simplified and misses some types of engineering (most
civil engineering projects are one offs, not prototypes then mass
production). Also, cutting edge engineers work in labs to build their
designs. However, as a general rule an engineer is not a mechanic or
line worker. He doesn't build what he designs.
Our field is the exact opposite. We design and build. Some of us
design more (call them master craftsmen) and some barely design at all
(call them apprentices) but most of us mix the entire range of design
to repair in our jobs. Yet we interview and test and train as though
we are engineers who design really interesting things but don't really
implement them.
I think this trap results from the fact that programs have no physical
presence and thus aren't considered a tangible work product.
--
Herbert H. Nowell
"Remember that a government big enough to give you everything you want
is also big enough to take away everything you have.” - Senator Barry
Goldwater
Who is John Galt?
Sukant Hajra
>
> Yes, yes, and as for the later:
>
> We need to stop thinking we're an engineering field. We're not, we're
> a trade or a craft. Consider the division of labor in a traditional
> engineering field. Engineers sit at a desk and consider a problem
> then design a solution using standard parts and mathematical models of
> how things work. Engineering techs interface with machinists,
> electricians, ect in a controlled environment to build prototypes and
> test item. Then once the issues are worked out an assembly crew turns
> out copies.
>
> Yes, that's over simplified and misses some types of engineering (most
> civil engineering projects are one offs, not prototypes then mass
> production). Also, cutting edge engineers work in labs to build their
> designs. However, as a general rule an engineer is not a mechanic or
> line worker. He doesn't build what he designs.
>
> Our field is the exact opposite. We design and build. Some of us
> design more (call them master craftsmen) and some barely design at all
> (call them apprentices) but most of us mix the entire range of design
> to repair in our jobs. Yet we interview and test and train as though
> we are engineers who design really interesting things but don't really
> implement them.
>
> I think this trap results from the fact that programs have no physical
> presence and thus aren't considered a tangible work product.
Hi,
I certainly don't want to be a contrarian on this matter, especially because I
think I agree with some of what you've said, but having worked in the
semiconductor industry as an engineer for several years, I feel as though
you've misrepresented what engineering really is. There's a couple of points
I'd like to try to make.
First off, I like both ideas from the Lean manufacturing /and/ the
software craftsmanship discussions. Lean is implicitly sympathetic towards
engineering disciplines. Yet somehow, the software craftsmanship movement can
sometimes make some "software is different" arguments along the lines of what
you've presented. I think this has to do somewhat because the movement is
guided by Old World sentiments that were unfortunately displaced by the
Industrial Revolution.
I think we need to reconcile these two attitudes. Fortunately, I don't think
it needs to be terribly difficult to do so. Although Lean does focus on some
very process-oriented solutions (Kanban, for instance), I think there's a also
supposed to be an emphasis on something social. In fact, I think Lean has some
craftsmanship ideas baked in as engineers are moved from apprenticeships to
master engineer positions over the course of years.
Ultimately, I think the reality is that /no/ disciple that involves the real
work with real problems can ever be addressed with cookie-cutter solutions.
The engineer /isn't/ a designer that hasn't ever implemented his work (although
that can be the case). A good engineer has an education that allow him to
reconcile problems that arise in real life. This education can lead him to
solve problems through design. But sometimes, the solutions involve things
outside of design (for instance, the semiconductor industry is saturated with
manufacturing engineering disciplines (photo, etch, yeild enhancement, test,
and the list goes on). Also, you completely overlooked chemical and petroleum
engineering, which are also very hands-on disciplines.
You do have a point that in software, we often build what we design. This
might work to our advantage, but it really doesn't make me feel like I'm not
performing some feat of engineering.
So here's how I feel about all this at the end of the day. Great engineers are
also craftsman. And great craftsman are also engineers. Engineering for me is
all about problem solving. Craftsmanship is all about how to capitalize on the
problems we've already solved before through a social consideration.
-Sukant
Olof Bjarnason
discussion - any pointer would be appreciated.
For the SC view of things, I've read Pete McBreens "Software Craftsmanship".
If you read that - what's your opinion on his clear and wide
separation of software engineering and software craftsmanship?
>
> -Sukant
>
> >
>
--
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english
Sukant Hajra
>
> Thanks for this long read Sukant. I'm not well versed in the Lean
> discussion - any pointer would be appreciated.
I haven't read many seminal books, so I should be clear about that. However,
there's a pretty strong community here so most of what I know comes from
discussions I've had at Agile and Lean groups around town and articles I've
read on-line. Hopefully that doesn't deeply discredit my arguments.
That said, I hear anything by the Poppendiecks [1] comes highly recommended.
[1] http://www.poppendieck.com/
> For the SC view of things, I've read Pete McBreens "Software Craftsmanship".
> If you read that - what's your opinion on his clear and wide
> separation of software engineering and software craftsmanship?
Someone at the office has this book. Having dipped into this discussion as far
as I have, I feel somewhat obligated to read the book and report back with my
thoughts. Might take me some time, though.
My suspicion is that we'll ultimately be arguing about the semantics of what
"engineering" means to us. In McBreen's context, that might be something
specifically polarized from software craftsmanship. But to me, that just
doesn't seem to reflect the reality of what I experienced not only in school as
a EE, but in the four years as an engineer after that.
I'll read McBreen's book, though, and write back.
-Sukant
Jeff Dickey
The way I've always understood "engineering" - speaking as a software
developer who only just let his quality-engineering certification lapse
(being out of the US and not plugged in locally), and the son of a civil and
drainage engineer who took those things seriously...
...the best definition of "engineering" I've ever heard (in my opinion, of
course) is "a professional who uses his education, his experience, his
judgment and his demonstrated mastery over a body of knowledge common to his
discipline to create an artifact or artifacts which solve a known problem or
set of problems, in a verifiable manner, to produce a result verifiably
knowable in advance."
With that definition in mind, by the time I had ten years' experience in
software development (circa 1989), according to a memo I wrote at the time,
I believed we were "20 to 50 years away from having a true discipline of
'software engineering.'"
I now regard that estimate as wildly optimistic; I'll be /amazed/ if we "get
there" in 50 years (i.e., by 2059). It's not due only to the imprecise
process by which we go about our precise craftsmanship; the clients and
colleagues I've had over the past couple of decades largely seem actively
resistant to the idea and its ramifications.
As one client put it to me a couple of years ago, "Imagine if developers
could legally force a project to exceed the schedule or budget set by
management - or have it cancelled outright." To which I countered, "Imagine
a world where management takes the estimates and judgment of software
professionals as seriously as civil or aeronautical engineers today, with
good reason."
I've blogged on this and closely related topic several times, including
http://archlever.blogspot.com/2009/08/debate-between-adequacy-and-excellence
.html and
http://archlever.blogspot.com/2008/07/best-practices-alleged-your-mileage-ma
y.html and
http://archlever.blogspot.com/2008/06/good-things-are-good-thingsarent-they.
html and
http://archlever.blogspot.com/2007/09/improvement-as-opposed-to-change.html
and ESPECIALLY
http://archlever.blogspot.com/2007/09/crap-is-not-professional-goal.html -
I'd value the opinions of the other folks on this list.
Thanks for reading.
Jeff Dickey
--
Jeff Dickey http://archlever.blogspot.com
Email: jdi...@seven-sigma.com
Phone/SMS: +65 8333 4403
Skype: jeff_dickey
LinkedIn: jdickey
Yahoo! IM: jeff_dickey
MSN IM: jeff_...@hotmail.com (for IM only, not for email, please)
ICQ: 8053918
QQ: 30302349
GnuPG key:
Fingerprint D367 FB97 4E59 BEC0 8EBC D8E3 3BD4 7D4C DFE0 6488
Valid 01/07/2009 to 31/12/2009
Download from http://tr.im/qqQa
Curtis Cooley
>
> Excerpts from Olof Bjarnason olof.bjarnason-at-......... |Software_Craftsmanship|'s message of Sun Aug 23 00:48:31 -0500 2009:
>>
>> Thanks for this long read Sukant. I'm not well versed in the Lean
>> discussion - any pointer would be appreciated.
>
> I haven't read many seminal books, so I should be clear about that. However,
> there's a pretty strong community here so most of what I know comes from
> discussions I've had at Agile and Lean groups around town and articles I've
> read on-line. Hopefully that doesn't deeply discredit my arguments.
>
> That said, I hear anything by the Poppendiecks [1] comes highly recommended.
>
> [1] http://www.poppendieck.com/
>
To grok lean, one must read at least the first half of "Lean Thinking"
by Womak and Jones.
They wrote "The Machine That Changed the World" about the Toyota
Production System. It's an academic study with lots of figures and
numbers proving how much more efficient the TPS is than the factory
line.
A fews years after the book, they went out to see how much progress
all the companies had made. They found that adopting the TPS was much
much harder than they had assumed, and it often didn't work. There is
no formula for lean. So they wrote "Lean Thinking" which is about how
adopting Lean values and principles then applying your own process is
much much more effective.
I'm anti formula when it comes to software process. No one process is
going to work for everyone, or for anyone else frankly. You need to
adopt values and principles of lean/agile and build your own process.
Perhaps picking practices from XP or Scrum, but most important is
making your process your own, then continually improving it.
Sorry for the mini-blog. It just sorta is flowing this morning :)
p.s. "The Goal" by Goldratt is also a great book. It's about theory of
constraints, an important piece of Lean manufacturing. If you can
apply TOC to your software process, you'll find your productivity
greatly increases. It's written as a novel with a fictitious factory
manager finding a mentor who teaches him about TOC. There are a few
chapters which just forward the story line which can be skipped or
scanned if you just want the meat.
Sonya Lowry
into a discussion of Lean? Programmers program. They are concerned
with coding and unit testing (if you are lucky) but process falls
squarely within the engineering domain. I do a great deal of work
with scientific programmers and strongly assert that, while they
understand that process is something that must happen around them, it
is not something with which they concern themselves whenever it is
avoidable.
Sonya
Steve Donie
Steve
Sonya Lowry
such. They do, however, bring value that cannot be ignored. My
assertions stated concisely are:
1) we cannot expect all programmers to be craftsmen
2) there are places in the SDLC for non-craftsmen
3) programmer != engineer, but engineering practices are an important
part of building quality software products
Sonya
Sonya Lowry
"Software engineering is the application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance
of software, and the study of these approaches; that is, the
application of engineering to software."
Sonya
Herb Nowell
>
> I certainly don't want to be a contrarian on this matter, especially because I
> think I agree with some of what you've said, but having worked in the
> semiconductor industry as an engineer for several years, I feel as though
> you've misrepresented what engineering really is. There's a couple of points
> I'd like to try to make.
>
I prefer "glossed over" or "simplified". Actually "idealized" is
probably the best. I'm well aware that what I presented isn't a
perfect map of the real world, but it does illustrate what I consider
key differences.
>
> Ultimately, I think the reality is that /no/ disciple that involves the real
> work with real problems can ever be addressed with cookie-cutter solutions.
>
This is a different (if related) discussion. Have you read "Shop
Class as Soulcraft"? I think software development in general and the
software craftsmanship movement specifically have a lot to learn from
it.
>
> The engineer /isn't/ a designer that hasn't ever implemented his work (although
> that can be the case). A good engineer has an education that allow him to
> reconcile problems that arise in real life. This education can lead him to
> solve problems through design. But sometimes, the solutions involve things
> outside of design (for instance, the semiconductor industry is saturated with
> manufacturing engineering disciplines (photo, etch, yeild enhancement, test,
> and the list goes on).
>
Yes, but do the designers spend much time on the manufacturing
engineering disciplines? And do the design engineers spend much time
working on the products after they are created? My disdain for
engineers as workers with things beyond design stems from a decade as
a mechanic in the Navy. While perfectly designed for their purpose in
isolation much of the gear I worked on was poorly designed when
deployed in context. Unnecessary complications abounded.
A perfect example is the wrenches needed. Mechanical engineers have
guide books of various fasteners to show holding properties based on
diameter, head size, thread fineness and count, etc. So, the HP air
compressors (among other items) I routinely worked on had each
fastener perfectly chosen for it usage, neither under or over
designed. Sounds great until you have to take the thing apart. An
engineer who was more than a designer but also a mechanic would have
selected a few standard fasteners and accepted that some parts would
be over designed for operation but the whole would be better designed
for repair and maintenance.
>
> You do have a point that in software, we often build what we design. This
> might work to our advantage, but it really doesn't make me feel like I'm not
> performing some feat of engineering.
>
Saying we're not engineers doesn't mean we aren't engaged in
engineering. I have come to the conclusion that engineering has lost
by becoming a field where academic training dominates to the exclusion
of other types (and I regularly rail against most CS programs for
similar reasons). I almost went to school for mechanical engineering
over mathematics and I'm convinced my years as a mechanic would have
made me a better machine designer that most of my classmates.
That we build (and repair) what we design should allow use to avoid
the 20 wrench problem. That we don't tells me we aren't taking
advantage of something unique we have to offer. The more we think of
ourselves as engineers instead of an integrated professional whose job
is the whole life cycle the less opportunity we have to provide good
software.
Great engineers may be great craftsmen but if so, it is by
transcending engineering and learning and doing things outside the
field. As you point out, that is arguably one of the secrets of Lean
(and before it what was called Theory Z): excellence by demanding
great cross area knowledge.
Herb Nowell
>
> I agree that they are not software craftsmen nor do they aspire to be
> such. They do, however, bring value that cannot be ignored. My
> assertions stated concisely are:
>
> 1) we cannot expect all programmers to be craftsmen
> 2) there are places in the SDLC for non-craftsmen
> 3) programmer != engineer, but engineering practices are an important
> part of building quality software products
>
Hmmm...I think I agree with the exception that I'd read #1 as craft
masters and #2 as "for lifetime journeymen". In fact, I think my fate
may be in being the later in the long term. To be a master requires
more than just time and not everyone has what it takes.
That said, more and more there is not room in any team for programmers
who want to be static.
Alexandru-Emil Lupu
I do not think that have been said allready...
There are out there a lot of programmers that want to improve their skills, but sometimes there is no time. I mean you guys speak about the perfect condition about: "a developer should have time to make TDD".
What could you can say in the situation that some good programmers try to make quality software, but there are a lot of salesmen guys who bring more and more clients, and the management, just throw to the developers all the project that are in. Some of the managers do not know what it really means "to program". They refuse to bring more people just because "tomorrow i will not have the same profit" etc...
So, a programmer is practically a "slave on the plantation", he does not have the time to improve his skills just because of tight deadlines.
Of course it has been said earlier in this topic: "a programmer should understand basic SQL knowledge". I understand that... but, in some manager's point of view, it would be better to hire a guy who know how to do: SQL, Some basic server administration, also some networking, basic protocol understanding and so on , prefferably on a small amount of money. It is possible that some of the guys that are interviewed just to say: "yeah, i have some SQL knowledge." and "networks? easy stuff... ". On an interview, the candidate might lie... or just mention the things that he has worked with, or worse, heared about them. A manager usually say : "EVRIKA! i got the expert that i wanted"... but soon he will be disapointed, when the "expert" will be in the first line of fire.
Alecs
--
As programmers create bigger & better idiot proof programs, so the universe creates bigger & better idiots!
I am on web: http://www.alecslupu.ro/
I am on twitter: http://twitter.com/alecslupu
I am on linkedIn: http://www.linkedin.com/in/alecslupu
Tel: (+4)0748.543.798
Sukant Hajra
>
> > Ultimately, I think the reality is that /no/ disciple that involves the
> > real work with real problems can ever be addressed with cookie-cutter
> > solutions.
>
> This is a different (if related) discussion. Have you read "Shop Class as
> Soulcraft"? I think software development in general and the software
> craftsmanship movement specifically have a lot to learn from it.
>
No, but I'm definitely jotting down notes of things to read.
I hope other people haven't been too heavily burdened by the debate churn of
this thread. For me, it's been helpful to canvas the views across the group
members (since I just signed up recently). Also, I'm getting recommendations
for what I hope are great reads.
> Yes, but do the designers spend much time on the manufacturing engineering
> disciplines? And do the design engineers spend much time working on the
> products after they are created? My disdain for engineers as workers with
> things beyond design stems from a decade as a mechanic in the Navy. While
> perfectly designed for their purpose in isolation much of the gear I worked
> on was poorly designed when deployed in context. Unnecessary complications
> abounded.
Okay, I /definitely/ sympathize with your views and experience.
> > You do have a point that in software, we often build what we design. This
> > might work to our advantage, but it really doesn't make me feel like I'm
> > not performing some feat of engineering.
>
> Saying we're not engineers doesn't mean we aren't engaged in engineering. I
> have come to the conclusion that engineering has lost by becoming a field
> where academic training dominates to the exclusion of other types (and I
> regularly rail against most CS programs for similar reasons). I almost went
> to school for mechanical engineering over mathematics and I'm convinced my
> years as a mechanic would have made me a better machine designer that most of
> my classmates.
The problems with academia is probably a whole new discussion altogether. It's
also one that's been on my mind recently. I had the idea to reach out to the
student population at The University of Texas at Austin. I got a bit
over-eager and sent out an impassioned E-mail [1] to the UT chapter of ACM in
the middle of their summer break. Once the students come back from break, I'll
try to reach out again (tepid response thus far).
[1] http://pastebin.com/m1c3fe4b2
I'm definitely interested in anyone's thoughts. I'm especially interested in
anything you guys have done in a similar vein. It would be nice to do
something more concrete in the community.
> That we build (and repair) what we design should allow use to avoid the 20
> wrench problem. That we don't tells me we aren't taking advantage of
> something unique we have to offer. The more we think of ourselves as
> engineers instead of an integrated professional whose job is the whole life
> cycle the less opportunity we have to provide good software.
I had speculated previously that some of what we'd be discussing would be the
semantics of engineering. It appears that some of that is panning out.
But I think we're reaching a common ground here. I often find in semantic
debates that there's two threads of discussions. The first is a legalistic
reasoning of terms, causality, etc. But the second thread is actually more
important -- the social context that's steeped in emotion and tone.
I guess I'm a little pooped of the debating at this point. I'm with you. Both
software and non-software engineer and craftsman have a long way to go. I
still, though, see a lot of similarities between software and non-software
problem spaces, so I'd really like to see a unification of terms and concepts.
That's one of the things I like about Lean.
> Great engineers may be great craftsmen but if so, it is by transcending
> engineering and learning and doing things outside the field. As you point
> out, that is arguably one of the secrets of Lean (and before it what was
> called Theory Z): excellence by demanding great cross area knowledge.
Sounds good to me.
-Sukant
Adam Sroka
knows how to build stuff (Houses, churches, barns, bridges, etc.) That
definition is still in use in a few limited contexts (US Army, for
one.)
Today engineers are trained primarily in theory. That is entirely the
fault of academia IMNSHO. However, good engineering schools still give
students the opportunity to apply what they learn in a variety of
contexts, and good engineering employers expect prospective candidates
to know things that they are only likely to learn by doing.
For example, I have an uncle who was an engineer and a high-level
manager at Xerox. He told me that when he was responsible for hiring
engineers he would ask specific questions to determine whether they
understood the difference between practice and theory. An example he
gave was asking the EE whether he would use an aluminum or ceramic
capacitor in a certain type of circuit. In theory, if they have the
same capacitance then it shouldn't matter. In practice, under the
circumstances he described, the aluminum one would behave as if it had
a much lower capacitance than what it was rated for. It was the sort
of thing that, according to him, you don't find out until you've tried
it.
Having said that, I wanted to be an automotive engineer. I attended an
ME program at the University of Maryland, but I dropped out before
completing my Junior year. Even at that point I was acutely aware of
the importance of where practice and theory diverged. We would look at
theoretical models. Then we would build something and evaluate the
model against what we had built. Inevitably there was something
missing from the theory, and we would attempt to discover what and
adjust our model accordingly. We would repeat this process until the
(software) model closely approximated what we had build. Then, we
would adjust the machine and see if the model could predict what
happened. Inevitably something was missing...
My understanding is that this is par for the course in hard
engineering. The models evolve at least as frequently as the machines
do, and the two are constantly compared to arrive at a deeper
understanding. The eventual goal is to *build something* that behaves
in a predictable way. Everyone understands that that is the goal and
that without both the model and the metal evolving at the same time we
can't get there.
...
Getting back to software: the only analogue to the above that I have
encountered in software is Test Driven Development. In TDD I can 1)
create a model that can be validated 2) create a working system and
validate it against that model 3) adjust both the model and the
implementation until I have a system that I am reasonably sure will do
what I want it to do and behave in a predictable way.
So, a "Software Engineer" if he is anything like a "Hard Engineer"
must have TDD as the central practice of his work. If he does this,
then the two disciplines are somewhat comparable.
Adam Sroka
>>
>> Thanks for this long read Sukant. I'm not well versed in the Lean
>> discussion - any pointer would be appreciated.
>
> I haven't read many seminal books, so I should be clear about that. However,
> there's a pretty strong community here so most of what I know comes from
> discussions I've had at Agile and Lean groups around town and articles I've
> read on-line. Hopefully that doesn't deeply discredit my arguments.
>
> That said, I hear anything by the Poppendiecks [1] comes highly recommended.
>
> [1] http://www.poppendieck.com/
>
In essence, Lean talks about "respecting people" and "continuous
improvement." These two are its core values and they are *extremely*
compatible with the SC way of thinking.
Beyond that there are a lot of individual practices that Lean suggests
from a manufacturing viewpoint. There have been a variety of attempts
from a variety of players to try to draw analogies between the
manufacturing practices and what we, as software people, do. This is
the most controversial part of Lean, and I think it will take time for
the community to reach some sort of consensus.
There are at least three camps right now: the Six Sigma folks, the
Lean Software Development folks (Poppendieck), and the Kanban folks
(Kanban is kind of like a "task board" in Scrum. Some people have
tried to take the specific manner in which kanban is applied in
manufacturing and literally interpret it for software.) There are
probably other ways to interpret Lean in a software context, but these
are the ways I have encountered thus far.
FWIW, LSD (Poppendieck) have probably invested the most energy of
anyone in determining exactly how Lean maps to software. So, you can't
go wrong by starting there.
>> For the SC view of things, I've read Pete McBreens "Software Craftsmanship".
>> If you read that - what's your opinion on his clear and wide
>> separation of software engineering and software craftsmanship?
>
Responding to Olaf:
I think that the way McBreen uses "Software Engineering" is a sticking
point. I prefer to interpret it as "software as profession" vs
"software as craft." To the extent that Engineers are people with a
specific education who belong to professional organizations and whose
role and value to society is determined by such they are different
from craftsman. However, I think using the term "engineer" rather than
"profession" as the point of comparison confuses the issue.
> Someone at the office has this book. Having dipped into this discussion as far
> as I have, I feel somewhat obligated to read the book and report back with my
> thoughts. Might take me some time, though.
>
Please do read it. It is an excellent book and should give you a great
background in understanding why some of us are here, why the manifesto
was created, etc.
Adam Sroka
>>
>> Thanks for this long read Sukant. I'm not well versed in the Lean
>> discussion - any pointer would be appreciated.
>
> I haven't read many seminal books, so I should be clear about that. However,
> there's a pretty strong community here so most of what I know comes from
> discussions I've had at Agile and Lean groups around town and articles I've
> read on-line. Hopefully that doesn't deeply discredit my arguments.
>
> That said, I hear anything by the Poppendiecks [1] comes highly recommended.
>
> [1] http://www.poppendieck.com/
>
In essence, Lean talks about "respecting people" and "continuous
improvement." These two are its core values and they are *extremely*
compatible with the SC way of thinking.
Beyond that there are a lot of individual practices that Lean suggests
from a manufacturing viewpoint. There have been a variety of attempts
from a variety of players to try to draw analogies between the
manufacturing practices and what we, as software people, do. This is
the most controversial part of Lean, and I think it will take time for
the community to reach some sort of consensus.
There are at least three camps right now: the Six Sigma folks, the
Lean Software Development folks (Poppendieck), and the Kanban folks
(Kanban is kind of like a "task board" in Scrum. Some people have
tried to take the specific manner in which kanban is applied in
manufacturing and literally interpret it for software.) There are
probably other ways to interpret Lean in a software context, but these
are the ways I have encountered thus far.
FWIW, LSD (Poppendieck) have probably invested the most energy of
anyone in determining exactly how Lean maps to software. So, you can't
go wrong by starting there.
>> For the SC view of things, I've read Pete McBreens "Software Craftsmanship".
>> If you read that - what's your opinion on his clear and wide
>> separation of software engineering and software craftsmanship?
>
Responding to Olaf:
I think that the way McBreen uses "Software Engineering" is a sticking
point. I prefer to interpret it as "software as profession" vs
"software as craft." To the extent that Engineers are people with a
specific education who belong to professional organizations and whose
role and value to society is determined by such they are different
from craftsman. However, I think using the term "engineer" rather than
"profession" as the point of comparison confuses the issue.
> Someone at the office has this book. Having dipped into this discussion as far
> as I have, I feel somewhat obligated to read the book and report back with my
> thoughts. Might take me some time, though.
>
Please do read it. It is an excellent book and should give you a great
Steve Hayes
>>> Craftsmanship".
>>> If you read that - what's your opinion on his clear and wide
>>> separation of software engineering and software craftsmanship?
>>
>
> Responding to Olaf:
>
> I think that the way McBreen uses "Software Engineering" is a sticking
> point. I prefer to interpret it as "software as profession" vs
> "software as craft." To the extent that Engineers are people with a
> specific education who belong to professional organizations and whose
> role and value to society is determined by such they are different
> from craftsman. However, I think using the term "engineer" rather than
> "profession" as the point of comparison confuses the issue.
While engineers may or may not be craftsmen, I think it's dangerous to
behave as if craftsman aren't "professional". Like it or not,
"unprofessional" has a lot of emotive baggage you probably don't want
to fight. I also consider myself both a craftsman and a professional -
I don't consider myself an engineer. YMMV.
Steve Hayes
Adam Sroka
Unfortunately, profession, like engineer, is an overloaded term. I am
referring specifically to the concept of a professional as someone
who: 1) has completed a specific course of academic training, often
requiring more than a four-year degree 2) is a member of a
"professional organization" e.g. a state bar association, state
medical board, NSPE, etc. 3) Is held to specific standards of
"professional ethics" under which his/her membership in the
professional organization can be evaluated and revoked. 4) cannot
practice his trade without the appropriate degree and/or membership in
the appropriate organization.
This, IMO, is what we need to contrast with "craftsmen" who, by and
large, receive training on the job and are held to the standards of
their peers as well as their customers. A craftsman may be, though
need not necessarily be, associated with some organization of his
peers (e.g. a "guild") He may be held to a standard of ethics by his
peers. Although, his ability to practice cannot be revoked other than
by word-of-mouth.
Steve Hayes
This is interesting, but does not describe anyone in software that I
have known in my 20+ year career. To me that makes it a straw man in
the context of software craftsmanship. Pete was referring to people
who did not meet this standard, but would still have identified
themselves as 'software engineers'. I think using "professional" the
way you are using it, in relation to software, confuses the issue.
Steve
Adam Sroka
according to the strict definition I provided. There are a few more
who wish to see those kinds of standards applied to our "profession."
Right now there is no standard. Many of us feel that there should be
one. The question is, should it be a standard based on "professional
ethics" and a membership in a "professional society' a la medicine,
law, accounting, professional engineering, etc? Or, should it be one
based on a community of people who share a common desire to create
high quality works and constantly improve the state of their art?
How would you characterize those options? As I have pointed out,
"Engineers" vs. "Craftsman" is not the best way to describe the
dichotomy. As you have pointed out, "Profession" vs "Craft" may not be
ideal either. What are the best words?
On Sun, Aug 23, 2009 at 11:17 PM, Steve
Olof Bjarnason
> There are very few people in software who are "professionals"
> according to the strict definition I provided. There are a few more
> who wish to see those kinds of standards applied to our "profession."
>
> Right now there is no standard. Many of us feel that there should be
> one. The question is, should it be a standard based on "professional
> ethics" and a membership in a "professional society' a la medicine,
> law, accounting, professional engineering, etc? Or, should it be one
> based on a community of people who share a common desire to create
> high quality works and constantly improve the state of their art?
>
> How would you characterize those options? As I have pointed out,
> "Engineers" vs. "Craftsman" is not the best way to describe the
> dichotomy. As you have pointed out, "Profession" vs "Craft" may not be
> ideal either. What are the best words?
Anyway, one thought is just "showing the world" what we are talking
about, instead of trying to explain.
If our ways are so much better - then the industry will notice. So
let's continue discussing, and share things like the better way to
interview people which was discussed not so long ago on this list
(pair programming something instead of asking 'geeky questions').
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english
Dave Hoover
>
> Anyway, one thought is just "showing the world" what we are talking
> about, instead of trying to explain.
Yes, that is the best way. Let's show the world the what we are
talking about by crafting remarkable software.
> If our ways are so much better - then the industry will notice.
Agreed.
Adam Sroka
Bjarnason<olof.bj...@gmail.com> wrote:
>
> 2009/8/24 Adam Sroka <adam....@gmail.com>:
>>
>> How would you characterize those options? As I have pointed out,
>> "Engineers" vs. "Craftsman" is not the best way to describe the
>> dichotomy. As you have pointed out, "Profession" vs "Craft" may not be
>> ideal either. What are the best words?
>
> Couldn't resist: "Joe McHacker" vs "A craftsman"?
>
:-)
I like your terms better than the preceding ones, but it would be
useful to have some that are more diplomatic.
> Anyway, one thought is just "showing the world" what we are talking
> about, instead of trying to explain.
>
> If our ways are so much better - then the industry will notice. So
> let's continue discussing, and share things like the better way to
> interview people which was discussed not so long ago on this list
> (pair programming something instead of asking 'geeky questions').
>
Lol. Yeah, you invited me here to discuss the topic that I brought up,
and we've worked a ways afield.
Problem solving is an important part of the software craft. And,
formal problem solving is theoretically useful. However, while
understanding if a problem is NP-complete or NP-easy is a useful
skill, and it may help me to determine what the first test should be,
It doesn't help me write the test and then implement a simple
solution.
That is the problem I have with traditional "software engineering",
and the problems that are presented on programming tests. Assuming
that I know what that test is, can I write it? And can I make it pass?
And can I do so simply? And can I keep such a solution simple as my
understanding of the domain evolves and I am forced to incorporate
more complex ideas? Etc.
Jeff Dickey
> (unfortunately massive snip of very interesting how-did-I-get-here post)
>
> Getting back to software: the only analogue to the above that I have
> encountered in software is Test Driven Development. In TDD I can 1)
> create a model that can be validated 2) create a working system and
> validate it against that model 3) adjust both the model and the
> implementation until I have a system that I am reasonably sure will do
> what I want it to do and behave in a predictable way.
>
> So, a "Software Engineer" if he is anything like a "Hard Engineer"
> must have TDD as the central practice of his work. If he does this,
> then the two disciplines are somewhat comparable.
>
> (rest of original conversation snipped for brevity)
Adam,
I'd agree that TDD /has/ to be a "central practice", in a similar way to the
way that, say, statistical analysis is a central practice of the process
engineer. It's necessary - but not in and of itself sufficient. The nasty
thing about TDD is that while it proves that you understand your
implementation and that your implementation meets your (known) expectations,
there can still be a very real risk that you've, in effect, built the wrong
product (i.e., something not fit for the (customer-)intended use). Other
aspects of various methods, including Agile as a whole, act to mitigate that
risk - but they're still craftwork; basic practices that get adjusted and
force-fit into a situation without really having proactive control over the
process and progress of the project. (Your uncle was an experienced man who
understood that even "proper" engineering disciplines, like EE, still had
some craft elements associated with them - if "you don't find out until
you've tried it", it's not part of the CBOK - and should it be?)
Thanks for sharing, and putting up with my own blathering here and on-blog.
Jeff
--
Jeff Dickey http://archlever.blogspot.com
Gmail: dicke...@gmail.com
Email: jdi...@seven-sigma.com
Phone/SMS: +65 8333 4403
Skype: jeff_dickey
LinkedIn: jdickey
Yahoo! IM: jeff_dickey
MSN IM: jeff_...@hotmail.com (for IM only, not for email, please)
ICQ: 8053918
QQ: 30302349
GnuPG key: (for jdi...@seven-sigma.com)
Markus Knittig
> That is the problem I have with traditional "software engineering",
> and the problems that are presented on programming tests. Assuming
> that I know what that test is, can I write it? And can I make it pass?
> And can I do so simply? And can I keep such a solution simple as my
> understanding of the domain evolves and I am forced to incorporate
> more complex ideas? Etc.
What's you definition of "traditional software engineering"? Because I
don't think software engineering is only theoretical. At least I didn't
learn it that way...
Best reagrds,
Markus
Jeff Dickey
of a largely self-regulating society with standards for entry and continued
membership and with enforced codes of conduct and ethics; said society is
the beneficiary (if you will) of a legal requirement that all who practice
the art or science with which the society is concerned must be members in
good standing of the society."
That seems to be a rough thumbnail sketch of how the professions of law,
accounting, medicine and "real engineering" (P. Eng.) are set up. I can see
a lot of value in /software practitioners/ aiming for that, but I think
herding autistic cats would be easier than getting a lot of the 'hacker
superhero coder' types to get on board. (But then, drawing a public
distinction between that type of possibly-employed para-amateur and
professionals meeting the above definition would be helpful for all
concerned.)
--
Jeff Dickey http://archlever.blogspot.com
Email: jdi...@seven-sigma.com
Gmail: dicke...@gmail.com
Phone/SMS: +65 8333 4403
Skype: jeff_dickey
LinkedIn: jdickey
Yahoo! IM: jeff_dickey
MSN IM: jeff_...@hotmail.com (for IM only, not for email, please)
ICQ: 8053918
QQ: 30302349
GnuPG key: (for jdi...@seven-sigma.com)
Fingerprint D367 FB97 4E59 BEC0 8EBC D8E3 3BD4 7D4C DFE0 6488
Valid 01/07/2009 to 31/12/2009
Download from http://tr.im/qqQa
On 24/8/09 10:35 , "Steve Hayes" <steve...@cogentconsulting.com.au>
wrote:
David White
For a few years I was officially a professional engineer (via Mechanical Engineering). It was not a pleasant experience, as I was not in any of the recognised categories, or projects.
I struggle to see how the software industry can become professional, in the sense that potential customers can distinguish between craftsmen and "cowboys" -- apart from some system based on Reputation.
david
Jeff Dickey
Agree with you about ‘software developers getting sued’; that’s not going to happen as long as big companies with well-paid lawyers and lobbyists can hide behind click-wrap licenses. I’m afraid it’s going to take a SERIES of major, clearly software-induced disasters (with concomitant loss of First World lives) before that has the proverbial snowball’s chance of happening. I have found that profoundly depressing for a long time.
The point I was really trying to make is that we NEED that mechanism for potential customers to ‘distinguish between craftsmen and “cowboys.’” We really have two options: first, as a craft and would-be profession, we can make that happen ourselves, using visibly (from the outside) objective criteria and transparent processes, or we can wait until defective code obviously and inescapably kills a few thousand people – at which time the system will be imposed on us, from the outside, by people proud of the fact that they know less than nothing about what we do, how we do it and why, and thereby create a “fix” that creates a larger, more severe problem than the one being “solved”.
Doing things right is rarely easy. But it really is the only choice we’ve got.
Jeff
Dave Hoover
good blog post to me.
Joel Helbling
partly, in the fact that those professions are older and well
established. What constitutes "professionalism" in a lawyer is very
highly defined, with specific strictures attending specific actions.
What constitutes "professionalism" for a programmer (in the minds of
most people you could ask) is something vague, like, "courteous,
smart, and avoids the most controversial kind of T-shirt on casual
Friday." Those other professions have built their codex's over
centuries. We've been mucking about with computers in earnest for
roughly fifty years.
Another problem with defining professionalism for programmers arises
from the question of cohesion. Programmers cohere together in after-
hours social gatherings aimed at improving our skills, exposing
ourselves to new ideas, etc. This is excellent. But from a business
value standpoint, it pales next to the importance of intellectual
cohesion with the various members of the domain knowledge pool at the
place where we work during the day. Don't get me wrong, TDD and other
aspects of craftsmanship are a vital development in the realm of
software production: I'm convinced they are the way forward for us.
But at the same time, we must recognize that TDD matters less to our
business clients than does our understanding of the domain in which
they work. They may come to recognize the important role of agile, but
remember that even so, to them agile is just a better tool to get done
the really interesting work at hand. This is as it should be: the
agile manifesto itself bears out this point.
My point is that while we certainly cohere as programming
professionals, we work, day in and day out, in the activity of
modeling business entities and processes. Domain knowledge,
fundamentally, is our business. As a thought experiment, suppose there
were no computers? The work we do would fall into the form of devising
faster, more accurate methods of (manual) calculation or of designing
better, more efficient analog processes. In other words, if you remove
the thing we (programmers) all share in common, it becomes apparent
that what's left is domain expertise.
That is why the dying breed of hacker superheros cowboys is taking so
long to disappear. It's not just that they are stubborn iconoclasts,
rebels without an agile clue. Generally you will find those hacker
types firmly ensconced in an organization which unshakably believes
that their hacker knows their domain inside and out. They wouldn't
dream of drop-kicking their superhero because above all that is
untried and untested, they want somebody who knows their problem
domain.
Consequently, if we want to define what professionalism means for
programmers, it seems to me we must at least give a nod to the
discipline of swift and sure-footed apprehension of all the many
domains in which computers can be applied to good effect. But frankly,
if you want my opinion, fifty years is a youngish span of time for
forming up the ranks of the new stonecutters guild. We still haven't
made an adequate case for agile methods. To put it into medical
parlance, a good many of us "doctors" are still prescribing blood
letting, and too many of us fail to wash our hands before surgery.
What I'm saying is this: rather than focusing on "here's what we are,
and what they're not", shouldn't we expend our effort on persuading
those who are not to become what we are also striving to be? Let's
change the world of software development, not by codifying an existing
set of standards, but by pursuing and exciting others to pursue the
best modes of software development. And at fifty years in, let's be
humble and admit that the odds are that many of the best practices in
the software profession haven't even been devised yet. Let's teach
more than preach.
> Agree with you about Œsoftware developers getting sued¹; that¹s not going to
> hide behind click-wrap licenses. I¹m afraid it¹s going to take a SERIES of
> major, clearly software-induced disasters (with concomitant loss of First
> World lives) before that has the proverbial snowball¹s chance of happening.
> I have found that profoundly depressing for a long time.
>
> The point I was really trying to make is that we NEED that mechanism for
> make that happen ourselves, using visibly (from the outside) objective
> criteria and transparent processes, or we can wait until defective code
> obviously and inescapably kills a few thousand people at which time the
> system will be imposed on us, from the outside, by people proud of the fact
> that they know less than nothing about what we do, how we do it and why, and
> thereby create a ³fix² that creates a larger, more severe problem than the
> one being ³solved².
>
> Doing things right is rarely easy. But it really is the only choice we¹ve
> got.
>
> Jeff
>
>
> > When software developers start getting sued for application failures with
> > mortal or financial consequences, then the pressure will increase in this
> > direction.
>
> > For a few years I was officially a professional engineer (via Mechanical
> > Engineering). It was not a pleasant experience, as I was not in any of the
> > recognised categories, or projects.
>
> > I struggle to see how the software industry can become professional, in the
> > sense that potential customers can distinguish between craftsmen and "cowboys"
> > -- apart from some system based on Reputation.
>
> > david
>
> >> To me, "profession" (and to a large degree "professional") denote "a member
> >> of a largely self-regulating society with standards for entry and continued
> >> membership and with enforced codes of conduct and ethics; said society is
> >> the beneficiary (if you will) of a legal requirement that all who practice
> >> the art or science with which the society is concerned must be members in
> >> good standing of the society."
>
> >> That seems to be a rough thumbnail sketch of how the professions of law,
> >> accounting, medicine and "real engineering" (P. Eng.) are set up. I can see
> >> a lot of value in /software practitioners/ aiming for that, but I think
> >> herding autistic cats would be easier than getting a lot of the 'hacker
> >> superhero coder' types to get on board. (But then, drawing a public
> >> distinction between that type of possibly-employed para-amateur and
> >> professionals meeting the above definition would be helpful for all
> >> concerned.)
>
> >> --
> >> Jeff Dickeyhttp://archlever.blogspot.com
> >> Gmail: dickeyj...@gmail.com
> >> Skype: jeff_dickey
> >> LinkedIn: jdickey
> >> Yahoo! IM: jeff_dickey
> >> ICQ: 8053918
> >> QQ: 30302349
> >> GnuPG key: (for jdic...@seven-sigma.com)
> >> Valid 01/07/2009 to 31/12/2009
> >> Download from http://tr.im/qqQa
>
kelly french
For a few years I was officially a professional engineer (via Mechanical Engineering). It was not a pleasant experience, as I was not in any of the recognised categories, or projects.
David White
I see the same trajectory being followed in the "software engineering" space, even in my city newspaper today:
http://www.nzherald.co.nz/opinion/news/article.cfm?c_id=466&objectid=10593105&pnum=0
To be fair, my research work did not legally require that I become a Professional Engineer. (It was a self-improvement and recognition thing.) And perhaps the same is true in software. My projects are not multi-million dollars in scope.