Sponsored Link •
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 didnt go to the store and buy me a belt. Why should he. He doesnt know if I like a 16oz or 18oz hammer. He doesnt know if I like reversible screwdrivers, he doesnt 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 thats 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? Heres 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. Dont 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 youre a developer you probably like what Im saying. If youre a manager you must likely dont. 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. Thats a lot of time and money and theyre right. So my solution is this the developer is responsible for their tools. That means they are responsible for its 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 dont 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.
|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.|