Conquering Complexity: Valuable techniques

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

Hands-in the Pocket Explanations.

(The phrase comes from this: http://portal.acm.org/citation.cfm?id=70024

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.

Answer 4

I found the following helpful to reduce complexity:

• Using a High Level Language, like Python. Not always possible, though.
• Programming Bottom-Up.
• Writing Unit Tests early.
• Refactoring, with high focus on DRY, using a Refactoring Tool.
• Using Design Patterns, but only when appropriate.
• Minding the SOLID Principles when doing OOP.
• Running Source Code Metrics Tools frequently, esp. measuring Cyclomatic Complexity.
• Avoiding Hungarian Notation and other naming pre/fixations obsessions, for health reasons.
• Stop confusing concrete vs. abstract with specific vs. general.