...then someone might implement the feature for you. In surfing around, I recently found out about creating “subreddits”, which are subdomains of reddit.com. I learned this when I saw Joel Spolsky’s weblog had a “Discuss” link that submitted the item to joel.reddit.com instead of hosting comments on his own weblog. I think this is a good idea, so you’ll notice that I’ve done the same here. This is especially helpful, given that in order to add comments to this weblog, I either have to build the feature myself or migrate my content to TextPattern or one of its ilk.

The next time someone insists you need a doubtful feature, ask them to choose something more important first. By the time you get to the doubtful feature, you might have discovered that someone’s built it for you!

edit Discuss

The standard, universal data processing answer is “it depends”. Specifically, it depends on the ongoing participation of your stakeholders.

If the development team is demonstrating the application at the end of the iteration to the stakeholders, then that’s an anti-pattern. If you’re not getting any constructive criticism from the stakeholders about the demonstration, then the stakeholders are likely not engaged by the demonstration, and it’s a waste of time. If your stakeholders are engaged, then they’re likely giving a sizable amount of constructive criticism, the result of which is re-working a substantial number of stories in the next iteration. Of course, you could just be that good, but I haven’t met that team yet.

The last time I worked with a team in this situation, they held demonstrations once per iteration, which for them meant every two weeks. They expressed to me that they were not getting feedback soon enough, so I asked them whether they thought weekly demonstrations would work better. They did, they asked the stakeholders to make at least two people available every Friday afternoon, and that worked. After a while, they added a Wednesday morning demonstration just before lunch. The next step would be daily demonstrations, then finally continuous stakeholder participation. The secret was to sneak up on the daily demonstrations.

Rather than ask your stakeholder to go from hands-off to daily meetings, hold demonstrations once per iteration. When they point out how much feedback causes rework, suggest having a mid-iteration demonstration to avoid so much rework. You might be able to fix a small problem or two right in front of the stakeholders, and if you can, then do. (It looks impressive.) Once you’ve established that you can fix some problems without putting the stakeholders to sleep, they’re more likely to want to work directly with you. Each time they notice a demonstration leads to substantial rework, suggest doubling the frequency of the demonstrations. Eventually you’ll arrive at the right amount of stakeholder participation for your project. The key is to let your stakeholders notice the problem of not enough feedback, because if it’s their problem, they might look for solutions, but if it’s your problem, they’re less likely to care. If they can’t see it’s their problem, then look for subtle, non-destructive ways to make it their problem.

My goal is for a key stakeholder and the development team to demonstrate the product together to any and all interested parties. This is an important step towards the whole team approach to building software that I find so incredibly effective.

edit Discuss

I remember being a technical lead, believing that it was my job to make sure everything was doing correctly and as quickly as possible. The result was predictable: I made myself a bottleneck because I was afraid to delegate important tasks to other people, for fear that they’d do it poorly and have to redo it, or even simply because it would take me less time to do it than to explain to someone else how to do it. I know now that letting myself be a bottleneck is a bad idea, but I wasn’t able to explain why very well until just a moment ago when a long-awaited neural connection finally happened. I almost felt the crackle in my brain at the point of impact.

Tim Ottinger wrote about Sooner, Not Faster, which I describe to people frequently in my work as a consultant. My goal in teaching test-driven development is not to help programmers write code more quickly, but rather to help them deliver solid code sooner. The time-saving techniques include being clear about what to build before trying to build it (write a failing test first), building only what you need (write just enough code to pass the test), stopping when you’ve built enough (continue until you can’t think of more failing tests to write), and keeping the code clean as you go to avoid building up inventory of uncompleted necessary work (“clean the kitchen” refactoring). Not all these techniques involve thinking or typing more quickly. Some involve thinking more to type less and knowing what’s enough then stopping. In general, I help teams by focusing on how to deliver a satisfactory result sooner, no matter how fast or slow the individual tasks are completed.

Now I wish I’d thought that way as a technical lead. If I have a backlog of 10 tasks that take a total of 4 weeks to complete, but I could delegate some of those tasks to others, then even if they take 5 times as long as I do to complete those tasks, I could delegate any task up to 3 days in length and, as a group, we could be done in 3 weeks, even if we spend more total time working. The alternative is to keep those tasks for myself, then have the others do busywork to avoid looking idle. You might think this is a false alternative, but how many people on your team are working on its top three priorities, and how many are working on other things? The other things are busywork!

Had I thought this way, I could have benefited dramatically. More important work would have been completed, I’d have learned how to delegate effectively, and I would have felt (and probably now feel) less stress.

If only.

edit Discuss

It’s nice to see that nearly five years after I started writing JUnit Recipes, people continue to read and review it. I imagined it would have become obsolete by now, especially with the proliferation of Java 5, Java 6 and JUnit 4.

The review ends with “If you use JUnit as your test tool and if you do any of the ‘things’ covered in the contents list of recipes then I recommend getting hold of this book.” I appreciate it.

