Virtual Method 2015 - IDesign Anti IDesign Virtual Method Iteration... · Virtual Method 2015 ......

©2015 IDesign Inc. All rights reserved www.idesign.net January 11, 2015

- 1 -

Virtual Method 2015

Iteration 1: The Anti-Design

Moderator: Jarkko Kemppainenwww.idesign.net


- 2 -

This document contains the summary of iteration 1, the anti-design exercise of the 2015Virtual Method conducted with the IDesign Alumni. The goal of the exercise was toprime the participant to recognize bad design decisions by explicitly designing the systemas closely as possible to the requirements. This is also known as functionaldecomposition. As discussed at length at the Architect's Master Class, by creating adesign that is tightly coupled to the requirements the design becomes brittle guaranteeingpain later on when the requirements change. Such systems are also notoriously difficult tobuild. It is these vulnerabilities that you need to avoid in subsequent iterations where wewill create a design that handles changes gracefully. Let me start with some credit for theparticipants, showing some of the proposed anti-design solutions in Figure 1.

Figure 1. Anti-Design Art.


- 3 -

The Seven Deadly Sins of Design

The anti-designs the Alumni presented by and large fell into seven categories. The firstthree (the void, the wall of empty text and the big ball) are all forms no-design designwhere the architect is just passes the buck to the developers.

The Void

The least harmful of these is the void. At least you are explicit about the fact that youhave done nothing useful as an architect.

The big client, the chain of shame and the epic pie fight were also common categories ofanti-design solutions presented during this exercise. As you will see shortly, these threeare typical the result of functional decomposition.

The 7th category of deadly sins of design encountered during this exercise was the bigdata where the business logic was all in the stored procedures or the systems wereotherwise tightly coupled to the database.

A picture-perfect example of the no-design design in the form of the big ball incombination with the wall of text was presented by Peter Rietmann. All of the complexityof the system resides inside the “TradeMe Website” shown in Figure 2.


- 4 -

Figure 2. Nothing wrapped in a pretty template.

The Wall of Text

The wall of text with of a lot of meaningless verbiage resides in many of the standardarchitecture templates in common use today such as in Figure 3.

Figure 3. Content-free architecture.

In no time this meaningless gibberish will fill out the pages (see Figure 4) giving thearchitect and the management a false sense of accomplishment, and the developers thesense that architecture is a completely pointless exercise of ivory tower architectsdisconnected from the reality of software engineering.


- 5 -

Figure 4. Wall of Text I. Ten pages of nothing. This is partial - there were in fact more pages!

In organizations where the real brains are the senior/lead developers and not the so-calledarchitects (and there are many of these) this no-design design is probably the only viableoption to architecture. Let the godsleads sort them out (in the detailed design phase).

The wall of text of Peter was hiding inside an architecture template. George Stevens inhis anti-design (Figure 5) omits the design and describes the big ball. Overladen incynicism, I had as much fun reading it as George had writing it.


- 6 -

Figure 5. Wall of Text II.

Comparing Peter’s and George’s solutions, Peter’s is more insidious because there isdecomposition unlike in George's solution and since it looks simple and easy (it even hasservices). There is a danger that this kind of a design could get approved. George’sdesign is very functional, but because it has no decomposition most organizations willreject it. However they will accept it if George were to just go one level deeper by puttingin services most of the code that was supposed to be in the forms (and stripping theobvious nonsense of the no database). This is a clear indication that functionaldecomposition is bad because fundamentally nothing has changed in the way ofencapsulation.


- 7 -

The void, the wall of text and the big ball, even though all are bad designs, sadly allfailed the anti-design effort because they did not satisfy the validation requirement. Topre-empt the “but but but, everything happens in the big ball” argument most of you whocame with the big ball got Southparked: The Gnome Plan is not a validation:

Figure 6. The question mark is the big ball.

The Big Client

Many of you came with the fourth deadly sin of design which is the big client (see Figure7). The big client is the result of functional decomposition where you are basing yourdecomposition on the logical flow on steps and activities in your requirements and usecases. When you base your design directly on the required activities somebody upstairshas to stitch them together and this somebody is often going to be the client.

Here the client is responsible of orchestrating the behavior of the system. This alwaysbloats the client code because practically nothing useful can be placed in the businesslayer. Also there is no way of re-using the orchestration in another client or technology.

Figure 7. The Big Client.


- 8 -

Luke Warneminde came up with the example in Figure 8 of the big client. Luke hasomitted the data access blocks which has made the design very brittle. However he stillhas perhaps some meaningful encapsulation in the different managers and therefore thisis not 100% functional design.

Figure 8. Luke's big client anti-design.

Shamus Fuller’s Mega Client Orchestra has a client is pulling and pushing data to all thecomponents. The components are practically directly picked from the use cases and therequirements and are therefore more functional and more tightly coupled to therequirements than in Luke’s big client example. Shamus's design is clearly valid (seeFigure 9) as it supports the requirements. Had he placed the calls directly to the databaseinstead of using data services this would have even more coupled design.


- 9 -

Figure 9. Shamus' big client anti-design.

