There are two layers of use case authoring and minimal consensus on which level is "right" for any particular purpose.

1. Business Level use cases - ignore the presence or absence of a GUI, and pursue the business problem. This leaves designers free to create any GUI, perhaps one that is not …

We know something is wrong or can be improved, but we lack the will to drill into details and write a problem statement. It isn't a lack of ability, it is purely a lack of will.

A common source of serious issues with software comes from proposing a solution without …

We're told, repeatedly, to avoid changing horses in mid-stream. We're told not to follow the crowd blindly.

Once upon a time, we made a technology decision that -- at the time -- was right. But things have shifted around a bit, and what was once prudence is now folly. When do you …

The challenge in starting a project correctly is to get a problem statement written down in spite of the lack of clue. There is a pervasive unwillingness to tackle problem description because it is so hard. It's hard because there is a potentially lengthy search to separate proximate from root …

See Holub's column "Requirements Gathering" [Requirements Gathering ] for the goods on what is actually useful and what isn't so useful in this activity we call "Requirements Gathering".

I have to applaud the notion that "focus on the minutiae" misses the whole point. A clear problem statement is perhaps more important …

This is what I remind myself to do on a daily basis. It forces me to be problem-focused, not technology focused. It also enforces the design principle of "deferred decision-making".

• Isolate design decisions (via proper allocation of responsibility) so that the final, final decision can be made as late in …

This year's Turing award for human-like Chat Bot announced on the BBC. [article ]

Boing Boing has already noted the Wired article pokerbots on bot's in on-line poker rooms.

I tried posing as a bot in an experiment and failed miserably. I hesitated too long on dumb postings and responded right …

It can be said that software is 'non-linear and time variant. ... The output is definitely not just a function of the current input.'

Whilepossibly true in one sense, the described understanding has to conflate a number of things into "software". The conflation makes it very difficult to take action to …

When we embed explicit constraint checking into a design, they can occur in any of the available tiers: persistence (database), access, model, control or view. Some of these options are easier to consider than others. The view tier, for instance, merely has responsibility for presentation and should be able to …

First, there are several tiers of mutability in requirements in general. These tiers define typical levels of change context, problem and forces that select a solution.

1. Natural Laws (i.e., Gravity). As well as metaphysical "laws" (i.e., reality). These don't change much. Sometimes we encapsulate this information with static …