Why Bugs aren’t Features and Features aren’t bugs!

This week, I thought I’d talk about a frustration that often occurs from a failure to communicate between project “requestors” and the project “doers”.  In my industry, this most often comes in the form of a project manager submitting work to a programmer, but it could as easily apply to marketing departments, artists, or really any other job where the worker has to be a bit more creative.

Creative work isn’t as cut and dry as other types of work, the “idea” or “planning” person has thoughts in their brain, which they’re trying to get across to the creative team.  This communication is rarely perfect, especially as the person giving the work rarely 100% knows all of the cascading effects that the person “implementing” the idea is going to experience.

Ok, so we all know there is usually going to be some back and forth between the idea person and the person building the idea, then why does it matter whether the idea person calls the product “Wrong!”, “broken!”, “buggy!”, etc, instead of simply saying that there needs to be more work done?  The reason why, as I talk about in the video, is because you can’t get better if you don’t know where the source of the issues are coming from.

If the issues are coming from a failure to implement the project properly, then the developer might need more training.

If the issues are coming from a failure to plan properly, then the developer might need to ask more questions or the project planner might need to schedule more time for the planning of the project.

If you follow AGILE methodology (or at least “try” to follow it), then you probably understand the concept of “Fail Fast”, meaning that you want to get something out there, fail, learn from your mistakes, and get better.  AGILE is totally something that in my experience gets good results, I love it!  But as part of the retrospective phase, where we ask what went wrong and why, we can’t protect people’s feelings.  Everyone, at least for the duration of the retrospective, needs to put their ego aside, ask the tough questions, and figure out if they need to make changes to improve things, or if any issues have been reasonble or perhaps the cure would be worse than the disease.  These are all good things, and they all come from an understanding of what is actually going on, not just blaming the developer and not by shifting the blame to the project manager.  Isolate issues, improve them if they can be improved.

Isolate issues, improve them if they can be improved, and the core of this strategy is honesty.

Thanks everyone!  Share with me experiences, both good and bad, or give advice to people who might read this blog!

Richard Mathis

Author

Richard Mathis

Richard Mathis is a software architect and CTO of CHSI Technologies. When he isn't imagining new ways to help insurance companies run their business, he's writing, gaming, or performing. You can follow his meanderings on twitter.

Up Next

Related Posts