"Crafting the details" to me evokes hours spent filling in the little
gaps and cleaning up, while rethinking the whole thing over and over
again. Hours when few lines of code get written, yet the overall
quality and understanding improve dramatically. I was thinking how
much I value and do it...
"Software craftsmanship is when we spend at least 20% of the project-
time crafting the details."
How does it sound?
Julio (aka LudovicoVan)
Julio P. Di Egidio
Software Analyst Programmer
=BUSINESS AND SCIENTIFIC=
=SOFTWARE DEVELOPMENT=
http://julio.diegidio.name
On 14 Apr, 09:47, LudovicoVan <ju...@diegidio.name> wrote:
> Hello craftsmen,
> "Crafting the details" to me evokes hours spent filling in the little
> gaps and cleaning up, while rethinking the whole thing over and over
> again. Hours when few lines of code get written, yet the overall
> quality and understanding improve dramatically. I was thinking how
> much I value and do it...
> "Software craftsmanship is when we spend at least 20% of the project-
> time crafting the details."
> How does it sound?
Sorry, I have forgot to mention that I have linked to this discussion
from my blog:
>> "Crafting the details" to me evokes hours spent filling in the little >> gaps and cleaning up, while rethinking the whole thing over and over >> again. Hours when few lines of code get written, yet the overall >> quality and understanding improve dramatically. I was thinking how >> much I value and do it...
>> "Software craftsmanship is when we spend at least 20% of the project- >> time crafting the details."
>> How does it sound?
> Sorry, I have forgot to mention that I have linked to this discussion > from my blog:
I fear this plays straight into the hands of the detractors who'll claim we spend needless hours doing needless refactoring instead of getting features done.
Of course, well crafted code is easier to add to and maintain, but that is not the prevalent thought these days. Slow down to go fast is not something the average project manager groks. -- Curtis Cooley curtis.coo...@gmail.com =============== Once a programmer had a problem. He thought he could solve it with a regular expression. Now he has two problems.
On Thu, Apr 16, 2009 at 11:45 AM, Curtis Cooley <curtis.coo...@gmail.com>wrote:
> Of course, well crafted code is easier to add to and maintain, but > that is not the prevalent thought these days. Slow down to go fast is > not something the average project manager groks.
I hear you and I agree with you that there is a definite concern here: hopefully the craft can be maintained in the realm of actual projects, with concrete restrictions and limitations. One of them is that we can't go off on a quest for the Perfect Code for months, or years, and never deliver the product.
I truly believe that Business Value ought to drive the process. [Note: That doesn't mean that the Quest for the Perfect Code shouldn't be attempted at all, but that's another topic]
All of that being said (I think of it as the "Pragmatic Clause" in my mind), I wonder if the fact that "the average project manager" doesn't seem to grok "Slow Down to Go fast" is something we should simply accept as-is, or something we should try and change.
Changing other people's opinion is always tricky, but my question is not "how can we make them get it?". Rather "Is it part of our craft to make them get it?" I ask, because it seems to me there's some similarity between this and the question discussed on this list before, about developers that don't 'get' the idea of a Software Craftsmanship and whether the Craftsmen should actively try to convince/convert them or not.
On 16 Apr, 18:02, Francesco Rizzi <francesco.ri...@gmail.com> wrote:
> On Thu, Apr 16, 2009 at 11:45 AM, Curtis Cooley <curtis.coo...@gmail.com>wrote:
> > Of course, well crafted code is easier to add to and maintain, but
> > that is not the prevalent thought these days. Slow down to go fast is
> > not something the average project manager groks.
Absolutely. Indeed a significant side of the problem is that decisions
about software are not taken where the competence is.
> I hear you and I agree with you that there is a definite concern here:
> hopefully the craft can be maintained in the realm of actual projects, with
> concrete restrictions and limitations. One of them is that we can't go off
> on a quest for the Perfect Code for months, or years, and never deliver the
> product.
=== Software craftsmanship is when we spend at least 20% of the
project-
time crafting the details, but never more than 50% (past the 50% it
just makes no sense). ===
That is as condensed as a slogan, but the numbers are precise. Of
course, in practice, it is a complex balance, so complex that we
cannot get to terms with the layman. We should be given requirements,
not tasks: problems to solve, not things to do. Those who are driving
the process are not those who are competent in it, and since bulding
software is the most complex engineering that there is, you have an
entire industry building lowest quality contraptions at the highest
possible cost.
> I truly believe that Business Value ought to drive the process.
> [Note: That doesn't mean that the Quest for the Perfect Code shouldn't be
> attempted at all, but that's another topic]
> On Thu, Apr 16, 2009 at 11:45 AM, Curtis Cooley <curtis.coo...@gmail.com>wrote:
>> Of course, well crafted code is easier to add to and maintain, but >> that is not the prevalent thought these days. Slow down to go fast is >> not something the average project manager groks.
> I hear you and I agree with you that there is a definite concern here: > hopefully the craft can be maintained in the realm of actual projects, with > concrete restrictions and limitations. One of them is that we can't go off > on a quest for the Perfect Code for months, or years, and never deliver the > product.
> I truly believe that Business Value ought to drive the process. > [Note: That doesn't mean that the Quest for the Perfect Code shouldn't be > attempted at all, but that's another topic]
<Insert Applause>
> All of that being said (I think of it as the "Pragmatic Clause" in my > mind), I wonder if the fact that "the average project manager" doesn't seem > to grok "Slow Down to Go fast" is something we should simply accept as-is, > or something we should try and change.
I think if we lead by example good things will happen ***slowly***. If managers see that the code that we've written rarely breaks and when it does the bugs are shallow then eventually they start to accept the importance of craftsmanship.
Changing other people's opinion is always tricky, but my question is not
> "how can we make them get it?". Rather "Is it part of our craft to make them > get it?" > I ask, because it seems to me there's some similarity between this and the > question discussed on this list before, about developers that don't 'get' > the idea of a Software Craftsmanship and whether the Craftsmen should > actively try to convince/convert them or not.
Its the usual problem. Why should they want to change. Not because we argued them to death - that usually has the contrary affect. We have to start asking them what their problems are. Keep asking the right questions and help direct their thinking in the right direction and eventually they will see it for themselves. Its a lot faster just to tell someone that craftsmanship is great/important. Its a lot more effective and long lasting if you help them get there themselves.
> On Thu, Apr 16, 2009 at 1:02 PM, Francesco Rizzi
> <francesco.ri...@gmail.com>wrote:
> > On Thu, Apr 16, 2009 at 11:45 AM, Curtis Cooley <curtis.coo...@gmail.com>wrote:
> >> Of course, well crafted code is easier to add to and maintain, but
> >> that is not the prevalent thought these days. Slow down to go fast is
> >> not something the average project manager groks.
> > I hear you and I agree with you that there is a definite concern here:
> > hopefully the craft can be maintained in the realm of actual projects, with
> > concrete restrictions and limitations. One of them is that we can't go off
> > on a quest for the Perfect Code for months, or years, and never deliver the
> > product.
> > I truly believe that Business Value ought to drive the process.
> > [Note: That doesn't mean that the Quest for the Perfect Code shouldn't be
> > attempted at all, but that's another topic]
> <Insert Applause>
> > All of that being said (I think of it as the "Pragmatic Clause" in my
> > mind), I wonder if the fact that "the average project manager" doesn't seem
> > to grok "Slow Down to Go fast" is something we should simply accept as-is,
> > or something we should try and change.
> I think if we lead by example good things will happen ***slowly***. If
> managers see that the code that we've written rarely breaks and when it does
> the bugs are shallow then eventually they start to accept the importance of
> craftsmanship.
> Changing other people's opinion is always tricky, but my question is not
> > "how can we make them get it?". Rather "Is it part of our craft to make them
> > get it?"
> > I ask, because it seems to me there's some similarity between this and the
> > question discussed on this list before, about developers that don't 'get'
> > the idea of a Software Craftsmanship and whether the Craftsmen should
> > actively try to convince/convert them or not.
> Its the usual problem. Why should they want to change.
I for one don't get it. The *developers* need to change?
> Not because we argued
> them to death - that usually has the contrary affect. We have to start
> asking them what their problems are.
That software managers, on the most, haven't got a clue.
> Keep asking the right questions and
> help direct their thinking in the right direction and eventually they
> will see it for themselves.
Pardon?
> Its a lot faster just to tell someone that craftsmanship is great/important.
> Its a lot more effective and long lasting if you help them get there
> themselves.
On Thu, Apr 16, 2009 at 4:05 PM, LudovicoVan <ju...@diegidio.name> wrote: > > Its the usual problem. Why should they want to change.
> I for one don't get it. The *developers* need to change?
No I was asking why would the managers want to change their beliefs.
> > Not because we argued > > them to death - that usually has the contrary affect. We have to start > > asking them what their problems are.
> That software managers, on the most, haven't got a clue.
First of all I don't agree with that statement, but even I did we still have to deal with them.
> > Keep asking the right questions and > > help direct their thinking in the right direction and eventually they > > will see it for themselves.
> Pardon?
> > Its a lot faster just to tell someone that craftsmanship is > great/important. > > Its a lot more effective and long lasting if you help them get there > > themselves.
> They *are* there.
My whole point is that telling and arguing are a great way to get people's backs up against a wall. Far more effective in the long run is to guide their thinking - by asking questions. Much more difficult but in the end more effective.
> My whole point is that telling and arguing are a great way to get people's > backs up against a wall. Far more effective in the long run is to guide > their thinking - by asking questions. Much more difficult but in the end > more effective.
On 16 Apr, 21:23, Mark Levison <m...@mlevison.com> wrote:
> On Thu, Apr 16, 2009 at 4:05 PM, LudovicoVan <ju...@diegidio.name> wrote:
> > > Its the usual problem. Why should they want to change.
> > I for one don't get it. The *developers* need to change?
> No I was asking why would the managers want to change their beliefs.
> > > Not because we argued
> > > them to death - that usually has the contrary affect. We have to start
> > > asking them what their problems are.
> > That software managers, on the most, haven't got a clue.
> First of all I don't agree with that statement, but even I did we still have
> to deal with them.
Why should we do such a thing? This may be where we need to start a
change in perspective. There is no such conflict. If you -say- go to a
farm where they build aeroplanes, the guy in charge of production
comes from an engineering background, and project management (and not
only) is a sub-function. Only in the software arena we have the guys
in charge of production come from management and, in this inversion of
roles, the eternal struggle for an impossible fast-food.
We need an industrial perspective... and speak only to the general
management. In fact, it is well known that any re-engineering effort
must start and be supported from the top. Re-engineering software
production is no exception.
On Thu, Apr 16, 2009 at 9:40 PM, Mark Levison <m...@mlevison.com> wrote:
> On Thu, Apr 16, 2009 at 1:02 PM, Francesco Rizzi <francesco.ri...@gmail.com>
> wrote:
>> On Thu, Apr 16, 2009 at 11:45 AM, Curtis Cooley <curtis.coo...@gmail.com>
>> wrote:
>>> Of course, well crafted code is easier to add to and maintain, but
>>> that is not the prevalent thought these days. Slow down to go fast is
>>> not something the average project manager groks.
>> I hear you and I agree with you that there is a definite concern here:
>> hopefully the craft can be maintained in the realm of actual projects, with
>> concrete restrictions and limitations. One of them is that we can't go off
>> on a quest for the Perfect Code for months, or years, and never deliver the
>> product.
>> I truly believe that Business Value ought to drive the process.
>> [Note: That doesn't mean that the Quest for the Perfect Code shouldn't be
>> attempted at all, but that's another topic]
> <Insert Applause>
>> All of that being said (I think of it as the "Pragmatic Clause" in my
>> mind), I wonder if the fact that "the average project manager" doesn't seem
>> to grok "Slow Down to Go fast" is something we should simply accept as-is,
>> or something we should try and change.
> I think if we lead by example good things will happen ***slowly***. If
> managers see that the code that we've written rarely breaks and when it does
> the bugs are shallow then eventually they start to accept the importance of
> craftsmanship.
Managers. They view time as a roadmap with versions at certain dates
and lots of man-hours in between (that's what I see when I look over
their sholders).
They might care about how long a certain feature takes to implement,
because it's a piece they need to fit into their schedule puzzle. But
do their care enough to argue with developers about how long things
take to implement? If we need to put out a fire, then maybe yes, but
usually they don't in my experience.
I estimate what I do and implement the way I do, and things take the
time things take. If it takes too much time, we cut the scope. Quality
and my work practices are only up for discussion if they have
noticably *worsened* - which, incidently, is the only way they will be
noticed anyway.
IMO, when managers grok that programmers estimate their own work, then
there's little need to argue whether they grok things like "Slow Down
to Go fast."
>> Changing other people's opinion is always tricky, but my question is not
>> "how can we make them get it?". Rather "Is it part of our craft to make them
>> get it?"
>> I ask, because it seems to me there's some similarity between this and the
>> question discussed on this list before, about developers that don't 'get'
>> the idea of a Software Craftsmanship and whether the Craftsmen should
>> actively try to convince/convert them or not.
> Its the usual problem. Why should they want to change. Not because we argued
> them to death - that usually has the contrary affect. We have to start
> asking them what their problems are. Keep asking the right questions and
> help direct their thinking in the right direction and eventually they will
> see it for themselves.
> Its a lot faster just to tell someone that craftsmanship is great/important.
> Its a lot more effective and long lasting if you help them get there
> themselves.
On 17 Apr, 10:36, Christian Vest Hansen <karmazi...@gmail.com> wrote:
> IMO, when managers grok that programmers estimate their own work, then
> there's little need to argue whether they grok things like "Slow Down
> to Go fast."
When our manager comes back with a "list of things to do" (!), that he
asks for how long will it take or not, the software process is already
compromised. In fact, the inversion of roles has happened long before:
we have a non-technical manager handling the key and most delicate
phase of the entire process: eliciting and analysing requirements (!),
while Analysis proper is banned from the technical office.
|
