Have you ever noticed that software developers tend to be extremely opinionated? If you haven’t, then go to your favorite programming email list or forum and state the “Eclipse is the only IDE you should use” or “Java is better than any language in existence” and watch what happens. Software developers have been known to lose days arguing over who uses the better IDE, whether static typing is better than dynamic typing, and any other opinion based issue.

So, it should not come as a surprise that some software developers are as fanatical about details of the things that affect them. I am OK with being fanatical about your work, but there is a line that tends to get crossed from “purist” to “zealot” that does not help anyone.

Why am I talking about this? Well, there were two posts in the past few weeks that caused some people to react as a “zealot”. I am not one of the people. If anything, I am fanatical about moderation and adaptation. First, Jurgen Appelo had an interesting post regarding the practices known as ScrumButs. The post starts with a great summarization:

Many organizations in the world are adopting Scrum, and many of those are adapting Scrum. But the adaptation of Scrum is frowned upon by lots of practitioners, and Ken Schwaber even has a name for this “bad” practice: ScrumBut.

Many people responded in the comments and on Twitter. In several cases, people agreed with the general idea behind the post, but included “if you are using a practice that is a ScrumBut, then you are not using Scrum.” If you talk to almost any agile process leader, you will typically get the same response. For example, if you adopt all of the practices listed for Extreme Programming (XP) except for pair programming, then it is typically said you are not doing XP.

Part of the problem is that agile software development is very disciplined, even if it does not sound like it. So, when people modify the process there is a backlash that you are no longer “adhering to the process”.

The other post that had the same type of problem was Joel Spolsky’s Duct Tape Programmer post. The basic idea of the post is that sometimes you need a guy that just make things work:

One principle duct tape programmers understand well is that any kind of coding technique that’s even slightly complicated is going to doom your project. Duct tape programmers tend to avoid C++, templates, multiple inheritance, multithreading, COM, CORBA, and a host of other technologies that are all totally reasonable, when you think long and hard about them, but are, honestly, just a little bit too hard for the human brain.

Thankfully Joel does include a caveat to his whole concept:

Duct tape programmers have to have a lot of talent to pull off this shtick. They have to be good enough programmers to ship code, and we’ll forgive them if they never write a unit test, or if they xor the “next” and “prev” pointers of their linked list into a single DWORD to save 32 bits, because they’re pretty enough, and smart enough, to pull it off.

Because Joel has a lot of subscribers, there were several posts both agreeing and disagreeing with him. Again, there were zealots on both sides of the argument, “ship it” being one side and “no cowboy coders” or any other disciplined process on the other.

To all of these types of arguments I have two words:

STOP IT

Software development is an inexact science. There is no silver bullet. There is no process that maintains the “one size fits all” idea. If a majority of the concepts in Scrum work for you but there are one or two that your corporation will not allow, then adapt Scrum to your organization. That is likely significantly better than what you had. When you are dealing with process or organizational change, it is much easier to adopt things incrementally or in “baby steps”. It make take you two years to fully adopt Scrum, but that is immensely better than not adopting it at all. If pair programming is too much for your management to stomach, then just adopt the other XP practices. Your software development process will improve and quality will skyrocket. At that point, your management may allow you to experiment with pair programming.

The funny thing is that these processes are all about being agile and adaptation. However, some of the practitioners refuse to adapt to the environment around them. Most of the processes are focused on incremental improvements in the code, but the practitioners refuse to adopt the process incrementally.

If we are going to preach incremental approaches and adaptation, we need to promote them within the process adoption as well. If we really want to be taken seriously as an industry, we need to stop having such loud discussions over whether Eclipse is better than IntelliJ. We need to be focusing on proclaiming the benefits of using an IDE at all. There are still many people, even in corporate software development, that use vi(m), Emacs or TextPad for development. While these are great tools for editing a single file or two, they are not what we want to use for developing a significant product.

Let’s all stop having these silly arguments and focus on improving our industry. How about having a junior level programmer write the tests for the “duct tape programmer”? If you see someone using a text editor for corporate software development, help them to learn an IDE like Eclipse. If we can improve these things from within our industry, we will all see the benefits in the long term. And yes, I know if all of this happens we will likely just find something else to argue about.

http://static.zemanta.com/readside/loader.js