"By this it appears how necessary it is for any man that aspires to true knowledge, to examine the definitions of former authors; and either to correct them, where they are negligently set down, or to make them himself. For the errors of definitions multiply themselves according as the reckoning proceeds, and lead men into absurdities, which at last they see, but cannot avoid, without reckoning anew from the beginning." -- Hobbes "Leviathan"
Keeping in mind the idea that just because something hasn't been done before doesn't mean it isn't good to do, I have been an early adopter of software tools and technologies, including things such as TCP/IP, when Novell was the dominant player, object-orientation and the unified modeling language in the early ninties, and the Java platform at version 1.1, before Swing, and currently OS X and Cocoa.
An interest in developing new skills, keeping current and ahead of developments in the field, and a willingness to take responsibility for what I do, enabled me to rise to a senior-level technologist. In late 1998, I stepped away from my comfortable expertise in the Perl language to pursue a more junior opportunity that allowed me to develop my skills in the Java platform. More lately, my focus has been outside of specific tools as I've defined experience for myself in terms of practices and attitudes. Programming is a creative problem-solving practice with elements of craft, and mentor/apprentice relationships. Open source and free software represent an expression of the desire to design satisfying solutions to problems.
I'm interested in mentoring junior programmers to help them develop a professional attitude, care about what they do, have a lifelong love of
learning, and take responsibility for their work. These kinds of attitudes are what any good software developer would have, ensuring I will be helping colleagues I would enjoy having work with me.
As a lead developer I chose, as one of my highest priorities, to encourage greater adoption of unit testing and the JUnit tools specifically. The experience was disappointing in some ways. It was apparent that only the self-motivated really were going to adopt a tool on their own initiative, but that the majority were expecting to be spoon-fed the tool, the practices, and minutae of usage. Exploration and a learning attitude were rare.
In some ways it appeared that many were expecting and would only respond to a management direction. Perhaps there was a sense that individually, adopting a new tool or practice would not be effective; that there needed to be top-down control for a direction to work, and a bottom-up advocacy of unit testing didn't fit the model of where good things come from.
This idea, that unless something is centrally managed and directed it can't possibly be effective, exists in the commerical software development world at a high level. In an interview at a Gartner symposium in October of 2003, Microsoft's Steve Ballmer seemed to suggest open source can't work because nobody's in charge. "Should there be a reason to believe that code that comes from, how do I say this, a variety of people unknown around the world somehow will be of higher q
1000
uality than people who get paid to do it professionally? There's no reason to believe it will be higher quality. I'm not going to claim it necessarily will be worse quality. But why should code that may get written randomly by some hacker in China and contributed to some Open Source project, why is its pedigree by definition somehow better than the pedigree of something that is written in a controlled fashion? I don't buy that."
Back at the office, with unit testing, the adoption rate continued to be low. Even with presentations, technical white papers, and one-on-one working sessions, it became apparent that JUnit and developer-centered unit testing continued to be viewed as somewhat maverick. There wasn't a vendor-branded product, no centralized corporate office leading the adoption of the practice of unit testing. Could the bottom-up approach have led to the low interest? What assumptions about formalized, centrally managed and mandated practices might have the developers had?
In exploring the ways that simple self-organizing software development practices can lead to excellent results, it is necessary to understand the view that top-down process is the only possible route to success. What role does a fear of taking personal responsibility have? What forces work against a developer taking the initiative to adopt tools and practices that have demonstrably positive affects on the development outcome when those tools and practices are not validated by the management hierarchy?
With senior experience both as a consulting developer, helping to solve specific problems, and as an "organization man", working as full-time staff, it is exciting to be able to put off both and see where programming as a craft could go for me.
Previous Topic
