Summary
What matters in the end is working code, not the tool that made it. I propose that developers buy their own tools and be held responsible for installing, maintaining, and dealing with them just like auto mechanics do.

This weekend I helped a friend wire his new house – I did many things before I was a developer. I showed up early in the morning with my tool belt and started in. Reread that last sentence. I said I showed up with my tool belt. My friend didn’t go to the store and buy me a belt. Why should he. He doesn’t know if I like a 16oz or 18oz hammer. He doesn’t know if I like reversible screwdrivers, he doesn’t know what kind of wire strippers I like. All my friend knows is that he owes me big and the inspector is coming on Tuesday.

So as I pig-tailed outlet after outlet I started thinking why do so many development shops enforce a tool standard? By tools I mean things like Eclipse, Forte, JBuilder, JDeveloper, etc. What does it matter if I use vi and you use Eclipse? In software development there is one very important thing that matters and that’s working code. Did you read that – working code? At the end of the day do you check in your IDE? At the end of the day does your IDE get backed up? Do you give status reports about your IDE? Here’s the simple truth. The success or failure of a project largely rests in the code that comprises it. That code is produced by a crazy group of people known as developers who are more like artists than engineers. Each of these new age artists has a favorite tool just as Michangelo had a favorite brush. I propose letting the developer choose his or her favorite tool and just worry about the code in source control. Don’t worry about how it got there. Do you think Michangelo would have painted so well if the Pope told him what brush to use?

If you’re a developer you probably like what I’m saying. If you’re a manager you must likely don’t. A manager is concerned about many things, but most notably is time and money. To a manager this idea means licenses for a variety of tools and support for all of them. That’s a lot of time and money and they’re right. So my solution is this – the developer is responsible for their tools. That means they are responsible for it’s purchase and maintenance. This is exactly what happens with electricians, plumbers, and mechanics. When they get that first job they have to buy their tools. When they switch jobs they take their tools with them. The same can happen for programmers.

To implement this idea you just need a few ground rules. The company outlines infrastructure pieces like versions of make, ant, Perl, Java and a source control program. Additionally they would define the application, LDAP, and database servers. The company is then responsible for these items, the same way a car dealer is responsible for the lifts their mechanics use. The developer is responsible for the tools they use to make the desired software. I say this includes the hardware they use. That means the purchasing, installation, maintenance, etc. The company just provides a network drop, accounts on needed servers, and other core infrastructure needs.

The end result I foresee is a happier development team with increased efficiency. No longer would managers who don’t code dictate how to code. No longer would programmers be able to blame their tools. Just image it – the focus would be on the code with no excuses.

Talk Back!

Have an opinion? Readers have already posted 14 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Matt Bauer adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Matt Bauer works with all things big and expensive. He has worked with weather satellites and space instrumentation, administered government data centers, developed global intranets and designed international rich internet applications. He is currently president of For-Loop, a Minneapolis based technology company focused on distributed transactional systems and rich internet applications. Besides pushing the envelope of technology, you will find him out running marathons.