Problem Decomposition deserves more attention!

If there is one idea in Computer Science and Software Engineering that underlies every other idea, then what is it? (It’s not Algorithms!)

“All problems in computer science can be solved by another level of indirection.” — David Wheeler

If indirection implies how a problem can be solved, then decomposition implies how a solution was reached. Problem Decomposition is about understanding the solution to a problem. It is the inverse of indirection.

Problem Decomposition is breaking a big, complex problem into smaller parts that could be solved relatively independently.

Code is written once, but read many times — that aphorism is as old as hills! It entails that a solution to a problem is formed once but understood by many, numerous times. This breaking of logic into smaller parts and understanding the whole is a form of decomposition. Thus, it is essential in resolving the complexity of a software system — whether it is a new functionality to be added, current functionality to be evaluated, unknown behavior to be predicted, (side-)effects of a change to be determined, aftermath of a crash to be traced or a problem to be debugged and fixed; every petty requirement is be addressed through Problem Decomposition. Not just this, it enables the programmer to devise elegant and cheaper solution. And, that is why Problem Decomposition is fundamental to software engineering and engineers — one skill set to die for!

Let’s shoot for things from day-to-day.

Problem-isolation is fundamental to debugging. Identifying an issue and reproducing the bug are the preliminaries of debugging. This is where we spend gazillions of man-hours in the software industry. A very critical competency for a programmer to posses. Problem-isolation, in essence, is decomposition.

Another one of those. The way to reach an algorithmic solution to a complex problem is to decompose the problem and then apply known methods (matching the subproblem to a known pattern, etc.) to figure out a solution. In fact, Divide-and-Conquer and Dynamic Programming apply decomposition straight away.

Performance-evaluation, design, architecture — pick any part of Computer Science or Software Engineering, and it will have Problem Decomposition at its heart.

If it is so fundamental, how do we not focus on specifically evaluating an interview candidate from this perspective. Has it ever happened, post interview you were completely convinced you hired a superstar who later, disappointingly, turned out to be supporting star-cast in cameo role?

The apprehension and concern is, probably, the candidate doing well in interview is great at solving stereotypical interview questions and “cracking” the interviews, but could fail miserably in the real-world software engineering action. There is a compelling need to be wiser.

Algorithms are a great way to evaluate an interview candidate, but it needs to be supplemented with explicit evaluation of the Problem Decomposition competency. Because that algorithm question you asked has probably got nothing to do with the real job, but Problem Decomposition very much does!

From the horse’s mouth: Prof. John Ousterhout on Problem Decomposition.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s