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

51–60 of 67 posts

Re: Criminal Overengineering

#51

Post by lukev »

bsaunder wrote: post #39
lukev wrote: post #30

Earlier quoted context omitted.

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 functionali…

This is a small example, so yeah, you're right, when the absolute times are so small.

But say instead that it's a larger problem, and that #1 takes one day to build, #2 takes a week, and the "preferred" solution (call it #3) takes two days.

Then along comes your change request. It will take most of a day to rewrite #1 to do something never anticipated, but it can be slotted into #2 or #3 in about an hour.

Now you've broke even between #1 and #3, and that's only the first change request. Any real system is going to get many more.

These numbers are pulled out of thin air, of course, but they're pretty accurate according to my development experience.

Re: Criminal Overengineering

#52

Post by Tamerlin »

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…

Experience WILL tell you that the best answer is ALWAYS #1. Don't make it complicated unless you absolutely have to. 99% of the time, you don't, and the architects are full of it, but if they ever admit that, then they lose their job security.

When in doubt, remember what Knuth said: "Premature optimization is the root of all evil."

Re: Criminal Overengineering

#53

Post by Silhouette »

ajdecon wrote: post #14
Silhouette wrote: post #8

I think this one line sums up my views about a lot of trendy software development practices: > If you're about to take a hundred lines to write what you could in ten, stop and ask yourself this: what the fuck ? TDD advocacy is my pet hate for this today. I read an article the other day that managed to turn Hello, world into about half a dozen source files and dozens of lines of code, all pulled together with a makefi…

Out of curiosity, can you post a link to the "hello, world" article?

Your wish is my command. :-)

http://blog.objectmentor.com/articles/2010/05/20/hello-world...

Re: Criminal Overengineering

#54

Post by j_baker »

radu_floricica wrote: post #49
j_baker wrote: post #42

Earlier quoted context omitted.

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 co…

If you have to explicitly remember which code was prepared for future development, you're doing something wrong. The point of having loosely coupled code is that it should be easily modifiable under a wide variety of circumstances.

Re: Criminal Overengineering

#55

Post by arethuza »

sprout wrote: post #43
arethuza wrote: post #20

Earlier quoted context omitted.

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.

http://c2.com/xp/YouArentGonnaNeedIt.html

Re: Criminal Overengineering

#56

Post by jimbokun »

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…

"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."

Isn't that why we write good unit tests and refactor? It gives you close to best of both worlds. Writing unit tests is helpful anyways, and gives you peace of mind when you introduce patterns later on when you actually need them.

Re: Criminal Overengineering

#57

Post by jimbokun »

Silhouette wrote: post #53
ajdecon wrote: post #14

Earlier quoted context omitted.

Out of curiosity, can you post a link to the "hello, world" article?

Your wish is my command. :-) http://blog.objectmentor.com/articles/2010/05/20/hello-world...

I kept looking for the give away that this was some kind of sick parody. But no, it seems totally sincere.

Re: Criminal Overengineering

#58

Post by jokull »

mechanical_fish wrote: post #23
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 conclusion, as I watch my own code wander back and forth in the space between the two poles, is: One needs a lot of practice!

"practice" or "experience" are the terms missing from this discussion! An experienced person can iterate less and has a better design right off the bat.

Re: Criminal Overengineering

#59

Post by jacabado »

j_baker wrote: post #54
radu_floricica wrote: post #49

Earlier quoted context omitted.

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 co…

If you have to explicitly remember which code was prepared for future development, you're doing something wrong. The point of having loosely coupled code is that it should be easily modifiable under a wide variety of circumstances.

I upvoted you for your braveness but I strongly disagree with you. (For me) Type 2 is wrong for everybody because: + Been there, done that, ended sadly; + We're all different but our limitations are pretty much the same, respect your colleagues! + Every successful achieving programmer I've worked with are persons with particularly good sense; + Knowing how programming related skills like abstraction and logic are highly related to cleverness you can be easily tricked into seeing programming as a cleverness demonstration or competition. That should be done in college or in controlled environments(no deadlines, no changes in team).

Re: Criminal Overengineering

#60

Post by Silhouette »

jimbokun wrote: post #57
Silhouette wrote: post #53

Earlier quoted context omitted.

Your wish is my command. :-) http://blog.objectmentor.com/articles/2010/05/20/hello-world...

I kept looking for the give away that this was some kind of sick parody. But no, it seems totally sincere.

I'm afraid several of the guys at ObjectMentor lost the plot some time ago. It's a shame, because back in the day, some of them wrote about ideas that were thought provoking even if you didn't necessarily agree with all of them.

I don't often visit their blogs any more, but occasionally, I still come across their site after someone links to it. It's one of those things where you know it's bad and you should just look away, but somehow you can't help yourself. ;-)

Post reply on HN