Software Engineering discussion

7 views
Code Complete > The Software-Quality Landscape

Comments Showing 1-3 of 3 (3 new)    post a comment »
dateUp arrow    newest »

message 1: by [deleted user] (new)

Although software quality can (and does) easily fill a book by itself, I think this chapter offered a nice summary, focused on implementation issues. In particular, I liked the focus on data-driven decisions about which techniques are most effective for improving quality. The discussion that defines the various facets of quality and the tradeoffs between them highlights the need to define quality objectives upfront, which in my experience is rarely done.

I would like to have seen a definition for "prototype". Some books define it as something thrown together and then thrown away as the development team restarts from scratch with the insight from the prototype, and other books define it as a base to iteratively improve over time, without throwing it away.

When reading about software quality, I anticipate an era when human code inspections are characterized as archaic and obsolete, yet they seem to endure (and this chapter supplies some hard data supporting the practice). I was surprised at how relatively ineffective unit tests (and tests in general) are in the studies. A bit more comparison and contrast between waterfall and extreme programming test paradigms and experiences would have been helpful.


message 2: by Aleksander (new)

Aleksander Shtuk | 84 comments Software Quality Assurance is the area of Software Engineer where I need a lot of improvement. I’ve been doing unit, integration, and regressions tests, but I feel like I’ve never been very intelligent about it. This chapter is filled with very interesting techniques, studies, and statistics. I hope this book gets in more details of QA techniques and provide good suggestions in later chapters.


message 3: by Erik (new)

Erik | 165 comments Yes, I liked how this chapter summarized and stayed with implementation details for Quality.

I recognized some (but not all) of the "Hard Data" examples as classic examples of metrics from large companies. Measuring quality for "bugs prevented" seems like the government putting out stats for "jobs saved or created".

To me, using Quality process techniques feels like being on a diet. It's hard to stick with and not much fun. The results are slow and can't be exactly measured.

I'm glad there are people out there that are passionate about QA & QC, but I'm not one of them.


back to top