brainsnorkel.com

A long time ago this was posted on HackNot. I thought I’d tidy it up a little and re-post it. It remains more than a little random and paternal, but I’ll update it as I go and see if the treasure to trash ratio increases.

Requirements

* Humans read requirements.
* Humans lose interest if they can’t understand a requirement.
* Humans lose interest if they don’t know why a requirement exists.
* There are no desirable requirements for this release. There are only desirable requirements for the *next* release.
* Requirement numbers should never contain the section number of the document they are in.
* A requirement only needs to require an implementation in rare circumstances when you need to require a point of concrete integration.
* Requirements should be testable. If you write a requirement that may be hard to test, write supporting notes about how you think the requirement could be tested. Testable means that a test is possible - do not restrict yourself to requirements that you can test with your available resources, but expect to justify them.
* Track requirements met during development by mapping requirement coverage to test results
* Because a customer asks for a feature to be implemented, that alone doesn’t make it a good feature
A man walks into a hospital having already diagnosed himself with prostate cancer. He demands that a surgeon operate immediately to remove the cancer. The surgeon operates. The man is caused inconvenience, discomfort and pain for the rest of his life from side-effects of the operation. The surgeon could have refused to operate, or consulted more, because most prostate cancer sufferers die with, and not because of, their prostate cancer. The surgeon gave the man what he asked for and not what he needed.
* A customer with multiple needs, may need more that one solution
Q: What can you brush your teeth with, sit on, and telephone people with?
A: A toothbrush, a chair and a telephone.

Performance

* Specify performance early.
* Always specify time and space performance.
* Optimize late.

Documentation

* Styles in Microsoft Word are your friend. If you want a Word processor, use Word. If you want a typewriter, use Notepad.

Reuse

* Beware the “framework.”
* Spurn the “reusable component.”
* It’s hard to specify a reusable complonent or framework because what users *might require* is always infinitely larger than what they’ll need for sure.
* “You ain’t gonna need it.”
* Your customer wants to pay for a solution for their problem, not everyone else’s.
* Designing for reuse typically introduces complexity. Complexity invites bugs and discourages reuse.
* Designing for reuse typically involves requirements compromise and schedule overhead.

* “Found object” reuse can be fostered with open access to source repositories, good design and documentation.

Technologies

* XML: it’s just a verbose way of representing structured data.
* SIP: it’s just a signalling protocol.

Projects

* Try not to build release 2 before release 1 has any customers
* When someone says “I know this is a death march, but you will be rewarded well regardless of whether you succeed or fail,” run (away) like the wind.

Peopleware

* Habitable development environments clearly define the level of cleanliness required.
* Habitable development environments have management who solicit, and listen to, criticism.
* Give directions in positive terms.
* Avoid saying what shouldn’t be done.
* Toddlers and software engineers want to please you, and do the right thing.
* Toddlers and software engineers hear “Don’t do X” and become paralysed with uncertainty because they now know for sure what they shouldn’t do, but can’t figure out what you *do* want them to do.

User Interfaces

General

* User interfaces are design, not requirements.
* Usable interfaces should not be innovative. If it’s clever or tricky,then it’s probably confusing.
* Users don’t use the right mouse button instinctively.
* It’s hard to know when to double-click unless someone shows you.
* Icons are hard. They don’t have to be intuitive, but they should be pretty and make sense once you know what they represent.
* Love the one you’re with. Try not to fight the operating system you’re on.

Trees

* Users don’t use tree views. Users don’t get trees.
* Users only (very) rarely see trees on computers.
* Developers love trees.
* IDEs have trees.
* Windows file explorer shows a tree.
* Most users never see or use tree-views when they’re using Windows (or Macs) and don’t find them comfortable.
* Windows explorer is hidden in the Start-> menu (it’s an “Accessory”) and where the “My Computer” icon is (on the Desktop) and what happens when you double-click it
* You have to go deep into most applications if you want to see a tree view.
* The standard Windows application file (save/open) dialog does not show a tree.
* A tree is not an easy metaphor. When was the last time you saw a tree of manilla folders? (There’s an art project in this somewhere)

Miscellaneous

* It’s hard to write requirements unless you’re ears are being pounded by “doof doof” music
* Unfinished Sympathy is the finest pop song ever written