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."

Comments

Wha?

[superpulpsicle]

Software development accountable what?! How about making Management accountable. The developers are not the ones screaming for new features every release with these ridiculous time lines. The decision makers are accountable. Aka executives.

Re:Wha?

[chris_mahan]

Yeah, I know, and same here. I'm just picky of my work environment.

I think his solution stinks to high heavens.

You know what writers say? "The story needs to be as long as it takes to tell the story well."

I say that trying to make all software development fit the 3-week cycle, is akin to making all software development fit the J2EE Way. I need more flexibility.

Re:Wha?

[neiras]

We evolved a lifecycle that fit our company and our needs. You're free to do the same, and that's what I would recommend to anyone who is serious about writing software.

Just don't discount the value of _having_ a lifecycle. I never said there was One True Way, I just presented our shop's journey as an example.

If it sounds like we're in chains, you're dead wrong. We've never had more freedom. The hard part is deciding you're actually willing to do what is necessary to get it when you work in an environment that needs, but does not understand, software development.

Re:Wha?

[mutterc]

I think this is a market failure, and so clueful management can't help you. From what I've seen, the market will simply not bear the cost of software done right.

Nobody will pay extra for quality software (I'm talking about business customers; individuals don't have any kind of realistic influence on software development). If you (as a developer) tell a customer they'll have to pay $X and wait Y months for the software they want, they'll just buy it from someone else who promises it at $0.5X and 0.6Y months. Therefore, as long as any one company is cranking out crap, all must.

(Perhaps it's software buyers (typically PHB's, after all), who exhibit the kind of inability to learn from experience that we programmers typically attribute to those making the schedules and budgets).

This forces for-profit software development firms to live on the edge, cranking out crap as fast as they can, trying to stay afloat. (And, of course, don't forget that in the U.S., for-profit companies must make ever-increasing profits, so you have to cut something as time goes by. Can't raise prices, oh no, so you gotta cut costs).

Open Source software is immune to these market forces, so it's possible for OSS to not suck.

Re:The most important thing is common sense

[Anonymous Coward]

A couple of thoughts:

1) As someone said, "Common sense is not that common" :-).

2) IMO unit testing IS common sense. As a matter of fact I can't think of a more sensible thing to do that to test units of code before integration. It's very logical approach that is finally getting the recognition and importance it deserves.

What I don't like about XP

[The Slashdolt]

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.

Re:What I don't like about XP

[chromatic]

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.

The fundamental premise of XP is that there are ways to reduce those costs dramatically. A secondary premise is that exposing the costs of those changes at the point of change gives stakeholders more information to evaluate the necessity of those changes.

Re:What I don't like about XP

[The Slashdolt]

Your comment is doing exactly what I complained about above...

...there are ways to reduce those costs dramatically.

I don't doubt there are ways to reduce those costs dramatically. But reducing those costs increases costs in other places. Change is not free. You aren't reducing overall costs, you're just moving them around. You can simplify your design, make it completely decoupled and resilient to change. But, again, this is not free. These decisions have costs. Especially in terms of technologies, performance, etc, etc. XP offloads up front work onto developers later in the project. They don't tell you that the entire project will cost more and take longer, they leave that part off. Management only see, "As requirements change, your software changes". Your comment is an example of how XP fools management into thinking that reducing costs in one area do not impact costs in other areas.

Re:What I don't like about XP

[swillden]

The fundamental premise of XP is that there are ways to reduce those costs dramatically.

Yes, as long as you keep in mind that (a) those costs are still much greater than zero and (b) those costs are also much greater than the cost of doing the up-front analysis.

Designing and implementing for change is a good thing, but it's still more cost-effective to get it right the first time wherever possible.

IMO, some of the ideas in XP are valuable for every development approach, but they don't change the fact that if it's possible you're *much* better off doing solid requirements analysis up front.

A secondary premise is that exposing the costs of those changes at the point of change gives stakeholders more information to evaluate the necessity of those changes.

True, and that's generally a good thing. There is a downside, though -- if the users are cost-sensitive the resulting software is often much less effective than it could have been if the requirement had been understood up front and implemented to begin with.

Incremental requirements analysis coupled tightly to incremental development leads to hodgepodge systems unless the developers are really given free rein to refactor on a whim. And often, even if cost isn't an issue, users are resistant to refactoring in the UI (assuming the system is in production). Even when the reorganized UI would be significantly easier to work with, users are likely to resist having to put in the effort to learn the new UI and change their work habits. It takes a farsighted manager to be willing to repeatedly shake up his peoples' short-term productivity in order make them more efficient in the long term. And even if management is supportive, the users may learn not to request changes because they don't like the relearning their tools.

The more requirements can be understood up front, the less cost needs to be spent by developers, testers and users in managing change. If the requirements can't be understood up front, and if a small prototype or two isn't enough to help the users understand their needs, then XP's approach is the only way to make the development manageable.

But the lack of requirements should be considered a problem, and every attempt made to solve it before starting serious development.

All IMHO, of course.

Re:What I don't like about XP

[chromatic]

...those costs are also much greater than the cost of doing the up-front analysis.

Only as far as the business requirements do not change after the analysis or the initial analysis anticipates changes in business requirements accurately.

That's possible, but I've never seen it happen.

Incremental requirements analysis coupled tightly to incremental development leads to hodgepodge systems unless the developers are really given free rein to refactor on a whim.

Indeed; that's exactly what XP suggests!

In a situation where I had complete, sufficient, and accurate specifications up front, I'd still use most of XP: frequent iterations, customer prioritization, test-driven development, and heavy refactoring. I haven't seen anything else reduce my bug counts or improve my code's maintainability and efficacy as dramatically.

Really Make It Real

[4of12]

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.

Re:Rise of software liability

[G4from128k]

Ok, fine. I'll just gouge my customers up front rather than sticking it to them later by not reimbursing them for patching their systems. Software shops can then sell protection plans along with the product that guarantees a payout in the event of patching.

Do you wanna pay now or later?

Absolutely true! But if a competing software company actually creates quality code, then it won't have to gouge its customers, won't have many pay-outs for defective/patched software, and won't have to sell a protection plan. The other company that can't or won't produce good, low-defect software will find that it is at a price disadvantage.