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

31–40 of 67 posts

Re: Criminal Overengineering

#31

Post by DannoHung »

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…

Yeah, this is why some people get paid money to make decisions about software design. Finding a balance between what you ain't gonna need and what you should be prepared for involves experience, a knowledge of the problem space, and just plain smarts.

Re: Criminal Overengineering

#32

Post by zackham »

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…

My 2 cents: Go for (1), keep several potential future use cases in mind, and make damn sure you don't architect yourself out of those being natural directions for the code to go. Often this leads you to stub out an interface that looks like the beginning of a nice architecture, but not actually flesh out the code beyond what is necessary. This strategy generally requires more thinking than coding, but in my experience that is usually a good thing.

Re: Criminal Overengineering

#34

Post by bmm6o »

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…

It's worse than that. The whole article is attacking a straw man, which so many software blog articles do. I'm not sure I would take the example in a Wikipedia article to be the pinnacle of software engineering. Sure, it would be strange to see the sample code appear as-is in a code base. I would agree that a strategy for adding and subtracting might be overkill. But it's an example! It's purpose is to convey an idea. If you're going to critique it, you really have to do so on those grounds.

Re: Criminal Overengineering

#35

Post by bediger »

jonsen wrote: post #5
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"

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.

Re: Criminal Overengineering

#36

Post by a-priori »

edw519 wrote: post #17
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…

Great comment. 2 thoughts: 1. You can read anything and it (often) sounds convincing. Quality writing that is incorrect often trumps poor writing that is correct. That's way we must always be vigilant readers, especially on the internet. 2. "ArchitectingForTheFuture" does not necessarily mean "MoreLinesOfCode". I'd like to read more articles of Type 3: How excellent design and proper use of tools gives you the best o…

As always, the best solution is somewhere in the middle of the two extremes. Everything has a cost. YAGNI has a cost of rework later if it turns out you do need it after all. Architecting For The Future has extra up-front and maintenance costs, which is wasteful if it turns out the future wasn't as you saw it.

And so, it becomes a cost-benefit analysis. C(YAGNI) = C(develop a simpler version) + C(rework) x p; C(AFTF) = C(develop) + C(maintain). Where p is the anticipated probability that you will actually need that feature (and realizing that you're probably going to guess higher than the actual probability).

Re: Criminal Overengineering

#37

Post by anamax »

a-priori wrote: post #36
edw519 wrote: post #17

Earlier quoted context omitted.

Great comment. 2 thoughts: 1. You can read anything and it (often) sounds convincing. Quality writing that is incorrect often trumps poor writing that is correct. That's way we must always be vigilant readers, especially on the internet. 2. "ArchitectingForTheFuture" does not necessarily mean "MoreLinesOfCode". I'd like to read more articles of Type 3: How excellent design and proper use of tools gives you the best o…

As always, the best solution is somewhere in the middle of the two extremes. Everything has a cost. YAGNI has a cost of rework later if it turns out you do need it after all. Architecting For The Future has extra up-front and maintenance costs, which is wasteful if it turns out the future wasn't as you saw it. And so, it becomes a cost-benefit analysis. C(YAGNI) = C(develop a simpler version) + C(rework) x p ; C(AFTF…

There's a C(rework) term in C(AFTF) as well because the "in advance" work never actually "just works" for the future that shows up.

Re: Criminal Overengineering

#38

Post by anamax »

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 :-)

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.

Re: Criminal Overengineering

#39

Post by bsaunder »

lukev wrote: post #30
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…

I feel your pain - I struggle with the same thing. But I think it's possible, to some extent, to have the best of both worlds. An ideal of clean , logical design actually satisfies both #1 and #2. You don't write any more than you need to, but you architect it sensibly so if you need to modify it in the future, there's a natural way to do it. A case study: you are responsible for maintaining a moderately sized mailin…

hmm...

If I have to do something new with the list, I don't have to completely rewrite my program (like #1 does)

You said #1 only took 15 minutes. Hardly seems like a big cost. If you never have to rewrite, #1's the right answer. Or if the rewrite includes functionality never even anticipated in your "correct solution". If it's that small, starting over with a clean slate may be faster than fitting in new functionality.

Re: Criminal Overengineering

#40

Post by radu_floricica »

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 point was when I decided rewrites aren't a bad thing. I started seeing the code as alive - unchanged code isn't good, is dead. The myth of perfect code is just an illusion. Writing for the next version sounds very sensible - until you get enough years under your belt to realize that either there won't be a next version or it won't be anything like you expect.

Post reply on HN