Code as a source of inspiration

The most important thing in software development is an idea. Idea is a spark that ignites and drives process of creating something useful, helpful or simply fun. As developers, we prefer good quality code and architectural design, but to users that is completely irrelevant. If bad code is making their life easier then in their eyes that is a great product. If that is not the case, you can write the cleanest code ever, but they will not care or ever use it.

Every program is a tool created to solve some specific problem. More problems it solves, more valuable it is to a user. Guided by that logic, we try to make make our solution more valuable. Our product grows and evolves so idea become something bigger, something that we originally didn’t plan.

But how does our idea grow? Where does inspiration come from? Often, users are the source of changes and improvements. They share their problems with us and we try to solve them. We can try to anticipate what user wants and suggest/implement changes by thinking how we can make things better. And sometimes, if done right, our solution can show us a full potential of the original idea.

Structure as foundation for a great idea

For code to be the source for improvements, it needs to be well structured. This is best explained with example. I was a lead developer on a project with a product that was integrated with three external systems from three different providers. All three integration were separate projects and developed as separated API-s that shared Data layer. This was something that we inherited and we didn’t question it. It seemed like a good idea at the time because we could scale any API the way we wanted, depending on traffic.

All three integrations are doing the same thing, but in different way. Each partner had something unique and specific that would differ one implementation from the other. Once I moved myself away from specific implementation, and looked at the project from higher perspective, I noticed that all three projects had almost the same steps in the process. The process could be unified.

I suggested that we merge business logic of all three projects into one. That way we would maintain only one project. So less work for everyone. To speed things up we would choose best and most generic of three implementations, and change it into something that would suit the flow of all three integrations. Existing integrations would be changed into adapters and would reference unified business logic. Each adapter would transform the request from external system into something that new implementation would understood and could process. Difference in logic could be specifically implemented if needed.

At the time I didn’t understood full potential of this idea. For me, this was only to make things easier for me and the development team. That was probably the reason why I didn’t get a green light to go with this changes. There was too many things that needed to be developed first, and this was not a priority. More like “nice to have”. Other arguments were that if we have a bug, we will have it in all three projects now. This meant that fix needed to be deployed for all three projects. When we were deploying something, we would always have downtime and product would not work for a short period of time. And in heavily traffic solutions like this one, that is something that we wanted to avoid. So this idea was postponed.

True benefits

I never had a chance to implement this idea. Not long after my suggestion I was needed on another project and I was transferred to the different team. But colleague of my did implement it. And this idea has grown far beyond what I intended to.

He implemented unified business logic and transformed existing integrations into adapters. As direct consequence of this change, integration with new (fourth) partner was implemented blazingly fast. And a reason for this was one simply fact: set of actions from unified business logic arose and contract was created. All adapter needed to do was transfer input from external system into this contract. It is not as simple as it sounds from this sentence (there was a lot of work to be done), but still better than implementing whole thing.

Once contract was established there was clear set of actions for new API that could be created. Until that point, all integrations needed to be done within solution. Now, with this API, work of integration could be done in external system. This brings benefit of working with new partner without cost of developing adapter for their system. With original implementation, this was not that easy to see. And implementing API without unified business logic would definitely require more time.

But why stop there? This product was used directly by end-users. What if, just like with external systems, contract could be created in communication with users? Now anyone could communicate with external systems. All they need to do is respect given contract (interface) provided by the system. Now you are in provisioning business.

You could split system into two different products: one providing service to the end-user, and other providing integration service to external systems you already integrated with. Whoever wants to start or expand its business could do it by integrations with each external system on its own or to just integrate with you and get integration with all of them.

Should this be done is up to the management to decide, but the idea was born from well formed product. Original implementation never shown this potential. And the fulfillment of these ideas would definitely require much more time and effort.

Conclusion

Idea is a great starter for any story. But without form, idea is just that — an idea. It needs to be explored, refined and tested. For idea to become a story, it needs structure: introduction, rising action, climax, falling action and resolution. That is a template for every book, movie or TV show.

Same goes for software development. We need template that we will follow. That template gives us a chance to explore and see what else could be done. This way “the story” (software) itself can show us where we can go. It is up to us to choose the path, but now we have a map to see what else is out there.