edit Discuss

An anonymous person at blog.isnotworking.com whose name I could not find on the site has written a short piece on helping teams avoid getting stuck arguing over different solutions to a given problem. It was inspired by my November/December 2007 article in IEEE Software Magazine.

http://blog.isnotworking.com/2008/03/quick-guideline-for-using.html

edit Discuss

I recently had the honor of speaking at the Emerging Technologies for the Enterprise Conference, where I renewed some friendships, made some new acquaintances, and spoke about something I enjoy: failures.

Last summer I debuted XP: My Greatest Misses 2000-2007, which became popular due to its honesty and directness. (See an example of the response to it.) I followed this theme of reflecting on failures to gather some mistakes I have seen people make as they make the transition from work group in chaos to agile team. It’s important to note that I didn’t talk about the five biggest mistakes, the five most common, nor the five most dangerous; but rather, simply about five mistakes that came to my head. As you’d expect, once I’d written my five in the notes, I found a number more, especially as I sat in my fellow presenters’ sessions. Even when they weren’t describing mistakes at all, they triggered a number of memories—so many that I could easily have written the 20 mistakes new agile teams make.

Please enjoy Five Mistakes New Agile Teams Make, and if you’d like me to visit your user group, please contact me at the prominently-displayed e-mail address on this site. You should also consider contacting the Agile Alliance to find out how to qualify for funding to bring out-of-town speakers to your user group or event.

edit Discuss

(From XKCD)

Should a class be a factory for itself?

edit Discuss

Another in the Enerjy TV series. This time, the question is “How do you believe McCabe Complexity helps programmers?”

edit Discuss

I have spent the last two days with Mary and Tom Poppendieck at one of their Practitioners Courses, and I find myself inspired. Among the interesting moments for me was a point at which I reached an unsettling notion: are we “too Western” to design software well?

I came to this question while watching course attendees talk about the problems in their organization. As they explored the flow of value through their IT organizations, I kept hearing about managers interrupting the flow and of centralized decision-makers as bottlenecks, when it occurred to me: I’ve heard about these problems in code before.

Specifically, I heard the word “manager” and my mind wandered towards thinking of Manager classes in a code base, rather than flesh-and-blood managers. In that wandering instant I saw a connection between the two kinds of managers: human managers have mostly commonly been trained over the last century to micro-manage, make important decisions and direct their people; and Manager classes do essentially the same thing in code. Now, while our ideas of management have changed in the past 50 years, mostly due to the work coming out of Toyota, we are still over-run by micro-managers whose effectiveness is limited.

It’s quite similar with code. In spite of the object-oriented design movement and the advance of test-driven development with its emphasis on simple design, procedural thinking dominates, even in code bases that use object-oriented languages. Most programmers approach code with Procedural Mind, even when they believe they want to design with objects. Even when I teach people how their can arrive at excellent designs by following four simple rules, Procedural Mind dominates.

So I wonder: given the parallels between tactical, command-and-control management and highly procedural code where important decisions are centralized in these Manager classes, and given that our most common human management style is a relic of western military thinking, and given that it perpetuates in part due to culturally-entrenched ideas about managing people, are Western programmers conditioned against excellent design? Are we mostly doomed to gather our code in Manager classes, rather than distribute responsibilities evenly and focus on object interaction?

Are those notions simply too Eastern for us?

edit Discuss

I use Backpack to help me change my habits for the better, and I wanted to share this little technique with you.

The programmer in me values version control systems because they allow me to keep an indefinite record of what I’ve done. If something goes wrong while I’m working, then I can go back to an old version of a file and continue working. This is why I use Mercurial every day.

The entrepreneur in me values off-site backups because if a fire destroys my office, then all I need is any computer and an internet connection and I can get back to work. This is why I use Amazon S3 every day.

The scanner in me values getting things done, because when commitments start to sneak up on me, I have my commitments, actions and priorities in one place, and I can get back on track. This is why I use OmniFocus every day.

What I’ve noticed, though, is that my tasks aren’t really getting done. For me, most tasks require building or changing some key assets. Sometimes that’s code, or expense receipts, or drafts of an article. It’s not good enough to write the article, I want to put it into version control and know it’s backed up off site. It’s natural for me to end a coding session by committing changes to Mercurial, but it’s not yet natural for me to end a non-coding work session the same way. I need to remind myself to do this.

Whenever I hear myself think or say, “I need to remind myself…” I immediately log in to Backpack, because it does such a great job of reminding me of things. Today, I added a reminder that reads

A task isn’t done until the assets are safe: under version control and backed up

I set the reminder for tomorrow, and every day after that, until the idea is burned into my brain and becomes second nature. I’m not sure how long that’ll take, but by this time next month, I should be able to switch that reminder to every month, just to make sure it doesn’t fall completely off my radar.

This is how Backpack helps me move away from bad habits and move towards better habits.

edit Discuss