The Dumbening

But then I started to notice something about the Java projects I was involved in: weak teams and weak programmers will go to great lengths to do the wrong thing

Glenn Vanderburg
No Fluff Just Stuff - 2006 Anthology
Buried Treasure Chapter

Has the pragmatic press put out a bad book yet?

I like this quote. It reflects a lot of my experience with teams lately. I’d put a different twist on it.

Here the author was talking about if the “weakest programmers” on the team could be trusted with more powerful language features. An argument may go along the lines of “we need static typing to protect developers from themselves…”.

A trend I’ve seen in large corporate development is to invest more in smart tools than smart developers. The problem is that smart tools keep developers dumb.

I’ve been on teams with very green developers and have had two experiences:

Simple Tools: Sophisticated Development

The first is that we set up an ant build that has simple targets. Basically, made it easy for the developer to use whatever IDE they wanted. I just gave them the golden rule that the ant build was king. I also set it up so that server processes kicked off in a console window. Taught them how to use the unix “tail” command on the network servers.

It turned out that even the weakest developers felt very comfortable with this setup. If something didn’t build they could figure out quickly if it was a code issue, a missing library, or something else. I saw them grow very comfortable with the command line and with Java development in general. In short trusting the developers made them smarter and made the team stronger. I’d see signs of this when the developers would be able to solve complicated problems independently. Because they felt close to the metal they felt comfortable trying to dig out and solve issues themselves. Try a little AOP? Sure.

The funny thing is that the code was also better. Smaller classes, less code doing more, better javadoc. Pretty much everything that would make a team leader proud.

Smart Tools

The second experience I’ve had is with a company that felt that tools were the solution. Builds, deploys, servers, were all launched from within an IDE. A right-click generated a web-service, or EJB, or JavaBean. Separate teams were responsible for configuration and deployment and each had their own tools. One example was a tool that would try to inspect the .project file from an Eclipse project setup and use that to generate a build script to be used only by the deployment team. Want to take a guess at how much productivity that sucked away? Here is a hint: The solution was to have the development team check in all generated artifacts so the deploy team’s tool would be easier to use.

The tools were smart but kept the developers from knowing what was going on behind the scenes. These developers would be able to crank out 100’s of lines of code but would stumble at the basics. They’d be asking why their workstation has red flags while mine didn’t. They’d be lost as to why a deploy didn’t work. Javadoc would be limited to the crap the IDE spewed out. 100s of TODO statements littered the production code.

In short, smart tools made for dumb programmers.

Why is this? One theory I have is that programmers want to program - not draw pictures or use someone else’s software. If we wanted fancy tools we would be word processors, graphic artists, CAD professionals, etc.

If fancy tools were the solution to good software development then industry would have solved the issue long ago. Yes, I love my IDEs. I love code completion when I can get it. Even debuggers, which I feel is the ultimate “smart tool that keeps programmers dumb” come in useful. I’m just saying that the focus should be on what the developers feel would make them most productive.

Invest in people first, not tools

It is rare to find the developer who does not have potential. Most want to do the best job they can. Most want to learn new things and be considered competent by the team. At the same time, a company that treats its developers like a disposable and replaceable commodity will get developers who live up to that perception. The U.S. military can take 18-year-olds and train them to use million dollar equipment with confidence. That institution knows that setting the bar high will create a team that works well together and as individuals.

The Dumbening

As always The Simposon’s has a relevant episode. In this one Lisa lives down to her expectations when she thinks she has a Simpson-gene that dooms her to slowly become an idiot.