After years in Agility
 

It’s been few years since I started following agile methodology. When I look back it’s interesting and happy journey. Was thinking about the book (User stories applied) which introduced me to Agile world. Back then, I read the book like a story book. Now I re-read the book after two years after practicing Agile. It was a fantastic read! I thought of sharing few fundamental things for being in an agile team.

  1. Team > Individual : When you are part of an Agile team, the focus shifts from individuals to the team . This will be a big change for those who come from waterfall model. Although during the standup meetings people talk about their achievements for the day and the next actions, it’s not the individuals work alone that make sprints successful. Things like, taking up pending tasks, helping team members complete tasks, pair-programming, looking for the overall success of the business etc. are thing which make significant impact than an individual’s ability to write optimal code/test.
  2. Where is the Design : When I came from the waterfall model, I was surprised that there is no definite design phase. But soon I realize that design is happening in iteration over a period of time. While being in a sprint, Design happens when we do sprint planning and tasking, design happens when we do the pair programming, it happens when we do TDD. This way, there is more scope for the developers to think about code and design, than a single monolithic time slot to think through design.
  3. Agility is different from being in an agile team : Having an agile mindset is completely different from being part of an Agile team. Being part of Agile team gives us leverage to do iterative development, do the ceremonies of agile process etc. But when we have not imbibed the principles and the manifesto behind Agile, it’s not Agility.
  4. Communication : Focus and Communication are fundamental to any successful sprint team. When there is no direct communication, thoughts & opinions are not converted to actions. Be it daily standup meetings or technical discussions/pair-programming/or during sprint planning, connected and collaborative people can only create beautiful software.
  5. Practice, practice, practice : There is no testing phase, there is no business verification phase, nor there is any formal review process. How can we sustain quality ? how can we insure reliability ? The answer to these questions come from the software development practices like TDD, BDD, emergent design, CI etc. Agile provides a way to use these practices. Apart from the acceptance criteria for a story, Definition of Done(DOD) governs the acceptance criteria for all stories. When we have DOD covering these practices, it becomes a standard for ensuring quality. There techniques and practices in combination with Agile process can help to deliver continuous business value while ensuring good quality.

There are an indefinite list of advantages for doing iterative development over waterfall and vice-versa. Although Agile, helps to deliver software faster to clients, there can be projects where regular waterfall model might help. We need to be choosy in selecting our process for each and every project that we work on. Provide your inputs and thoughts on this topic in comments.

Projects do FAIL. It’s NOT only Code
 

It is NOT only code

We recently failed in our product. The 6 persons effort for nearly 2 years went into nothing. Besides we had all kind of testing, functional, unit, integrations, load test, stress test etc, to protect the application from any kind of questioning. When the management and product team took a decision about scraping the product, the scrum team was awestruck.  Soon all water cooler conversations were only about this. Team retrospected a lot about what has just happened and discussed everything under the sun that could have been better. Below are few pointers from that.

crash

Projects and products do fail

Software industry exists and continues to get better just because someone is continuing to write good/better code and solving problems. If we see the history of this industry, we just had assembly language, then we created abstractions after abstractions and OOPS, functional etc. As we progressed and got better, our ability to focus on the primary objective seems to be lost ie Problem solving. So when software “just don’t work, get scrapped“. This is what most developers conclude when project get scraped.

Stakeholders need to be happy

A projects need support and buy-in from all part of the organization. This includes marketing, management, product org, and of-course the customers. Each of them have a role to play in-order to successfully deliver the product the to customer. When one of them does not align to the vision and mission of the Product, it will ultimately fail.

stakeholders

When People change, alignment also changes.

Lot many times, when senior management changes, the whole mission of the company or division also changes drastically. This might be because they bring a new perspective, ideas and ways of doing things.

change

Competing products

Product acquisition and market reaction to a new products can cause products to be abandoned. Its often survival of the fittest. As a developer, Competition is healthy when it does not affect my product drastically. But unfortunately, businesses can not function like that. Ultimately, the product which the customer wants the most wins.

competition

Great products may not sell

Developers often think we need to build a great product in-order to capture the market and excite the customer. Great products also need great sales people to sell them.

sell

Timing

Its all about timing!. One of my friend told me an example of touch-based Windows mobile which was available very long before iPhones and Android dominated the mobile industry. Even though the product was good, there were lots of timing issues the market was not ready, Touch was not affordable etc.

timing

SO on and On

There are various reasons because of which leads to a failed software project. I have listed some of them here, But the list is infinite. And of-course Code is one of them.

