Slashdot Mirror
Software Accountability Made Real?
An Anonymous Reader writes "In a recent presentation and post, Kent Beck (eXtreme Programming, Embrace Change) highlights Open Quality Dashboards as a means to make software development accountable. Many different approaches attempt to reduce the number of issues creeping in all along the development process. Whether a shop abides by the rules of up-front UML design or test-driven development, or a methodology somewhere in between, the ongoing burst of popularity for tools enabling continuous integration and frequent releases shows the need for unit testing to appear earlier in the development process. In this context, quality dashboards could well establish a credible benchmark for software accountability."
At my company, most of our products are built daily (at a minimum) and the metrics are published to an internal website. Things like ugly code, unit test failures, bad JavaDoc, poor test coverage, and findbugs problems are visible to everyone in the company.
This makes it a lot easier for developers to do the right thing (and fix these problems). Nothing like a big red bar to motivate you!
The Wallstreet Journal has a page B1 article (free via this link?) on buyers trying to hold software providers liable for flaws, damages, bugs, etc. It seems the old EULA disclaimer is not going to hack it anymore. Buyers argue that each software patch is equivalent to a product recall and that vendors should help pay for the cost of patches (AT&T says it sends $1 million per month on patching).
If General Motors can be held liable for damages caused by a defective car part, some argue that software makers should be held liable for damages arising from buggy code.
Two wrongs don't make a right, but three lefts do.
That's EXACTLY it. At our shop, we got sick of being blamed for "taking too long on projects" - so we got together, got up to speed on Personal Software Process and Team Software Process, and started a development lifecycle and process improvement team.
There are a number of interesting benefits to this. The best one so far is that we maintain a 'responsibility trace' right from individual stakeholders in Management, to each requirement, to each design element... we can actually tell who in management has a stake in a particuliar _block of code_.
The other neat thing is, the execs can make changes all they want. We really don't care. Because we're on a fixed 3-week development cycle (all the way through the cycle each 3 weeks, culminating in a release) we can either say "sure, we'll do that in the next build" or "scratch the current cycle and we'll do that now". In the latter case, we only lose a maximum of 3 weeks work. Not bad at all, and if management complains, well, we can show them WHY we lost 3 weeks. They shut up pretty quick.
Unfortunately, convincing management that the paperwork we end up doing to improve and maintain our process is a Good Thing, is difficult. If we aren't coding, we must not be working, right? Wrong. Now we have nice graphs showing number of defects in our software falling through the floor, time spent fixing defects falling through the floor, developer productivity skyrocketing... It's fantastic.
Bottom line: Management in some places doesn't WANT responsibility. They want to hand down directives from above, and we are the magical little gnomes who make their projects at 1/4 their salary, if we're lucky. If they go sour on a gnome for whatever reason, they want to be able to fire with impunity. Process is the way to make them eat their own crap whether they like it or not. They WILL end up liking it, and you get your life back.
Managers tend to think that gathering proper input, leading to proper requirements, is "hard". But doing this upfront work is required to properly analyze/design/estimate a programming effort. Along comes XP/Agile whatever you want to call it. They say, you don't need everything up front, you can change things as we go, we're "agile". This is what managers want. Every month along the project the requirements change, the design changes, we adapt, this is great. The part they keep leaving out is the fact that change is not any cheaper. With any method you pick, as everyone knows, the later in the project you make changes the more they cost. They always leave off that part.
I can't recall where, but I remember reading the quote somewhere, "you can't refactor an elephant into a cheetah". I don't think many managers truly understand that...
To me XP/Agile is just an excuse that allows marketing and management to not have to do their job.
mp3's are only for those with bad memories
These are all good ideas, the unit testing, the automated frequent testing, etc.
Having experience a few crashes of bleeding edge versions of evolution and firefox with the automated calling back to the developers about the crash symptoms got me to thinking that having actual use (and abuse) be automatically incorporated into test suites might really abet the development of less crash prone code.
Despite the capability of automated testing to test many more features than can be done by hand, new applications have so much context and so many options that we need to test for what the users are actually doing with the application. Not just what we think they're doing, what we hope they're doing, but what they're really doing.
The most important bugs would be the ones that happen to the greatest number of people the most times.
Harvesting application interactions and sending them back to the test suite has a lot of value, but it's up to the developers to do this in ways that are sensitive to the user's need for privacy, too.
"Provided by the management for your protection."