Topic: software develoment

Under the Waterfall: The Cost of Bugs After Launch

Dietrich Kappe, Monday, October 19, 2009 @ 1:44 pm

photo credit: bobistraveling

We have a few simple principles when it comes to software guarantees: either we have developed the software according to our rigorous testing standards or the third party code we being asked to support meets some basic criterea:

1. It has full functional specifications.
2. It has unit tests that provide better than 85% line and branch coverage.
3. It has automated functional tests that exercise 100% of the user stories.

That may seem pretty extreme, but if we're promising to fix bugs on our dime, we can't have it any other way. Doing without these basic criteria is like guaranteeing you can drive from New York to Los Angeles in 30 hours, keeping under the speed limit without a speedometer and without being told what the speed limit is. Spelling it out a little more, if you can't tell me what your application should do, how do I know if it is "broken?" If I can't run and inspect unit tests to tell if individual classes and methods are doing the right thing, how can I quickly tell if my changes have broken the system? Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Ten Keys to Successful Software Development: #10: Tools and Infrastructure

Bernhard Kappe, Monday, May 18, 2009 @ 10:10 pm

After last month's post on the five deadly sins of software development, I thought it would be good to write about how you can overcome those sins (present in every project) to successfully develop software. The list we use internally roughly parallels that of the Standish Chaos reports, and I've illustrated it with the patterns we use, as well as some antipatterns we've seen and experienced.

#10 on the list is Tools and Infrastructure:

Pattern: We use standard tools for our software development process. For example, every project uses a source code repository, we do continuous integration (hudson) and enforce test coverage as part of every build. Every project uses our wiki for in process definition and documentation. The tools have the benefit of being easy to use, of making communication between team members and clients easy and transparent. They have the benefit of enforcing/reinforcing what we consider important in our method (like test driven development, continuous integration, just in time specification and continuous feedback) and getting out of the way where too much structure is a hindrance.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development