Simple introduction to NServiceBus
 

What is NServiceBus

NServiceBus is a Microsoft .Net based framework for implementing the Enterprise Service Bus pattern. Its a framework for implementing reliable messaging through various transports without having to write boilerplate code. NServiceBus also provides facilities for pub/sub, retries, format abstraction, encryption, workflow orchestration, and scalability.  Below are a few highlights of the system.

  • Seamlessly work with various messaging systems (Transport)
  • Automatic Serialization & De-Serialisation
  • Enforcing a Bus architecture
  • Transaction Scope (Unit of Work)
  • A simple model to handle long-running transactions (Sagas)

Building a simple Unicast bus using NServiceBus

Let’s use .Net core 2.0 for building a simple bus. Everything in NServicebus can be configured using a simple class called “EndpointConfiguration”. An endpoint is a service that uses NServicebus framework for handling messages.

var endpointConfiguration = new EndpointConfiguration("UnicastBus");

NServiceBus uses persistence to store all the configuration and temporary data so that the data is not lost while there is a failure (fallacies of Network). We can configure NServiceBus persistence using the below code. We are using an In-memory persistence for the sample app. But in real applications, other reliable persistence like SQL, Raven, Azure Service fabric etc. will be used.

endpointConfiguration.UsePersistence<InMemoryPersistence>();

NserviceBus is a framework and is not a message queues on its own. However, it uses an Adapter pattern to fit any open source & commercial queuing systems. In our case, we are wiring it up with RabbitMQ (an open-source message queuing system written in Erlang).

var tranportExtensions = endpointConfiguration.UseTransport<RabbitMQTransport>();

tranportExtensions.ConnectionString("host=localhost;username=guest;password=guest");

RabbitMQ also has a concept of routing topology where a user can configure how data is passed between exchanges & queues. In our case, we are going to use ‘direct routing’ topology.

tranportExtensions.UseDirectRoutingTopology();

var routing = tranportExtensions.Routing();
routing.RouteToEndpoint(assembly: typeof(Order).Assembly,destination: "Sales");

Through this configuration, we are pushing all messages coming to “Unicast Bus” exchange to “Sales” exchange. That’s it, we are good to start the Unicast bus.

var endpointInstance = await Endpoint.Start(endpointConfiguration).ConfigureAwait(false);

Now, sending messages using the bus that we just created is simple.

endpointInstance..Send(“My First Message using NServiceBus”);

To see the result, we should run the program and look for messages in the ‘Sales’ queue in RabbitMQ management tool.

Conclusion:

NServiceBus is one of the frameworks for doing reliable messaging for handling the fallacies of distributed computing. This is just a gentle introduction to NServiceBus. We shall see more advanced concepts in future posts.

Maintaining IEnumerable-Yield Data Pipeline is Hard
 

C# and .Net had IEnumerable and yield since its early versions. And I think its one of the most misunderstood features of C#. This is because of the pattern of deferred/lazy execution implementation.  Before we delve deep into this let us understand the iterator model.

IEnumerable and IEnumerator:

This is the foundation of the C# Iterator pattern and there are a number of detailed articles about this by Eric Lippert. The simple example is here.

There is a basket full of Oranges.

 
public class Basket
{
    private readonly IEnumerable Oranges;

    public Basket(IEnumerable oranges)
    {
        Oranges = oranges;
    }

    public IEnumerable GetOranges()
    {
        return Oranges;
    }
}

public class Orange
{
    public int NumberOfSlices { get; set; }

    public void Peal()
    {
            
    }

    public void Consume()
    {
            
    }
}

And if we have to consume oranges, we will have to peel each one of them. So we can use a simple iterator pattern on them.

var basket = new Basket(new [] { new Orange(), new Orange(), new Orange() });
foreach (var orange in basket.GetOranges())
{
    orange.Peal();
    orange.Consume();
}

But the problem is, we need not consume all the oranges from the basket at one go (I am not Hungry ;-).
So how can I get one orange from the basket at a time? or whenever I am Hungry?

Yield:

C# Yield keyword provides an answer to this problem. Slightly changing the Basket class using Yield keyword. (signature of the GetOranges Method not changed)

public class Basket
{
    private readonly Orange[] _oranges;

    public Basket(Orange[] oranges)
    {
        _oranges = oranges;
    }

    public IEnumerable GetOranges()
    {
        for (int i = 0; i < _oranges.Length; i++)
        {
            yield return _oranges[i];
        }
    }
}

