This one has been around awhile, but it’s still a worthwhile (re-)read. It’s full of radical ideas like:
- Individuals are important
- People aren’t “Plug’n Play” components
- Productivity can be maximized by making it easy for the project team to communicate
- Pay attention to the team’s environment
If you’re in anything like the environment I describe below, you can try using Cockburn’s writing in an effort to reform your workplace. If you have any influence over your workplace, heed Mr. Cockburn’s writing now rather than learning the hard way.
This Stuff Matters
A couple years ago I got to jump straight from pure insanity to a high caliber agile shop. An oranges to oranges comparison of effectiveness between the Microsoft Solutions Framework process at the first shop and Extreme Programming in the second is useless because too many other factors were different (stronger teams, more supportive organizations, less customer involvement), but the simple ideas of:
- Sitting near all of my teamates in an open room
- Everybody focused on only the one project
- Developers, testers, and analysts on the project at the same time!
were an enormous improvement in my mind.
Project Team Insanity
I used Cockburn’s chart on the effectiveness of various communication channels in a presentation several years ago trying to convince my then management to move towards iterative and more collaborative processes. At the time the entire organization was in a “matrix” organization structured by functional group first, and project teams second. Cubicle assignment was strictly by discipline (development, architects, analysts, testers, etc.) because management was tired of reorganizing teams and paying moving costs to colocate teams. Everybody was working on multiple projects at a time so that all projects had equal access to specialized knowledge and skillsets. I had the distinctly unpleasant experience of simultaneously working on the rump end of a death march project as a developer (later cancelled), and trying to lead the development of a separate project.
The first project was an early Web Services project using a custom in-house SOAP-like framework developed by the internal integration architecture team (if you ever hear a sentence like that, run away!). The lead developer/project manager was in his first lead role and had no prior lead or architecture experience. There were five distinct methods for the service, and five developers, so naturally each developer was assigned a method and told to go off and code it. I failed in my attempt to escape the assignment and began to code my assignment (throwing out the unworkable design that was handed to me. Win32 API and COM calls from within XSLT transforms? No thank you).
Early on, I asked the lead where the development database was located and was told each developer was just using their own box. Come to find out, every single developer had created or reused a different database schema structure to hold the same logical data. Two developers were using an existing Oracle schema structure (the database was overworked and we had an opportunity to move some load off), and the other three had made their own Sql Server databases. Two of us had created fully functional, specialized rules engines that did roughly the same thing, but radically different in implementation. My first action as a newly minted Systems Architect (make finger quotes for the full effect) was to blow the whistle on the technical weaknesses to my new boss. The project was fortunately abandoned and replaced by a different effort (2+ years in MSF Planning!). Integration testing at the very end was apparently pretty interesting;) I sincerely think the project could have succeeded if the developers had been working in a common location instead of in a complete vacuum. Just accidentally overhearing conversations would have tipped us off that our code could be shared between service methods and certainly would have got us on a common database early. Of course, the fact that every developer was actively plotting to get off the project and the organization went through a massive reorganization at the same time didn’t help either.
The second project was an extremely complex system with three other developers, all of whom sat in different wings of the floor, and were working on other projects at the same time. At no time during the course of the project was the requirements analyst present on the team at the same time I was. All communication was through a requirements document that was prepared when I was on the other project (that turned out to be incomplete and/or flatout wrong). Come to find out late in the game, there was a second requirements specification no one in development knew about. We pulled it off by working way too many hours, but I’ll never do a project like that again. The saving grace was very good involvement from the business partners, otherwise it would have bombed. The system is undeniably successful in production (one of my friends won an award from the business for it), but it was a long time before I enjoyed software development again. I’m pretty sure the CMM crowd would call this an unrepeatable process.
Of course it didn’t help that I over-engineered the application a bit, but I’m making fun of other people here, dammit! I read somewhere that the worst designer is a fellow on his second project trying to use every idea he had from the first system (editor’s note, it’s from Fred Brooks in the “Mythical Man Month.” Thanks to Darrell for the head’s up). Guilty as charged. I’d also just read the GoF book for the first time and got a little patterns happy. They should put a warning label on that thing.
My former employer has since quietly removed the worst of the organizational madness and is simultaneously working toward climbing the CMM ladder and tentatively introducing some basic best practices like automated builds and better unit testing. All I can say is good luck to you guys, and it’ll be worth the effort (maybe not the CMM part, though).
I think it’s fun to laugh at the absurdity of past projects, as long as you don’t repeat them. Bad examples can be more illustrative than good examples sometimes.