Days 2 & 3 at SEPG
Yesterday and today were "session days" while Monday and tomorrow are "tutorial days." It's been interesting to take a step into the world of the software industry that is passionate about the formal frameworks for development and process improvement. I have met many interesting people, including Watts Humphrey. When I summarize my learnings for my team, I'll share them with you.
For now, random thoughts from my brain...
Hmmm, thinking of top take-aways.... It is sort of sad that the sort of industry standard for actual development task hours are 5-15 hours per week, with frameworks can get upwards of 20, but still, surprises me how low the number is. I do like some of the semantic differences between the way we talk at Microsoft and the way some of the rest of the industry talks. For instance "bug" versus "defect." "Defect" implies something more strong than bug; I think "bug" has become an endearing term, where as I don't think we could warm up to "defect." The other is "code review" versus "code inspection." To me, inspection makes me feel more like I'm receiving a challenge to find something wrong, whereas a review seems like a scan and nod.
Process improvement seems to be something in peoples minds along the lines of other habits people try to work on with varying success. People (okay, I'm included here) who don't eat the most nutricious meals and snacks usually know what to change yet often have trouble doing it. Smokers and heavy alocohol drinkers (I'm not included here) know that what they are doing is harmful to them, yet they continue. Um, people know that racking up credit card debt isn't good, yet the American family average is along the lines of 7-10K$, right?
What I'm trying to get at is that the number two issue our industry seems to have with implementing effective development (number one being management support) is the simple fact that people are resistant to changing habbits, even when they know it is good for them! It is perfectly logical that finding bugs earlier is cheaper. It makes sense that the better your requirements, the less time you spend coding. It makes sense that the more time you spend checking your work before checking in reduces the number of bugs/defects in test. Still, when these expert coaches in the worlds of CMM, TSP/PSP, Six Sigma, what-not, try to affect positive change that will result in higher quality, higher productivity and more effecient development cycles, the intial reaction from engineers is "Noooooooooooo!!!!!".
What are your thoughts out there? Why are we as a people so stubborn, and why are software developers, stuck somewhere between engineering and craft, seemingly especially resistant to process frameworks, even when face to face with data that shows it will pay off hugely?
april
