This is powerful if we believe we would benefit from a more profitable Domain Intelligence oriented culture that produces an intelligent network of products in and out of IT.  This, I believe, opens a serious potential for larger organizations.  It is possible to stream-line the value of the Domain under development and to attack and solve business needs by deliberate intelligent design – with or without software as the target. And once you have Domain Intel documented in some organizational ubiquitous format, you can reuse that in collaboration and development on anything that depends on it more readily.

Context Maps, Domain Models, Flow-Charts for manual processes, Tool and Die CAD images, Training for Customer Service – I am scratching the surface and your environment may have a completely different set of needs.

Organizational DIN Helps the Budget?

The DIN focus in this series is designed to advance the usefulness of DDD principles slightly further back up the chain.  Many master craftspeople of Software Development Lifecycles and DevOps  will tell you that solving a bug sooner or getting feedback earlier in the process costs the company far less than if solved further downstream – usually exponentially so.  There is ample reason to believe that similar potential savings could be experienced when working with Information, Knowledge and Intel.  If we appropriately practice Domain Intelligence (DK Knowledge Crunching) where that knowledge gets its genesis, the less it will cost to refine that knowledge for IT projects, even if the use is not for IT.

So how would we use that DIN better in IT?  Currently, many focus it on just User Story creation for those in Agile based workflows.  Let’s explore that.

User Story Heavy?

If you are an experienced User Story writer, then you know how that unfolds.

As an actor I want to do X for some benefit(s).

Great.  And if you are a developer that is all you want from the businesspeople to get maximum freedom to build that thing however you want.  Right?  Be wary the rope with which thy might be hung.

Developers get caught in this trap often and it is sad to see.  I too have been burned.  I finally started to protect the client and myself by not just relying on User Stories alone.  The history of where those snippets of requirements came from often reveals a more detailed picture than a normal User Story or set of them can provide.

Sadly, this is where a ton of finger pointing begins and then the company starts to be the biggest loser caught in these battles.  We lose time, trust and energy.

Example: Drive the Car Epic

Let’s pretend that we could fully describe all we needed to build a car with just DIN flowing into User Stories. You have all the User Stories describing a driver wanting to drive a car so that they can go places complete with taillights, engine power, fuel type and all the rest.  Given that the big picture is spread through a ton of User Stories, do you think  5 teams building aspects of that car would build something worth driving even in 5 iterations?  How about 20?  How about a Bugatti? I am going to say this is less likely than hitting the jackpot in Vegas – twice.

You would want Designs AND User Stories.  And the distinction is hopefully stark.  Think use cases alongside blueprints.

This example by the way is for a car – an object easy to see.  Software is complex partly because you cannot see it unless… you model it.

User Stories Are Not Design

Just as importantly User Stories do not produce Designs.  However, Domain Knowledge crunched into DIN further upstream could quite possibly give us the material we need for both.

Also, code is effectively the operational design, but there is so much accidental complexity when trying to “design by code” that you end up with a Big Ball of Mud or a Hoarder House of Code as I wrote about in my recent post “Big Ball of What?”. The longer a team adds code using that method, the closer they get to a horribly unsustainable code base.

I believe it is better to nail down the real details of the business need and then iterate on intelligent designs using DDD along with User Stories as changes crop up.  This targets a higher quality design, which supports Real Agile.

Let’s explore an extreme example to see what is possible.

Sans User Stories for One Project

What if we just used Domain Knowledge to create a Domain Intelligent model with the derived intel and built a system using that model?  I am not saying you would do this for large teams.  But what if you had control of the project as a sole dev experimenting with this idea, would it deliver better or worse than with User Stories alone?

To play with this, I recently attempted a 6-month C# library project with no User Stories – (oh my!).  Just DDD Aggregated Designs based on existing and mined Domain Knowledge on a whiteboard crunched into DIN. Even without UI in the mix, the complexity existed in the data relationships and the business rules and other heuristic needs.

I did have a Trello board.  It had super high-level content about what to build, above the aggregates, some would say Epic level.  As the design was shifting real time, if something changed at a high level, the Trello board was adjusted to reflect the current state.  The whiteboard was the model surface for more detail work. It was where I documented the Knowledge Crunched DIN from my interviews with the domain experts about the aggregate relationships and the functionality within.   But if there was an Epic adjustment, The Trello board followed the design.  The Trello board….followed…the design.

As the code was getting laid down and I had run into uneasy design issues, I stopped and engaged Eric Evans’ Whirlpool technique to one extent or another.  I would allow myself time and energy to challenge especially the puzzling bits that bothered me about the object graph and the relationships of the Entities and especially the Value Objects and properties that were hard to pin down to a true Aggregate owner.

I would hit a breakthrough and then a bump, Whirlpool, breakthrough…bump…and on and on.  This process morphed the Aggregates slightly each time and I felt a peace about the process as it was just getting better with each pass. Things were fitting well based on the Domain Intelligence I kept collecting from the client.  This is not new in some sense, I have had this experience, but not normally without the contention of competing User Stories.

So, what was the result?  A week before writing this post, the software was put to the test by my client in a very real-world scenario.  100,000 record merge tests through all this dynamic query using some very proprietary concepts unique to the client (CORE DOMAIN) and here is where we ended up from their findings:

• Performance: Outstanding
• Features/Algorithms : 100% functioning
• Bugs: None Experienced (Everything was set to raise/throw)
• Client Response: “Anyone object to putting this under production load and beating the heck out of it.”  Team…”no objections”.

More context?

• Again, no User Stories, just Design based on DIN that was already in motion before and during my modeling of the product.
• Cost, 1 Developer – 3/4 time – 6 months.
• Significant Scope Changes: ~3
• Code Stuff:
  • 0 Errors
  • 0 Warnings
  • 0 Messages
  • Cyclomatic Complexity super low in almost every file
  • VS Maintainability Index in the 80’s, VS doesn’t know DDD though.
  •  About 5000 lines of application and 2600 lines of Unit Testing (I only tested the things that I felt needed a bit of validation through the project not “everything”)  but I know of areas that I can add more robust Unit Tests.
  • As the features were maturing, I found ways to keep line count compressing which is why we don’t see 15000 lines in this product.
  • Generous but safe parallelism wherever I could add it.
  • No ORM.

This is NOT a perfect product by any means.  And I am sure something will come up. But it is not an overwhelming product to support.  I built what they needed based on their Domain and I only engineered it to be as tough as they needed it.  It is what I call a successful project by Real Agile standards and yet I wonder what reaction some might be having given the anti-Scrum process I used?

I like SCRUM to a degree, until we are measured by a double standard where they are not compatible (Outcome vs. Output).  But I digress.

Ok. So Now What?

I fully agree that User Stories help developers see intent of the use of the system. I also fully agree that iterative agile design like Eric Evans’ Whirlpool greatly assists with targeting and creating quality AND sustainable products.

I cannot stress enough that a culture that figures out how to marry Design process with Agile User Story Process by mining for DIN to use for both, probably going to feel a new sense of empowerment to build great enjoyable systems efficiently.

I hope you are imagining what it could look like if your culture started mining DIN corporately to use with more than the software model by now.  Strangely, it often means adopting the Agile Manifesto more intently.  If you want to build a plan to empower your teams in and out of IT with Domain Intelligence, then the first step is the mindset upgrade from whatever is going on in your organization that could prevent it.

These first two posts introduced you to DIN and the power to drive Design and User Stories.

Next we will explore how a company might embed this as a practice and then if possible, measure the outcomes from it.

Until then.