CSDP Driven

I was impressed with the Lean Software Development process, and thought it would be worthwhile to discuss it in context with this Software Design knowledge area. The biggest takeaway I have is that of the principle of eliminating waste. (All the principles of lean should be implemented, but I like to identify a few words to associate with new ideas) For those who need some background, please visit Mary and Tom Poppendieck’s site.

As applied to manufacturing, eliminating waste seems intuitive. As in manufacturing, there are many areas (obvious and non-obvious) in software development where waste can be eliminated. And lean fits well with the strategies and methods of agile development. It is our duty as a CSDP to understand and apply these principles to our projects.

From the Poppendieck site, “Lean organizations concentrate on the rapid flow of value, because they have discovered the fundamental principle of Lean Six Sigma: quality, speed, and low cost are tightly linked; in fact, they work together to provide world class performance”. Just like the agile concept of customer focus, lean considers waste to be anything that does not provide timely customer value. This does NOT mean that you throw necessary methods or processes out the window. It means you must justify that the method or procedure provides value either to the customer or value to the process of creating value for the customer. For example, does that document need to be formally produced or would a wiki entry be good enough?

Finally, I think there is one thing that I keep hearing over and over at conferences and in books that is stated in the “LEAN Software Development” book by Mary and Tom Poppendieck, “..transferring practices from one environment to another is often a mistake. Instead, one must understand the fundamental principles behind practices and transform those principles into new practices for a new environment.” This is where we as a CSDP can help!

Allen

According to the IEEE definition [IEEE610.12-90], design is both “the process of defining the architecture,
components, interfaces, and other characteristics of a system or component” and “the result of [that] process.”

The SWEBOK identifies six sub-areas;

1. Software Design Fundamentals
2. Key Issues in Software Design
3. Software Structure and Architecture
4. Software Design Quality Analysis and Evaluation
5. Software Design Notations
6. Software Design Strategies and Methods

I subscribe to the IEEE Software magazine. One of my must read articles is “on architecture” by Grady Booch. I have been reading his books and articles since my college days. In the November/December 2007 issue he compares building architecture with software architecture. And in one page, he clearly states where the two disciplines differ and converge. Of course, books have been written on these ideas, but I now have a simple list anytime someones needs to have a discussion.

I have read and heard a lot of people talk about “software design“. I’m sure you have seen many compare it to building a building, or liken it to a craft, or even describe it as an artistic endeavor. At the last conference I went to, Alan Shalloway of NetObjectives, compared current software development to the crafts of the middle ages, before the industrial revolution! Even Grady Booch in the previously mention article observes that “the software industry has a long way to go to achieve the building industry’s level of predictability, reliability, and quality. ”

There are many ideas out there on design, I have mentioned lean development, design patterns, agile, and there are more. As a CSDP holder, I think we must consider the pro and cons of the different approaches and use the most appropriate one for our current project. Like the old saying (no animal cruelty intended) “there’s more than one way to skin a cat”. We need to have a variety of approaches in our toolbox, and like any proper craftsperson, know which tool works best for the desired result.

Allen