Todd Gleason’s big client is almost purely functional decomposition and the call chainobviously validates. Todd was one of the very few that resisted the urge to have a dataaccess layer. His forms call the database directly (why else would Microsoft make it doeasy to drop connections on forms?). Note the “beautiful” database initiated callbacks.Yes, you can actually do this:


- 10 -

Figure 10. Todd's big ball client. All the forms are wired directly to the database.

The Chain of Shame

The fifth sin is the chain of shame where the business logic is chained together in steps.Figure 11 shows the one that Eric Fischbein cooked for us with his second crack at theanti-design.

Figure 11. The Chain of Shame.Note again how functional this decomposition is, where every step in the chain is directlymapped to a specific requirement. Besides the fact that you have to construct such a chain


- 11 -

for every permutation, there is almost no chance of reuse across chains due to theassumptions on the order of the components and the pre and post system state after eachcall. The other danger with chaining a system together like this is the excessive bloatingthat often occurs. Add-Tradesman Component (A) is directly coupled to Process Payment(B) but also it must be able to handle any parameters that need to reach ApproveTradesman (C).

Figure 12. The upstream components are coupled downstream components causing excessivebloating.

Unfortunately the situation is much worse because if you want any kind of meaningfulrobust functionality of the system you will come into trouble with the edge cases anderrors. If the calls reaches C (Approve Tradesman) and then blows up it somehow needsto be able to undo B (Process Payment) and this would create incredible complexityfusing all these objects together. The system would very quickly blow up in complexity:

Figure 13. Are these really independent autonomous services anymore?


- 12 -

Functional decomposition by definition is lacking in proper decoupling of responsibilitiesfrom each other. This causes the intricate relationships inside and between thecomponents to manifest themselves in the code. When this has become overly evidentyou have committed the sixth deadly sin of design which is the epic pie fight.

The Epic Pie FightThe epic pie fight of Figure 14 is an open architecture where any call in any direction isvalid and is often required.This causes enormous amount of coupling, both in code and in organization. Becauseeverything is tied to everything else every time there is a change to the system alldevelopment is affected creating turf wars and excessive time spent in meetings.

Figure 14. The pie fight.

Chris Yoker went all out with the glue gun and created the mess in Figure 15. Note heretoo that there still is some meaningful encapsulation in the business logic. It could beworse.

Figure 145. The revenge of the glue gun I by Chris Yoker.


- 13 -

Jonathan Bourke’s pie fight of Figure 16 stands above all else. Note that this is even morepure functional design than the one from Chris because the steps from the requirementsare directly mapped to the design without a hint of abstraction or encapsulation:

Figure 15. Jonathan Bourke's Pure functional design.

The Big Data

Very common anti-design encountered in the wild and also during this exercise is the bigdata.

Lars Athle Larsen strolled back into memory lane and recalled a previous employerstating something like “The database is the common thing, so why don't we make use ofthat fact through stored procedures. They can do almost everything these days, youknow.”Figure 17 shows Lars with his big data:

Figure 17. The Big Data, because who needs those pesky business layers anyway?


- 14 -

And the winner is…The best anti-design is not synonymous with the worst possible design. The point of thisexercise was to prime your senses to recognize bad design decisions that couple yoursystems tightly against the requirements. Also the anti-design has to have relevance.Something that is rejected outright or is practically never encountered in the wild doesnot serve a purpose from practice point of view.

It was not easy to pick the winner. Shamus Fuller and Todd Gleason both presented verygood examples of an anti-design. However I declare Jonathan Bourke as the winner ofthis iteration. He had the best literal translation of the exercise. The design is valid, isfunctional, there is no encapsulation, demonstrates tight coupling and it is very commonin the wild.


- 15 -

School Solutions

Functional decomposition directly from the requirements leads to an explosion ofbuilding blocks as in Figure 18.

Figure 18. The eighth sin. Explosion of building blocks.

Figure 19. Chain of shame within the explosion of building block. Good luck maintaining this!


- 16 -

The same use case, now as a big client is in Figure 20.

Figure 20. The big client call chains.


- 17 -

Often functional decomposition comes in disguise, in the form of domain decomposition,basically decomposing along the domain line as in Figure 21.

Figure 21. Functional design along the domain line.

Functional decomposition along the domain line. Note that it is almost impossible tovalidate the call chains just like in the big ball design sin (see Figure 22 and Figure 23).

Figure 22. The encapsulation along the domain line is too coarse to get a meaningful validation of thearchitecture.


- 18 -

Figure 23. Important nuance is lost when composing along the domain line.

Domain decomposition leads to the domain objects becoming ugly dumping grounds ofthe required aspects and features of the domain, where each just absorbs more and moremethods reflecting the activities. Furthermore, these will almost always have to berepeated and duplicated in subtle ways in the various domain objects. For example,RequestTradesman() will appear both on the ProjectsManager and TradesmanManager.

Date post:	04-Jun-2018
Category:	Documents
Upload:	lydang
View:	229 times
Download:	0 times

Virtual Method 2015 - IDesign Anti IDesign Virtual Method Iteration... · Virtual Method 2015 ......

Documents