Showing posts with label teams. Show all posts
Showing posts with label teams. Show all posts

05 October 2010

Duck Typing Developer Styles: 4 Ducks

Developers can be categorised along two orthogonal dimensions: coding-skills and design-skills. This post explains how to locate a developer according to this scheme, and describes how best to manage each development-style.

Tame Ducks are easy to manage, get on with the job, etc. They produce decent working code, but won't come up with the most innovative solutions. Great maintenance coders.

Wild Ducks are your innovators who will break new ground, but it's hard to get them to follow rules, comply with standards, etc. Give them the tough stuff to code.

Lame Ducks: deal with a Lame Duck by making Duck Sandwich. Sandwich the Lame Duck between a Wild Duck and a Tame Duck. They will either learn and gain competence, so becoming a Tame Duck in time, or they will Ship Out through fear of revealing their lack of knowledge.

QUACKS: talk a good project; strong tendency to bullshit their way through design by resorting to TLAs like SOA. XML and xDD. Deal with them by - again - making Duck Sandwich. The Wild Duck has exquisitely sensitive bullshit-detection capacity which, combined with their cultivated lack of tact and intolerance for freeloaders, will leave the Quack with no place to hide. The Tame Duck is there to back up the Wild Duck's assertions as to the Quack's actual performance. The Quack will almost certainly soon move on.

(Where do I fit in? ;-)

Credit: I first heard this Duck-Typing Scheme from an important mentor in my career, Nat Lunn, sometime around 1990, and so I must credit the whole story to him. Thanks, Nat!

03 August 2010

Measuring Progress in Software Development


I am about to take on the leadership of a new, still-in-formation developer team, on a project - the first of several - of critical importance to the client. This means that everything is up for negotiation: team structure, development methodology, coding styles, frameworks to be used,... everything!

Initially my role was confined to that of Consulting Architect, but, by force of circumstance, has evolved to Architect and Team Leader pro tem for a few months while the client gets their dev team properly resourced and settled-in. Naturally I'm trying to help that along as best I can.


The client initially planned to use a BDUF (Big Design Up Front), waterfall approach to the project. The requirement is extremely well-known and quantified, in a very well understood business domain.

I have never believed in my tummy that BDUF is in any sense realistically or practically achievable, though, even long before the Agile Movement tore the idea to shreds. It is impossible to foresee every detailed design element, no matter how hard you work at it. On the other hand, some Agile proponents seem to say that no up-front design is necessary... Perhaps my hearing is playing tricks with me. I cannot agree with them, either.

So call me a proponent of SDUF: Some Design Up Front.

And on the Process front, I don't think there's a lot to argue about when we contrast a waterfall/sequential process with an agile/incremental process. For me the critical difference lies in how we report and feed-back progress and how frequently we do this. And what we do about the feedback we receive - how flexibly we accommodate direction changes from customers, business sponsors, unit-tests,... to change the still-in-the-pipeline development and requirements without completely trashing the budget and time-to-market constraints. An also-essential aspect of agile development is "to reflect on what has gone before, and to adjust what we do to make
things better." [Ron Jeffries]

Waterfall possibly still does have a place in some circumstances. I can't honestly say that I've ever actually been party to such circumstances, though I've certainly been on projects where some of our business partners thought they needed hard, contractual milestones with no going back. (In reality we always "went back" anyway, when necessary, after some amount of renegotiation.)


A very greenfield situation, this, which some people would immediately call a "wonderful opportunity", but which I very much see as a "two-edged weapon"...

The question that has been most on my mind is, "What should we measure?"

I am a very firm believer in the old saw, "Tell me how you Measure me, and I'll tell you how I Behave."

Measure a sales-person by the number of sales, and you'll get a high order volume of the easiest-to-sell products, regardless of whether they represent the best margins or quality-of-business for the company. Measure the same sales-person by margin-value of product, and you'd best hope that your high-margin products are ones that lots of people want to buy. Measure them by the number of sales calls they make and you'll have lots of calls that don't result in sales.

Here is where I believe that some Scrum proponents are going wrong... We take Features and break them up into Tasks - the developers' unit-of-work. And they measure Task completions using a burn-down chart of Tasks completed versus time. This can easily result in a situation where many Tasks are being completed, but not so many Features. A situation where Features reach an 80%-complete state, and then get stuck, for any of a variety of reasons, all of which amount to "Nobody wants to complete those Tasks" because they're boring,... or they're "just" test Tasks,... or they're difficult (because not well understood), or...

