Martin Fowler
Posts: 1573
Nickname: mfowler
Registered: Nov, 2002
|
Martin Fowler is an author and loud mouth on software development
|
|
|
|
PreferDesignSkills
|
Posted: Jan 16, 2008 9:55 PM
|
|
|
This post originated from an RSS feed registered with Agile Buzz
by Martin Fowler.
|
Original Post: PreferDesignSkills
Feed Title: Martin Fowler's Bliki
Feed URL: http://martinfowler.com/feed.atom
Feed Description: A cross between a blog and wiki of my partly-formed ideas on software development
|
Latest Agile Buzz Posts
Latest Agile Buzz Posts by Martin Fowler
Latest Posts From Martin Fowler's Bliki
|
|
<p><b>NOTE: if you are still reading this feed, I should remind you that THIS FEED IS NO LONGER ACTIVELY MAINTAINED. Please go to <a href = "http://martinfowler.com/bliki/RssFeeds.html">http://martinfowler.com/bliki/RssFeeds.html</a> for information on my current active feeds.</b></p>
<table>
<tr>
<td style = 'font-size: larger; font-style: bold'><a href = 'http://martinfowler.com/bliki/PreferDesignSkills.html'>PreferDesignSkills</a></td>
<TD valign = 'bottom' width = '15%'><a href = 'http://martinfowler.com/bliki/agile.html'>agile</a></TD>
<TD valign = 'bottom' width = '20%'><b>18 January 2008</b></TD>
<TD valign = 'bottom' width = '10%'><a href = 'http://technorati.com/search/http://martinfowler.com/bliki/PreferDesignSkills.html'>Reactions</a></TD>
</tr>
<tr>
<td colspan = '4'>
<p></p>
<p>Imagine a hiring situation. There's two candidates both with a few
years of experience. In the blue corner we have someone with good
broad design skills in the style of design that you favor (in my case
that would be things like DRY, judicious use of patterns, TDD,
communicative code etc, but the actual list isn't important - just
that it's what you favor). However she knows nothing of the particular
platform technology that you're using. In the red corner we have
someone who has little knowledge (or interest) in those issues, but
knows your platform really well - edge cases in the language, what
libraries are available, fingers move naturally over the
tools. Assume all else about them is equal (which it never is except for
thought experiments like this) and that your team doesn't have any
gaping holes that this candidate might fill. Which one would you
prefer?</p><p>My answer is simple, I'd take the one in the with broad design
skills. I've always held the view that a good programmer should be
able to pick up a new platform relatively quickly. Learning basic
design aesthetics is both harder and carries over better to new
platforms. Good design practices that matter in Java are equally
valuable in .NET. Not being familiar with the platform does slow you
down (how do I get a literal class name in C# again?), but producing
well designed code is what really makes a difference.</p><p>Broad design skills aren't completely portable. Java and .NET are
mostly equivalent as languages - moving to Ruby, however, changes
more. Moving to a significantly different beast, like functional
languages, is a bigger shift. In any case, you can't just blindly
replicate all design habits in a new environment. But if you're aware
of the new world, an awful lot does carry over.</p><p>We've seen this principle prove itself at ThoughtWorks. In our
early days with Java, we found the skills experienced developers had
learned in Forte gave us excellent instincts for working with Java. We
moved away early from the EJB-dominant thinking, and I think it was
experience with other platforms that guided us. We saw it even more
strongly with .NET. Time and again we saw that good developers with a
Java background were rapidly more effective than those with a longer
.NET or Microsoft background who lacked those skills. The difference
was visible in weeks, not months (and sometimes days).</p><p>At the moment we see this shift most notably in Ruby. We've had
quite the run of Ruby projects this year, and often we turn to people
with long experience in curly-brace languages to fill the need. Again
we've seen the value that broad design skills gives us.</p><p>It's not always a sure thing. I have seen cases where someone
experienced in another platform just doesn't desire to get in and
learn the new one. Desire to learn is a necessary component here - I'd take
the single platform specialist if he wanted to learn broad design and
the broad designer didn't want to learn the new platform. It's also
essential to have someone on the team who knows the platform well.</p><p>I'd say most people at ThoughtWorks prefer design skills over
platform knowledge. Many clients don't share that point of view -
which can lead to some difficult pragmatic and ethical choices.</p><p>What happens if you have someone you want to bring onto the team
with strong design skills and no platform background - yet the client
insists on at least two years experience on the platform. In your
professional judgment, the broad candidate is going to be more
productive than anyone else available. You need to be honest with your
client, but on the other hand he is paying you for your professional
judgment. Does this change if the client has given you responsibility
for delivery of the project?</p><p>For us these questions are more charged because there is a
financial interest involved. If we add a ThoughtWorker to a team, then
we bill for that person. If a client hires a platform specialist
contractor, we don't get that income. For many people this is a
crucial fact in the situation, yet I expect our project managers are
wise enough to know that the risk of adding the wrong person is much
more important than one billable income. </p><p>Consider another case where you're open with the client and the
client demands a reduced rate for the broad design person due to her
lack of platform knowledge as she'll be learning on the job. You're
sure that she, despite that lack, will be more productive than the
competing platform expert due to those design skills. Should you
accept a reduced rate? </p><p>It's the nature of our, and most other, professions that
you learn on the job. A platform specialist also has to learn broad
design skills if he's going to produce maintainable code. Here
it's important to remember that not just is it usually harder to learn
design than platforms, it's also less certain. Given a motivated
broad-designer, I can be pretty sure she'll pick up a platform in
time. But there's no guarantee the other way around. Some people are
good at learning details of a platform, but never figure out how to
write clear code.</p><p>I've talked here about broad design skills - and I do believe this
makes a difference on the technical axis. But there are other
dimensions of broadness too. Most risk in software projects lies in
the communication between businesspeople and programmers, so a
candidate who can communicate well with users brings a great deal to a
team. </p><p>A similar issue is knowledge of the problem domain. Often clients
want people who already know their business, yet are surprised when
someone rapidly gains enough understanding to be useful. I've long
held that it's the ability to collaborate with others which is central
here. By collaborating with a domain expert, or a platform expert,
someone with broad skills can be become effective very
quickly. Knowledge of other domains often introduces surprising
insights into a project and similarities often crop up in sup-rising
places. It's remarkable how often things like core accounting patterns
crop up in places that don't look like accounting on the surface. In
the end it's the ability to work with others, coupled with being a
fast learner, that is the critical skill.</p><p>I'm not dismissing deep platform knowledge here. In an ideal world
every team member would be excellent broad programmers with several
years platform experience, good familiarity with the problem domain,
and written similar systems at least twice before. But we all know how
far our world is from that ideal. You need some platform knowledge on
a team, and if it were a gap I would reach for the platform
specialist to fill it. But that doesn't alter my default position to
prefer broad design skills most of the time.</p><hr></hr></td>
</tr>
</table>
Read: PreferDesignSkills
|
|
Previous Topic
