Neil Harrison and James Coplien’s book Organizational Patterns of Agile Software Development was released this summer and was reviewed today on Slashdot. I worked with Neil at Avaya, and I can attest that he was one of the many smart men and women with whom I worked during my tenure there. Neil was very knowledgeable and reasonable and was a great guy to discuss software architecture and methodologies with. He wasn’t easily seduced by the latest, greatest silver bullet, but he wasn’t tied down to the “way we’ve always done it”, either.
“Architect Also Implements” was a pattern he strongly advocated to the product groups. In a really big company, though, that can be very tough for an architect to pull off. When you have hundreds, or even thousands, of developers building products, you can reap a significant benefit from having a group of people review the designs and implementations to hopefully ensure that it’s all going to work together well in the end. In addition, as an architect gains more and more competence and experience with a company’s products, he or she becomes the best candidate to review designs for cross group compatibility and reuse. Before you know it, your best architects are spending all their time just trying to keep up with what big packs of developers are working on. One of the many great things about my move to Voxify has been that I’ve gotten the chance to be an architect who also implements.
The review on Slashdot points out that the authors were not too kind to ISO 9000. That’s very interesting, because Avaya is ISO 9000 certified. I shudder when I think of the horrors of the certification process and the amount of time blown on audits. Fortunately, I never lost too much time to the audits, because I did everything I could to avoid getting sucked into their time-wasting vortex.
ISO certification is a pointless activity for all but the most disorganized software development organizations. If anyone out there thinks that buying software only from ISO 9000 certified companies is going to ensure that they receive high quality products, they need to think again. Certification ensures only that the vendor is willing to make its employees spend large amounts of time filling out overly generalized (but in line with the mind-withering, approved process) forms, instead of spending time developing innovative, high quality products. The day that I see that one of my company’s competitors has become ISO certified will be the day that I know we have one less viable competitor.
Oh, and did I mention that I think ISO certification is a bad idea for software development organzations?
Anyway, based on the Slashdot review, the reviews on Amazon, other articles and books I have read by Coplien or Harrison, and my personal experience working with Neil, I can strongly recommend Organizational Patterns of Agile Software Development to any person who is serious about software development as a profession. And, yes, I do plan to buy it and read it, but I currently have way too many books in my queue.
“Oh, and did I mention that I think ISO certification is a bad idea for software development organzations?”
Why is do you think so? I think it will unify the work flow!
Personal experience, mostly.
It’s, of course, possible that the certification process at Avaya was badly mismanaged by the internal people and the external auditors. But, having read what was required to become certified, it looked like a design-by-committee-that-can’t-say-no process. That is, the requirements seemed to be a huge list of every idea that a big group of people thought might be a good idea.