Gets Things Done

This is not a complete, clean, clear, prescriptive article that's been polished. It's a collection of observations. You may not agree with it, but can I suggest that people try to be constructive rather than simply pick holes in it. Picking holes is probably easy. Being constructive will be more useful in the longer term.

I haven't signed this because although I've written in the first person, it's not something I care about owning. It's something I want to contribute.

As an experiment, can I ask that people try not to discuss and try not to use ThreadMode. Try to start with and maintain DocumentMode. In particular, don't take things as absolute statements that must always be true everywhere and at all times. Try taking them as statements of general utility but which may have exceptions.

Thanks.

PS: I can see now that this page is really two. The first part is actually about being constructive and producing pages of value rather than ThreadMess arguments. The second is about the value of getting things done. I'm going to leave things as they stand for now and see if anyone else wants to be constructive.

In his GuerrillaGuideToInterviewing, JoelSpolsky says that at Fog Creek Software they have just two criteria for hiring. The candidate has to:

Be Smart
Get Things Done

I'm pretty sure this is an over-simplification, but let's just take it as a guideline.

The second of these has struck a real chord with me. It relates strongly to the XP idea of doing exactly and only the next highest priority, and not doing extra work, even if you think it might/will be useful in the future. It says, Get it done. Get it done now, efficiently and effectively.

Sometimes the fastest way to get things done is a hack. Sometimes it's inelegant, nasty, and long-term unmaintainable. Fine, because the next job after this is always "Clean it up."

XP seems to me to be a way of ensuring this attitude is the driving force, while at the same time ensuring that the "Clean it up" job is never forgotten or postponed.

Someone with a "Gets Things Done!" attitude is essential. Business is about delivering value, yesterday, if not sooner. Getting things done is vital, literally. The life of the business depends on it.

Probably the alternative to "Get Things Done" that I commonly see is "Get Things Started". This tendency leads to lots of stubs, dead page links and pages, and semi-functional features. The goal often seems to be to demonstrate how much we could do if just given a little more time. I have become an advocate of "Get Things Done" and repeatedly emphasize that I want one thing completed and not a dozen things partially working.

If you think that the reverse sometimes applies, and that if you show various partially-working features then you may be able to charge for completing some of them, you are wrong. In that case what you are doing is defining the "thing to be done" to be a demonstration versions of features. Again, emphasising the target as Get Things Done and defining "things" in line with your requirements makes it clear that getting things done is the purpose and the point.

Less-experienced staff still need to Get Things Done. Make sure the things you set them are within their ability and expand their experience.

Having moved more into project management than direct programming, I find that often the more-experienced staff has the most difficulty with Get Things Done. Tying Get Things Done to Iterative Development, an underlying skill is the ability to heavily decompose a problem into a series of accomplishable tasks. One of the skills brought by more-experienced staff members is the ability to see the broader implications of a problem or change. The difficulty arises in convincing some to implement the broad change as a series of small changes without implying lack of confidence in their ability to implement the big picture change.