Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: The Economics of Software Quality

samzenpus posted more than 2 years ago | from the read-all-about-it dept.

Businesses 83

First time accepted submitter BenLinders writes "The Economics of Software Quality provides solutions to quantify software quality, helping you to manage software development and maintenance. It contains software quality data that you can use to build a business case to improve the quality of your software, and decide upon processes and techniques that can help to implement the needed improvements in your organization." Read below for the rest of Ben's review.Quantifying software quality is not an easy thing. Several measurements exist, for instance estimating and tracking the number of defects that are found (both within development/maintenance and from customers), measuring software quality with static analysis tools (complexity, fan in/fan out), or measuring the effectiveness of software development methods and techniques (like inspections, test, and Cost of Poor Quality). This book covers software quality factors that influence the quality of software products as perceived (and believed!) by customers. An extensive list of factors is provided, where the authors have selected those factors that they consider most significant to achieve quality.

Many software development processes and techniques are covered in this book, from a quality and economic point of view. This also includes agile methods, where a body of data is available about the effects of agile techniques like user stories, Test Driven Design, Scrum Sessions, Measuring Technical Debt, and Pair Programming. For instance, about agile user stories the book states "... the user story method seems to be concise and fairly trouble-free, User stories average below 0.5 pages per function point and seem to contain fewer than 0.5 defects per function point`. This kind of information can be very helpful to build a business case for using agile methods in your organization.

Most of the data on software quality that the book provides is in "Defects per Function Point". A backfiring table is also provided, to translate language statements/lines to function points. So if you are not using function point, but programming in Java, Ruby, C++ or any other popular programming language, the data can still be used.

There is a full chapter covering defect prevention. Methods like Reuse, Formal Inspections and Quality Function Deployment are the most effective in preventing defects, and also techniques like Root Cause Analysis and PSP/TSP are claimed to be very effective. Given that the top ten techniques reduce defects with 40% — 85%, makes it interesting for many organizations to investigate the business case to improve the quality of their products, using these methods and techniques.

Additional information is provided on how to measure the effects on quality from a given method or technique. The book also provides warning for quality measurements that can be unreliable. An example is measuring cost-per-defect. When the quality of your development activities increases, for instance by improving requirements practices and implementing defect prevention for design and coding, the number of defects that testing finds will go down. Since test case preparation is a fixed cost, the cost per defect for testing will go up when the software has fewer defects. This makes such a measurement potentially unreliable. I believe that the main benefits will come when you can reduce your testing activities, based upon measurements that quantify the quality of your products before testing starts. Techniques like risk based testing can also reduce your testing hours, thus saving time and money on tests that are not needed.

Defects measurements and tracking are used in more then 55% of the military and defense software applications (using CMMI, TSP, QFD, etc), but in less then 15% of IT, commercial, web or embedded applications. Given their prevention effectiveness of -35%, and removal effectiveness of 25%, it is still surprising to me that this is not used more often. The data needed for these kinds of measurements is usually available in the defect management systems, though some addition effort is needed to classify defects and to do Root Cause Analysis. The benefits of using these kinds of measurements, combined with estimations of the expected quality at release, to decide and steer software development and prevent defects during the development and before release are significant.

The book also gets into methods to quantify structural quality issues that are not exactly "defects" but have an important impact – "Technical Debt" being one of these methods of quantification. These kind of measurements help to manage the quality of your code base, being able to see the impact on quality from changes, and take action to get quality back on the desired level when needed.

Reviews and inspections are very effective ways to remove defects before testing. Several techniques are described, both informal and formal techniques. Several of them are also usable within agile methods, supporting teams in developing better quality software. Applying these techniques effectively requires training, and arrangements within your company that enable employees to use them. The book makes clear that if you want to reduce post release defects and lower your maintenance costs, the work needs to start with early software development activities, like using better techniques for managing requirements, software modeling and design, reviews and inspections, and automatic code analysis. Testing alone is not sufficient to improve quality, and is also very costly.

The relationship between quality and risks is also explored. Many major software problems are related to the quality of the software products, e.g. outages, data loss, security issues or regulatory non compliances. Investigating such issues, for instance with Audit or Root Cause Analyses, and taking action to prevent similar problems in the future can be essential for your business. Measuring the losses and estimating potential benefits from preventive actions helps you to select the right improvements, and acquire commitment and funding to implement them.

The capabilities and skills of the staff that develops the software have significant impact on the quality. The benefits of training, skill development, and sharing of experiences to develop a learning organization can be huge. Software methods like Agile and RUP include mechanisms to continuously evaluate, learn and improve the capabilities of your staff. E.g. using retrospectives and scrum boards, to identify and follow up with improvement actions.

