The OOPSLA 2007 podcasts have been available for quite a while, now. If you are interested in software engineering make sure to have a listen. I especially enjoyed Frederik Brooks talk on "Collaboration and Telecollaboration in Design".

Get it here.

Writing software which you can modify easily is not an easy task. Over at InfoQ they have a nice video of a panel discussion which discusses this topic. Watch it here.

For me two things stood out:

1. You need a solid and clean design + automated testing if you want to be able to change your software later. While this should be obvious it is still not the case in our industry that all developers use and care about techniques like encapsulation, tell don't ask, dependency injection, unit testing,...
2. It is important that you do not make any premature decisions regarding your design. Always wait until the last possible moment for making a decision especially if this descision is hard to reverse. This rule can be applied not only to software but to every important descision which has to be made. For example Giuliani writes about this topic in his book Leadership.

Cem Kaner on quality assurance:

"When I was hired at WordStar, back in 1983 (when WordStar was the top producer of word processing software in the world), the test group was called Quality Assurance. The company was attached to the label QA for testers, but as Testing Technology Team Leader, I was able to convince them to change the name, from Quality Assurance to Quality Assistance.

Quality Assistance--that's what testers do. We help. We investigate. We learn things. We report them clearly. We make sure that people understand what we have found and what its significance means. We provide the good data that is so important for understanding and improving the quality of the product. That's important, but it's not "quality assurance."" from The Ongoing Revolution in Software Testing.

Kaner has a valid point with his argument. Somebody can only assure quality if this person has the necessary powers. However most tester will not be able to stop a release if the quality goal has not been met. Furthermore the word assistance lowers the tension between the developers and the QA group. Assisting somebody is about offering help and guidance which is completely different than what assurance stands for.

"Methodologies are like cookbooks: follow their recipes and a successful system will result. Some methodologies are modest in scope and depth, while others contain literally thousands of pieces of work, or tasks, tied together into templates. Each template is appropriate for a specific type of development project" (from Agile Software Development with Scrum)

As the quote suggests processes are like recipes (XP, Scrum, RUP, V-Model, Water****,...) but if you want to apply them successfully you need to know more. You need to know when and how to tweak the recipes. You need to know which ingredients are the most important ones and how they work together. You need to know which tools are crucial, how they work and when to use them.

It's about time that more people start to look behind the recipes...

Found over at swissmiss.