The Business Value of Short Branches

Context: I recently wrote this for an internal email. I thought I would share it with the rest of my friends. :)


In the world of software development, we can’t say it’s done until the code is in production, working, and providing the company with value. It doesn’t matter how pretty my code is, if its sitting in a branch. 

Show me the Money
 

One way to understand the reality that shipping early and often provides more value to the company is to take a look back at Finance 101. Now if you managed to avoid this class, you may have missed out on a very cool concept, the “Time Value of Money”. This concept states, among other things, that $100 today is worth more than $100 tomorrow

In the book ‘Software by Numbers’ the authors discuss just this in quite some detail. If you can get a hold of a copy, even reading chapter 2 is quite eye opening.

But let’s go over a simple example to see what we are talking about. One of the equations that came out of the Time Value of Money is the “Present Value”. The present value (PV) of a sum of money is equal to the future value (FV) multiplied by one plus the interest rate (i) to the power of the number of payments (n) or PV=FV*(1+i)-n 

For example, lets say we have the awesome new feature X. Feature X is going to bring the company a value of $10,000 once it ships, and if you will humor me, the interest rate of this investment is 10% (more than likely this number would be based on another financial term IRR but lets leave that alone for now). The last part is the ‘n’ and this is the one we are going to play with. In terms of shipping software the value of ‘n’ is going to be the number of times we ship. 

So if I said shipping feature X would give the company a business value of $10,000. And we shipped it all at the end the PV of that feature would be PV=$10,000*(1+0.1)-2 or $8264.46. The ‘n’ is a 2 in this case to represent the cost of waiting two releases (the amount the next example is going to use). But what if we broke this up into two releases, each one providing some value but not the whole value. Furthermore, let’s say the first release doesn’t provide a lot of value, so $3,000 and $7,000. Using those numbers then then the first release has a PV of PV=$3,000*(1+0.1)-1  or 2727.27 and the second release has a PV of PV=$7,000*(1+0.1)-2 or $5785.12. If you add that up $2727.27 + 5785.12 = $8512.39. That’s a gain in business value of $247.93, just because we shipped multiple releases. 

Not only that, but there is another part of this story that we haven’t discussed. Let’s say we ship the first part and learn that if we make a few tweaks to the project we could net more than $7,000! If so, then the return for the company goes up even higher further increasing the business value of the project over the original $8,264.46. Conversely, we get the added benefit of the other side of the coin. If after shipping the first iteration we notice that the business has changed and we need to move in another direction, then we have only cost the company for the first iteration, shipped it, got some value and can now redirect onto another, more lucrative, project.

So, enough with the fancy math. How can we actually take what we have learned and apply it to our day to day jobs? One of the simplest ways to detect this is to look at how old your branch is from master. Have you been working on a branch for a week, two weeks, a month? That might be too long, or you may be trying to push too much into one branch. Can you break the work up so that you are shipping code sooner? Teams that practice Continuous Deployment will often ship the database changes way before the application changes. Then they might deploy the new code behind a feature toggle so that stakeholders can review, and then finally they will make it active to the user base. Each one of those is a push towards a specific feature and each one provides value to the business in terms of feedback on the progress, on how the systems will react to the changes, etc.

So think about how you can make smaller branches that will push into master sooner. As a team member, once a PR hits Github take a moment to help the teammate out and give it a code review, the quicker we can give feedback to our colleagues the faster we can all learn and improve the way we work. In addition we don’t want WIP to hang out too long either. A topic for another post as this one is quite long already.

Posted in Uncategorized | 2 Comments

Message Context and MassTransit

Did you know that MassTransit has the ability to ‘smuggle’ data? Now maybe smuggle isn’t the right word, but messages in MassTransit have the ability to carry ‘more’ than one contract of data.

For example, at work, some of our integration partners provide us with extra data that we need later on in the order life cycle. This data is unique to the provider. In the past this lead to the usage of some patterns I dislike such as the ‘mystery meat’ where we stuff data into a dictionary and use magic strings later to get it
back out.

