Being stupid to get better productivity?
Posted
by
loki2302
on Programmers
See other posts from Programmers
or by loki2302
Published on 2011-09-06T10:09:32Z
Indexed on
2011/11/25
10:05 UTC
Read the original article
Hit count: 258
I've spent a lot of time reading different books about "good design", "design patterns", etc. I'm a big fan of the SOLID approach and every time I need to write a simple piece of code, I think about the future. So, if implementing a new feature or a bug fix requires just adding three lines of code like this:
if(xxx) {
doSomething();
}
It doesn't mean I'll do it this way. If I feel like this piece of code is likely to become larger in the nearest future, I'll think of adding abstractions, moving this functionality somewhere else and so on. The goal I'm pursuing is keeping average complexity the same as it was before my changes.
I believe, that from the code standpoint, it's quite a good idea - my code is never long enough, and it's quite easy to understand the meanings for different entities, like classes, methods, and relations between classes and objects.
The problem is, it takes too much time, and I often feel like it would be better if I just implemented that feature "as is". It's just about "three lines of code" vs. "new interface + two classes to implement that interface".
From a product standpoint (when we're talking about the result), the things I do are quite senseless. I know that if we're going to work on the next version, having good code is really great. But on the other side, the time you've spent to make your code "good" may have been spent for implementing a couple of useful features.
I often feel very unsatisfied with my results - good code that only can do A is worse than bad code that can do A, B, C, and D.
Are there any books, articles, blogs, or your ideas that may help with developing one's "being stupid" approach?
© Programmers or respective owner