Panel on SC at SPA

0 views
Skip to first unread message

John Daniels

unread,
Jan 23, 2010, 3:18:08 AM1/23/10
to software_cr...@googlegroups.com, j...@syntropy.co.uk
Hi,

I'm hoping to run a panel discussion on software craftsmanship as part
of the SPA conference in London in May (the evening of Tue May 18 to
be precise). I intend to have David Harvey, who is giving the anti-SC
talk at QCon that Jason mentioned recently, on the panel.

Is there anyone on this list who would like to be on the panel? If so,
please contact me privately. I'd like a range of views, including, if
possible, someone who wants to defend strongly the guild analogy.

Thanks,

--John

John Daniels
www.syntropy.co.uk

Adewale Oshineye

unread,
Jan 23, 2010, 5:58:01 AM1/23/10
to software_cr...@googlegroups.com
Hi John,
I'd like to be on the panel. I'm not a strong proponent of the guild
analogy but I do believe that the notion of software development as a
craft is very valuable.
Dave Hoover and I spent 4.5 years researching this material for our
book so I can speak knowledgeably about the ideas behind craftsmanship
e.g. tacit knowledge; the importance of the focus on individual skill;
situated learning; deliberate practice; learning in public;
communities of practice and the limitations of existing approaches.

> --
> You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
> To post to this group, send email to software_cr...@googlegroups.com.
> To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
>
>

Corey Haines

unread,
Jan 24, 2010, 12:31:10 PM1/24/10
to software_craftsmanship
I doubt that I'll be there then, although I'd love to be on it if I am there.

I'd recommend talking to the guys down at eden development, Enrique
Comba and Chris Parsons. They have a fairly serious involvement in
some SC activities, so they'd be good people to include.

-Corey

> --
> You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
> To post to this group, send email to software_cr...@googlegroups.com.
> To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
>
>

--
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines

John Daniels

unread,
Jan 27, 2010, 5:50:33 PM1/27/10
to software_cr...@googlegroups.com, j...@syntropy.co.uk
Hi,

I'd like to thank everyone who has contacted me. A great pool of
talent. It will take me a few days to get the details sorted but I
will get back to each of you as soon as I can. Please be aware,
though, that space on the panel will be limited and I won't be able to
take you all.

--John

====
Original message
From: John Daniels <j...@syntropy.co.uk>
Date: 23 January 2010
Time: 8:18:08 AM
Subject: [SC] Panel on SC at SPA
----
Hi,

Thanks,

--John

John Daniels
www.syntropy.co.uk

--

Corey Haines

unread,
Jan 27, 2010, 5:57:48 PM1/27/10
to software_craftsmanship
John,

Looking at the schedule of Nordic Ruby Conference (May 21-23), I think
I could figure out how to have a layover in London for this. If you
are interested in considering me for the panel, I would love to see if
we can work it out.

Of course, you've had a lot of responses, I'm sure. :)

-Corey

--

Michael Feathers

unread,
Jan 27, 2010, 5:58:16 PM1/27/10
to software_cr...@googlegroups.com
John,

I wouldn't mind being on the panel. I do have a reframing position:
craftsmanship, as articulated, is too programmer-centric. The future
belongs to UX designers and we're coming along for a ride.

Michael

Adewale Oshineye

unread,
Jan 27, 2010, 6:22:48 PM1/27/10
to software_cr...@googlegroups.com
2010/1/27 Michael Feathers <michael....@gmail.com>:

> John,
>
> I wouldn't mind being on the panel.  I do have a reframing position:
> craftsmanship, as articulated, is too programmer-centric.  The future
> belongs to UX designers and we're coming along for a ride.
>
> Michael
Could you talk more about this reframing? What makes UX different from
any other skills that a software craftsman could acquire from reading
books and working with a set of skilled practitioners over the course
of time? Why do UX designers own the future?

Dion Stewart

unread,
Jan 27, 2010, 9:05:26 PM1/27/10
to software_cr...@googlegroups.com
+1 on the current craftsmanship movement being too programer-centric.

Dion

