Installment #3 of Complexity-Driven Development

About a month ago, I posted a pair of articles that describe a method I call complexity-driven development.  These two articles discussed the rationale for this method and described a process for how to perform it.

Today, I have posted the third article in the series (http://charliealfred.wordpress.com/complexity-driven-3/).  This article describes a problem to be used to apply this method.  The problem domain is local-area transporation operations, ranging from less than-truckload (LTL) trucking to overnight carriers (Fed Ex and UPS) to embedded delivery fleets (bottled water delivery, resturant supply, uniform service, etc.).

This article discusses the common factors that affect all local-area transportation operations.  It also discusses each of the three contexts to highlight the differences in their current state, pain points and constraints, and desired future states.

This is a complex and rich problem space.  The presence of the three similar, but different, contexts will challenge you to figure out how to address them.  Will a single system be sufficient?  Will three different systems be necessary?  Or is it possible to architect a product family platform/framework that can support high quality systems for each context?   The complexities you discover and consequences you assess will inform you.

A fourth article (in this three part series) will be posted shortly with my application of the complexity-driven development method to the local-area transportation problem.

New Articles on Complexity-Driven Development

I posted the first two articles in a series of three this morning on the subject of “Complexity-Driven Development”.  The titles of these pages are “Complexity-Driven #1″ (http://charliealfred.wordpress.com/complexity-driven-1/) and “Complexity-Driven #2″  (http://charliealfred.wordpress.com/complexity-driven-2/)

The inspiration for these articles was a meeting held at my company several weeks ago.  One of the topics was: “Should we make SCRUM be the company standard development process?”  Now, I am a huge fan of SCRUM and its focus on backlog, iterative development, and daily standup meetings, as well as its requirement for the Scrum Master and Product Owner roles.

But somehow, the question didn’t seem like the right question.  Town meetings are a great idea, too, but I am glad that every municipal decision doesn’t require one.  It was clear that SCRUM should be used where SCRUM fits, and so should written architectures, prototypes, design reviews, and performance benchmarks.

But the question that lingers, is “how do I know what fits?”  I’m not sure that “use your best judgment” is the most effective response.  Over 30 years, I have seen several development projects choose the wrong path, in the name of schedule pressure, religious zealotry, or just the desire to add a new technology to ones resume.

No, I felt that there had to be a more systematic way to answer this question.  And thinking about this led me to the conclusion that complexity (and its first-cousin challenge) is the primary thing that makes software development projects different from each other, and forces them to tailor their approaches.

My hypothesis was that if we could come up with a systematic way to discover and assess sources of complexity in development projects, we would take a big step toward consistently choosing the right approaches.

Complexity-driven development is a meta process.  It is a process of better understanding the complexities in the problem space, with the goal of choosing or constructing the right process for that problem.

Welcome to Charlie Alfred’s Weblog

In this blog, I will try to post challenging, thought-provoking writings about topics related to how systems provide value.  Some of the thoughts contained here follow conventional wisdom.  Others branch off and try to take a very different perspective on this problem.

My philosophy is simple: modern day systems are complicated, in many ways.  And to make matters worse, these ways interact with each other, and the whole mess evolves rather quickly.  As a result, I feel that it is vital that systems architects:

1. Be able to understand how and where value is created by a system.  We spend an awful lot of time and money building complex systems, but too often the result is something that the designers think the users will benefit from, or don’t much care whether they benefit or not (because the system was fun to build).
2. Be able to understand that value varies by context and situation (context is a change in external forces by location or role, situation is a change in external forces by time or circumstance).  This is especially important for product family architecture.  Many organizations pursue product families in order to achieve ROI gains by capitalizing on commonality.  Unfortunately, aggressive exploitation of commonality is often a prescription for failure.  Instead, the critical differences in challenges between contexts/situations must be understood, and a strategy that exploits commonalities while respecting these differences has a decent chance to be successful. 
3. Understand that many different subject matters are an integral part of a system, and many different subject matter experts are needed to uncover and assess complexities.  On top of this, it is critical to realize how much these subject matters interact.  While these interactions amplify complexity, the problem is worse.  Frequently, many of these subject matter experts can be fluent in their own subject, and nearly clueless in others.  This creates a severe obstacle to communication (more specifically, our ability to actually understand what each other means).  Recognizing this situation is the first step toward addressing it.