Overall the book covers the economic perspective of quality. The information provided can be overwhelming for some readers. If you need to improve your product quality, and are limited in time and money to do it, this book helps you to select effective quality methods and techniques, and to measure and track your progress when implementing improvements.

Ben Linders is a specialist in quality, process improvement and organizational development.

You can purchase The Economics of Software Quality from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

83 comments

Sorry! There are no comments related to the filter you selected.

As reviewed in Amazon... (-1)

Anonymous Coward | more than 2 years ago | (#38375898)

An extract review from Randy Rice [amazon.com] for this book:

The authors maintain that the real economic value of high quality software is not the cost to fix defects, but rather:

* the reduced likelihood of canceled projects
* the reduced risk of litigation
* shortened development schedules
* lower development costs
* reduced warranty costs
* increased customer satisfaction

This book addresses:

* What is software quality and how do we define its value?
* How can we estimate and measure software quality?
* How can software defects be prevented?
* How can we find and remove defects before testing?
* What are effective ways to test software and measure its effectiveness?
* What is the current state of post-delivery software defects?
* How do projects of various characteristics (low, average and high-quality) compare?
* How can technical debt be addressed from a business value perspective?

You will find a multitude of data from projects in a variety of industries, at various levels of quality, and at various levels of practice maturity. You will see by the numbers which project approaches work and which ones don't work very well.

Bring back Packt! (0)

Anonymous Coward | more than 2 years ago | (#38375914)

Not by Packt? Not interested.

-RickJWagner

Agile programming is a lie (4, Informative)

elrous0 (869638) | more than 2 years ago | (#38375948)

There, I said it.

"This programming philosophy will allow you to develop high quality software really quickly, and on the cheap" is the equivalent of a politician promising to fix every problem in the country with no sacrifices required, and put chocolate milk in all the water fountains to boot.

It's always the old thing: fast, cheap, or quick--pick any two.

Re:Agile programming is a lie (1)

sapgau (413511) | more than 2 years ago | (#38376030)

umm...

fast as in good performance and quick as in rapid development?

I heard it before but now I can't remember it.

Re:Agile programming is a lie (4, Informative)

Desler (1608317) | more than 2 years ago | (#38376050)

Aren't fast and quick the same thing?

Re:Agile programming is a lie (0)

Anonymous Coward | more than 2 years ago | (#38376250)

We need team commenting...

Re:Agile programming is a lie (1)

Synerg1y (2169962) | more than 2 years ago | (#38376420)

There's a slew of ven diagrams out there on google in regards to the comparison :)

Re:Agile programming is a lie (3, Funny)

Hillgiant (916436) | more than 2 years ago | (#38377104)

After consulting my MBA decoder ring, I will pick "cheap". Twice.

Re:Agile programming is a lie (1)

kgeiger (1339271) | more than 2 years ago | (#38391086)

What Hillgiant said. The MBA's "this is fungible" argument assumes software has uniform quality. Outsourcers' marketing plans exploit this assumption to the nines.

Re:Agile programming is a lie (0)

Anonymous Coward | more than 2 years ago | (#38376142)

...fast, cheap or quality

Re:Agile programming is a lie (5, Funny)

elrous0 (869638) | more than 2 years ago | (#38376176)

My post was fast and cheap. If you wanted me to proof it better, you should have given up one of those two.

Re:Agile programming is a lie (0)

Anonymous Coward | more than 2 years ago | (#38376278)

Best typo defense yet.

Re:Agile programming is a lie (2)

Maxmin (921568) | more than 2 years ago | (#38381396)

Agile is the interruptor the business side has always wanted: a leash for engineers.

But it gets much abused, resulting in needless rewrites, and scattered or stunted architectures - seen it at three tech-centric companies now.

"Refactor" is a banished term in Agileland. And you never really get to refactor, to design patterns or anything else, because you're too busy replacing hand-wired code to fit the latest redesign or business strategy change.

Tech management everywhere have lost their collective spines, caving in to "get it done cheaply and quickly" every time. Even when the resources are available to develop maintainable, well-thought-out code.

Re:Agile programming is a lie (3, Informative)

Anonymous Coward | more than 2 years ago | (#38376160)

Should be:

Fast, Cheap, or Good - pick two.

Re:Agile programming is a lie (3, Informative)

jd2112 (1535857) | more than 2 years ago | (#38376940)

Should be:

Fast, Cheap, or Good - pick two.

And expect at most one.

Re:Agile programming is a lie (1)

elrous0 (869638) | more than 2 years ago | (#38383148)

And if you work for certain developers, spend several years working to end up with none.

Re:Agile programming is a lie (2)

Eil (82413) | more than 2 years ago | (#38376258)

Agile programming is not a lie. It works, and the company I work for has the customers, profits, and happy non-burnt-out engineers to prove it. But it's not easy to do right, and certainly isn't cheap if you're hiring the right people.

Re:Agile programming is a lie (1)

roman_mir (125474) | more than 2 years ago | (#38376442)

Oh, this brings back memories, long forgotten, painful memories. [slashdot.org]

Re:Agile programming is a lie (1)

TheCouchPotatoFamine (628797) | more than 2 years ago | (#38377384)

Read the linked comment about XP. On his setup of "two 90/hr contractors"
not being better then one: how about 1 70/hr and a 35/hr one? I have seen
*very* good coders routinely spend forever on simple issues, spending the
the night working to find things that were almost proofreading in nature. Not
the way I want to time spent. The second coder can help keep the
first developer sane in approach,, focused, and with a venue to verbalize approaches,
not least of which is because only when you teach a thing, can you possibly
claim to have written quality code.

Not needed you say? Okay, can you find the error i made in the paragraph
above? (I'm not joking, start a timer, how long did it take you to find? It's
there!). Why should a project stall for half a day because of something
like that, something that doesn't take big brains, but a perspective that is
merely different? BTW, try not to post the answer below, so others can have fun;
the point is that having two people write code together can be really,
really effective so long as a chain of command is established and respected,
not to mention an amazing way to develop talent in-house!

Re:Agile programming is a lie (2)

DragonWriter (970822) | more than 2 years ago | (#38377604)

Not needed you say? Okay, can you find the error i made in the paragraph
above? (I'm not joking, start a timer, how long did it take you to find? It's
there!).

Which error? Are you referring to the "then/than" error, the sentence fragment, or the doubled comma, or the complete mess that the last sentence becomes after "approaches,"?

I mean, that's all I found in 30 seconds, there might be more.

Re:Agile programming is a lie (1)

xaxa (988988) | more than 2 years ago | (#38377910)

Not needed you say? Okay, can you find the error i made in the paragraph
above? (I'm not joking, start a timer, how long did it take you to find? It's
there!).

Less than a second, probably less than half a
second. But I know what kind of error is easy
to slip into a paragraph of text like that, so I was
was looking in the appropriate places and it stood
out obvious.

Re:Agile programming is a lie (1)

obarel (670863) | more than 2 years ago | (#38377998)

Same here. The oldest non-mistake in the book.

Re:Agile programming is a lie (1)

roman_mir (125474) | more than 2 years ago | (#38377956)

can you find the error i made in the paragraph above

I assume you are not talking about your multiple grammar errors (like double commas), so it must be that you think that good coders spend forever on simple issues, or maybe it's that you believe one must spend time teaching others to be a quality coder.

None of that defines of a good coder. Having a $70/hr and a $35/hr coder on the same thing is also stupid. It's good for the contractors, good for the agency (or whatever company that provides them), but it's stupid for the end-customer, who ends up being billed through his nose.

But that wasn't all that I had problems with back then, that thread has more info.

Re:Agile programming is a lie (1)

Synerg1y (2169962) | more than 2 years ago | (#38376512)

I still can't believe they actually named the obvious "common sense" into a programming model. I've seen a project go from waterfall to agile in its dev cycle and go from abstract to relatively meeting business needs through the communication. I don't know anybody that can devise a complex system on paper and factor in for all the little sutleties that require decisions from the system creator as well as compensate for the business practices. It's just a fast track to getting overwhelmed fast when using waterfall for anything large. Having been in IT on the receiving end of the agile process (giving direction), it is quite annoying, lesson learned though :)

Correlary (5, Insightful)

RingDev (879105) | more than 2 years ago | (#38376298)

Everyong knows: Fast, Cheap, or Good - pick two.

But not everyone knows its correlary:

Slow, Expensive, or Wrong - pick one.

-Rick

Re:Correlary (3, Insightful)

darkwing_bmf (178021) | more than 2 years ago | (#38376444)

Counterpoint: Non-trivial software is never cheap. It will either cost more up front for quality or more after delivery when it doesn't work the way it's supposed to.

Re:Correlary (1)

DragonWriter (970822) | more than 2 years ago | (#38377478)

Everyong knows: Fast, Cheap, or Good - pick two.

But not everyone knows its correlary:

Slow, Expensive, or Wrong - pick one.

Its most critical to realize that neither of those numbers is fixed; the first is "at most" and the last is "at least".

I've certainly seen projects where, in regard to the last trio, all three were chosen (or, at least, achieved.)

Re:Correlary (4, Funny)

Stirling Newberry (848268) | more than 2 years ago | (#38379194)

Slow, expensive, or wrong. Why compromise, you can have them all.

Re:Agile programming is a lie (5, Insightful)

scamper_22 (1073470) | more than 2 years ago | (#38376426)

A typical software process innovation happens like this:
1. Group of highly skilled and motivated developers create a new process (agile, code review, team programming...)
2. They see the results are great and start writing about it.
3. Other skilled and motivated developers take note of the new developers and start implementing it. The new process gains acceptance.
4. Consultants and the general software community picks up on the idea and starts implementing it.
5. Projects fail as usual as unskilled and unmotivated developers and organization can't execute it.

The key to software development is that is starts with the people. Success in software is 95% people, 5% process.
http://slashdot.org/comments.pl?sid=2560806&cid=38280588# [slashdot.org]

The team of highly skilled and highly motivated developers that create the new and cool processes would have been able to build a successful project using almost any process... or even no process.

Software processes can enhance a highly skilled team and highly motivated team. They can't do much if you don't have the talent or motivation across the organization.

Re:Agile programming is a lie (1)

Anonymous Coward | more than 2 years ago | (#38378598)

Motivated means well paid. No manager will ever agree to this.

Re:Agile programming is a lie (1)

rioki (1328185) | more than 2 years ago | (#38381998)

Motivated means well paid. No manager will ever agree to this.

I would say motivation means way more that that, but yea it starts there.

Re:Agile programming is a lie (1)

scamper_22 (1073470) | more than 2 years ago | (#38384408)

It's not just money. I'm pretty happy with my salary.

What I'd like
1. stability to know my investment in a company is long term. It doesn't help when they lay off senior staff...
2. Professional development, mentor ships...
3. Well run management, projects... but that is highly tied to 2.

Re:Agile programming is a lie (1)

elrous0 (869638) | more than 2 years ago | (#38383324)

The team of highly skilled and highly motivated developers that create the new and cool processes would have been able to build a successful project using almost any process.

Excellent point.

Re:Agile programming is a lie (1)

scamper_22 (1073470) | more than 2 years ago | (#38384484)

Yep. I'm not against process by any means, but it has to be productive.

Considering how much of the success of a project is based on people... it's amazing to see how little 'people process' there is. Processes to make sure you hire/keep skilled people. Processes to develop skilled people (mentorships...)

Once you have the right people developers, then you can make use of the other processes to enhance things.

Fields like medicine, law.... have extensive people processes. Internships, residency, credential screening....

They lack what we would think of as business processes. Simple things like surgeons have check lists for their tools so they don't leave them in patients :P

We tend to have all business process and no people process.

Re:Agile programming is a lie (2)

forkfail (228161) | more than 2 years ago | (#38376552)

It would appear that you don't understand agile.

When done right, agile is the formalization of good work habits (realizable short term goals with something to show at the end of each sprint in order to reach the overall long term goal). It also eliminates a lot of overhead time spent in planning that gets thrown away, unnecessary gant charts, etc.

The long and the short of it is that agile saves time by making the process that a good dev would impose upon himself the formal process for the product.

If you think agile means shipping the prototype, or that because you're agile you can just halve the time to ship, you are looking for a magic wand that doesn't exist.

Re:Agile programming is a lie (3, Insightful)

Anonymous Coward | more than 2 years ago | (#38377586)

Unfortunately, while Agile may formalize good work habits, it does not magically turn poor or mediocre programmers into good ones. No matter how much Agile you throw at a problem, if you have average developers, you still get average software.

Re:Agile programming is a lie (2)

forkfail (228161) | more than 2 years ago | (#38377676)

However, if you have great programmers, but saddle them with a really badly implemented waterfall approach, by way of example, you'll also wind up with poor to average software in all likelihood.

Unless your devs manage to overcome the methodology. But you don't want your devs to be battling both the problems of the code and the management approach at the same time, now do you?

Re:Agile programming is a lie (1)

tomboalogo (2509404) | more than 2 years ago | (#38382308)

Or this (http://en.wikipedia.org/wiki/ISO/IEC_15504). This SPICE stuff is gonna be the death of me.

Re:Agile programming is a lie (1)

elrous0 (869638) | more than 2 years ago | (#38383384)

Jesus, that HAD to have come from an engineer. An engineer could make peeling an apple a pain in the ass.

Re:Agile programming is a lie (1)

CockMonster (886033) | more than 2 years ago | (#38376554)

There, I said it.

"This programming philosophy will allow you to develop high quality software really quickly, and on the cheap" is the equivalent of a politician promising to fix every problem in the country with no sacrifices required, and put chocolate milk in all the water fountains to boot.

It's always the old thing: fast, cheap, or quick--pick any two.

You beat me to it. Agile is growing like a cancer, every job description at least mentions it if not requiring some experience in it. It seems to me that managers believe that it's 'Agile or die'. It isn't, if you're poor development practices and processes already in place suddenly 'becoming Agile' won't help anything. I've read employee comments about startups like Zygna, while they probably proudly proclaim to be Agile their developers consider it chaotic.

Re:Agile programming is a lie (1)

rwv (1636355) | more than 2 years ago | (#38376752)

You can have fast, cheap, and quick if the scope is tiny. You can't have fast, cheap, and quick if the scope is meaty. Scope is the magical fourth factor when comparing the other sides of the triangle.

Something something Diamond is the en vogue chart for the popular engineer trades related to this. And guess what? I am not spending time on this post to go lookup a reference to the chart I'm talking about that's somewhere on Wikipedia. This would be out-of-scope for me. Maybe somebody else will add it in.

Bullshit. Agile programming is a manifesto. (2, Informative)

Anonymous Coward | more than 2 years ago | (#38377262)

The Agile Manifesto doesn't make any promises about quality, speed or price. The only lie here is that your claim that it does.

www.agilemanifesto.org

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Re:Agile programming is a lie (1)

DragonWriter (970822) | more than 2 years ago | (#38377444)

"This programming philosophy will allow you to develop high quality software really quickly, and on the cheap" is the equivalent of a politician promising to fix every problem in the country with no sacrifices required, and put chocolate milk in all the water fountains to boot.

It might be, but II've never seen that as the main promise of agile . The big value I've seen from agile is that small, independent iterations reduce the cycle time from the investment of resources to getting some return, and manage risk of change by not devoting lots of effort to things that might be not needed by the time they are delivered.

It doesn't get you better software, cheaper, and faster than, e.g., waterfall if you have requirements handed down on gold plates in advance, it just avoids some of the waste that results from front-loading planning and analysis in an environment of uncertainty or evolving challenges.

(Which also highlights where it isn't useful: if you've got something where the detailed requirements are handed down in advance as unchangeable Holy Writ for some reason, and where there isn't independent value that can be derived from delivery of some distinct subset of the whole feature set, agile doesn't have a whole lot to offer. In most business software scenarios -- and, more broadly, in most software development to serve the ongoing operational needs of a going concern -- the factors which favor agile over front-loaded planned projects exist. But there are certainly circumstances where they are absent or at least less prominent, and where the smallest meaningful unit of work is the whole enchilada.)

Re:Agile programming is a lie (2)

shutdown -p now (807394) | more than 2 years ago | (#38377618)

Agile is not really a lie. As originally formulated, it was really just a rehash of the common sense approach that was practiced by many in any case, just without all the fancy labels. But, as with any brand, consultants hopped on the train selling "the Agile" as a silver bullet. Many of the same people also write the books, so in the end it ended up as yet another snake oil. But it doesn't mean that basic tenets such as having relatively small iterations with specific deliverables don't work.

As with any other technology or business method, apply your common sense filter. If something screams "bullshit!", then it probably is. Get rid of that and all its hard dependencies, and use the rest.

Re:Agile programming is a lie (1)

marcosdumay (620877) | more than 2 years ago | (#38378490)

Just because you are spending a lot of money/time, it doesn't mean the thing you are spending it on is useful. Rarely anything runs in an optimal way*, thus nearly every time there is rom for increasing some of those variables without reducing the others.

Agile programming is an aswer to iterated design. Altought iterated design was an answer to the wastefull beast that is waterfall development, it still didn't get ride of all the waste. Agile improved it. Now, it won't make your software write itself, or take all the bugs away. It just makes you stop burning some of the money you are burning with iterated design.

* A few hints for knowing when you are NOT working in near optimal way: Middle management and near optimal work are seldon seen toghether; if you measure a process, you've already made it not optimal; if you formalize a process you've made it not optimal again (except if you also automatize it).

Re:Agile programming is a lie (1)

hibiki_r (649814) | more than 2 years ago | (#38380270)

Nah, agile provides gains compared to many other methodologies, but for two reasons:
-It does its best at avoiding retarder requirements processes that lead to spending way too much time rewriting code or programming secondary features
-Provides practices that help team cohesion, which in turn lower turnover.

Too many employers have insane requirement processes and have nobody that works on the same team for more than a year. By just avoiding said demons, agile will provide improvements. If you already have a team that works together instead of as a set of separate individuals that just happen to work on the same codebase, and get to talk to your users/customers, you've already way ahead of the curve.

Re:Agile programming is a lie (1)

russh1451 (1303713) | more than 2 years ago | (#38380558)

Whoever described Agile in that way lied to you. I get tired of ignorant statements made folks who don't actually know anything about Agile software development.

Yes, Agile facilitates development of high quality software. The team I work on develops and maintains a distributed sensing and processing system including multiple CPUs, OS installations, something like 100 purpose-built software components, several hundred off-the-shelf software components, and custom hardware. These systems are deployed worldwide. Our open bug list is a small handful of low priority items. Over the last 5 years, we've averaged less than 1.5 bugs per month.

Turn around time for Agile development can be very fast. A typical deployment of new feature includes running many thousands of tests including unit tests, acceptance tests, and hardware integration tests. Without agile practices, these tests would require weeks to run. We'll run them in an afternoon. This means that a relatively small change can be quickly deployed.

Regarding "on the cheap": None of this comes cheap. It takes discipline and a lot of hard work. We pay very close attention to our process. It is not "on the cheap".

Re:Agile programming is a lie (1)

elrous0 (869638) | more than 2 years ago | (#38383432)

Are you saying the Agile developers I've worked for aren't true Scotsmen?

Re:Agile programming is a lie (1)

r8ndom (2531926) | more than 2 years ago | (#38382912)

Consider these refinements: One Time = Good, Fast, Cheap, Achievable Ongoing = Good, Fast, Cheap, Sustainable Pick any 3 is simplistic - it's more of a sliding scale. http://jeffrandom.com/gfcs [jeffrandom.com]

Actually sounds interesting... (1, Interesting)

RingDev (879105) | more than 2 years ago | (#38375958)

But at 600 pages, I just don't have the time to sit and read it. What I do have is a 45 minute commute twice a day that make for some excellent listening time. If I could get this as an audio book on CD, I'd pick it up tonight.

-Rick

Re:Actually sounds interesting... (1)

Anonymous Coward | more than 2 years ago | (#38376376)

Can you just hire an Indian programmer to read it to you?

Re:Actually sounds interesting... (3, Informative)

Jonathan C. Patschke (8016) | more than 2 years ago | (#38376764)

Have you heard of the Software Engineering Radio podcast? I've been listening to it for a few years, and I really enjoy it—even if I don't share Markus' enthusiasm for model-driven software. The web site is at http://www.se-radio.net/ [se-radio.net] , and even the back issues are worth listening to (processes don't get dated nearly as rapidly as tools).

Re:Actually sounds interesting... (1)

RingDev (879105) | more than 2 years ago | (#38378806)

Nice! Thanks for the link, I'll check it out.

-Rick

don't forget the organization itself (4, Informative)

Trepidity (597) | more than 2 years ago | (#38376054)

While it's popular to focus on code metrics (defect count, test-based metrics, etc.), when it comes to how to improve software quality, don't forget that it's strongly related to organizational characteristics. Whether you look at it via Conway's Law [wikipedia.org] , via Fred Brooks's analysis [amazon.com] , or via recent empirical research [pdf] [umd.edu] , it's pretty clear that software developed in an organization isn't independent of the organization itself, and sometimes the way the company is structured/managed is the problem.

Re:don't forget the organization itself (1)

CockMonster (886033) | more than 2 years ago | (#38376572)

This is exactly the reason why Nokia is now struggling for survival.

Re:don't forget the organization itself (2)

shutdown -p now (807394) | more than 2 years ago | (#38377654)

So long as we stick to capitalism, the only ultimate code quality metric is "how well does it sell?" - since that's the only thing actually relevant to the company (note, this includes side effects such as customer dissatisfaction from shipping crap once leading to dwindling sales on later releases).

Re:don't forget the organization itself (2)

bladesinger (2420944) | more than 2 years ago | (#38380784)

This is an excellent point that is widely ignored today. There is almost fanatical appreciation of Agile and rebuking of waterfall, based on "code metrics" and organizational culture that are internal to the development process and are largely subjective ("software quality" alone is so ridiculously convoluted at this point). The only metric that should be used to determine success is how well the product sold. I'm interested in finding studies that conclude positive or negative correlation between the various software design approaches and net income or units sold.

Peopel dont buy quality, they buy Brand (2, Informative)

Gothmolly (148874) | more than 2 years ago | (#38376122)

"If it compiles, ship it. If it sells, patch it."
"Nobody ever got fired for buying IBM."

THAT is the software sales model. That, and having people who know braindead CTOs who buy from their golf buddies, creating a giant naked Emperor.

idea (0)

roman_mir (125474) | more than 2 years ago | (#38376132)

have the team seat in a single file in the order of their position in the business. So CEO sits first, then it's CTO, some other management, then it's the program managers, the project/product managers, then it's the architects, then QA, then developers, the DBAs and the support and have the janitor at the end of the file. Chain them to their place in the row and have a dozen meter long, protruding metal spike aim at them through the center of mass. Every new incoming bug complaint in the bug tracking system forces a piece of software to send a signal to an external electrical motor (have a serial interface, RS-232 will do), and as the motor cycles, it uses a gear (rack and pinion) to translate rotational force into linear and to push a dozen meter metal blade forward.

The blade is aimed at the center mass of the first person in line.
---

That's how you ensure quality.

Re:idea (1)

sapgau (413511) | more than 2 years ago | (#38376242)

It's an interesting idea.

What I find shocking is the DBA being close to the janitor.
I bet they want to be with the architects!

Just sayin.

Re:idea (1)

roman_mir (125474) | more than 2 years ago | (#38376362)

well, they are in front of the support, and though in many places they do have some say in the architecture, I think in most shops they are delegated about the same amount of power as the support.

Re:idea (0)

Anonymous Coward | more than 2 years ago | (#38376366)

The blade is aimed at the center mass of the first person in line.
---

That's how you ensure quality.

That's how you ensure that your software won't be made at all. If you want software to be good, then buy it. The rest is history.

(where will be your place in that line, for being the one buying the software?)

Re:idea (1)

roman_mir (125474) | more than 2 years ago | (#38376388)

Oh, right after the ACs, I think you take priority in any line up of that nature.

Re:idea (1)

CockMonster (886033) | more than 2 years ago | (#38376632)

Let me guess, you work in QA?

Re:idea (1)

roman_mir (125474) | more than 2 years ago | (#38377852)

Wrong, I am the janitor.

Re:idea (0)

Anonymous Coward | more than 2 years ago | (#38379334)

I don't recall when your lord and savior ron paul proposed this idea. can you refer us to the speech from the exalted one where he suggested this?

makes sense in context (1)

ronpaulisanidiot (2529418) | more than 2 years ago | (#38381756)

this fits well with your desire to see everyone lose their jobs [slashdot.org] . now you are saying, they either lose their jobs through being laid off in your dream economy of your lord ron paul, or they are executed in the same.

not that it is actually sensible, but it certainly has precedent in your history.

Six Sigma (1)

theurge14 (820596) | more than 2 years ago | (#38376748)

I felt like I was studying for the Green Belt exam reading that review.

Cost (1)

Anomalyst (742352) | more than 2 years ago | (#38376810)

$43.19 ebook
$57.47 Hardcover

Re:Cost (0)

Anonymous Coward | more than 2 years ago | (#38386958)

Exactly, I'd love to read this but cannot justify 60 bucks for it.

"Software quality" even exists? (1)

lennier (44736) | more than 2 years ago | (#38377108)

I'll believe that when I stop getting monthly Critical security updates from Microsoft, Apple, Oracle and Adobe for products which already passed their entire battery of industry-standard best-practice software QA tests.

Re:"Software quality" even exists? (0)

Anonymous Coward | more than 2 years ago | (#38381294)

Don't be silly. They aren't actually fixing anything. That's just how they get you to reboot your computer so that you won't notice that it gets less stable the longer it runs.

Re:"Software quality" even exists? (1)

Maximum Prophet (716608) | more than 2 years ago | (#38382612)

/bin/true works pretty well. It's only been through a few dozen implementations.

On the Suse linux machine I have handy, /bin/true --version reports: true (GNU coreutils) 5.93

Back in the day, the BSD version was a shell script. I know IBM had to update it for licensing reasons. As far as I know, all the bugs have been removed. (But there's still a chance someone will introduce on with an update)

Re:"Software quality" even exists? (1)

sartin (238198) | more than 2 years ago | (#38403466)

On the other hand, /bin/false is totally broken. It returns an error every time I run it.

Yikes! (5, Insightful)

Un pobre guey (593801) | more than 2 years ago | (#38377622)

It contains software quality data that you can use to build a business case to improve the quality of your software

If you have to "build a business case to improve the quality of your software," you are in deep shit. Don't buy the book, change jobs instead.

Re:Yikes! (1)

obarel (670863) | more than 2 years ago | (#38378110)

Not everybody believes in "spend money to make money". There are other business models as well. And there are many lemons in the market, as you probably already know.

Re:Yikes! (1)

lennier (44736) | more than 2 years ago | (#38379206)

Not everybody believes in "spend money to make money".

Or even "first do no harm", which in the software world translates to "first install no botnets on your customers' machines". Certainly Microsoft, Apple, Adobe and Sun/Oracle don't, since they're the top placers for drive-by botnet installs. But none of the open source projects are immune either - Mozilla and Linux still push out monthly security updates.

What worries me most about the present (let alone the future) of software quality testing is that we still don't even have a way to tell if we're doing harm when writing code. Merely proving program correctness in the very restricted realm of "no random filesystem or TCP/IP packet data executed as machine code" seems to be beyond us. Seriously how hard can that be? How many programs, other than just-in-time compilers, need the ability to literally transform user data into machine code AND then run it in the same process context? Why do these kinds of exploits keep occurring in purely data-transform software like PDF or JPEG parsers? Why do our current best-of-breed programming languages seemingly make it impossible to simply assert "this program will NEVER need to dynamically execute as raw machine code ANY incoming data?" Why do our current best-of-breed operating systems allow programs to communicate through raw machine code in the first place? Wasn't the entire point of the object-oriented revolution, from Smalltalk on, that we would build systems out of message-passing and "shared-nothing" designs? Yet we've apparently abandoned the fundamental principle of OOP while still keeping the abstract formality.

I remember when Java was first announced, circa 1995, and its main selling point was "absolute security" since it was a virtual machine. I'm still scratching my head as to how they managed to cram a type-safe, pointer-free VM so full of critical vulnerabilities. I mean, that should be a theoretical impossibility, shouldn't it?

Re:Yikes! (1)

hazah (807503) | more than 2 years ago | (#38387980)

The problem stems from the fact that past all abstractions, code is data.

Re:Yikes! (0)

Anonymous Coward | more than 2 years ago | (#38406096)

'best-of-breed'??? That's a BizSpeak term, and you're using it in the most nonsensical way possible. You're most likely some kind of code monkey or business person that likes programming on the side, not a real, properly educated software developer.

There's no 'best-of-breed' programming language, nor does that term apply to operating systems. There are perhaps 'best-of-breed' software developers, that will choose a proper programming language (or more specifically, COMPILER and other development TOOLS) and of course, operating system according to the hardware/software platform base chosen to accomplish the task... or whatever the target user base uses (Wintel usually...). I don't like the term 'best-of-breed' anyway, it's as if everything is comparable in a strictly linear way from everything else. There's no 'number 1 best for everything' computer, let alone software development software.

All the stuff you're talking about in terms of OOP concepts and program communication makes no sense. You misunderstood the conceptual explanations for OOP: within an application, you have OOP, but not ACROSS applications, for which you're stuck with good old protocols. OOP was never 'sold' as a 'revolution' either, only a new set of concepts to make large scale software development and maintenance more manageable (up to a point) in comparison to procedural languages.

Java VM is broken because marketing hype pretended it was going to be programmed as though it was forged by the Gods into a perfect piece of software. Obviously, there are not Gods, only mere humans...

Re:Yikes! (1)

wonderboss (952111) | more than 2 years ago | (#38378288)

It contains software quality data that you can use to build a business case to improve the quality of your software

If you have to "build a business case to improve the quality of your software," you are in deep shit. Don't buy the book, change jobs instead.

Amen.

As Deming said "Most of the costs of quality are unknown and unknowable."

Mod UP! (1)

marcosdumay (620877) | more than 2 years ago | (#38378540)

Here. This is it. Too bad I've already posted.

Somebody please mod the parent up.

Re:Yikes! (1)

bmajik (96670) | more than 2 years ago | (#38380600)

actually, I think you're quite wrong.

Everything in life is a cost/benefit tradeoff. The notion of building perfect software "at any cost" is similar to how Rolls Royce thought about building cars. Making something the absolute best possible it can be is a praiseworthy ideology, but there is obviously an associated cost for doing so.

The world is fortuneate that the Henry Ford's of the world _also_ got into the car business, and decided NOT to compete with Rolls Royce on quality, functionality, etc.

Supposing that there are two possible software development methodologies, which differ in cost, time to market, and objective quality upon release, it is of course not a foregone conclusion that the higher quality methodology is the one which should be chosen.

The target customer in question may prefer the lower-quality item sooner and for less money.

Everything done at a business needs to have a business case. That includes improving quality.

People who embark on improving software quality who categorically reject doing a cost/benefit analysis tend to not ship.

Think of all of the software products you use. All of them have bugs that the team decided to not fix. They may fix them in future, they may never fix them at all. They may make modifications to their engineering to attempt to prevent these bugs or find them earlier, or they may not.

Once Again Beancounting (-1)

Anonymous Coward | more than 2 years ago | (#38385630)

The biggest software quality problems are related to well-know attitudes of managers and developers. Namely, "product is ready when pulled from developer's hands" , "documentation/specification is too expensive", "not time for testing, we must ship" , "not time for specification", "I am the customer and give you money, no time to answer your questions" and so on.
No amount of "metrics" will effectively tackle the problems of above, but a different attitude will do. Why is Linux a reliable operating system ? Because it is not affected by managerial BS, but by a sense of duty to deliver high-quality code. Developers would simply be ashamed to ship something bug-infested.
If managers would actually care about the products their teams develop and would test the products themselves in detail, they would know very well where the problems are. But they are soo busy to paint powerpoint slides, phone their manager buddies or meet their manager buddies to present some cool powerpoint slides. In some industries such as aerospace it is different, because lives are on the line and people can go to jail, so quality is good. Think about it.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>