Igor's Blog

"... no matter what they tell you, it's always a people problem!"

Thursday, July 16, 2009

Modeling for Domain Evolution

A constant goal of mine is to express intent while developing software systems. In the begging, I spent a lot of time trying to create a better Object Oriented Design hoping that the abstraction level would be enough to clearly represent a business model. Of course, this wasn't enough and I continue looking for better abstraction levels.

The next step was my obsession with Design Patterns and Frameworks. Common understanding of the problem, at least among developers helped a lot but business people still couldn't easily relate a system solution to the actual business model.

Continuing in that direction led me to discover the incredibly valuable book - Domain Driven Design and just a little later the somehow related concepts behind an interesting but not very popular framework called "Naked Objects". Domain Driven Design was huge advanced towards expressing intent and introduced an invaluable concept about ubiquitous language.

At that point, the level of abstraction was pretty good in relation to designing domain models, but specifying the behavior of a system was somehow problematic. Again, mostly a change in the perception and the way of thinking rather than technology advances led me to the concept of Behavior Driven Design. Specifying system behavior in an executable way was an impressive step but a little hard to achieve with the current static programming languages that most of the systems were build at that time.

Didn't take me long to discover the disruptive power of dynamic languages like Ruby and all meta programming concepts that came with them. Additionally, I discovered a much different way of designing APIs in the form of Fluent Interfaces. That allowed me to express business intent through a software solution in an almost natural english language form that business people could start understanding.

Interestingly enough, it turned out that even this is not enough because of a simple fact - business people use a natural language only to define different specific languages that better describe their business domains. Well, not surprisingly this realization led me to the concept of Domain Specific Languages (DSL).

After the initial euphoria of designing and implementing Domain Specific Languages, I start looking for the same impressive tool support that I was used to while working with other well established general purpose programming languages. It turned out that there is not a better time for that with current release of most of the main players in this area (Intentional Software, JetBrains, MS Oslo, Eclipse xText,...) delivering solutions for a really disruptive concept summarized as Language Workbenches.

In order to visually represent this path towards delivering better software solutions, I created "My Curve of Abstraction Towards - Expressing Intent & Ubiquitous Language"

I don't know if DSLs and Language Workbenches would be successful in practice, but those concepts would definitely change the way in which I approach and design software solutions. In most of the system that I have built until now I used programming languages to specify a domain model and the behavior of a system. Recently, however, I worked on software solutions that had to be model for domain evaluation. Basically, I used programming languages to define a business model definition and structure via other languages and notations, or so called Language Oriented Programing.

This is actually the topic in my presentation that I gave recently called - "Domain Specific Languages- ... a forgotten interface metaphor with renewed tooling support".

Labels: ,

|| Igor, Thursday, July 16, 2009 || link || (0) comments |

Wednesday, July 15, 2009

Agile within Constraints: Embrace Kanban Limits

Every time when I try to introduce Kanban ("visual card/board") Lean system in an Agile team I got the same question - Kanban looks exactly the same as the current index card board, so what is the difference? As I mentioned in my previous post, the main difference that really defines a Kanban system are limits. Logically, the next question to follow is why we need limits.

Well, there is a problem that I see occurring often with the basic index-card task board. There is nothing to prevent accumulating a big pile of story cards that are work in progress. Usually, the bottleneck could happen in multiple places. Sometimes, it is the huge backlog that is constantly and prematurely prioritized, other times it is the familiar pattern of busy developers in the beginning of an iteration and busy BAs and QAs at the end of the iteration. More often than not a big story card queue for testing is left beyond a current iteration without any timely feedback.

Actually, an iteration, which is central part of an Agile practices is a natural time-boxing constraint to how much Work in Progress can be accumulated. However, the time-boxing limit doesn't help in optimizing the overall team workflow and throughput, doesn't avoid premature work.

Let's take a common example of an agile story board:

I see some bottleneck from the pile of story cards in the testing backlog on the picture above but I can't tell for sure if this is a problem. I don't know what the team testing capacity is because looking at the story board I don't see visual indication of the current limit - the time left to the end of an iteration.

So, I have to wait to the end of the iteration to know for sure if there is a problem and I would still not find out where the bottleneck is. Even if all the story cards are completed on time, the basic index-card task board with time-boxing limit show team progress during an iteration but doesn't indicate whether the team has optimal throughput. Also, accumulating a big backlog at some stage of the work in progress (as the big pile of cards in the testing backlog on the picture above) could delay feedbacks (development going in wrong direction until BAs/QAs complete review/testing) and consequently allow for premature work to be done.

At the end, one of the goals of a development team should be to maximize overall team throughput and reduce waste through constantly optimizing team workflow and enhancing teamwork. A Kanban Lean system is one mechanism that can be used to control a workflow and indicate waste in form of bottlenecks.