public interface RegisterSalesOrderWithMysterMeat
{
    string OrderId { get; }
    //other properties
    IDictionary<string, string> MysteryMeat { get; }
}

the alternative of course is to extend your nice clean model with partner specific payload

public interface RegisterSalesOrderWithMoreStuff
{
    string OrderId { get; }
    //other properties

    //shopify stuff
    string ShopifyOneOff { get; }

    //bigcommerce stuff
    string BigCommerceOneOff { get; }
}

I am not a fan of either of these approaches. A third approach creates a message per integration partner, not a bad approach either in my book, but today I want to show of the Message Context in MassTransit, so I am going to ignore it.

Check this out

public class RegisterSalesOrderConsumer :
    Consumes<RegisterSalesOrder>.Context
{
    public void Consume(IConsumeContext<RegisterSalesOrder> context)
    {
        //normal payload
        var salesOrder = context.Message;

        IConsumerContext<RegisterShopifySalesOrder> shopifyDataContext;
        if(context.TryGetContext<RegisterShopifySalesOrder>(out shopifyDataContext))
        {
            //do stuff w/ shopifyData
            var shopifyData = shopifyDataContext.Message;
        }
    }
}

How sweet is that?!

How do you do it?

First you define your contracts with an interface rather than a class.

public interface RegisterSalesOrder
{
    string OrderId { get; }
    //other properties
}

public interface RegisterShopifySalesOrder
{
    //shopify stuff
    string ShopifyOneOff { get; }
}

public interface RegisterBigCommerceSalesOrder
{
    //bigcommerce stuff
    string BigCommerceOneOff { get; }
}

Then at your edge you have a class implement the correct interface.

public class RegisterShopifySalesOrderCommand :
    RegisterSalesOrder, RegisterShopifySalesOrder
{
    //implement the properties
}

public class RegisterBigCommerceSalesOrderCommand :
    RegisterSalesOrder, RegisterBigCommerceSalesOrder
{
    //implement the properties
}

and then publish the concrete class

bus.Publish(new RegisterBigCommerceSalesOrderCommand());

MassTransit will take care of routing the message for you, and now you can add additional content that may or may not be required. This isn’t a feature I recommend abusing, but its one more sharp tool in your toolbox.

Posted in MassTransit | 1 Comment

MassTransit and Interface Contracts

 MassTransit interface-style messages

Did you know that in MassTransit you can use interfaces for your message
contracts rather than classes? If not, you can and here is how.

Let’s take the following example:

public class RegisterSalesOrder
{
    public string OrderNumber { get; set; }
}

public class Program
{
    public static void Main())
    {
        var bus = BuildNewBus();
        bus.Publish(new RegisterSalesOrder { OrderNumber = "abc" });
    }
}

Nothing too surprising here I hope. We get our bus instance and then publish our
message. Later someone will consume it. Like so:

public class Program
{
    public static void Main()
    {
        var bus = ServiceBusFactory.New(sbc =>
        {
            //ignoring a bunch of setup
            sbc.Subscribe(subs =>
            {
                subs.Handler<RegisterSalesOrder>(msg =>
                {
                    //do stuff
                });
            })
        });
    }
}

more configuration options here

Why interfaces?

So this is great and all, but if our contract was that messages should be immutable
it would be nice to have that enforced by the compiler. But with classes that can
be tricky if we want to support being able to easily build the messages when
we need to as well. We could just use private setters, but now they are a pain
to build and would require constructor parameters which further makes
serialization a pain.

public class RegisterSalesOrder
{
    public string OrderNumber { get; private set; }
}

MassTransit support interface based contracts like this

public interface RegisterSalesOrder
{
    string OrderNumber { get; }
}

