Yesterday I had this idea about doing a conference talk about decoupled code from a clients perspective. Maybe other things too. Because when something matters to the client it should matter to you too.

Here’s a start.

By decoupled-ness I mean following the Separation of Concerns principle thinking in components with very little glue code in between. Each functionality or functionality group has its own space and none or very few dependencies to and from.

Sounds technical? Right but it still matters to your client and here’s why.

1. Assessability

It’s easier to assess a functionality when it comes to developing it and your not confronted with “oh but then we have to change this here and that there and another thing over here…”. I just want a thing and I don’t want to have to think about al the other things I already have as well. I thought about how the new thing fits to the product and it does now don’t tell me I have to change everything else as well.

Also when things break it is easier to assess fixing work on a single component that went titsup as I can see what is wrong with it. If you have to touch everything just  because a specific feature didn’t work it fails me.

2. Budget

Not touching everything else when adding or changing a specific feature obviously will be less expansive than only working on the feature and then some integration code.

Decoupled-ness also reduces side effects which become costly during development and maintenance.

3. Acceptance

It would be so nice if I order one thing and get to see it when it’s ready to approve it without having to look at nearly everything else to check if it’s still working. I want to focus only on what I ordered.

4. Controllability

Sometimes a feature turns out a failure and needs to be turned off. Can I do that or do I have to touch everything again?

There are other reasons to shut down a feature. Maybe it gets hammered by bots, is insecure or doesn’t comply with a new law. Being able to quickly turn it off matters.

Also turning on is an issue. If a feature needs to go live on a certain date it would be nice to not deploy a whole new application that might fail on so many levels when being live although it behaved under staging conditions.

And what if I want to move a feature behind a paywall? Can I do that or does the feature need to be rewritten?

5. Flexibility

The clients focus will always be on getting a better user experience by providing new cool up-to-date features that are fresh on the market.

Having separate components rather than a monolithic blob makes it easier to come up with new ideas and getting them out. Changing things is easier this way so I can try out things that I wouldn’t have before because it was too expansive and complicated.

As you can see even a technical detail such as decoupling matters to your client.

Separation of Concerns

<< Easiest client-side form validation with Happy.js

Google search provides context – the knowledge graph >>