It's Time to Decouple Your Development Processes

Photo: kris krüg

Over the last couple of years, I feel like I've become a broken record. On project after project I find myself hearing about a particular problem. And, shortly thereafter, I find myself calling a meeting wherein I explain what I am about to share with you. It's something that I've always thought obvious and thought it was already well-covered in articles, books, classes, etc. However, experience says otherwise. Quite simply, projects have way too much tightly-coupled development process and they need to decouple the bits and things will run much more smoothly.

While "loosely coupled" often refers to service-oriented architecture and web-specific things, this approach to decoupling is not limited to that sphere. The concepts are certainly related, but you can still have a project that's building loosely couple technology but the team is working in a tightly coupled way.

It usually comes up when I'm being asked to deliver a huge amount of work in a staggeringly short amount of time. That, by itself, isn't a direct indicator. However, shortly after asking that I leap over a tall building in a single bound, the requester usually indicates that the reason for the giant jump is because an upstream or downstream member of the project "can't" move on with their work unless I can succeed.

Fortunately, rather than finding the nearest phone booth to change into blue and red spandex (the world does NOT need to see that), I've learned to push back on such requests.

A prime example is when I'm building the AJAX or client-side screen designs for a JSP/ASP/PHP server-side application. I'll be told that they "can't" build the server-side components until they have the actual screens.

Now, given that all HTML or AJAX actually does to interact with server-side scripts is make HTTP requests, you can completely decouple that dependency by defining those messages. You can usually whip up "fake" forms that will make all of the appropriate requests and those can be used to build and test the server-side components.

The reverse is also true. If the database design and sample data aren't ready to populate the JSP script that will deliver data requested by AJAX, you can define the middle again and have the JSP endpoint deliver a fake set of data.

Then, both people or teams can work toward the middle. As each side works on their own area, they may find things that aren't supported in the agreed-upon middle, but you only need to re-negotiate that bit and each side can adjust. As long as everyone codes to *that* specification, things line up as code gets finished.

This results in the very things that everyone says they want. You've got code that's easier to unit test, an elimination of roadblocks for nearly every person on the project and things move forward much more smoothly. Whenever I've worked on a project where we started by defining the connections between layers and then all went off to do the stuff we're best at, we delivered functionality faster, it worked better and we had fewer bugs.

Again, this probably seems obvious to lots of you. However, reality seems to indicate that it's not as obvious as it should be, because I keep having to explain it. You've got lots of pieces that need to communicate with each other, but people seem to ignore the contents of that communication when doing their initial design. Yet, if you did nothing BUT define those bits, nearly everything else would pretty much work itself out. The reverse isn't true.

Of course, in an ideal world, we'd all do things according to the book (whether that's the Agile book or another one). However, as long as I have to live in the real world instead of Utopia, defining the middle and working toward it is a fantastic compromise that keeps things moving forward and lets me go home at night and have my weekends off as well.