Now we have an immutable contract, and we can subscribe to this interface in
our subscription setup part of the bus. The trick is now in the publishing.
How do you create an interface and set its properties and publish it?

I simple create a class that implements the interface (outside of the contract dll). I usually make them in the publishing system as they are a private implementation detail of that system.

public class MyRegisterSalesOrder : RegisterSalesOrder
{
    public string OrderNumber { get; set; }
}

Now I can create an instance of the contract w/ ease and it can be made in whatever
way my publishing code needs it. It can be built using a ctor, a factory method,
through the container, whatever my app wants or needs. Then I can simply publish it

bus.Publish(new MyRegisterSalesOrder { OrderNumber = "bob" });

And subscribers to the interface will get the message as it conforms to the interface.

Boom.

Posted in MassTransit | 24 Comments

From IoC to require

Lately I have been working on building out my first non-trivial application with node. It has been a very interesting smashing of my brain cells. Coming from a strictly typed language and moving into a prototype based language has removed a lot of my tools from my tool belt. I can no longer ‘scan assemblies for types’, even if I had an IoC i would be forced to use normal strings rather than Type names. I also no longer have my powerful toolset of Visual Studio and ReSharper (yes its a resource hog, but its damn powerful too). But of all the changes, I think it is the lack of IoC that is hurting me the most.

Last weekend I attended a session at Houston Code Camp on “Beyond AMD” where my good friend talked about the various ways people are extending JavaScript applications. Ryan summed them up into three flavors, you can modify an instance (duck punching), you use a factory (think jQuery $.fn) or you can use a plug in model (think flatiron.js Broadway). It was a great talk that really helped to round out my understanding of developing in JavaScript land.

It wasn’t until I was really rereading through the flatiron docs that it hit me. I really have two ways to get at things. One is by attaching it to a global (it seems that the app object is the preferred one) or I can use require to locate the objects I need. Since require felt right at the time, I started to happily require my way into happiness. That is until my first refactoring that changed a file path. You see require doesn’t have an app root concept so through out my code I am calling require(‘./file’) and then deeper in a nest I have require(‘../../../file’) and different files have different paths. For a moment I thought, Aha! I know what I will do. I will add to require the ability to do something like require(‘~/someFile’) where the ‘~’ was my package root. As I thought it about it having the file system involved at all just didn’t feel right. It seems that for JS the best thing for me to do really is to just extend the ‘app’ global.

It all comes back to the fact that I don’t have a type system in the way that I am used to thinking of it. Its ok, because I can stub this out quite easily for tests. But I do believe that it ALSO means I have to stay extra on guard because I am passing around a global and depending on its presence. It will be very interesting to me to watch how this next round of coding procedes because of this. I hope to report back with more, as I get actual experience doing it. But until then, I am jumping in feet first.

-d

Side Bar: I am drawn to node because I feel it has the module problem solved well. Python has the whole 2.x vs 3.x distutils vs setuptools (easy_install vs pip) etc stuff going on. Ruby has the bundle vs gems thing going on, where node just has npm which is private by default with SEMVER support. I like this. (its still no APT-GET but it works nicely. :) )

I am also loving Sublime 2 – though I am missing VIM’s keyboard navigation.

I also, enjoyed reading this. JavaScript is tragically important. LULZ. Its funny cuz its true.

Posted in Uncategorized | 15 Comments

A story on composable systems

<warning>This is a long post that attempts to describe a positive experience leveraging multiple frameworks</warning>

TL;DR. Static Typing / IoC == AWESOME FLEXIBILITY

