"Sometimes creativity just means the daily work of helping others to see a problem in a different way."
Joseph Badaracco

"Man will occasionally stumble over the truth, but most times he will pick himself up and carry on."
Winston Churchill

"It usually takes more than three weeks to prepare a good impromptu speech."
Mark Twain

"Use models to find out how things work or to find solutions to puzzling dilemmas. Create models to communicate ideas and understand things you can’t see. Recognize models and the countless ways models are used for working, playing, teaching and explaining. Assess models for what they do and don't tell you about the real thing and how useful they are"
Boston Science Museum

"Our failure to master the complexity of software results in projets that are late, over budget, and deficient in their stated requirements."
Grady Booch, Object-Oriented Analysis and Design, 2007

"The fundamental task of the software development team is to engineer the illusion of simplicity"
Grady Booch, Object-Oriented Analysis and Design, 2007

"Abstraction can reduce complexity by spreading details across a network of components"
Steve McConnell, Code Complete: A Practical Handbook of Software Construction, 2007

"Simplicity is the final achievement. After one has played a vast quantity of notes and more notes, it is simplicity that emerges as the crowning reward of art."
Frederic Chopin

"If you can't explain it simply, you don't understand it well enough."
Albert Einstein

"Important developments often arise out of analogies. By comparing a topic you understand poorly to something similar you understand better, you can come up with insights that result in a better understanding of the less-familiar topic. This use of metaphor is called 'modeling.'"
Steve McConnell, Code Complete: A Practical Handbook of Software Construction, 2007

"The structure of a software system will reflect the communication structure of the team that built it."
R. E. Fairley

"We apply the analytic procedure in order to create a conceptual framework within which we can draw conclusions about the means by which a system solves its tasks. Indeed, we do this with the express purpose of establishing a solid foundation from which we can carry out a subsequent synthesis. This synthesis, in turn, acts to verify the conceptual model as an explanation. The process is an iterative one."
Tom Ritchey, Refactoring, 1991,

Great software design mercilessly strips away unnecessary compleixty and hides unavoidable complexity behind better abstractions.

Designing good software is a constant battle with complexity. Great software designers know this and mercilessly strip away all unnecessary complexity. They are intolerant of unnecessary complication, flexibility and cleverness in designs and code. Nevertheless, some complexity is unavoidable, often where performance needs to be optimised or when, ironically, it is needed to create an illusion of simplicity in the user experience. Here, good design encapsulates the complexity, hiding it behind much simpler service-oriented and object-oriented interfaces of carefully selected abstractions. The best software designs are ingeniously simple or at least present a perception of simplicity to their users. The elegance of such solutions can be truly delightful.

Understanding the Problem

Great software designers know that one of the primary keys for creating simple, elegant designs is an intimate understanding of the structure and dynamics of the problem they are trying to solve. They also accept that for more complex problem domains, this is always and iterative process and analysis cannot be fully separated from design, implementation, and testing too.

One of the most documented problems of the old waterfall Critical to doing this is an intimate understanding of the domain you are working within, the inevitable trade-offs of the design options available, and a passionate intolerance of low quality work. This is regardless of whether we do all the analysis and design within dedicated phases of a traditional, waterfall-style process or iteratively as part of a modern agile approach.

Modeling in Colour
One of the very best techniques for initial analysis of the problem domain of an enterprise software system is Peter Coad's somewhat simplistically-named 'modeling in color'. The culmination of a number of years work by Peter Coad and colleagues, modeling in colour is a set of concepts, strategies and patterns for fast, pragmatic, problem domain analysis for both agile and traditional development teams. It helps pick better domain classes quicker and gives your software a more resilient, extensible foundation; far less serious refactoring needed later.

All teams working in .Net, Java or Cocoa have some sort of object model at the heart of their software. Modeling in colour helps ensure it is robust, flexible, and extensible from day one. Use it with a Scrum-like approach to produce a better backlog earlier, or as an integral part of a more Feature-Driven Development (FDD)-style project.

The Unified Modeling Language (UML)
Since the turn of the century, the Unified Modeling Language (UML) has been the de facto graphical notation for modeling and communicating software analysis and design. From its relatively simple start, UML grew into a large, over-complicated, clumsy, and frequently impractical standard. Nevertheless, the enormous benefit of a common, shared notation for software analysis and design means it remains important. Thankfully, it is not necessary to learn every different symbol and squiggle of the language to use it. Like any language, you only need to know a very small proportion to be able to communicate effectively. Neither do you need an expensive UML modeling tool to use UML. The best UML tools for the job are often coloured, sticky notes, flip-chart paper, and marker pens.

Java/J2EE Design
Notes on various aspects of designing applications, components or systems using the standard and enterprise editions of Java. Although details may differ, the design principles are often just as applicable for .Net languages such as C# and VB.Net and developing in Objective C and Cocoa.

Miscellaneous Analysis and Design Topics
A set of introductory notes and notes on topics that do not fit naturally into any of the other categories above. Topics range from object modeling to list management and layered architectures

Simple designs don't mean less work, they mean more thinking.
Jim Highsmith, InformIT Article, 2002

Four Logical Layers
One of the most common initial strategies for selecting the types of object needed in a software system, service or component is to define a set of logical layers into which we can place candidate classes. There are various layering schemes but they are generally variations of a similar theme.
Read the full article...

Object Modelling: Why would I waste time doing this?
All software teams writing in programming languages like Java and the .Net family of languages have an underlying object model represented by the classes of objects they define in their source code. Therefore, it is not a question of whether to build an object model or not...
Read the full article...

Object Modeling in Colour
Object-oriented analysis with class archetypes: 'Modeling in Color' is a set of patterns and strategies that can help produce better object-oriented analysis and design models.
Read the full article...

Model Archetypes
'Modeling in Color' is a set of patterns and strategies that can help produce better object-oriented analysis and design models...
Read the full article...

Follow me on Twitter...