A few years ago, I was doing full-time consulting.
At one particular client, we were building a component based UI where pieces of the screen could be swapped in and out pretty quickly. This was all done through clean APIs that were message based and consistent across the components.
Each component was independent of the others.
None knew about the others, directly, but would communicate through in-process messages and a centralized communication mechanism.
As I began to work on one particular screen, I noticed a problem.
We were laying out the software based on the old paper workflow, where there was information from a previous page that was needed on the current page.
In the software, however, it made more sense to move some of the current page’s components to the previous page, and some of the previous page’s components to the current one.
I thought through the reasoning and logic of the way the paper was laid out vs the changes I wanted in the software and it all made sense to me. It would significantly reduce the code size and complexity if we swapped these things around.
I called my client and we talked about the changes I wanted to make.
He agreed on the reasons for the changes I wanted – it made sense and would be better. But he was concerned about timelines.
We were already running behind, and he didn’t want to continue pushing behind further. It was a valid concern – and it was his job to make sure we met the deadlines.
I expected the change to take up to 3 days as there were a lot of parts to move around and a lot of logic to change in order to make this work.
He reluctantly agreed and asked me to see if I could get it done faster than that.
I said I would try.
15 minutes later, I told my client I was done.
The message based communication and component based architecture had given us far more freedom and flexibility in re-arranging and rebuilding the workflow than either of us had imagined.
I was able to take an estimated 3 day change and complete it in 15 minutes.
It was a great moment for both of us, to see that the work we had put into this was going to serve us well and create a system that would be far easier to maintain.
The benefits of messaging and decoupled components are many.
But, the improvements found in messaging aren’t always that dramatic.
Whether in-memory or through the use of a messaging server like RabbitMQ, these patterns can provide significant architectural advantages. That client work was a prime example of how powerful these patterns can be.
Sometimes – especially when you’re first getting started – the benefits don’t seem to be there at all.
Sometimes you’ll sit back and look at what you built, and wonder why you spent so much time on it. You find yourself looking at something that should have been “simple”, and it became complex.
The benefits are especially hard to see when first learning a technology.
Learning takes time and often creates more questions than answer.
I want to help answer those questions for you. I want to show you the benefit of messaging and good architectural practices.
I want to help you turn a 3 day estimate in to 15 minutes of work.
Join the mailing list, below, and over the next few weeks you’ll see how how these patterns can work for you.