Software Engineering discussion

I grew up in IBM with the inspection process outlined in this chapter. One problem I experienced is that when schedules get tight, reviewer prep time drops. In theory, the moderator asks reviewers, before the review, for their prep time, and if they feel that it is insufficient, they postpone the review. In practice, this was rarely done, and inspections proceeded with on-the-fly reviews.

I have no experience in pair programming, and I personally probably fall in the camp of strongly preferring solo development with team inspections. I find that I best work in bursts of productivity "in the zone", sometimes outside of normal work hours. I wonder how many people would truly prefer team programming if they were not part of an organization that required it?

I’ve never tried paired programming as described in this book, so I’m not sure which camp I belong to. On one hand it sounds like a very good opportunity to learn from others and share own knowledge. I noticed that I understand an idea better after I try to explain how I understand it to somebody else. On the other hand it would require me to stay focused on one task for a long period of time that I don’t think would work for me very well. Sometimes I work on two or three projects at the same time; the other time I need to answer a phone or e-mail; discuss something with QA or my team lead, do some research. Despite all the benefits of pair programming provided in book, I don’t really understand how it works in other companies (unless it’s scheduled like a meeting may be?). But I would definitely give it a try if I had a chance in work environment.
We’ve tried to do design reviews that weren’t very efficient probably because of lack of experience in this area. I would try to run code reviews or readings the way book describes it. But then what is the probability of me changing my opinion if I had more responsibilities like running own team…

I liked the views on using Reviews and Inspections as learning and feedback tools rather than only for quality purposes.

The last time I was around pair programming, it was two of my coworkers. A senior and junior programmer were paired up. It was a 6 month project, and the junior programmer was being "trained" in the software in order to support it after it was released. I think the product could have been built cheaper, but that was a really great way to train support engineers on very complex software to support. Supporting complex software after its release by training people after the release of software never works out that great. This difference in training support staff feels like "preventing versus fixing" a bug.