Kanban is what enables a pull system for just-in-time work. Very simply, there is a queue of work, which goes through a number of stages of development until its done. When someone needs new work to do, they pull it from their upstream queue. Not much different from an Agile story board until here. However, the important element, as I mentioned above, is different type of limits. There are two basic limits – Queue limits and Work in Progress limits.

Queue limits try to achieve just-in-time work and are designed to avoid premature work. The limit should be large enough to keep the team busy (i.e. there is always something in it for the team to start work on), but small enough to avoid premature prioritization (i.e. having things sitting in the queue for too long before they are begun). The later is what pressingly is missing in a typical Agile team story board.

Work In Progress limits are designed to reduce multi-tasking and maximize throughput. The former concept of reducing context switching and performing task sequentially to yield results sooner is very familiar to Agile teams. The later, however, is usually overlooked in typical Agile settings. Maximizing overall throughput by decreasing Work in Progress is often seen in various areas. Simple examples of this effect are traffic jams, where traffic speed reduces as more traffic builds up.
Limiting Queue size and Work In Progress like this can seem unusual for teams, and there is often a worry that team members will be idle because they are having no work to do, but are unable to pull any new work. However, the Queue and WIP limit sizes can depend on type of work and size of a team and should be adjusted to achieve maximum flow and reduce bottleneck. One easy approach is to adjust the WIP limits to the number of available people/pairs in a team. For example, if there are 6 developers in a team and they work in pairs, the size of development Work in Progress limit should be 3. The development Queue size limit should be large enough to keep continues development Work in Progress (so at least 3 story cards) but not big enough to allow premature prioritization on every developer pull (so this would require some adjustment and depends on the Average Developers and BAs Completion Rates as well as the number of BAs. I think that twice the size of WIP could be a good start as a queue limit).

Finally, the consequences of using a Kanban system could be a little surprising or even controversial and could include eliminating the Story Card Backlog (because the immediate queue is the only work of interest), time-boxed iterations (i.e. Sprints) can be eliminated as well because work is pulled as necessary, and consequently estimations can be eliminated because work is not planned into iterations.

Now, most of the questions at this point would be along the lines that if an Agile team isn't estimating or planning within iterations(Sprints), how it can make reliable commitments in front of business product owners.

As a start, Kanban could help you eliminated iterations, estimations and backlogs but can work equally well within a time-boxed limit and with a reasonable backlog size. However, the real answer to that questions is Cadence Lean system, which is an approach to achieve commitment and reliability with a Kanban system and for which I will continue in further post on this topic.

Labels: , , ,

|| Igor, Wednesday, July 15, 2009 || link || (4) comments |

Thursday, July 09, 2009

Agile within Constraints: Identify

All parents know what is going to happen when a kid walks in a toy store. That is why, every parent knows to better set some kind of expectations and constraints (like "…you can choose a toy but only one ..., one toy or nothing.") before entering a toy store (actually any store).

Setting the right expectations and identifying all constraints can help achieve a given goal. Working within clearly identified constraints could make our solution leaner and more efficient.

Interesting example of that idea is the classical children book "The Cat in the Hat". The author of the book, Dr. Seuss, had very clearly defined constraint - the book could only use a vocabulary of 225 words, so that beginning readers could read it. Dr. Seuss used clever combinations of the 225 words and a lot of illustrations to create a very interesting long lived story.

Of course, a lot of similar examples could be found everywhere, especially in technology field. The HTTP protocol over TCP has been commonly criticized to be very constrained one and yet, exactly that constrained nature of this protocol is considered to be the main reason behind the wildly scalable and successful word wide web.

Interestingly enough, most of the advices that one could get about web application scalability would come down to embracing system constraints and rely on them rather than try to overcome them.

In fact, a constraint is a restriction on the degree of freedom you have in providing a solution. However, such a restriction on the degree of freedom could be utilized to convert complexity into simplicity. To illustrate that ask yourself how your perfect house would look like, or where you would like to be professionally in 5 years, or .... Easy questions but hard answers. The reason - prefect implies no constraints but perfect is hard if not possible to achieve. Now, if you include some constraints like the "perfect" house should not be more than 3 times your yearly salary, you would probably compromise somewhere but you would get to a solution much more easily.

Embracing constraints to help provide leaner solutions is something that I am currently excited in retrospect to Agile. In fact, this was the main difference that I discovered while exploring Lean software development in recent years. The first time when I realized that was while working with Kanban ("visual card/board"), which is an essential part of Lean Software Development and for which I would write more in my next post.

Labels: , ,

|| Igor, Thursday, July 09, 2009 || link || (0) comments |