Recently while working at Dovetail I had the absolute pleasure to provide a solution to a customer request. We were adding SAML authentication to our product, and we wanted to provide an extensibility point to handle unknown users. By default the product would show a not authorized screen if we encountered a valid SAML assertion referencing an unknown user. This was pretty easy to setup, but as I said, we really wanted this to be extensible. What I wanted to support was redirecting the user to a different page, maybe one that a customer has specified which would give the user the information needed to request access to our application through the approved channels. That would have been pretty easy with just a configuration entry, but we decided that really wasn’t enough. We also wanted to be able to handle a request to make a user right there. Well, now we need the ability to execute some code, a configuration file isn’t going to handle that very well. Even if we kept the config file approach we would have to redirect the user to somewhere else in the app, and then figure out how to shuffle all of the required data around. :( It just didn’t feel like a solid solution.

Thankfully, FubuMVC, Bottles and StructureMap came to the rescue. FubuMVC gives us controllers that can easily take dependencies on services (nothing to fancy here, you can do this in ASP.NET MVC too). So our SAML Authentication controller (or action in Fubu land) takes in a service that acts as a policy (SuccessfulSamlAssertionPolicy) it takes a valid SAML assertion, and attempts to locate the user in the database, if it finds them, the policy logs them in, and then redirects the user to the home page. If we can’t find the user, then we invoke the UnknownUserPolicy (another service/policy thing which is injected in the SuccessfulSamlAssetionPolicy) the default implementation of this policy simply redirects them to an error page of ours, but since it’s a interface/class pair, we can easily swap that out. This is where IoC/DI/StructureMap make things really nice.

So, the above may seem a bit complex (I definitely didn’t explain it that well). So lets break it down and make it concrete. I have an interface that looks like this

public interface UnknownUserPolicy
{
    //FubuContinuation is a way to redirect the user
    FubuContinuation HandleUnknownUser(SamlAssertion assertion);
}

we ship with the following implementation

public class DefaultUnknownUserPolicy : UnknownUserPolicy
{
    public FubuContinuation HandleUnknownUser(SamlAssertion assertion)
    {
        return FubuContinuation.RedirectTo<LoginController>(c => c.Login(null));
    }
}

Super easy code, nothing too hard here. We wire it up in StructureMap using a convention, so there is really nothing else to show. Now, lets imagine we have a customer, that doesn’t want them redirected to the login page, they should instead go to: https://silly.corporate.subdomain.company.com/request_access.cfm . Using StructureMap, this is as easy as registering our policy later in the container (after the default registrations) by adding a line like this:

For<UnknownUserPolicy>().Use<CompanyXUnknownUserPolicy>();

That will override the default policy and boom! We have just customized our application for this one customer. So that’s great and all – but I want that in only ONE deployed instance of the application. I do not want to modify the base product for this customer, and this is where Bottles comes to my rescue. :)

Bottles is a framework for assisting us in loading dynamic code in a controlled and predictable manner. Its built with an IoC container in mind, but is completely agnostic of them and FubuMVC entirely. When our application starts up, we go through all the usual stuff for a .Net / IoC project. We initialize logging, spin up our container, blah, blah, blah. The one new step that we add with Bottles though, is to run through every discovered Bottle, and look for ‘StructureMap Registries’ and load them into the container. Now, a bottle is pretty much a glorified zip file holding .Net assemblies — among other things. The bottles, being a separate file from the base product, can be used to modify our existing application. In this case, we have a Customer Bottle that does one thing. It executes that above piece of SM registration code to override the base UnknownUserPolicy. :) WIN.

So, by putting all of these various tools, patterns, and frameworks together, we were able to build a solution that allows for a lot of customizability, does NOT require us to change our base product (would have loved to have had this at the bank), and I think truly encapsulates the changes that customizations for a customer can bring into one easily deployable unit.

There are a LOT of things going on in this post, we have programming to interfaces, we have making small classes that do one thing well, we are using IoC, we are using a web framework that makes redirecting deep in the bowels of the app easy and testable, we have composition, dynamic code loading and a lot of ‘abstractions’ (Yup, learned about those at a young age ;) ). Using all of these has allowed us to add a lot of seams to our application, and it’s this kind of power that keeps our application nimble and easily customizable for any customer.

Posted in Uncategorized | 8 Comments