Sometimes, the models we use are predictive (like yesterday) or are analogies. For example, e-mail is a pretty straightforward analogy to snail mail; you have a send, receiver, addresses, transfer mechanism, routers, and so on. In many cases, the analogy (or prediction) is helpful; you what to expect and how to behave.
Then again, like the famous outside-the-box problem, analogies can limit our thinking. Consider, for example, the term 'requirements gathering', which for me always brought an image of a child on an easter-egg hunt. The requirements are right there; just go collect them. In that model, requirements are a contract – customers tell the technicians what they want, then we haggle over the price (schedule), sign the contract, and develop.
Except in software, the contract is not static – it's fluid. Oh, and English is a vague and ambiguous language, so when we communicate solely in written words (like a typical contract), we are losing information. Plus, with this model, if the developers have a better idea "gosh, if we knew zip code, we could call out to the mapquest web service and ..." they do not have a mechanism to contribute the idea to the software. (And don’t even think about testers contributing ideas!)
The contract model can work for certain kinds of software – for example, avionics software that has to go on a new helicopter for the department of defense. Given an incremental improvement to a well-defined, state-based system, you can both state requirements precisely and limit change. That is not software development; it is software engineering.
... And most of my project just aren’t like that. On most of my projects, the contract model is a joke. Instead, I prefer the defense-lawyer model, which works like this:
The customer has a problem. He does not understand the technical jargon and doesn't have the education or tools to solve the problem. So he hires a lawyer. The lawyer makes the plan, and the customer can over-rule the lawyer on key decisions (how to plead), or, if he is not happy, fire the lawyer. Ideally, the two work together in collaboration, admitting that if they do not, the project will have much less chance of success.
For commercial software with at least hundreds, if not tens of thousands of customers, you don't even have a customer to write the "contract." Instead, you have to invent roles like business analyst or product owner. That's fine, but sometimes the limits imposed by the model aren't real – they are simply part of the model.
Now, on a real contract, all elements of the contract can be negotiated – not just price and schedule. By not mentioning that earlier, I’ve limited the model by omission, making it worse.
We humans do this all the time. As much as this is a problem to avoid, it’s also a huge opportunity. When your competitors get trapped in an analogy, *you* can break out of the analogy.
This doesn't sound like much, think of what it could mean for version control software, email, file systems, or any other piece of software trapped in a metaphor. Look at what google did with search, using back-links instead of a dewey-decimal system metaphor. Think of what they did with email with "search, don't sort". Think of what developers are doing with AJAX and mashups – taking two different web services and combining them in interesting ways – or what testers are doing with random, automated testing instead of a traditional list-checklist-verify model.
Sometimes, people get it wrong. Sun spent years trying to change the model from PC-centric back to the mainframe using the term "thin client." (Eventually, that happened anyway, due to the web browser, not Sun.)
As I mentioned above, models can have a lot of value. But, often models can be like the stock market: By the time everybody is buying, it's probably time to sell and find something else ...
The contract model can work for certain kinds of software – for example, avionics software that has to go on a new helicopter for the department of defense. Given an incremental improvement to a well-defined, state-based system, you can both state requirements precisely and limit change. That is not software development; it is software engineering.
... And most of my project just aren’t like that. On most of my projects, the contract model is a joke. Instead, I prefer the defense-lawyer model, which works like this:
The customer has a problem. He does not understand the technical jargon and doesn't have the education or tools to solve the problem. So he hires a lawyer. The lawyer makes the plan, and the customer can over-rule the lawyer on key decisions (how to plead), or, if he is not happy, fire the lawyer. Ideally, the two work together in collaboration, admitting that if they do not, the project will have much less chance of success.
For commercial software with at least hundreds, if not tens of thousands of customers, you don't even have a customer to write the "contract." Instead, you have to invent roles like business analyst or product owner. That's fine, but sometimes the limits imposed by the model aren't real – they are simply part of the model.
Now, on a real contract, all elements of the contract can be negotiated – not just price and schedule. By not mentioning that earlier, I’ve limited the model by omission, making it worse.
We humans do this all the time. As much as this is a problem to avoid, it’s also a huge opportunity. When your competitors get trapped in an analogy, *you* can break out of the analogy.
This doesn't sound like much, think of what it could mean for version control software, email, file systems, or any other piece of software trapped in a metaphor. Look at what google did with search, using back-links instead of a dewey-decimal system metaphor. Think of what they did with email with "search, don't sort". Think of what developers are doing with AJAX and mashups – taking two different web services and combining them in interesting ways – or what testers are doing with random, automated testing instead of a traditional list-checklist-verify model.
Sometimes, people get it wrong. Sun spent years trying to change the model from PC-centric back to the mainframe using the term "thin client." (Eventually, that happened anyway, due to the web browser, not Sun.)
As I mentioned above, models can have a lot of value. But, often models can be like the stock market: By the time everybody is buying, it's probably time to sell and find something else ...
No comments:
Post a Comment