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 …

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 …

Analysis is a difficult job. It requires capturing the business problem, including the business entities and the business processing. It requires endless patience, good interviewing skills and excellent writing skills. Most important, it also requires the discipline to discover the whole problem before putting forth any solution.

This essay provides …

There is a Design Pattern, sometimes called "Don't Talk to Strangers" that embodies the OO design principle of "Responsibility Assignment". This pattern can also be called "The Opacity Principle."

Sometimes I like to describe it as "If you don't control it, it's none of your business what's under the hood …

I've seen two common varieties of management trump cards. These are played by managers who don't like the architecture, and want to make changes. These are a little bit like the spell cards in Magic:The Gathering. These cards can either change the state of the game (different requirements, context …

Recently, I've seen a number of data structures that evolved from 2-dimensional data models. They devolved into a morass of complications because they started out violating First Normal Form rules. Once that rule has been broken, the door is shut on the benefits of the relational model of data.

For …

The thesis is that the first step in solving a problem is stating it. It's hard to argue with that, but people do.

Here are all some ways that people have made stating a problem as difficult as possible.

1. Complain that there are too many steps in the methodology. For …

How do we get started writing requirements (or doing architecture or even design)?

The important thing is to recognize the what vs. how distinction. Following Pressman's advice, we note a whole waterfall of what 's and how 's. It breaks down something like the following four phases. For information on …