Now the basket will provide one Orange at a time. ie when MoveNext() Method of the IEnumerator is called. In other words, we have paused execution of the “for” loop in GetOranges method till the time the next Orange is required.

Or in more technical words, until you Enumerate, the data will not be fetched and once Enumerated, there is no data. It all boils down to “when you Enumerate”.

The Maintenance Problem:

This is tricky for developers who are inheriting an existing code base. A developer might accidentally add an Enumeration before the place where it actually has to. The next time or When the original Enumeration happens, it can not find any new data and the iterator just completes without any looping. This can happen very silently without any exceptions. So care to be taken to see where we are yielding and where we are Enumerating.

“Yield return” is a great feature in C#, but use it with caution.  Let me know your thoughts.

Team Code Reading
 

One of the very old practices in the software industry is Code Reviews. The general process is, a senior engineer providing feedback on how a code is written by another engineer. There are many issues we have observed with this approach and we have adopted something called Team Code Reading.

Approach of Team Code Reading

  • Trust: We trust the team members that they have written good code and they are free to check-in their code without someone’s comments. Although this is validated by our functional tests and Unit tests.
  • Team Code reading: We meet as a team to read/go through to each of the lines of code to understand it and try to be critical about it, irrespective of who has written it. The person who wrote the code would normally explain the business and technological background behind it.
  • TODO’s /User Stories: Outcome of code reading is mostly a TODO on the code or a user story on the product backlog.
  • No Finger pointing: Being Critical is fundamental about the code reading session. There are no fingers pointed at the person who wrote it originally. The team takes collective responsibility for the code.

Benefits of code reading:

  • Knowledge Normalization: Since all the team members are part of the code reading session, the product and technology knowledge gets normalized/spread across all the team members. For example, A junior/fresh grad will get lots of technical best practices from the code reading session.
  • Team bonding: Since there is no finger pointing, the team owns the problem in the code, it helps team bond well along with the code.
  • New ideas: Code reading session becomes a platform for brainstorming for new ideas as everyone is in thinking on critically about the product and code. Some innovative ideas come out and have become great product features.

It isn’t all Rosy                                             

There is a cost associated with each of the approaches. Below are the few costs that you have to pay if you are doing Team code reading.

  • The complete team’s time is required to do the team code reading. This is the cost that team members need to spend to get the product/business knowledge.
  • Distraction: There are chances that team gets distracted by some idea/problem. Scrum master or one of team member need to re-align the team towards code, every time there is a distraction.

Concluding remarks

There are always many ways to improve product and code. But the process that is followed drives the effectiveness of the outcome. I believe Team Code reading can greatly help improve the effectiveness of the team.

 

Tail Recursion
 

My Kid’s encounter with Iteration

I was teaching the addition of 2 numbers to my 5-year-old kid. The initial approach is to use fingers in the hand, so she could sum 2 numbers which add up to a maximum of 10. When it went beyond 10, she needed a placeholder (a variable in software terms). Now I taught her to have one of the numbers in mind so that she could just count the fingers for the second number. Again if the second number is bigger than 10, she was limited. When I started questioning about what her next approach will be, I was surprised by her answer. She came up with an iteration algorithm! The Idea is to use a counter (0n paper) for the number of times the set of 10 fingers were counted. This triggered my thoughts about iteration and recursion, hence this blog post.

 Iteration & Recursion

Recursion had been there in software for very long time. Recursion in software is derived from its mathematical formulations. Below are the rules of recursion.

  1. A simple base case (or cases)
  2. A set of rules that reduce all other cases toward the base case

If we can categorize each of the iteration into a form of simple base cases, then the iterative operation can be made recursive. In simple form: A function calls itself. A ‘Recursion’ is a special form of Iteration where no one knows the number of times the iteration will happen. Below is an example of recursion based Fibonacci series generator.

 
        public int Fibonacci(int n)
        {
            if (n == 0)
                return 0;
            else if (n == 1)
                return 1;
            else
                return (Fibonacci(n - 1) + Fibonacci(n - 2));
        }

 

 Stack Based Languages/Frameworks

Recursive logic in stack based languages/frameworks(example .net, Java)are limited by the amount of memory available. This is because these frameworks add the method name and the data(value types) to a top of the call stack for every call to a method. This is done to retain the data in the current method (in the stack) so that when the method returns, the data can be popped out the stack for usage.The data in the stack is not useful if they are not used after the method call.

 
public void PrintCallStack()
{
  var stackTrace = new StackTrace();           // get call stack
  var stackFrames = stackTrace.GetFrames();  // get method calls (frames) 
  foreach (StackFrame stackFrame in stackFrames)
  {
    Console.WriteLine(stackFrame.GetMethod().Name); 
  }
}

 

 Tail recursion (example)

