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."
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.
The most important thing is common sense; depending on your team, different methodology is needed.
The most important aspect of development for my team today is requirements reuse, sound silly but works great. By following this simple methodology we have made errors nonexistant; it beats unit testing by a mile in efficiency, plus it matches the results.
Most other teams fail with this approach though, and hard. It simply comes down to what the team is made of, mine love it.
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.
Only as far as the business requirements do not change after the analysis or the initial analysis anticipates changes in business requirements accurately.
I think you're talking about two things here. The first is the reduction of scope of a large project. Where we know we'll have to do X, but we'll only do x for now. We'll incorporate into our desing the knowledge that we will eventually have to do X. The second is anticipation or prediction of related requirements. As in, I am doing an email client, of course they will want a spell checker so we can anticipate that.
Neither of these things is what I am talking about, or have experienced in my career. My experiences are more along the lines of, "lets build a transaction processing system to do these overly broad things because we really don't know what is going to sell". The development team works on requirements as they see them, very little customer input or involvement. We're told to "just get something together so it can be sold to customers and we can figure out what they really want". A few months later a "product" is produced and sales can't sell it because it doesn't align with the customers needs. They come back with statements that it needs feature X, Y, Z. And of course, every sales person needs different X, Y, Z features. High priority. Management now says, "OK, we've determined that these three features are the highest priorities, now get them done". These three features are usually products in and of themselves. An example would be, adding a complete realtime business intelligence layer on top of a transaction processing app. When we try to explain that these two systems are fundamentally different architectures management will usually say that we should be "agile" and our design must be insufficiently robust to handle "change".
Don't get me wrong, everyone knows requirements change. Requirement changes within the scope of the application are manageable. The issue is when people take the XP/Agile ideas and use them as a replacement for solid upfront product research or customer input.
mp3's are only for those with bad memories