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”
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”
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”
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?