On Jan 27, 2010, at 5:58 PM, Michael Feathers <michael....@gmail.com

Adewale Oshineye

unread,
Jan 28, 2010, 3:18:16 AM1/28/10
to software_cr...@googlegroups.com
Dion,
What do you mean by this? Are you saying that SC should be more about
project management, UX or/and some other roles in software
development?

Trying to be all things to all people was one of the things that lead
the Agile movement astray and I'm quite comfortable with the idea that
Software Craftsmanship isn't for everybody. I'm just as comfortable
with the idea that Python/Java/C++/etc isn't the right tool for
everybody.

2010/1/28 Dion Stewart <dion.s...@visi.com>:

Esko Luontola

unread,
Jan 28, 2010, 5:17:44 AM1/28/10
to software_craftsmanship
On Jan 28, 10:18 am, Adewale Oshineye <adew...@gmail.com> wrote:
> What do you mean by this? Are you saying that SC should be more about
> project management, UX or/and some other roles in software
> development?

As said by Alan Cooper in an interview, in software development there
are four kinds of design:

1. What is the problem?
2. What is the solution?
3. How do be build it?
4. Building it.

The first two are what user interface designers are best at. The last
two are what programmers are best at.

Quoted from http://www.infoq.com/interviews/Interaction-Design-Alan-Cooper
after 19 min:

"However, there are very different flavors of design in the world of
software. One of them is the design of the problem. Most programmers
know that to be a given, then there is the design of the solution,
mainly we know what the problem is, now how do we solve it? Then there
is a third design problem which is how do we build it? And there is a
forth design problem which is building it. Now in the world of
software, the problem is moot, generally the design of the problem is
moot.

It is usually some business thing that is ended up from high that, by
the way, doesn't work, but that's the status quo anti. Design problem
number two of what would the product be and how will it behave, that's
what I do that's what I have been focused on and that's what I call
interaction design, the design of form and behavior: what does the
product do, who does it do it for, how does it behave? The next stage
of design is how do we construct it and I call that design
engineering, and the forth stage of design is construction
engineering.

Generally those last three phases are conflated and in the old battle
days we are done just under pressure by some random group of people
and usually the human facing side of it was given the leak of a
promise and then everybody as slaved over the design and engineering
aspects of it. Yet another wonderful thing about Agile is that by
being relentlessly self introspective, it exposes all the weaknesses
in the process. And one of the great weaknesses in the process is that
there is nobody figuring out what the problem is and what the solution
is. There is lots of good people figuring out how to build the
solution, and there is lots of people figuring out actually building
the solution."

(It's best to watch the whole interview.)

Corey Haines

unread,
Jan 28, 2010, 8:53:19 AM1/28/10
to software_craftsmanship
I'm with Adewale, I don't see a need to turn SC into a
be-everything-to-everyone. I don't believe it is intended to the the
entirety of a developer's persona or encompass all their thoughts.
And, it isn't even intended to be for everyone.

-Corey

--

Michael Feathers

unread,
Jan 28, 2010, 11:52:02 AM1/28/10
to software_cr...@googlegroups.com
Good insights. I like to be very direct on this one (and it's a
thought that I've heard a few other people mention):

There's no such thing as software requirements. It's all design.
Requirements are an artifact of a schism between people who write code
and people who don't. They are how people communicate across that
gulf. In actuality, every "requirement" is a design decision and you
can get incredible leverage by dropping particular "requirements." At
that point, you are actually doing product design. Historically, in
software, we haven't done that. Software development has been hard
enough that people have been happy to get any software at all even if
no real product design has happened and the software was driven by a
laundry list of requirements.

Michael

David Starr

unread,
Jan 28, 2010, 12:08:36 PM1/28/10
to software_cr...@googlegroups.com
That's why I call them "Desirements". This helps people truly understand the idea that desirements are written in a document. Requirements are expressed as tests.
--
David Starr
Guild 3 Software, Principal Craftsman
208.577.7000
guild3.com | Training: pluralsight.com
Reply all
Reply to author
Forward
0 new messages