Should we/can we convince programmers to care about their craft?
tieTYT
ones that don't know what DRY stands for. The ones that pump out
features as fast as they pump out bugs. What can we do about these
people? If there was a book on convincing them to produce quality
code, I'd buy it in a second.
But on the other hand, I'm not these people's managers and I haven't
heard of any success stories unless the person has an interest in
improving in the first place. What's your take on this?
Aaron Weiker
Dotan N.
i'm coming from academy right now, where i see a concerning trend of people that 'fall between the chairs' deciding on what kind of profession they want to acquire. they always select software engineering just because the paycheck is the biggest. i personally know several that not only have no interest but loved the maths, hate the programming.
i think programming is firstly about the thrive for knowledge, not for nothing we replace almost everything we know every 3-5 years. you want to be willing to do that for the rest of your life. and that's (accumulating new knowledge) more than fine with me.
Markus Gaertner
look like. This includes for example showing tdd at coding dojos and prepared
katas or just pairing with a junior colleague on a difficult issue. I think
practically convincing colleagues by showing them the capabilities of our craft
is the only chance to deal with it. Forcing them by management or sending them
out to some trainings might work, sometimes, but to get a real buy-in you need
working practices just as you need working software.
Regards
Markus Gärtner
Chris Hedgate
fact, I am sort of on a tour of the larger conferences in Sweden
delivering this message. My main points are that 1) caring about code,
writing great code, clean code, matters, and that 2) trying to train
our colleagues/employees to do this, to take this attitude, is a dead
end. I refer a lot to a psychology article called Unskilled & Unaware
Of It: How Difficulties in Recognizing One's Own Incompetence Lead to
Inflated Self-Assessments (http://www.apa.org/journals/features/psp7761121.pdf
) and also to a learning model called the Consciuous Competence
Learning Model (http://en.wikipedia.org/wiki/Four_stages_of_competence).
In short, the message is that incompetent people (such as "programmers
who don't have an interest [...] to produce quality code") are not
only incompetent (at producing quality code), they are also completely
unaware of their incompetence. Since they believe that they are doing
the right thing, they have no reason to want to listen and learn from
any teaching we could try and give them. What we need to do is inspire
them, make them aware of their incompetencies and of the benefits of
writing clean code.
I think reflecting on work is the most important factor to make this
happen. So, while management cannot convince people to care about
code, they can however set the tone and goals using tools such as
slack, pair programming, code reviews, katas, brown bag sessions etc.
As craftsmen trying to help novices (incompetent clean coders), we
must focus our attention on creating awareness, before we try to teach
them the techniques. If we can succeed in this they will want to
learn, which means they are already on their way.
/Chris
PS. Incompetent is a strong word. I use it here, in the same way as in
the above referenced article, to distinguish between those who are
competent at a skill (writing clean code), and those who are not. DS.
Matthew Segvich
this the other day. Jim, please chime in if I missed something. We
said that there are 3 groups.
A. Those new to the profession. They can be "convinced" through
apprenticeship.
B. Those who believe there is a better way. They don't need
convincing. They just need support. That's where groups, mentors,
books, etc. can help.
C. Those that don't have any interest. I'd probably argue this group
can be split in two. One side is those that think their way is
right. Who knows? It might be working for them. However, you'll
never convince them. To me that's the group you shouldn't waste
effort on. If we do our jobs right, that group will eventually die
out or more likely, get considerably smaller. The other side is the
group that realizes if they don't change, they'll be out of a job. So
though they may not believe, they're doing it out of necessity. Again,
the assumption here is we've done our job and have gotten enough
traction.
I would say we'd get more bang for our buck focusing on A and B. Yes,
it's organic growth. Which will probably take longer, but to me at
least, that's the most likely way we'll change the culture.
Matt
Dave Hoover
development organizations and have seen a common pattern. There is
usually a small minority of people who are genuinely interested in
improving themselves. And although I was a change agent, I didn't
actually change anything. I just identified the people who wanted to
change. I've never met anyone who could make a disinterested person
into an interested person. Maybe Uncle Bob has done it. I think your
best bet for handling disinterested people is to never, ever hire
them. Ever.
As harsh as it sounds, I want to put disinterested developers out of
business. I want development teams that are dedicated to
craftsmanship to replace disinterested teams. One of my biggest
clients fired their entire IT staff several years ago after years of
repeated failures. They've slowly hired some internal IT people
again, but continue to outsource all of their application development
to my team. Are we more expensive than an internal development team?
Well, we get paid more per pair-hour than what they would have paid
their people. But the business value we deliver per dollar is *very*
hard to compete with. And we literally deliver it *every day* and
talk with the business stakeholders *every day*. And they have become
very happy customers.
I think that Pete McBreen was right when he said: "Today we have more
developers than needed, but we have a shortage of good developers."
With today's tools and technologies, a passionate developer with solid
communications skills and 10 years of experience can do the work of
literally dozens of disinterested developers. This ratio is only
going to get bigger as our tools, technologies, techniques, and
skillsets continue to improve.
The last sentence of my latest blog post sums up my thoughts on
disinterested developers:
http://nuts.redsquirrel.com/post/83937889/responding-to-craftsmanship-quality-dogma-and
Also, Jay Fields had some insights into what he calls NNPPs:
http://blog.jayfields.com/2009/01/cost-of-net-negative-producing.html
Best,
Dave Hoover
//obtiva: Agility applied. Software delivered.
hotfus...@gmail.com
I'm sorry to mar it with the following nitpick but just can't not do it: the correct word in this context is "uninterested", not "disinterested ". "Disinterested" means unbiased, impartial.
But the post's content really was great!
Al
Sent via BlackBerry by AT&T
-----Original Message-----
From: Dave Hoover <dave....@gmail.com>
Date: Fri, 6 Mar 2009 22:13:05
To: <software_cr...@googlegroups.com>
Subject: Re: Should we/can we convince programmers to care about their craft?
Dave Hoover
Markus Gaertner
hotfus...@gmail.com
Date: Sat, 7 Mar 2009 05:22:55
Michael Hunger
of the trickiest fields in psychology.
The minimum requirement there is: they should want to change :)
Michael
Eric Smith
Enrique Comba Riepenhausen
while I tend to agree with your statement I guess we should not take
it to the extreme either. Many people are just afraid of doing things
in 'new' ways and therefore procrastinate instead of trying to
improve. I usually call that victimism (the world is so bad, poor me
that has to live here).
I think it is important, that we, as change agents, try to make people
see, lead by example, that there are good ways of doing things and
that these are not so difficult to follow at the end. If you like what
you do (i.e. your job) you can change for the better with a little
help from a helping hand.
But if these people are really not willing to change there is nothing
to do, so I would share wholeheartedly your point of view.
Enrique
2009/3/8 Eric Smith <payto...@gmail.com>:
Enrique Comba Riepenhausen
[@]: <eco...@gmail.com>
[w]: <http://www.nexwerk.com>
tieTYT
fix their mess. Perhaps you're in a position where you don't have to
deal with uncaring programmers, but I'm not. If I was, I wouldn't
care either :)
whatth...@gmail.com
Before I start, I want to congratulate everyone for the fantastic work
on this manifesto. The questions I ask below ( and in my next post)
are not mean to be a criticism but a genuine concern with the
scalability and success of this initiative.
I wish this movement grows beyond a group of experienced switched on
professionals and inspires the young people about to enter the job
market and even university students. I also wish this group is able to
be articulate the benefits of these values to business leaders, more
on this later.
A common complaint I hear from some of the senior developers/
architects/ community leaders (?craftsman?) I interact with, is that
they want to work most of the time with other senior leaders so that
they can brainstorm ideas and continue to develop their own skill set.
There is a certain frustration when they are asked to mentor highly
capable, motivated apprentices with little professional experience.
A pattern that I have identified time and time again is that some of
the brightest techies out there are actually not so keen to pair with
apprentices although they are religious followers of good practices
such as TDD, CI etc some even fallback to review build logs and re-
write ( by themselves) the code an apprentice spent the whole day
working.
Assuming that there are many keen capable apprentices, journeyman etc
( sorry I am still a little unclear on all these terms) out there
willing to embrace this manifesto and follow the guidance of the
community leaders, do you believe these same leaders are willing to
invest their time in mentoring the rest of the community?
How much are our leaders willing to invest in the community?
What is the right leverage on a SW development team?
How can we enable everyone to feel that they are growing?
thanks
On Mar 8, 6:26 pm, Enrique Comba Riepenhausen <eco...@gmail.com>
wrote:
>
> while I tend to agree with your statement I guess we should not take
> it to the extreme either. Many people are just afraid of doing things
> in 'new' ways and therefore procrastinate instead of trying to
> improve. I usually call that victimism (the world is so bad, poor me
> that has to live here).
>
> I think it is important, that we, as change agents, try to make people
> see, lead by example, that there are good ways of doing things and
> that these are not so difficult to follow at the end. If you like what
> you do (i.e. your job) you can change for the better with a little
> help from a helping hand.
>
> But if these people are really not willing to change there is nothing
> to do, so I would share wholeheartedly your point of view.
>
> Enrique
>
Adam Williams
> A common complaint I hear from some of the senior developers/
> architects/ community leaders (?craftsman?) I interact with, is that
> they want to work most of the time with other senior leaders so that
> they can brainstorm ideas and continue to develop their own skill set.
> There is a certain frustration when they are asked to mentor highly
> capable, motivated apprentices with little professional experience.
I would submit that this is a matter of maturity. Hopefully taking the
frustrated aside and restoring them to an understanding of the long
term value of investing in these 'highly capable, motivated
apprentices' will set things right.
> A pattern that I have identified time and time again is that some of
> the brightest techies out there are actually not so keen to pair with
> apprentices although they are religious followers of good practices
> such as TDD, CI etc some even fallback to review build logs and re-
> write ( by themselves) the code an apprentice spent the whole day
> working.
Again, I feel this is a matter of maturity. I have rewritten code an
apprentice has written, but I believe I am getting better about
waiting until there is a failure in that code. At that point,
rewriting may be necessary for a number reasons, though admittedly not
always in order to fix the squeaky wheel which brought the code to
attention.
I believe it was on this list where a discussion about being an
apprentice/master changes within the context of a particular skill.
That is, I may be a master at tech x, but an apprentice at tech y. You
can search for that discussion; I only want to recall it to say,
perhaps these 'brightest techies' are apprentice people builders.
> Assuming that there are many keen capable apprentices, journeyman etc
> ( sorry I am still a little unclear on all these terms) out there
> willing to embrace this manifesto and follow the guidance of the
> community leaders, do you believe these same leaders are willing to
> invest their time in mentoring the rest of the community?
Some will sign who only give these ideas lip service; there are some
great names to associate ourselves with on here. There are those here
who are willing to give up a great deal to mentor others.
> How much are our leaders willing to invest in the community?
> What is the right leverage on a SW development team?
> How can we enable everyone to feel that they are growing?
We must be willing to die to 'self' and recognize that we will fail,
and so will those around us. In our selflessness, we must be
interested in passing the baton to the next generation. That's a
start. Then we must be willing to do the hard part - tell the truth. I
hope I can mature more in this (and other things, too).
I don't believe that everyone can be an exceptional software developer
(the knack?). I do believe that everyone who wants to can grow, but
not without growing pains.
'Seven Laws of the Learner' does a decent job of illustrating how
important it is for the teacher and the student to willingly
participate in education. And remember, education isn't about knowing;
it's about being prepared and able to respond appropriately in the
situations we will face.
Fun stuff!
adam williams
Dave Hoover
<whatth...@gmail.com> wrote:
> I wish this movement grows beyond a group of experienced switched on
> professionals and inspires the young people about to enter the job
> market and even university students.
That is the exact demographic I am targeting with our in-progress
Apprenticeship Patterns book. The book is Ade's and my attempt to
provide guidance for newcomers to our field. The patterns are based
on our experiences, supplemented by dozens of interviews with current
and former apprentice-level people over the last 4 years. We are
currently looking for people to interview for our last round of
story-gathering.
> A common complaint I hear from some of the senior developers/
> architects/ community leaders (?craftsman?) I interact with, is that
> they want to work most of the time with other senior leaders so that
> they can brainstorm ideas and continue to develop their own skill set.
> There is a certain frustration when they are asked to mentor highly
> capable, motivated apprentices with little professional experience.
I can't imagine how mentoring a highly capable, motivated person could
be frustrating. I'm not saying it doesn't frustrate some people, but
to me, there are few greater joys in my work than watching an
apprentice acquire and then leverage knowledge for a customer. I
assert that one of the principles of Software Craftsmanship is that a
craftsman takes responsibility for passing on what s/he has learned.
> A pattern that I have identified time and time again is that some of
> the brightest techies out there are actually not so keen to pair with
> apprentices although they are religious followers of good practices
> such as TDD, CI etc some even fallback to review build logs and re-
> write ( by themselves) the code an apprentice spent the whole day
> working.
There certainly isn't going to 100% overlap between bright techies and
good mentors, but I believe that a craftsman needs to be both. And
that's fine. There's nothing wrong with being a bright techie who
isn't a craftsman.
> Assuming that there are many keen capable apprentices, journeyman etc
> ( sorry I am still a little unclear on all these terms) out there
> willing to embrace this manifesto and follow the guidance of the
> community leaders, do you believe these same leaders are willing to
> invest their time in mentoring the rest of the community?
Absolutely. Apprenticeship is one of pillars of craftsmanship focused
business like 8th Light and Obtiva.
> What is the right leverage on a SW development team?
We've found that our ideal team leverage is 1 apprentice + 2
"transitional" apprentice/journeymen + 1 experienced journeyman.
jamesl
craft' but instead focus our efforts on
educating the consumer. Educating the programmer is focusing on the
symptom rather than the cause.
While I do think craft is important and try to make my code clean and
maintainable I think the sad reality is
that "near enough is good enough" in almost all situations, and like
water most people take the path
of least resistance.
This reality is compounded by the fact there are typically departments
dedicated to maintaining or re-building, and
the real cost of craft vs little or no-craft is missed or negligible
in the scheme of other drivers.
Hopefully the following analogy won't screw up my argument/opinion,
but here goes ....
Imagine if each day a mechanic was servicing your car whenever you
were not using it and that the cost of a car included
this servicing, would you think cars were expensive? Would you know if
the car was a lemon, since it never appears to break
down when you are in it, or do you know the cost of the servicing
component?
We should not try to convince the programmers but try to convince the
consumers of the importance of 'craft'.
Rgs, James.
Lance Walton
is because software development teams have trained them to be this
way. Expectations are far too low, all around.
I had to phone up Sky a while ago because I was having trouble with my
set top box. While I was waiting in the queue, the music was
interrupted by an announcement every twenty seconds or so that said:
"Because your set top box is like a computer, you will need to reboot
it from time to time". I despair.
Regards,
Lance
-----
Lance Walton
http://www.stateofflow.com
http://homepage.mac.com/LanceWalton
Mark Nijhof
Dave Hoover
> We should not try to convince the programmers but try to convince the
> consumers of the importance of 'craft'.
The only way I know how to convince a consumer of my software about
the importance of 'craft' is to create software that exceeds their
expectations. Do I need to have a perfectly SOLID design and 100%
test coverage to do that? Nope. But it's going to be very difficult
to continue exceeding (their ever-changing) expectations release after
release if the software was crafted poorly. And there's a lot more to
exceeding their expectations than the code. Setting the correct
expectations in the beginning, and then communicating effectively as
the release approaches, and ultimately establishing a long-term,
trusting relationship is just as vital as doing the right thing
technically.
Eric Smith
you that trying to get them to care ends in the mental institution. You'll drive yourself crazy and
you'll get nowhere with them.
Now as for cleaning up their mess, crush them in competition doesn't just mean get the jobs they wouldn't
in a consulting sense. Consistently deliver better quality. Demonstrate to management why caring matters,
show continuously improving work. Get yourself in a position to choose your own team, so you don't have
to work with people who don't care.
If you work in a company that just doesn't care at the upper levels, and can't be convinced to care, then it might
be time for the "Get a new job" refactoring. It just doesn't pay to be surrounded by people who don't care, because
eventually you'll spend all your time cleaning up their messes and all your money on scotch.
jamesl
a differing priority as to how
much of their time they spend fighting to get quality increased.
Michael Hunger
very interesting and helpful paragraph:
Quote:
In my life as an architect, I find that the single thing which inhibits young pro-
fessionals, new students most severely, is their acceptance of standards that are too
low.If I ask a student whether her design is as good as Chartres, she often smiles
tolerantly at me as if to say, “Of course not, that isn’t what I am trying to do. . . . I
could never do that.”
Then, I express my disagreement, and tell her: “That standard must be our
standard. If you are going to be a builder, no other standard is worthwhile. That is
what I expect of myself in my own buildings, and it is what I expect of my stu-
dents.” Gradually, I show the students that they have a right to ask this of them-
selves, and must ask this of themselves. Once that level of standard is in their
minds, they will be able to figure out, for themselves, how to do better, how to
make something that is as profound as that.
Two things emanate from this changed standard. First, the work becomes
more fun. It is deeper, it never gets tiresome or boring, because one can never
really attain this standard. One’s work becomes a lifelong work, and one keeps
trying and trying. So it becomes very fulfilling, to live in the light of a goal like
this.
But secondly, it does change what people are trying to do. It takes away from
them the everyday, lower-level aspiration that is purely technical in nature, (and
which we have come to accept) and replaces it with something deep, which will
make a real difference to all of us that inhabit the earth.
That is what we must strive for. Not mediocrity.
Looking forward to QCon :)
Michael
Albert Chou
Steven Smith
Sometimes it's a matter of frustration because you must deal with
them via a client. If you own your own software company, you can fire
or not hire such folks. But if you're a trainer you'll get them in
your classes. If you're a consultant you'll find them at clients.
And if you're a developer in a large organization you'll inevitably
encounter them and need to work with/around/after them on the same
codebase. Thus, you cannot totally ignore their existence, and they
do often make your job more difficult. If there were some magic
bullet that would make them care, it would help you, them, the
company, and pretty much be a win all around. I don't know of any
such formula, unfortunately, but since finding something even
marginally effective would be a big win, it's worthy of discussion, I
think.
Steve
Steve Smith
http://SteveSmithBlog.com/
http://twitter.com/ardalis
Paul Pagel
I could not agree with you more. Setting the expectations of the
customer higher is a path towards moving everyone to a software
craftsmanship attitude. If customers stop accepting crappy software,
then people will start to have to pay attention to quality. There are
those of us who are actively engaged in quality on this list and in
the software craftsmanship community at large, but I don't want to
write off those that are not passionate or actively engaged in the
community as worthless developers. To me the goal is to not give them
a standard of acceptable behavior when developing software (Raising
the bar).
For example, I would no longer buy a cell phone that does not have
100% service. If I get NO bars, I start thinking "Wow, this is
amateur, I should call up my provider." There are certain standards
which you can not go back from. The health care industry is another
great example. If some advancement comes out in diagnosing an
illness, it becomes the standard you can't go back from.
As long as we are releasing for customers or employers high quality
applications, we are moving the users in the right direction. People
will not be OK with crap software if it wasn't so prevalent they
become immune to it. So, let's raise the bar by writing lots of good
code. We don't need to convince the developers who are not passionate
through quality arguments, but instead let the market for software say
"We won't spend money on poor software." If you have the choice of
writing high quality code and getting paid respectively or writing bad
code and getting paid respectively, what will you choose? What will
the dispassionate developer choose?
Paul Pagel
Dave Hoover
what you're describing. Here's an attempt:
"As software craftsman, we permanently alter our customer's definition
of software excellence"
Steven Smith
somehow able to empower customers to distinguish quality software from
not. Any ideas (perhaps a separate thread - sorry to hijack).
Steve
Enrique Comba Riepenhausen
I'm not sure if "permanently altering the definition of software
excellence" is a good thing at all. I mean, I understand what it means
to us, although if I try to see that sentence in a customers eyes I
can only read from it that we will do anything, even bad quality
software, if we ate asked to. Which I don't think we are among for here.
As software craftsmen we permanently enhance the quality of our
software to better serve our customers.
Not sure if that one is ok (just woke up and it's 6am ;) )
Cheers,
Enrique Comba Riepenhausen
Olof Bjarnason
> Hey Dave,
>
> I'm not sure if "permanently altering the definition of software
> excellence" is a good thing at all. I mean, I understand what it means
> to us, although if I try to see that sentence in a customers eyes I
> can only read from it that we will do anything, even bad quality
> software, if we ate asked to. Which I don't think we are among for here.
>
> As software craftsmen we permanently enhance the quality of our
> software to better serve our customers.
Min blogg:
http://olofb.wordpress.com
[My blog, in Swedish]
Dave Hoover
permanently altering our customer's definition of software excellence.
1) Ensure that the software functions as the customer expects and,
when it can be done at a negligible cost, even better than they
expected.
2) Write software that is actually soft. It should remain easy to
enhance and extend by any other experienced craftsman.
3) Explain to your customer why quality code means inexpensive enhancements.
I have used all of these approaches with my customers over the last 2
years and I believe they have helped change my customers' standards
for software excellence. That said, I certainly could have done much
better at times and taken more opportunities to educate.
Dave Hoover
On Tue, Mar 10, 2009 at 1:25 AM, Enrique Comba Riepenhausen
<eco...@gmail.com> wrote:
>
> Hey Dave,
>
> I'm not sure if "permanently altering the definition of software
> excellence" is a good thing at all. I mean, I understand what it means
> to us, although if I try to see that sentence in a customers eyes I
> can only read from it that we will do anything, even bad quality
> software, if we ate asked to. Which I don't think we are among for here.
I'm not seeing the problem. Looking at it from a customer's
perspective, I'm not sure how they could interpret it negatively.
There certainly are people out there that will write bad quality
software if they are asked to. And sometimes, like when you're
creating a prototype, bad quality software is acceptable. In this
case the goal is to learn and prove a concept, not create maintainable
software. We just wrote a Facebook/iPhone prototype for a customer
and didn't follow our usual development practices because we knew it
was a throwaway project.
> As software craftsmen we permanently enhance the quality of our
> software to better serve our customers.
I don't see how it's possible to permanently enhance the quality of
our software. Sorry to be so contrary.
Enrique Comba Riepenhausen
> I'm not seeing the problem. Looking at it from a customer's
> perspective, I'm not sure how they could interpret it negatively.
> There certainly are people out there that will write bad quality
> software if they are asked to. And sometimes, like when you're
> creating a prototype, bad quality software is acceptable. In this
> case the goal is to learn and prove a concept, not create maintainable
> software. We just wrote a Facebook/iPhone prototype for a customer
> and didn't follow our usual development practices because we knew it
> was a throwaway project.
Does that mean that you did that in a very low quality standard? Or
that you just did a spike/prototype using the best of your skills and
knowledge to do so?
If my customer pays me for doing a prototype, that is fine, I will do
it, not shipping the prototype, ever, but making a demo to him to
prove that the concept we came up with was fine.
> I don't see how it's possible to permanently enhance the quality of
> our software. Sorry to be so contrary.
I guess that comes from the teachings of Taiichi Ohno and the way he
changed the way Toyota works, thinks and breathes as a company;
seeking constant (aka permanent) improvement to work, better and more
efficient all the time.
I think that we can learn a lot form the Toyota Production System and
Lean (and no Lean is not only Kanban). The whole value system is
targeted for excellence and improving the way they work constantly, at
every level.
Maybe the choice of word 'permanently' was a poor one and I apologize
for not being a native english speaker (I will make sure I use the
build in dictionary more often ;) ).
You don't need to be sorry for being contrary, the more we filter out
our ideas and discuss them the easier it is to get an understanding.
And I don't think that anyone in this list is absolutely right or
wrong. We all have our points of view, our ideas, and our experiences
upon which we build our value system, and that is good as it is...
Cheers,
Bil Kleb
I have an upstream problem: Many of the people I work
with do not consider themselves programmers even though
they typically sit in front a computer 8 hours a day
coding. (They consider themselves scientists or engineers.)
Regards,
--
Bil Kleb
http://fun3d.larc.nasa.gov
http://twitter.com/bil_kleb
hotfus...@gmail.com
The computational physicists I worked with as a grad student didn't, but I think neither did they aspire to be great computer science types -- they had their hands full with physics and math.
One of the oldest ones didn't even seem to know that outside the small niche of numerical methods, floating point computation is not what computers spend the majority of their time doing.
Most probably had never heard of and certainly none used version control software, even though Sun and other Unix machines (including the Crays and massively parallel supercomputers of the day) were de rigueur.
But I think if someone had shown them relatively easy ways to get significant benefits from the accumulated knowledge of CS/programming, they would have appreciated that. I really don't think any of them intentionally wanted to remain in the relative Dark Ages of computing and programming.
Al
Sent via BlackBerry by AT&T
-----Original Message-----
From: Bil Kleb <Bil....@NASA.gov>
Date: Tue, 10 Mar 2009 07:41:55
To: <software_cr...@googlegroups.com>
Subject: Re: Should we/can we convince programmers to care about their craft?
Casey Charlton
hotfus...@gmail.com
Al
Sent via BlackBerry by AT&T
From: Casey Charlton
Date: Tue, 10 Mar 2009 12:09:12 +0000
Bil Kleb
> Bil, do they disdain programming/programmers?
Some do, and quite overtly. I felt it strongest
while visiting with some teams at NCAR on the occasion of
http://www.ucar.edu/sea/cmte/seminar/ancmt/sem20070301.jsp
> [..] they had their hands full with physics and math.
They often think so, but my experience has been the increase
in confidence and productivity that come from skilled programming
leaves *more* time for the physics and math.
> One of the oldest ones didn't even seem to know that
> outside the small niche of numerical methods, floating
> point computation is not what computers spend the majority
> of their time doing.
Unless you consider all the GPUs out there. :)
> Most probably had never heard of and certainly none
> used version control software,
I have found this to be true.
> But I think if someone had shown them relatively easy ways
> to get significant benefits from the accumulated knowledge
> of CS/programming, they would have appreciated that.
The problem is getting the horse /to/ the water, let alone
making them drink. In my limited experience lecturing on
this topic, they are generally moved slightly once you open
the door, but it is difficult to get some of the high and
mighty ones to even attend such a lecture.
> I really don't think any of them intentionally wanted to
> remain in the relative Dark Ages of computing and programming.
In my experience, some do. I have a phrase for them:
"aggressively incompetent," i.e., they are being aggressive
about their incompetence by failing to train themselves.
hotfus...@gmail.com
The issue of how to get exposure/awareness of what you're doing remains, though. Where I was as a grad student, office doors were almost always left wide open, so one could achieve "guerrilla marketing" by simply having a somewhat loud conversation in the hallway. <g> There was one young scientist who was known to be the local computer guru whom people went to on occasion for non-scientific computing advice; I think if he'd wanted to, he could've used that as a successful platform for broader education on such topics than he did.
Of course, the problem of creating such a situation where it doesn't exist remains; it's something marketers are good at, and it's probably worth stepping outside _our_ niche to learn what we can from them.
Al
Sent via BlackBerry by AT&T
-----Original Message-----
From: Bil Kleb <Bil....@NASA.gov>
Subject: Re: Should we/can we convince programmers to care about their craft?
Bil Kleb
> The same situation applies to a lot of mathematicians in banking ...
> they use Excel and similar "off the shelf" packages to
> provide solutions, or code really "poor" (by developer standards)
> C#/Java/C++, because it is just enough for what they need.
...and they often spend a painfully long time debugging their mess.
> They have no
> interest in going far beyond what gets their calculations and models
> run.
Even though without something like TDD/BDD, they often run
unverified code where here I'm defining "verification" as
the correct translation of math to code. This flies in the
face of the Scientific Method and mathematical formalism.
> Again they don't see themselves as developers, they see development
> languages as a way to express their models, not of value in themselves.
And in my experience, they spend too much time stumbling
around down the weeds producing irreproducible results.
With a bit of programming skills, they could spend their time
more wisely.
Curtis Cooley
Based on your reference to Lean and the Toyota Production System my
guess is the word you are looking for is 'continuously'. On primary
guiding principle behind the Toyota Production system was perfection
and the continuous effort to reach it. As a craftsman I think its
important to shoot for perfection even though we know nothing is
perfect. We cannot attain perfect quality, but we must make it the
goal.
If you are not shooting for bug free software, what are you shooting for?
--
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
> If you are not shooting for bug free software, what are you shooting for?
I am shooting to exceed my client's expectations.
Albert Chou
Bil Kleb
> I totally hear what you're saying and agree, but I would
> argue that a lecture is just about the worst possible approach.
Unfortunately, lecture and papers are the current modus operandi
of this particular group.
> I think a grass roots "proof by construction" demonstration
> of a better way of working would be better received.
Been working that since 1999 and have even managed to spin it
off to an aerospace engineering group at MIT.
> The issue of how to get exposure/awareness of what you're
> doing remains, though.
Yes, and tiresome.
> Of course, the problem of creating such a situation where it
> doesn't exist remains; it's something marketers are good at,
> and it's probably worth stepping outside _our_ niche to learn
> what we can from them.
My MBA minor was in marketing, so I've already done that to
some extent. Does reading Seth Godin's blog count? ;)
Regards,
--
Bil Kleb, PhD
http://fun3d.larc.nasa.gov
http://twitter.com/bil_kleb
Curtis Cooley
> Yes, I have encountered (and personally had <g>) that attitude. The
> programming is just the means to a "greater" end. An analogy is forming in
> my mind of the difference between master furniture makers and the lower
> skills required to nail together studs to frame houses. If the house is
> perceived as the only worthwhile goal, then excellence in driving each nail
> may not be valued (randomly reminded here of the "one stroke" nail driving
> scene from The Karate Kid -- a [stereo]typically Japanese study in focus on
> perfection). And further, if code is perceived like house framing to be the
> "under the skin/hood" stuff and thereby de-valued because it is not seen,
> then the uninterested attitude of the typical programmer can develop.
> Of course, what those who read and post here know is that the work can be
> easier/better if attention is paid and care taken with this stuff that
> others decline to value.
>
I just had a little epiphany reading this post:
Perhaps the whole construction metaphor is actually part of the problem.
Non-craftsman:
"The customer only cares that feature X got implemented, so if I cut
corners and hack in feature X then the customer is happy. The customer
never sees the framing anyway, so why does she care?"
The hole in the metaphor, besides the fact a crappy foundation leads
to a crappy house, is that in software we can continuously change the
foundation, and how we change that foundation determines how easily
feature Y goes in.
I'm reminded of Ward Cunningham's notion of "making room." When he
goes to add feature Y, he checks the code to see if it will easily
'accept' feature Y. If not, he refactors it until it does. This notion
of 'pre-refactoring' is currently under utilized and under emphasized.
Albert Chou
Albert Chou
Bil Kleb
> So what does your marketing education tell you? <g>
Become an ethnographer and learn to play golf.
Regards,
--
Bil
http://fun3d.larc.nasa.gov
http://twitter.com/bil_kleb
Lance Walton
mother is a piano teacher and, although she'd given up trying to teach
me (because I was a difficult bugger), she did advise me when I would
let her
I was obsessed with making sure there were no mistakes (in terms of
getting the notes right). One of the pieces of advice my mother gave
me was this: at this level of performance, the examiners simply expect
the notes to be correct and this concern will not even be on their
radar. What matters to them is the musicality of the performance.
In software development, we need to get past 'getting the notes right'
as the pinnacle of excellence, and focus on the music instead.
Regards,
Lance
P.S.
I failed my diploma.
Three times.
I'm a much better programmer than I am a pianist.
-----
Lance Walton
http://www.stateofflow.com
http://homepage.mac.com/LanceWalton