Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Software development techniques exist to solve problems. I think a key problem we face is conquering complexity. Also, software developers must often classify and understand complex systems, separating accidental complexity from essential complexity. I believe that sufficiently useful definitions of these terms all exist on Wikipedia.

My question is: What techniques are most valuable in conquering complexity, as a professional software developer, and/or software architect?

Answer examplar; a blog post on conquering complexity that seems to be coming at things from a java/c++/OOP centric perspective.

share|improve this question

4 Answers 4

up vote 5 down vote accepted

YAGNI. The best way to avoid accidental complexity is to stop making stuff more generic and flexible than they have to be.

For instance, don't start looking for frameworks and libraries until you actually know that you need them. Instead of solving todays problems, we spend time thinking up potential problems that might arise in the future. Don't do that. Focus on today.

share|improve this answer
I've bee thinking about this for about a week, and I really think this is the most obvious, and correct answer. A lot of accidental complexity gets in BECAUSE WE PUT IT IN THERE. So, sometimes, ya gotta just stop doing that. :-) – Warren P May 2 '11 at 19:36

I find Event Driven Architecture and Command-Query Responsibility Segregation to be the most common techniques I use to conquer complexity.

In a nutshell:

  • UI Controllers submit granular Commands on behalf of the user
  • Command Handlers mutate application state through subsystems (like a domain model, or simply transaction scripts)
  • Changes in application state raise events
  • Event handlers react by submitting more commands and/or interacting with application services (updating auxiliary data for display, sending emails, etc., etc. - a lot happens here and this is the main method of decoupling auxiliary logic from that logic that modifies the application state)

On a large scale, I try to stick somewhat rigidly to the send a command, handle the command, raise events, handle events pattern - it can lend large scale organization to a variety of project types.

Then, I allow handlers to achieve their function through whatever mechanism seems appropriate. These mechanisms form sub-components of the application like a domain model with persistence, loggers, email helpers, etc.

Allowing flexibility in the implementation of these sub-components enables agility (write it to get it done, if need be), code reuse (whether linked library or copy and paste), refactoring (let's base off of this previously written component but improve/change it as so).

But sticking to EDA & CQRS gives us some architectural consistency across projects, which makes navigating a foreign code base much easier. It also provides nice points to implement functionality with AOP - like authorizing & recording commands, persisting events, distributing workload, etc.

share|improve this answer
It should also allow components to be written in the language that suits them best. – Christopher Mahan Apr 25 '11 at 23:08

Hands-in the Pocket Explanations.

(The phrase comes from this:

If you can't explain it with your hands in your pockets, it's too complex. Simplify until you can explain it.

It helps to summarize use cases, architectures, design patterns, programming idioms and the like as short, easy-to-grasp stories.

This usually means that you have to create meaningful chunks or abstractions tht have to be isolated and explained separately.

These chunks are not programming language monstrosities, but are actual useful simplifications. More like the "class" vs. "instance" nature of abstraction than the "abstract superclass" vs. "concrete superclass" problem where the OO mavens have gone crazy.

share|improve this answer

I found the following helpful to reduce complexity:

share|improve this answer
Especially think "Bottum Up design" is powerful, and using an expressive language (perhaps that means, high level). – Warren P Apr 26 '11 at 1:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.