A recursive method is called Tail recursive if the last line of the method calls itself. Since there are no other operations done after the recursive call, the stack data is useless. So the stack need not be built for each of the recursive calls. A compiler is said to be Tail recursive if it can identify the above scenario and replace the caller with called, and the current stack is reused. This is a huge performance optimization and you might never encounter Stack Overflow exception during recursion.

 
public int NonTailRecursiveFactorial(int n)
{
    if (n < 2)
        return 1;
    return n * Factorial(n - 1);
}
 
public int TailRecursiveFactorial(n, a)
 {
    if (n == 0) return a;
    return TailRecursiveFactorial(n - 1, n * a);
  }


Tail recursion is some times equivalent to Goto statements

public int factorial(int n, int a) 
{ 
beginning: 
if (n == 0) return a; 
else 
  { 
     a *= n; 
     n -= 1; 
     goto beginning; 
   } 
}

 

 By the way..

Generally Tail recursion (tail call optimization) is attributed to functional programming languages and unfortunately major programming languages like C# and Java does not support Tail Recursion. But this optimization is available in their sister frameworks F# and Scala. Also there are thoughts like Trampolines and Lambda expressions are far superior method to achieve results than other form of iterative programming. But i think that is a separate post altogether.

Contextual Friendship Framework
 

Recently one of my colleague,  Rahul Rathore and I were on a conversation on object-oriented techniques and we both agree that it has lots of inspiration from the real world. Below is the background of our conversation and what emerged out of that.

Background:

The object-oriented languages like C#, Java are more close to real world. We can mimic the real world behaviors in these languages easily. Scenarios are well captured because of their object-oriented abilities. Inheritance, polymorphism, and encapsulation are principles derived from the real world. In the real world, there are more concepts which are applicable to humans but are not well mimicked in the computer world. One of them is Friendship (between objects).

For better code re-usage, Object-oriented programming languages like C++ have a feature called Friend classes. A class in C++ allows access to all the private & protected members to its friend classes.

But in the real world, we share only a few things with our friends based on the context we are in. We have complete control over what we want to share with our friends and families. This is not the case with C++ friend classes; it shares all the private & protected members to its friends. This poses a threat to the object-oriented theory of encapsulation.

Because of this threat, advanced programming languages like C# and Java have completely removed friendship between objects. But friendship can significantly increase code re-usage and cohesion in objects than breaking them. We wanted to have friendship in C# and Java but still, follow other object-oriented principles.

We observe that C# is very easy to use and highly extendable. So we embraced C# and extended it with the custom module which will enable friendship between classes.

Contextual Friendship Framework:

The framework extends the Microsoft.Net framework to enable friendship among classes. This Friendship framework allows developers to add attributes to classes and its members to enable friendship. There are 2 attributes available.

  1. FriendOf – for classes
  2. AvailableToFriends – for members
  3. FriendOf attribute can be applied to a class whose private and protected members need to be made available to specific friend classes. It takes an array of .Net Types as a parameter. AvailableToFriends attribute can be applied to a class member to allow its access to specific friends only.

A Friend class can access a private/protected member of its friend class by using the ‘MakeFriendlyCall’ extension method exposed by the friendship framework. MakeFriendlyCall method is an extension method that internally uses .Net Reflection to reach to private and protected members. MakeFriendlyCall will allow making calls to private/protected members with AvailableToFriends attribute.

Friendship enables selective sharing of members with friend class based on the class definition. The module provides facility to decorate members of a class for granting access to its friend. Let’s understand this using the below example

 
    [FriendOf(typeof(World))]
    public class Hello
    {
        public string Name { get; private set; }
 
        public void HelloPub()
        {
            Console.WriteLine("Public Hello");
        }
 
        [AvailableToFriends(typeof(World))]
        private string PrivateMethodsAvlToFriends(string name)
        {
            Name = name;
            Console.WriteLine("Private Hello : " + Name);
            return Name;
        }
 
        private void PrivateMethod(string d)
        {
            Console.WriteLine("Private method" + d);
        }
    }
 

    public class World
    {
        private void DoSomething()
        {
            var h = new Hello();
            h.MakeFriendlyCall("PrivateMethodAvlToFriends", "John");
        }
    } 

