Welcome to GlobalLogic Blogs

Agile the revolution: Now what?

Before we start our journey I would request the reader to be patient enough to reach the end of the blog and not to draw a conclusion in the middle of it.

So what did I mean when I said “Agile the revolution”? Let us go back to the days when waterfall was considered as the de facto approach for executing software projects. People use to spend months and months on the analysis phase and more months on the design phase producing lot of documents in the due course and finally some code. The worst part was to seen the project failing after all this time and effort just because of all the wrong assumptions and predictions made during the design phase. This brought together a revolution which lead to the birth of completely new software development process “The Agile”.

Let us try to compare the same to any of the revolution that we have come across in the history of the mankind. The story begins with the existence of a government which exploited the citizen or to the least played blind eyes to the obvious problems that existed in the society. The state of anarchy grew to an extent that people revolted and toppled the so called government. Now what do we have, a completely lawless society. When we walk further down the roads of history we will find that soon some new group of people came together and put together new set of rules or constitution but this time based on the hindsight of the past.

So if we look closely the phase just after the revolution there was a small phase which leads to higher degree of anarchy. Closely examining the phase will make us realize that it was during this phase when the very ideology that inspired the people to revolt was blindly followed. So what is the moral of the story? The very ideology which brought about the revolution cannot be practices in its purest form on a normal course.

Before we go further with our discussion let us all try to summarize on what the software revolution was against:

1.       Counterproductive and irrationally long design phase.

2.       Piles and piles of document which would soon turn into some sought of relic.

Now let us step back and ask these questions:

1.       Don’t we need designing to develop a world class software product?

2.       Don’t we need documentation of the software product we are developing?

Don’t run for cover yet. Let us put the very first reason for the revolution under the microscope and try to derive our conclusion. Revolution was not against the process of software modeling per say but against the counterproductive way it was done. Upfront modeling was the real culprit that made the entire modeling process a victim. I cannot agree any more with Eric Evans (author of the book Domain-Driven Design: Tackling Complexity in the Heart of Software) when he said “The worst model I build was on the day one of the project and the best model I build was on the last day of the project”

What was he trying to convey? Software solutions are manifestation of the actual domain for which the solution is laid down. So how can we model a system to manifest a domain which we are least aware of as in day one of the project? Any attempt to derive a model on day one will fall victim to all wrong assumption and prediction about the future of the domain. But then due to all the frustration the desperation against the counterproductive software modeling phase which brought about the agile revolution there is a slight element of anti-model in it.

I am sure anyone who have spend enough time with software development agree that solving a problem without proper direction and guidelines will only lead to more problems. So what we need is not a complete no-modeling software development software process but rather a more productive and flexible modeling approach. Before I explain any further on the need of a model let us try to see the second evil which triggered the revolution.

Piles and piles of documents which would soon turned into relic. I am sure anyone who has been on those waterfall projects will recollect the nightmare of spending weeks reading those document to understand what they are needed to do and still find themselves as “Alice in Wonderland”. Now a pinch of reality “Can we survive with no documentation?” Most common argument I hear is minimal documentation but then how little is minimal documentation. One other interesting comment I here is “Code should be self documenting”. As soon as a developer is enlightened with this single line of software oracle they start decorating there code in all possible means.

Let us take a simple example of imaginary financial software module which calculates the principle at the end of every month. Basically there is a starting principle from which based on the monthly installment paid some amount will be deducted. But then for every 6 months which the customer has paid the loan without any default they will receive a small bonus which will again be deducted from the principle to finally derive end of the month principle. Now the developer who was assigned the user story came up with following classes:

·         Principle

·         Installment

·         DeltaDeduction

Now delta deduction is the amount that will be deducted based on the bonus earned over the period of 6 months.  Now no matter how well the DeltaDeduction class is commented it will be a source for uncertainty for anyone reviewing the code. First question will be “What should I relate the DeltaDeduction class to in the domain”. Rather if the developer would have named it as something like “NonDefaulterBonus” it would be have been self documenting even when it was not decorated with lot of comments.

Now even to name our classes correctly we need to understand the domain that we are working in and have some model of the same in our mind.

We need to realize that the end goal is not to complete a user story but to deliver a shippable piece of software with a tolerable degree of bugs.

Another common excuse made regarding the modeling is “We know we need some modeling to be done but cannot find time”.

So when did software development become a 100m sprint where all we care about is time. Software development without adequate modeling take us to the very software anomaly which is called as “Big Ball of Mud” (http://laputan.org/mud/ ).

“Co-owning the code” is another very religiously followed principle in agile. I am very sure where this is coming from. If you remember the old days when certain piece of the code is completely owned by one single person. It became completely impossible to make any change in his/her absence. But then does just co-owning the code solve this problem. Let us take a scenario consider a user story which span two modules A and B. The developer who is implementing the user stories works with the team which own the module A. Now to implement the user story he/she need to modify the module B. Risk is that the modification will be done without understanding the actual motivation that went behind the design of module as he/she was not part of the team which co-owned the module B. So the ownership cannot be code -centric but rather should be a domain context centric. Such contexts are called as Bounded Context in Domain Driven Design or DDD.

“Re-factor when your code starts smelling”. Again this is inspired by the fact that many of the waterfall project failed due to ignoring the known issues in the project which acted as time bombs which finally called upon the doomsday for the project.

In reality all large system are not well designed and investing the time and effort to re-factor every bit of the system to adhere it to all know design principle will not yield the expected benefit. The idea is to identify the core modules that the business relies on the most and keeping it clean all time. It is also very beneficial to identify the axis of frequent change within your project and re-factoring it enough to accommodate more changes. There are always going to be certain module of the software which would look more or less like Big Ball of Mud. But as we said before investing time and effort to get these modules re-factored might not yield the desired return. But again left unattended will make the chaos in these modules to creep into rest of the modules.

I am sure most of you are familiar with the Trojan horse story. Modules which are not well designed and re-factored are similar to the Trojan horse. If left unguarded the enemy (bad design) will creep into our castle (code). So how do we deal with such scenario? If the Trojan’s had put the horse in a fenced premise with a strong gate and a gatekeeper the enemy would have failed in their plan. So how do we build wall around these “Big Ball of Mud”. DDD offers a beautify pattern call the Anti-Corruption layer (ACL) that will mask the chaos from infusing into the rest of the software module.

So in short what need is not a completely no-design and no-documentation software development process rather a smatter way to model the domain and implementing the model in our code in such a way that it requires little documentation to be explicit.

I idea of this blog was to set the stage for my next blog “Introduction of Domain Driven Design” in which I will explain how DDD will allow you to achieve high degree of agility and still enjoy the benefit of having domain model in place. Most importantly I will also cover how DDD allow modeling and agile go hand in hand.

Popularity: 88% [?]