The solution is really simple. Just measure Feature completion instead of Task completion. Then the team only gets rewarded when Features or User Stories get completed. We only get beer and Pizza when the Business gets value.

But is this enough? Can we go further? Is there a way to tie developer reward directly to delivered Business Value?

In the situation I'm headed into, Business Value should be pretty easy to quantify: The product to be built is one that will directly generate revenue for the company, so we can very easily quantify how much Business Value the software is generating. (Successful completion of the product will also deliver a huge  strategic Business Value by enabling new revenue streams, but that's also quite easy to quantify, and, indeed, is the prime reason the client is taking on this quite substantial investment in the first place...)

Are there ways to close the loop? To feed-back to the dev team on how much business-value their efforts are generating without making money too much of an up-front issue? Then, too, I have a reservation: Developers can have notoriously short memories, and the sort of value we're talking about here is only delivered on longer time-scales... Maybe it's good to have both long-time-loop feedbacks as long as we also have the short-timespan feedback in place as well... Waterfall's failures are largely a result of too little feedback taking too much time for us to correct project course when we need to.

My instinct is that moving towards a continuous deployment process (the step beyond continuous integration) might help to shorten this feedback loop, which is completely the point of "agile" thinking, but I'm still not really clear on how we might implement it.

12 April 2010

Cogito Ergo Wiki

For your entertainment and delectation, I offer up a small write-up in which I muse about complexity and simplicity in the tools we choose to inflict upon our project partners.

A short excerpt:
I think that WikiMedia is a relatively terrible thing to inflict upon unsuspecting project partners who are already stressed out by the weird idea that they should contribute documentation to your project, that they might actually be asked to actually write something
Wiki Wondering: Share and enjoy.

10 January 2010

How Do Development Managers Screw Up?

Here's a question, much on my mind:

What is the single most important thing that Development Managers do, or fail to do, or pay insufficient attention to, that create a friction in the delivery of working software?

Answers in comments (or email if you don't want to publicly reveal details) please!

By "Development Manager" I don't just mean those people who have those words in their job title, but I mean any person who is responsible for tasking development teams - large or small - and ensuring the delivery of software systems by their developers. Sometimes they are called Project Managers, sometimes - in small entrepreneurial startups - they are the Boss Of The Whole Gig. The point is that they are the interface between the business stakeholders and the technical people who do the development and implementation work.

25 April 2008


"The Ark was built by one man.
The Titanic was built by a team of professionals."

26 April 2007

Netbeans Collab Modules

Installed the Netbeans Developer-Collaboration Module yesterday, and gave it a trial-run together with Jason.  Wow! 

The chat-client is pretty standard; not much to say there.  The only thing we both disliked was that you have to use "Control-Enter" (or "Alt-N") to send your text rather than plain "Enter".  Probably we could reconfigure the keybindings somewhere...

But!  The ability to drag a file, folder, Java package or, indeed, entire project into the collab area, and then have both people (and presumably everybody in the chat session) simultaneously able to edit the same files, seeing each other's edits live,... pretty cool.

The real OhMiGod Factor was when Jason hit "compile" on the shared file, to have it compile on my PC (since the original file came from there,) with both of us seeing the compile output.  Very, very cool!

We were speculating about some alternative form of development setup where all the code (and docs, web-pages, and other project components) get stored in a wiki-like (auto-versioned, of course) system so that its not just one developer's PC that gets to do the work...  Just daydreaming, really.  For now.

If you're working in Java, C/C++ or Ruby, and you work with other faraway developers (even occasionally -- the dowload is only a couple of meg) you owe it to yourself to explore the Netbeans Collab stuff.  I am pretty sure that what we're seeing now is only the start.

27 February 2007

The last 10% takes 90% of the Time

I guess its easy when it's a larger project.  There's a Project Manager, there are Account Managers, there are User Representatives.  They may or may not be actually doing much.  But they're there, pushing for completion.

When it's only two developers working together, it's hard!  How do you keep the focus, keep the energy going, especially on a short-term project that you have zero interest in...?
Related Posts Plugin for WordPress, Blogger...