Home | Login | Recent Changes | Search | All Pages | Help

PushbackFromTheTrenches

Sometimes the troops push back. Here are some recent writings that skewer conventional wisdom.

Getting Real, Step 1: No Functional Spec points out some truth about what functional specs are often really about.

This rant on methodologies leads with

Every methodology I've come across has, at its kernel, a very small section labelled "do magic here".

I've read through both of these. I see the push back. However, as the first one notes, they depend on a shared understanding of specs and methodologies. The first says design the GUI first and work back from there. What if we don't plan a GUI? What if, the GUI already exists and we're extending functionality? The second says that methodologies ignore the underlying skills needed. I agree, but I would say it differently. The methodologies assume the skills exist. We may forget that when we go looking for easy fixes. Perhaps Jerry's admonition elsewhere helps: if we think of methods rather than methodologies, then we more readily avoid the magic trap. Methods are tools. We have to learn how and when to use them. -- MikeMelendez 2005.02.13

Jason Fried writes We want to build something we can all start looking at, using, clicking through, and �feeling� before a line of back-end code is written.

Sounds like an NF talking.

Jason Fried writes So what do we do in place of a functional spec? We write a one page story about what the app should do. If it takes more than a page to explain it, then it�s too complex.

The story could be superior to a functional specification document. But I don't know why a story is inherently superior. If you have a poor writer, regardless of whether they are writing a story or functional specification document, the writing will be poor.

The writing process could be used to gain a consensus about what will be done. And that could have value even if the writing is poor.

I am old school. I want to know what the customer requirements are first before doing any design. Perhaps the requirements are assumed to be done. Perhaps the story gives the requirements. I don't know. I would appreciate someone interpretting this aspect for me.

SteveSmith 2005.02.14

Katie ? writes And at the core of RUP is a small area where you have to use OO design talents.... if you don't have them, it's like having a methodology for running the 100m.

I found the next section of the article hilarious. And I agree with her.

She implicitly advocates that if you want to run fast, engage a talented 100m sprinter rather than assuming that a methodology replaces talented people. Katie implicitly advocates that the same strategy -- use a talented person -- if you want to do high-quality OO design.

Let's assume you are a manager of a software development group. You have a talented OO designer on staff.

• How demanding are you that the talented designer strictly uses your company's methodology?
  
  
• What latitude do you give the talented designer to use their own methods?

SteveSmith 2005.02.14

First, every methodology worth a damn has an indication of the skills you need available to get the work done. A methodology is a way to organize the work, not a way to do the work. It's easily conflated because on big part of organizing work is hand-offs between people, for example the hand off between an XP developer and the maintainer who comes along later after the project has spun down. While the story cards may or may not be of any use at that point, the automated tests are - quite a bit, actually. And the API docs. Unfortunately these things look like *ways* to do the work as well as hand-offs.

Second, methodologies are necessarily incomplete in the sense that they require "do magic here." A methodology is a way to orgnaize work that a bunch of people do. If the steps, activities, decisions, etc. could be fully (or economically) specified ahead of time we'd build a machine to do the work and dispense with the people. We don't. Therefore, the activity can't be fully specified (or we'd be on to the next problem.) In fact there are multiple examples of "do magic here" in any methodology. They differ in what magic, when, who does it, working with whom and how the magic is communicated - the organization of the work, in short.

Third, methodologies aren't methods, yet methods have the same problem. If there weren't some magic in doing the methods, we wouldn't need people to do them.

Finally, a methodology like any other kind of technology can be reverse engineered, duplicated, stolen, or knocked-off. The only sustainable advantage is the stuff that isn't on the forms, or in the story cards, or in a pile of books titled "Super Methodology <whatever>." Take care of the people, they're the only advantage you have.

Not that I have an opinion.

-- JimBullock, 2005.02.14 (There's a method to my madness - er - methodology.)