Insights and outlooks on software development


On Process Workarounds

Saturday, March 27, 2010 by Thomas L

In product development in fairly large organizations, there are often rather strict development processes, which sometimes have to be worked around. All such Process Workarounds are evidence of a process that doesn’t fit the organization.

Let me give an example. How many times have you heard this conversation?

Project manager
- May 5th is our feature complete deadline, after that we won't change or create any new features.

- All right, then we'll do nothing than fixing bugs prep the release after that

Project manager
- Oh, but we still have a couple of changes to the functionality after that

- But didn't you just say we mustn't develop on features?

Project manager
- Oh yeah, let's file that as a bug!

- ...

The reason for the feature complete deadline is a common one in waterfall organizations; there is a lot of fear in the organization about (the previously promised) deadlines and thus the project manager has to promise to his/her steering committee that there won't be any changes to the current feature set. This self-imposed limit to the feature set is then worked around by filing changes as bugs.

In this situation I can fully understand the need to have deadlines; it’s very demanding to come to the lean development process where there is flow between the producer and the consumer of a module. However, it’s the workaround that bothers me. Either the change is performed, or it isn’t.

To the developers in this situation, my only advice is to learn to say No. When a process workaround is performed, it’s done by people, and people are the ones who can stop it.

To any project manager in this situation, my advice is to reflect on the why's of filing this as a bug, and the consequences. If you really need the changed feature, you definitely need to be able to sell the change to the steering committee. If you can't do this, the feature should probably not be implemented. Additionally, by filing the feature as a bug, you poison the defect rate measurements.

On BDD for web applications at ScanDevConf 2010

by Thomas L

The second of two posts on my Scandinavian Developer Conference presentations. (See the first here.)

Like the first one, this too is designed to be viewed together with some live demonstrations (in this case, cucumber + webrat executing the requirements against a Wicket Java web app).

On Ruby for C#-ers at ScanDevConf 2010

by Thomas L

As I’ve said on Twitter, I’ve done two presentations on the Scandinavian Developer Conference in Gothenburg. As promised (although a tad bit late), this is the first of the presentations; my presentation on Ruby for C#-ers.

The presentation is designed to view together with some demos; those aren’t posted here.