Monday, April 10, 2006

Over-engineering

So BlackTigerX says in his most recent comment that what I described in my last post is a case of over-engineering (with a hyphen, 'cause that's what turned up the most results when I Googled it). He's very right, and not being acquainted with me he probably has no idea how funny his observation is.

My tendency to over-engineer is dramatic. Always has been. Perhaps it's a character flaw, but I tend to like to figure things out before I attempt them.

I will often spend a significant amount of energy just thinking about a problem. I suspect many folks look at me and think, "Why doesn't he just try something? Anything?"

The answer is this: because when I do that -- try something just to see what happens -- I invariably throw out the result. The reason is always the same, too. Invariably, without digression, I run up against that "something I didn't think about" that causes my whole mental model up to that point to collapse.

Mix that behavior pattern into the feedback loop where it combines with over-engineering, and you will have undoubtedly spent twice too much time trying something that proved useless.

I've done this too many times to repeat it anymore, so now I tend to just think about the problem. That way, I reason, I will run into those showstoppers in my head, where the cost of failure runs no more than that of a still-maleable mental model modified.

But I adjusted my strategy lately. I'm trying to make a concerted effort to break problems down into more manageable chunks. I'm doing it both at work and at play. Some of the results have been encouraging: I find that I'm spending more time working on Vyde now that I have a more concise set of immediate goals. But I also find the results a little troubling: with less design and more attempts, I've found that I'm throwing out solutions and then repeating those mistakes in a different way later. Though rejected attempts seem to spur a new line of reasoning, I think it may be an illusion, as the new path tends to run up against the same problem more often than not. You'd think that taking a different approach would lead to at least a different kind of problem, but no, the problem I didn't take the time to think through the first time shows up again. I think this lends some credence to the idea that design really is worth doing, and over-engineering is something to reduce, not eliminate.

I've noticed a similar pattern at work. There come times when my complicated designs get the better of me. Today, for instance, I all-of-a-sudden felt overwhelmed by the complexity of my current project. Specifically, my ability to unit test has reached a plateau: building in layers seems to lead to testing procedures for higher-level constructs requiring a lot of low-level legwork. That is, if an instance is created as a product of low-level code, my unit tests for higher-level operations on than instance require building the instance from scratch.

Wait. I'm doing it again, aren't I?

1 Comments:

Blogger BlackTigerX said...

if you haven't, I recommend you read Code Complete (second edition), now, "knowing" you, I think you'd have a pretty hard time reading the whole dang thing, but at least read some chapters, I think it will help a lot

seems you have a problem defining the problem, you have to learn how to define the problem without trying to give a solution at the same time

4/22/2006 10:16:00 AM  

Post a Comment

<< Home