At a client’s office, almost a year ago, a very talented developer on their team thought it was interestingly funny when I said - “and that’s how you divide and rule”. “We call it Divide and conquer” – he laughed. [Being an Indian, at times my English tends to have a slightly different touch to it. :)]
“But you’re probably correct. You don’t just want to conquer. What you really want to do is to conquer and then control the situation and rule, for a long time.” - He added on.
No, we were not making a sinister plan to take over the world. We were just talking about how we can break one big Monolithic BizTalk Orchestration into smaller, easy to mange, easy to comprehend and faster orchestrations.
He had drawn up this Big Design of their existing approach on the left and then I had proceeded to draw smaller designs of multiple Orchestrations and how they would talk to each other on the right when I finally wrapped up the meeting with the line “divide and rule”. I was suggesting that he break his Orchestrations down to smaller moving parts so that when a part doesn't work - he can take it out - independently - and Analyze it!
I don't think any programmer disagrees with the fact that we should Code Smaller. A Lot of basic concept articles, teach a person who is starting out on his programming endeavors how he can Break Larger Pieces of Code into Smaller Pieces. But divide and conquer (/rule) design paradigm goes beyond just writing cohesive, small and easy to maintain functions and classes.
Every now and then I see even good developers forget the Divide and Conquer paradigm under pressure. Or they simply do not put it to practice for tasks other than coding. I've recently seen a very capable business analyst trying to learn build management by taking a CuriseControl configuration file and trying to configure CriuseControl to get the source code from SVN, fire the build, send email notification when the build fails and log the result in the formatted HTML report, all at once.
When I was called in to help, my first reaction was to wipe out all other code from the 50+ line config file - and leave just 5 lines that will have cruise control fire the build. Turns out, those five lines were broken. Once that was fixed we moved on to Getting the source code from SVN - another 3 lines which just worked. We kept fixing a part at a time and soon we were done in a couple of hours.
I've seen so many engineers (Highly capable ones. At times, I'm guilty of this too) run through more than 10 screens before they can reach a reported bug and just reproduce it. Then apply the fix, go through the screens all over again only to find out that the fix doesn't work. Then start thinking of a different fix. Over and Over again. Spending more than 5 minutes on every attempt, just to check if the fix worked.
When we do this the time taken to fix a bug increases dramatically, the frustration level increases dramatically and the ability to think using a Pragmatic Approach comes down with every failed attempt. We start programming by co-incidence! In situations like these, Isolating the problem by replicating it using smaller code snippets and moving it out of your codebase so that you can analyze it separately, can help a lot.
If you are trying to fix a bug that requires more than a couple of minutes to just reproduce and has taken more than 5 attempted fixes already, you might be better off isolating the bug by bringing it out of the codebase and reproducing it independently using simple code snippets. If you are finding a bug too complex to fix you're probably trying to fix more than one bugs at a time. If a feature you're building in your sprint seems too complicated you're probably trying to build two connected features simultaneously.
In the pressure of fixing a bug that refuses to get fixed or in the excitement of writing code for something fairly complex, it's very easy to tell yourself - "I'm almost there!" - and it's easy to spend away hours or sometime even days - by continuing to tell yourself that, not realizing that you're in fact, getting nowhere!
If something takes much longer to fix or build than you initially expected or you're starting to get frustrated with a problem - Divide and Conquer! And then, once you've conquered the problem, enjoy your Rule over the situation! :)
Comments are closed.