Here we have 2 classes, Hello and World. The Hello class has two private methods “PrivateMethodsAvlToFriends” and “PrivateMethod”. PrivateMethodsAvlToFriends is decorated with AvailableToFriends attribute. Now the Friend class “World” can make a call to this private method. This can be done by using the ‘MakeFriendlyCall’ extension method exposed generically.

Class Diagram Of the dependencies:

FriendshipFramework

Alternative solutions:

  • Friend class in C++
  • C# has Friend Assemblies which allow all internals of a class visible to another assembly using InternalsVisibleTo attribute. This is more generic than the C++ friend class and does not allow selective access.

Comparison of C++ Friend class Vs Friendship Framework:

Criteria C++ Friend Class Friendship Framework
Security All members are available to friends Granular control over what is available to Friends
Encapsulation Breaks Encapsulation Enhances Encapsulation
Re-Usability Part of the C++ library, so re-usable Fully re-usable as the framework is shipped as a package.
Design Pattern Access Modifier Decorator pattern is used. Also, can be implemented using Access Modifier

Future scope:

We have enabled friendship between classes without breaking encapsulation and security. However, this design can be extended to objects of classes, which makes it closer to the real world. After all, we are not sharing our car with a friend all the times.

Also, the Friendship attributes ‘FriendOf’ and ‘AvailableToFriends’ can be converted to new access modifiers like Public, private, protected. This could be done using Roslyn which is a complier extension to .Net. The Friend framework is available in .Net, but can be implemented to Java framework as well.

 

 

Perspective Designing
 

Recently, I was working with a colleague in refactoring one of our projects. As we added tests, we found few code issues and continued refactoring. Was feeling happy as our unit tests were rearing benefits. However, we know TDD or unit testing does not guarantee clean code. As we progressed, the naming conventions consumed a lot of our time. And eventually, it brought us to a discussion about why specific naming conventions can create a better design. Thought I will share our discussions and practices here.

While we design classes for application, we often think of it as a different subject than ourselves (programmer). When I say different subject, we think of it as a different object and not as a person. When a programmer considers classes/interfaces as personalities and thinks from the perspective of the class, design can change drastically. This is what we call “Perspective designing”. Let’s take an Example:

    public interface ITotalTaxCalculator
    {
        decimal Calculate(IEnumerable products);
    }

    public class TotalTaxCalculator : ITotalTaxCalculator
    {
        public decimal Calculate(IEnumerable products)
        {
            decimal total = 0.0;
            //add total of products etc....
            foreach (var product in products)
        	{
                using(var dbContext = new ProductContext())
                {
                    var productInDb = dbContext.FistOrDefault(prod => prod.Id == product.Id)
                    total += (total * productInDb.taxRate);
                }
        	}
            return total;
        }
    }

In the above example, the name of the class and interface are perfectly fine. But they are impersonal and it’s very hard to think of it as a person and bring in perspective thinking with these names. So we refactored them to ‘ICanCalculateTotalTax’ and  ‘TotalTaxMan’.

public interface ICanCalculateTotalTax
{
    decimal Calculate(IEnumerable products);
}

public class TotalTaxMan : ICanCalculatorTotalTax
{
    public decimal Calculate(IEnumerable products)
    {
        decimal total = 0.0;
        //add total of products etc....
        //blah blah blah..
        total += (total * taxRate);
        return total;
    }
}

These naming conversions have lots of inspiration from in NServiceBus for their class/Interface names. With the new class and interface names, it’s easy to think of them as personalities. However, this does not guarantee good design. So we needed refactoring. Perspective thinking comes in handy especially while we do refactoring When my colleague and I started putting ourselves in the place of each of the classes. We had very reasonable questions which triggered our object-oriented thinking.

Example1:  As ‘ICanCalculateTotalTax’ , why I am having database related behavior?

Example2: As ‘ICanCalculateTax’, why I am having logic to find which language it needs to be presented?

These questions helped us to refactor the code to follow good design principles. When we implement these interfaces/abstract classes, we have clarity on what the class is capable of doing. So we generalized these naming conventions & questioning attitude and derived below two rules to do Perspective designing (think like a class).

  • Give personality to the names of  classes/interfaces (example: ICanCalculateTax)
  • Use the Agile User Stories way of articulating what the class should and should not do. (example: As ‘ICanCalculateTax’, I should be able to provide behavior to calculate tax)

I think, “Perspective designing” can make classes more object-oriented and best practice like SOLID principles automatically fall in line. Let me know your thoughts.