Ivar Jacobson's Smart Practices

Here's a neat little article that provides several quotes from Ivar Jacobson regarding current Agile practices and software methodologies in general.

The really cool part is the juxtaposition of what Jacobson considers to be smart and un-smart practices - and I tend to agree with him. Here are the top three I can pick from that list (in the order they came in at that list).

• Unsmart with Projects – Trying to follow a waterfall approach
• Smart with Projects – Build a “skinny system” to demonstrate that you have eliminated all the critical risks, then add more capabilities on top of that skinny system as needed.
  
  “Think big, build in many steps”

I work at a shop that essentially uses a waterfall approach. Nothing is really done iteratively with very little to no prototyping - outside of a rare alpha delivery here and there. What unfortunately ended up happening was lots of debate and wasted time with up front planning, no one group owned the full architecture (as there wasn't buy-in up front), implementers of a project shoved everything out in one go using the same technologies that were selected up front without knowing, through the use of a prototype, whether they were the right tools for the job. Time then gets wasted during the "death march" period fighting problems that could have been identified up front with a prototype.

That basically results in two instances of wasted time and contention - once up front because everyone tried to get the implementation correct on the whiteboard in their own way instead of in code, and a second time because everyone ends up dealing with a design problem during the construction process because the design wasn't correct. This has been written about at last as far back as Steve McConnel's first edition of Code Complete in 1993 - and probably even further back than that. It seems we haven't learned much as an industry since that point if well known names in the software industry are still having to give talks decrying the waterfall methodology as a common pitfall in today's practices.

• Unsmart with Testing – having two classes of people – developers and testers. Unsmart projects testers are “the cleaners in the software world” – picking up the mess left by the developers
• Smart with Testing – the whole team is jointly responsible for quality and testers are first-class citizens
  
  “Whatever you do, you are not done until you have verified that you did what you wanted to do”

In a shop I've worked at, I have seen the "Unsmart with Testing" scenario crop up as well. I've heard straight from the mouths of developers that "our job is to write code, we don't need to test our code at all, that is QA's job", to the point that 10 minutes would not be spared for a member of that time to run a quick smoke test on a build before it was delivered to QA. Additionally, no form of automated unit testing was being performed by this team, essentially leaving all formal testing up to QA folks. This is the epitome of not owning your own work. It also did not help that at this shop many QA folks were not especially savvy at describing and reporting bugs or helping developers find issues. It was the stereotypical example of a place where bugs were just tossed back and forth over a very thick brick wall with no communication.

The point here is that developers should own the testing of their code and QA folks should be proactive in helping resolve bugs. To provide concreteness to that assertion - developers need to 1) write automated tests for their code up front 2) write automated tests that reproduce bugs deliver by QA 3) take at least some time to work with QA members on the resolutions of bugs. QA folks also need to 1) make the developers lives as easy as possible by not only owning the reporting of bugs, but by helping see them to resolution b) provide concrete steps and extremely detailed pieces of information in every peice of communication given to developers - "It doesn't work" is always the wrong piece of communication in this case.

• Unsmart with Documentation – slavishly filling in a document template because some process rule says it has to be there
• Smart with Documentation – recognize the “law of nature: people don’t read documents”. Document only what is absolutely needed
  
  “Focus on the essentials – the placeholders for conversations – people figure out the rest for themselves”

I'm wary of this, as I think documentation of any form is better than no documentation than all (which is debatable). However, I feverishly oppose enforcing documentation by template any chance I get - if the documentation writing is manual. The only documentation that ought to be placed in a template needs to be something automatically generated - such as bug resolution reports from an issue tracker, or something like javadoc or maven site generation.

Beyond that, documentation should be treated like like creating the software itself - make it an iterative process. Document only what is necessary and when the gaps need to be filled in, they get filled in. This is why wiki's as documentation are a powerful thing. Developers need to spend time in their tools and in conversation with other co-workers, not time in Microsoft Word or whatever the editor of choice is.

What are your thoughts and takes on Ivar's list?