Monday, October 20, 2008

Programmers and Common Tools

Years ago I used a programming editor from IBM called EPM; I don't even remember what the letters stood for, but I liked the fact that my editor's acronym matched the initials of my name. I used a version that worked on PC DOS and IBM OS/2. I became so good at this editor, and the commands so ingrained in my neural pathways that I believe my children were proficient in EPM from birth.

I worked on a team where there were constant debates and competitions to see whose editor could accomplish the most arcane tasks with the fewest keystrokes, because after all - this was a sign of superior software quality! Daily EPM versus vi versus emacs versus Notepad versus Wordstar versus godknowswhat took place - it's a wonder we delivered any useful applications at all.

Most of the time were were writing C and/or C++ code, so we believed that as long as the code compiled and ran, the editor used in the construction phase was of no particular importance. Every programmer could select their tool of choice, thus maximizing their personal productivity. So long as each member of the team was productive, then it follows the team and (by extrapolation) the company was productive.

As time went by, a few problems began to surface that caused some of us to rethink this approach. First, the tools became more complex and did more things for us. For instance, some of the tools performed on-the-fly syntax checking and compilations so we could execute the application without having to wait for a compile step. Different tools had slight variations in the compilers which caused different performance characteristics which we would spend days trying to resolve.

The tools became more complex and included wizards to automate the generation of code and of course the different tools generated different solutions. This yielded another round of debates and competitions which delayed actual work.

The purests maintained that these complex tools had the effect of dumbing down the programming staff, a claim that others thought to be entirely impossible (if you catch my drift). I always felt that dumb programmers were dumb and smart ones were smart, tools themselves did not cause that distinction. Personally I always examined auto-generated code to see how it worked and frequently stepped through the code with a debugger. Some of us believed that auto-generated code had the desirable effect of code consistency; different developers using the same tool would deliver consistent code if much of it was auto generated by a tool.

After years of debate, working with teams, and managing teams, I've come to the position that the more you can establish a standard set of tools and uniformly employ those tools across the enterprise, the better the organization will be.

First, let's assume that a wise tool choice has been made; one with extensibility, lots of functionality, is well regarded in the industry, and has ample technical and third-party support. The use of a common tool across the enterprise will yield many positive benefits. Chief among these is control over costs and quality. When every developer is allowed to select their own personal tools of choice, the enterprise has an enormous challenge in leveraging the tool vendors to realize lower costs or manage technical support.

Developer tools today are more than just text editors; these Integrated Development Environments (IDEs) perform complex tasks to generate code, stubs, manage configurations, integrate with requirements, project management, and source control repositories. It is not in the enterprises' best interest, nor a good use of programmer time to develop these functions, features, and integration points on their own - uniquely for each personally favorite IDE.

Quality in application development is a descendant of predictability and consistency. That a specific developer is slowed down by the nuances of having to use a less-than-perfect-tool (for them) is not significant in the larger goal of consistently building applications in a predictable way. Developers who insist on using vi, emacs, or Notepad in an Eclipse shop (for example) typify the notion that Pony Express Riders, with the wind in their face, are more productive than Locomotives with their overhead of rails, tunnels, bridges, and water towers. Ahh, No.

Staff mobility is another positive outcome of tool standardization. Being able to move resources around based on needs, due dates, problem determination activities, and business cycles can more easily be achieved if everyone is using the same tools. We've seen this again and again with productivity software such as word processors and spreadsheets; we saw it again with email solutions and calendar software. Developer tools are no different.

Still there are diehards that think programmers are special and should be able to choose whatever tools they want so long as the output (source code or binaries) are consistent. If you examine their work closely you will find that they have actually built their own IDE, specifically tailored for the enterprise in which they work, and then spend a significant amount of time maintaining their custom-home-grown IDE. Is that what they get paid to do, really?

No comments:

Post a Comment

Follow by Email