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 …

Is data more important than processing? Not necessarily; the central issue is one of enduring impact on the problem, solution, architecture and implementation.

Generally, the available or desired data has the most enduring impact. Processing, functionality, user interface nice-to-haves and other considerations are much softer and more malleable than the …

Architecture is the first step in creating software to meet the requirements. This is followed by the design effort to transform the high-level picture into components that can be realized in software. This line between assemblies of components, and the internal construction of components is a good dividing line between …

Politics are the lifeblood of requirements gathering. For architecture, they are important, but don't as often take center stage.

Requirements are about the actors, their goals and motivations, and their interactions with some potential system. People are political, and the presence or absence of certain requirements, certain turns of phrase …

Requirements have a number of uses.

1. They document progress. This management value is sometimes the only value placed on requirements. This happens when requirements are really just high-level design and don't describe the problem adequately.
2. They test candidate architectures. This is done well when there is a back and forth …

Walker Royce notes that the early parts of a project involve discovery; as a consequence the scope is subject to change. He calls the early phases inception and elaboration. Inception identifies the need for a project, and stakes out an initial context and problem. Elaboration adds details, including the constraining …