Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Criminal Overengineering

coderoom.wordpress.com

Post reply on HN
Print view View original

41–50 of 67 posts

Re: Criminal Overengineering

#41

Post by j_baker »

telemachos wrote: post #15

Argh. Apparently there are two very popular types of article in the software blog world: Type 1: YAGNI (like this example): Do less now. Refactor later as needed. It won't be needed, most likely. Chill out. (All driven by the question, "Dude, wtf? 100 lines of boilerplate for a 5 line case statement? Snap out of it.") Type 2: Architect astronautics: Do more now. Build for the next version. You will need more then, so…

The reason is that neither view is correct or incorrect. They're just different. Reality is in the happy medium: preparing for the future without overengineering.

Re: Criminal Overengineering

#42

Post by j_baker »

radu_floricica wrote: post #40
telemachos wrote: post #15

Argh. Apparently there are two very popular types of article in the software blog world: Type 1: YAGNI (like this example): Do less now. Refactor later as needed. It won't be needed, most likely. Chill out. (All driven by the question, "Dude, wtf? 100 lines of boilerplate for a 5 line case statement? Snap out of it.") Type 2: Architect astronautics: Do more now. Build for the next version. You will need more then, so…

Sometimes the world just is as simple as it seems. Type 1 is right, type 2 isn't. After 15 years of writing code I can only vouch for two metrics of code quality: clarity and length. For a long time I too thought that clarity means using "thisIsAStudentBirthDate" variable names - but it turns out there are very very few instances where the shortest code isn't also the most obvious at first glance. I think the turning…

Type 1 is right for you. A good type 2 knows they can't anticipate the future and prepares for the unknown. If overdone, this is bad, but the same can be said for type 1.

And rewrites do become difficult as a system grows if you don't think them through. It's easy to rewrite one component with no dependencies, but it's not so easy to rewrite something that lots of different pieces of code rely on.

Re: Criminal Overengineering

#43

Post by sprout »

arethuza wrote: post #20
jemfinch wrote: post #16

Earlier quoted context omitted.

> So what's wrong with using a switch statement if all you have are 3 operations? Because you won't always have only three operations. What about division? Exponentiation? Square root? Factorial? Arbitrary user-defined functions? What if you didn't anticipate an operation one of your clients needs? If you use standard OO principles, your client can rectify that problem; if you use a switch statement, they can't. > Ev…

I would guess that 95% of extensible systems are never extended :-)

Yes, but how much time does it save the other 5% of the time?

If the other 5% of the time stuff takes off and becomes standard throughout the projects using your code, then it can more than make up for it.

Re: Criminal Overengineering

#44

Post by infinite8s »

stcredzero wrote: post #22
ErrantX wrote: post #3

Earlier quoted context omitted.

One of my lecturers wrote the following at the top of our course notes: Contrary to popular opinion using OOP does NOT mean "thou shalt make every last thing an object"

Really, it depends on your environment. In Smalltalk, most things are objects. Not surprisingly, it turns out to be easiest to make most things objects. I find that Smalltalk is best when a program is mostly objects, there's a sprinkling of short-ish procedural methods whose workings are hidden by encapsulation, and perhaps a handful of long optimized algorithmic methods. I suspect that in Self, it's easier to make m…

Also, functions + closures = objects

Re: Criminal Overengineering

#45

Post by sapphirecat »

stcredzero wrote: post #25
efsavage wrote: post #12

TLDR: Don't solve for problems that don't exist.

I think a better way to put it is: 1 - only solve problems that already exist 2 - only accept solutions less painful than the problem Really, if programmers could stick to this, this would be all the methodology we'd need!

> 2 - only accept solutions less painful than the problem

That sounds good, but it doesn't work unless you have the experience to tell how painful the solutions you thought of actually are--which you don't have if you haven't been hurt by some overengineering.

Re: Criminal Overengineering

#46

Post by stcredzero »

sapphirecat wrote: post #45
stcredzero wrote: post #25

Earlier quoted context omitted.

