Scott Bellware‘s recent post Mort or Elvis? A Question for a Bygone Era is more than a rant on the inadequacies of pigeon holing developers into roles created and propagated by a group of uninspired thinkers. This post captures the raw emotional frustration that many developers have with the current state of the industry. Heck Sam Gentile even called it the best post of the year.

For me, Scott’s message touched on ideas that are almost taboo to talk about. For instance, waterfall. I ran into it today at work. PM Boy wanted to enforce his waterfall schedule on the project’s tester and myself. He had no ability to appreciate that two or more interations that each included test and code was going to produce better and more thorough results. Instead he was stead fast and adamant that one batch of testing and two days of coding for fixing identified bugs was all that we would do. Luckily for me, and the success of the software, I give two shits about what he thinks and whether he knows it or not we will be having multiple iterations. Why should it be so difficult to broach a subject that is founded in the idea of providing a better product?

I think that the software development industry longs for the structure of a methodology. We developers work in logic and structure all day long and are most comfortable when we are working in it. Because of that comfort level we buy into the methodology and it’s structure with great gusto. We become religious zealots about the methodology and all of a sudden we’ve restricted our ability to be creative and to innovate.

It doesn’t matter which methodology you use, if you’ve bought into it as the silver bullet, you will be restricted.

I’m a firm believer that no one methodology, just like no one tool, is the final answer. I like the strong specification documents that are created during a waterfall process. Not because they make it easy for me to create the software, but instead because these documents create a firm foundation for supporting the software. If you’ve never been a support programmer you will never understand how benefitial this information can be when you have to figure out how something was agreed to work, whether a reported defect is in fact a defect or is it a feature request, and being able to pick up the code during the hand-off from development to maintenance. I also am a strong proponent of the more “agilish” idea of always having buildable code. The flexibility that this gives you is phenomenal. I love the sense of achievement that sprints can give a team. Far too often I’ve worked on projects where the “sprint” was over only when the code was delivered. Sometimes that can be years in duration. If creative people have to wait that long to get feedback, they become disinterested, disenfrachised and, ultimately, unmotivated.

Which methodology do I practice? None, some and all. This is partially because I don’t believe in a silver bullet solution and partially because finding training on this type of thing is almost impossible where I’m located. Yeah I can get all the information I want off of the internet, but I really want to sit down and talk with people that are full on users of the different methodology flavours. I want to be able to gather information in that fluid, old fashioned concept called a conversation.

I’m the Igloo Coder and I’m getting really stoked about the upcoming Edmonton .NET User Group‘s first meeting.