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.
> 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
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.
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.
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
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.
> 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,
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
Sent via BlackBerry by AT&T
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.
...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.
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.
I am shooting to exceed my client's expectations.
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
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.
Become an ethnographer and learn to play golf.
Regards,
--
Bil
http://fun3d.larc.nasa.gov
http://twitter.com/bil_kleb