Welcome to issue #6 of Allen Holub's Sporadic Newsletter. Subscribe at /newsletter [...] -- An interesting process article There's a really interesting article from the Sept/Oct issue of IEEE Software entitled "Trade-offs between Productivity and Quality in Selecting Software Development Practices." The authors looked at 29 projects of various sizes and scopes, all done within Hewlett-Packard. They correlated various common development practices (Design Review, Code Review, Functional Specification, Daily Builds, Regression Testing, etc.) against productivity (measured in lines of code [LOC] per person per day) and quality (measured in customer-reported defects per month per million LOC). Bear in mind that *none* of these projects were using ad-hoc development---they all had design and development processes in place, and followed these processes. The question, then, is not whether process works, but rather; when given a palate of processes from which to choose, which are the most effective? The results were interesting, to say the least. First of all, the mean level of productivity was 26 LOC/day/person, which is up from where it was 20 years ago, but not much. The range of values was also interesting (the least-productive project averaged 0.7 LOC/day and the most-productive project averaged 80 LOC/day.) I'll bet that most of us estimate project times based on a lot more than 26 LOC/day. Only one process measurably improved both productivity and quality: releasing early prototypes to end users. There was also a correlation between when prototypes were released and how much impact they had (the earlier the better). For example, releasing a prototype at the 20%-complete mark, as compared to the 40%-complete mark, yielded a 27% reduction in the defect rate and a 35% productivity increase. If you focus on productivity alone, only one other practice significantly improved productivity (without significantly impacting quality): Daily builds. I guess the knowledge that your code *has* to work correctly at the end of the day makes you more careful. This is paradoxical to many programmers, who assume that they want to write as much code as possible in a day, as compared to writing fewer lines that are better quality. Shifting the focus to quality, the two additional practices that measurably improved quality were design reviews (not code reviews!) and integration/regression testing. This result underlines the importance of a good up-front design and strengthens the XP test-first argument. I'm particularly interested in the fact that code reviews didn't have as much of an impact as design reviews. I guess up-front design does have some value after all :-). I'm just summarizing the article here, so if you don't subscribe to Software, you may want to go to the library and read it ("IEEE Software" 10:5 [Sept/Oct '03], pp 78-85). -- Blows against the Empire. JavaWorld just published a couple of (what I naively thought were) boring introductory articles of mine. They covered two basic OO concepts that have been around for 25 years or so: fragile base classes and implementation hiding. The articles discussed the practical ramifications of both concepts; namely: you have to use extends very carefully, and you should avoid accessors and mutators ("getters" and "setters") because they tie you down to a specific implementation. The articles are at: http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html The most interesting thing to me is not the articles, but the resulting discussion. The venomous vindictiveness of the people who didn't understand the concepts but nonetheless attacked them, was shocking. Moreover, the most mindless respondents didn't just attack the concepts, they attacked me personally. The invective and name calling outweighed the content in a significant number of postings. Some people impersonated me and posted ridiculous messages with my name attached. Several messages (which have been deleted) threatened me with physical violence (as in "go after thewith a pipe"). The many people who tried to talk about the value of OO concepts were either attacked viciously or ignored. By now, most of the knowledgeable people have dropped out of the discussion in disgust, so the board is serving as a garbage pit. On one hand, I suppose I should be pleased that people are this passionate about programming. On the other hand, I'm disturbed both by how uninformed some programmers are about the basics of their craft, and by how vigorously they resist new (to them) concepts. As far as I can tell, the most vicious of the respondents had never read a book on OO design. They learned what they know by working with existing code. (That is, they've read nothing but programming how-to books.) The general tenor was "you're full of because doesn't work that way." Of course, none of you would act this way or you wouldn't be on this list, but if this kind of knee-jerk attack on an unfamiliar concept is representative of the way that American programmers think, I really wonder if the industry has a future in the U.S. Trying to get programmers to even think about what they're doing is clearly an uphill battle. -- Help. So, in the interest of general enlightenment, I'm going to start two projects: First, I want to assemble a list of books and online resources that people can use to learn about OO. Though I have my favorites, I'd like to know what yours are so that I can make the list more comprehensive. The posted page will have a "contribute your favorite resources" button on it, but for the initial pass, I thought I'd just ask you. Please email your ideas to me. The second thing to do is to start compiling a list of successful projects that were written using OO principals. I intend to put a survey form on the web site some time in the next few weeks, and I'm hoping that you'll participate at that time. I'll send a note out to the list when the survey is live. -- Recasting the OO Workshop The third thing I intend to do to address the programming-with-a-closed-mind issue is to recast my OO Workshop to teach OO concepts even more effectively. I'll spend more time on techniques that you can use to design and write solid OO systems, and on techniques for breaking out of a procedural mindset. I'll still go through the entire process from front to back with a multi-day hands on exercise, but I'll add even more hands on exercises directed at helping you learn object-think (and less time on management). I'm also going to replace the design-patterns component (which is really an advanced topic) with more coverage of UML, particularly the new UML 2.0. This Workshop will be the premier way to learn how to design and build OO systems. I've scheduled a session of the new Workshop for Nov 10-14. Find the new course description at /training/oo.workshop.html -- The Personal-Networking Dept. Getting personal for a moment, I've decided to expand my consulting practice to include high-tech expert-witness work, primarily in the code-quality and process arenas. I'd appreciate it if you can refer me to any attorneys that you might know who specialize in high-tech litigation. ----------------------------- Until next time. -Allen Contact Allen via: /allen.html :-). (c)2003, Allen I Holub. All rights reserved. You may redistribute this newsletter freely, provided that you redistribute it in its entirety without modification. 2003/08/08
