FDD or DDD not BDUF

David Anderson's post about the roots of FDD started me off on a trip down memory lane: I fondly remember receiving the Coad Letter by email, hearing Peter Coad in person talking to the BCS about "Modelling in Colour", and being inspired by a "Better Software Faster" workshop run by Andy Carmichael. All of which probably makes it apparent that I believe in constructing models as an important part of a software development process.
Modelling has unfortunate "Big Design Up Front" connotations though, despite people like Scott Ambler and Eric Evans demonstrating that it doesn't have to be that way. These kind of models - the small-in-ambition ones that help us to turn stories into code via specific test cases - have remarkably similar characteristics to the programming languages described as "New Jersey style, not MIT/Stanford style" in The Rise of Worse Is Better: the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained.

Dysfunctional teams

I just came across a reference to the book "The five dysfunctions of a team". Lencioni's five dysfunctions are: absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results. In software development teams I think that lack of honest communication is also a common dysfunction - I say what I think you want to hear, or you choose not to hear what I want to say - though honesty itself hardly flourishes without trust and the ability to handle conflict.

Abundance vs. scarcity

Towards the bottom of a recent post about testers and developers working together, Brian Marick writes about the cultivatation of "a gift economy of the sort described by Marcel Mauss, one where a person's status depends on how much she gives to others." His observation struck a chord with me: a characteristic of the high performance teams I have seen is that they maintain a culture of abundance and optimism, despite facing the same challenges that lead to a culture of scarcity and fear in other teams. (Interestingly, I have probably seen some of the highest performing individuals in these other teams. I'm still undecided whether to believe that the teams performed less well overall "despite the Star Player" or "because of the Star Player".)

As a coach I know that I want to share with others some of what I know and enjoy about software development, and to demonstrate that such things can (and should) be shared.

Me and my persona(s)

"Agile / TDD / XP is all well and good but how does it fit with..."

A "but" I've heard a couple of times recently is "how does it fit with user-centred design". One way of approaching an answer is to look at customer tests (as JB Rainsberger does here). And another way that I find works well is to approach it via user stories: define stories in the format*

"As <a persona> I would like <feature> so that <goal is achieved> in order to <produce business value>"

and the scene is set for the fruitful discussion of personas, features, and goals.

*Not a format I came up with: it was passed on to me by TimMackinnon, Rachel Davies and Ivan Moore in their Connextra days...

Dads

Despite the strapline on my blog I haven't written much about being a dad. Maybe it's because being a dad is hard. (And it seems harder the more you care about your kids, your partner, your own parents-that-are-now-grandparents, and the kind of world you live in.) Or maybe it's because being a software-developing-dad is just too far out of the mainstream?
Several of my software development colleagues and ex-colleagues have started families of their own recently, and I wonder what kind of advice I might offer them, with the benefit of hindsight, now that both of my own kids are at school? What would I have wanted to know when I was in their situation?
I'll think on that and post a response later...

Engineering an ineffective team

It's unfortunately far to easy to engineer an ineffective software development team. How about these ways to start with...?

• Create an awful working environment... and prevent the team from changing it. (Don't know how to create an awful workspace? Use this handy list. You could make it: too hot, too cramped, too isolated from the team's customers, too loud, too dark, too busy, too rundown - preferably with furniture that is uneven, unsteady or falling apart, too obstructed by partitions and cubicles, lacking whiteboards, lacking shared space, or lacking necessary software / hardware / connectivity...)
• Give the team conflicting goals... and be adamant that you require all of them to be met
• Set meaningless deadlines... like slicing 30% off all the team's estimates "to set stretch targets"... and hold the team to those deadlines, no matter what happens in the meantime
• Or set a meaningful deadline... but make the team agree to complete more work before the deadline than they believe is possible
• Get upset if you ever see developers not "hard at work" (i.e. hunched over their keyboards)... especially if they're "wasting time" by talking to one another
• Track the effort spent by individual team members on each development task... and reward those who spend the least time on "their" tasks... regardless of the quality of the work they produce
• Ostracise members of the team who don't want to spend their weekends working to fix bugs... that they knew 6 weeks ago would be the result of the corners cut "because we don't have time to do it right this time"
• Insist that the team's software must conform with common architectural standards and guidelines... without allowing the team to discuss their ideas with any of the people who drew up the standards and guidelines
• Stick rigidly to the original plan of action that was drawn up when the project was conceived... no matter how much the business or technical environment alters. (You may of course revise the plan at any stage if the political environment alters.)
• Never - EVER - tell the team that they are doing a good job... instead keep them motivated by fear: the fear that they will be late, that they are useless because they are going to be late, and that they will lose their jobs because they are going to be late
• Persuade the team that they have no need to talk to anyone who will ever actually use the software they are creating (or in fact to talk to anyone who understands the business drivers behind the software project)... instead give them a pile of documentation to read (preferably written by another team that has since been disbanded)
• Perform all testing after the "development complete" milestone date... even if that milestone slips and the duration of "allowed testing time" is squeezed... Certainly don't provide any functional test data until after "development complete"
• Don't allow testers and developers to talk to each other to reach a common understanding of the customer's needs... and reward testers for the number of "defects" they raise, even if those defects are in fact just misunderstandings
• Leave all users out of any workshops, walk-throughs, or testing before the "user acceptance phase"... and then allow all their concerns to be raised as "critical defects" without effective prioritisation
• Ignore any arguments in favour of "non-standard" hardware or software... or "non-standard" programming languages... even if they might save time or money
• Make sure that the "framework" required by the application is completed before development of the application starts... and have the framework be developed or architected by people outside the application team

This is a deliberately contrarian response to Laurent Bossavit's original post on engineering effective teams. But it was fun to write it :-)

And / Or

Esther Derby's recent post about "but / and" reminds me of an "and / or" reframing I find useful. When I give myself a deadline to achieve several things and have high expectations of how much is possible, I often find that I slip into a frame of mind where I'm thinking like this:
success = completing this AND completing that AND completing the other thing AND...
failure = not completing this OR not completing that OR not completing the other thing OR...
When I'm thinking like this there's only one possible way to feel successful, and many ways to feel unsuccessful - even if there are factors outside my control that make completing a task impossible. When I catch myself doing this try to I reframe the situation* like this:
success = completing this OR completing that OR completing the other thing OR...
failure = not completing this AND not completing that AND not completing the other thing AND...
In this healthier frame of mind I can get on with tackling a mountain of work without the fear of failure hanging over me. Unsurprisingly I also work better when I'm not weighing myself down with excessive expectations.

* Obviously I have less control over other people's expectations of me or the deadlines that they set, but that doesn't prevent me from reframing my own point of view. If I don't meet someone else's over-ambitious target then reframing my point of view allows me to take pride in what I did achieve, and to also to consider (free of shame or guilt) whether the target I was aiming for was realistic or how I might achieve more in a future similar situation.

How much is too much?

The feed to Dave Astels' blog recently became my 100th BlogLines subscription. (I guess I should have added it a lot earlier, especially after he was nice enough to include XMLUnit in his book on TDD, but the last time I stumbled across the blog it had a ghost-town feel to it and my roving mouse finger moved on elsewhere.)
A hundred blog feeds feels like a lot - but is it really? Is there such a thing as too much reading? Will I get so distracted by other people's opinions that I start to ignore my own gut feel or experience? Or worse still, will I lose the capacity for any creative thinking of my own?! Watch this space, I guess...