I think a better way to put it is: 1 - only solve problems that already exist 2 - only accept solutions less painful than the problem Really, if programmers could stick to this, this would be all the methodology we'd need!

> 2 - only accept solutions less painful than the problem That sounds good, but it doesn't work unless you have the experience to tell how painful the solutions you thought of actually are--which you don't have if you haven't been hurt by some overengineering.

Lacking that, lines of code isn't a bad place to start. Also, if you have coworkers, look at their facial expressions when you explain the thing to them.

Re: Criminal Overengineering

#47

Post by stcredzero »

bediger wrote: post #35
jonsen wrote: post #5

Earlier quoted context omitted.

In some sense that's what the second O says, isn't it? It's not called Object Programming, but Object- Oriented Programming.

But isn't that where it goes astray? If we all called it "Class Oriented Programming" we'd come closer to an accurate name. "Class Oriented Programming" as a name might take away the emphasis on instances, and put emphasis on designing classes. Or not. There appears to be no bottom to human stupidity.

If we apply a design pattern from Smalltalk, we have Concepts. Every Concept has another concept which is its Misconception. This gives us an infinite regress of misconceptions, unless we can come up with a Metamisconception, which is a concept which is its own erroneous misconception. Then we can implement unbounded stupidity in a system of finite size.

Re: Criminal Overengineering

#48

Post by ErrantX »

stcredzero wrote: post #22
ErrantX wrote: post #3

Earlier quoted context omitted.

One of my lecturers wrote the following at the top of our course notes: Contrary to popular opinion using OOP does NOT mean "thou shalt make every last thing an object"

Really, it depends on your environment. In Smalltalk, most things are objects. Not surprisingly, it turns out to be easiest to make most things objects. I find that Smalltalk is best when a program is mostly objects, there's a sprinkling of short-ish procedural methods whose workings are hidden by encapsulation, and perhaps a handful of long optimized algorithmic methods. I suspect that in Self, it's easier to make m…

A lot of stuff can work as objects; in fact in many cases an object can be the smallest (or simplest, or most logical etc.) piece of code.

But not everything must be abstracted :)

Re: Criminal Overengineering

#49

Post by radu_floricica »

j_baker wrote: post #42
radu_floricica wrote: post #40

Earlier quoted context omitted.

Sometimes the world just is as simple as it seems. Type 1 is right, type 2 isn't. After 15 years of writing code I can only vouch for two metrics of code quality: clarity and length. For a long time I too thought that clarity means using "thisIsAStudentBirthDate" variable names - but it turns out there are very very few instances where the shortest code isn't also the most obvious at first glance. I think the turning…

Type 1 is right for you . A good type 2 knows they can't anticipate the future and prepares for the unknown. If overdone, this is bad, but the same can be said for type 1. And rewrites do become difficult as a system grows if you don't think them through. It's easy to rewrite one component with no dependencies, but it's not so easy to rewrite something that lots of different pieces of code rely on.

A problem with a verbose approach is that when ver 2.0 comes you can't really know/remember which part of the code is actually used and which was just prepared for future development - so you end up maintaining and coding around pieces of code that will never be used.

Like I said, what eventually bites you is that you never ever ever know exactly what version 2.0 will require. So in the end you still have to adapt code, and adapting clean short code is easier.

Re: Criminal Overengineering

#50

Post by jemfinch »

anamax wrote: post #38
arethuza wrote: post #20

Earlier quoted context omitted.

I would guess that 95% of extensible systems are never extended :-)

I'd guess that more than 5% are extended (maybe 6-8%), but that more than 95% are not extended as expected. When something is not extended as expected, either you end up with something not as good as you'd have gotten by waiting or you have to rip out some of what you put in for the future without ever using it.

The problem with this term "extended" is that it's unnecessarily limiting. Code needs to be maintained, whether or not it's "extended," and switch statements are by far less maintainable than the alternative polymorphism-based implementation. They don't as readily admit separate testing, and the implementation of specific operations are not isolated from each other, etc. 100% of code is maintained and the polymorphic method is far better for that than the switch statement. A programmer who chooses the latter over the former is being shortsighted.
Post reply on HN