eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The habitat of the Real Programmer, observed Ed Post in his classic 1982 essay, may have a computer screen at its focal point, but it has piles of hard-copy listings of source code obscuring every other surface in the office. Code, not specifications. Code, not project schedules. Code, not transcripts of user walk-throughs or focus groups.
“In the top left drawer of the desk,” Post concedes, “underneath the Oreos is a flow-charting template. …” He goes on, though, to say that this is invariably a relic of the previous occupant of the office. “Real Programmers write programs, not documentation,” he declares–with tongue in cheek, or maybe not.
The biggest problem with the Real Programmer stereotype is that so many people have the attitude, but so few can carry it off. “For every programming hero capable of monumental coding achievements,” warns guru Steve McConnell, “there are other pathological programming disasters who just dont know how to work well with others. They hoard design information and source code. They refuse to participate in technical reviews. They refuse to follow standards established by the team. The sum total of their actions is to prevent other team members from making potentially valuable contributions.” If you dont mind going through a free registration process, you can read the rest of that McConnell essay at the game developer Gamasutra site.
The self-styled Real Programmers focus on code, not on the process by which it solves enterprise problems, is of course the natural enemy of management. Managers are ill-advised, though, to seek ways of imposing their own priorities by threat of dire consequences. You can push water uphill, but the moment you stop pushing, its natural nature asserts itself.
If you want something done more consistently and more often, success in the long run depends on making that task easier to do–which brings us to last weeks announcement from Telelogic, whose ActiveCM configuration management technology (formerly an extra-cost add-on) is now a standard feature of the companys CM Synergy product.
Instead of asking developers to work for their management tools, going through extra steps such as checking out files of code before going to work, ActiveCM uses our ample supply of spare computing cycles to watch what a developer does and to take appropriate configuration management actions in the background. If a file gets changed, ActiveCM checks it out to the person who just changed it, with no manual command (or time delay before getting to work) required. Actions such as renaming or moving of files trigger automatic changes to configuration management databases. For most of the 20 years that Ive been working with source code and related documents, Ive wondered why configuration management features couldnt just be part of the system environment: The answer is that they can.
I date myself severely, I know, by even remembering when even a substantial application consisted of a single source code file, or a family of such files plus an assumed context of standard libraries. For as long as most developers today have been plying their craft, applications have also depended on associated bitmap graphics for on-screen controls, and on various other resources that could not be managed with ASCII-oriented tools. The component management aids in the updated Synergy products provide a higher-level packaging of these related but dissimilar files, making it much more straightforward to control a component-based project.
Configuration management systems are difficult to describe: Actually interacting with one is the only good way to get a sense of what it makes easy, and whether the nuisance is worth it. What I do see in the latest release of Synergy is a welcome, and long overdue, shift in viewpoint. Configuration management systems have always been good at telling developers what has been done to their code, but have made it hard to get the big picture on what the consequences might be for any substantial project (especially one that involves a geographically dispersed team). Were finally seeing products that put the burden on the system to figure out what the developers are doing, and to reflect their actions back to them in a way that makes it easy to understand their effects.
Thats a whole lot better than systems that say, in effect, that programmers can get along–but only if they really want to.