7 ms·

Criminal Overengineering

116 points by moconnor 16y ago

VBprogrammer 16y ago
I completely disagree with the example given in this blog. I don't have time to give a full explaination but I believe the google clean code talks gives a far better arguement than I ever could. On the general principle I agree that overengineering is to be avoided, but I actually think the example shows a clear disregard for Object Orientated principles. http://www.youtube.com/watch?v=4F72VULWFvc http://www.youtube.com/watch?v=4F72VULWFvc
- ErrantX 16y ago
  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"
  - jonsen 16y ago
    In some sense that's what the second O says, isn't it? It's not called Object Programming, but Object-Oriented Programming.
    - bediger 16y ago
      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.
      - stcredzero 16y ago
        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.
  - edanm 16y ago
    Tell that to Java developers :)
  - stcredzero 16y ago
    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 more things objects. (jk - everything is an object in Self.) Objects aren't quite as easy to use in C++ and Java. The cost is higher, so the opportunities to use objects with a good cost/benefit payoff are fewer. That's all there is to it. Does this generalize? In most Functional languages, functions are really easy to use, and can be used in flexible and powerful ways. What's the best way to program in them? Why, using functions! Yup, seems to work. Fancy that!
    - infinite8s 16y ago
      Also, functions + closures = objects
    - ErrantX 16y ago
      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 :)
    - hboon 16y ago
      In Smalltalk, everything is an object.
- arethuza 16y ago
  So what's wrong with using a switch statement if all you have are 3 operations? Even if more operations had to be added I'd probably let it grow to the point where the method the switch is in was getting a bit unwieldy then look at refactoring it using a pattern if I really thought it would be worth it.
  - jedbrown 16y ago
    Depends whether it's in a library where extensibility is a feature.
  - jemfinch 16y ago
    > 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. > Even if more operations had to be added I'd probably let it grow to the point where the method the switch is in was getting a bit unwieldy then look at refactoring it using a pattern if I really thought it would be worth it. Why not just do it right from the start? It's extremely simple, it's a pattern every OO programmer is familiar with, it's more computationally efficient and has other advantages as well. It's also not nearly as complicated as the linked Strategy code. The appropriate analogue to the author's switch statement (in Python, since I'm not a Java programmer): class Op(object): def eval(self, a, b): raise NotImplementedError class Add(Op): def eval(self, a, b): return a + b class Subtract(Op): def eval(self, a, b): return a - b class Multiply(Op): def eval(self, a, b): return a * b It's twelve non-blank lines, more than half of them boilerplate; translated into Java it would probably gain a few keywords and a couple lines of ending braces, but would not grow significantly. Compare this to almost that many lines for the switch version (note that the OP left out the declaration of the enum, the function boilerplate, etc.) for something less maintainable, less extensible, less idiomatic, and with lower performance.
    - arethuza 16y ago
jewbacca 16y ago
I don't think I've ever read a rant about code smells which couldn't be trivially fixed with basic functional programming principles.
- stcredzero 16y ago
  It also depends on the language. I bought a book about functional programming in Java once. I found it painful.
  - tkahn6 16y ago
    You should seriously consider checking out Clojure. It's awesome.
Silhouette 16y ago
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 makefile several times longer than the whole effort should have been, and seemed to be claiming some sort of profound revelation from doing this! The quote is also a succint analysis of why C++ and Java are becoming less useful every year, relative to the field of programming languages as a whole. And of course, as in the example in the article, it's good for bashing people who think tools like design patterns must be used everywhere, regardless of whether they actually help to keep a design clean and maintainable.
- ajdecon 16y ago
  Out of curiosity, can you post a link to the "hello, world" article?
  - Silhouette 16y ago
    Your wish is my command. :-) http://blog.objectmentor.com/articles/2010/05/20/hello-world-revisited http://blog.objectmentor.com/articles/2010/05/20/hello-world...
    - jimbokun 16y ago
      I kept looking for the give away that this was some kind of sick parody. But no, it seems totally sincere.
      - Silhouette 16y ago
        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. ;-)
gfunk911 16y ago
Part of the problem is that a language like Java: 1. Is verbose by its very nature 2. Has language characteristics that push the developer in the direction of using design patterns at every opportunity. So what might be a 1000 line program in Ruby is a 3000 line program in Java (translated as directly as possible), but then the deficiencies of the language turns simple idioms in a powerful language into complex design patterns in Java. See: closures, lack of duck typing/deficient type system, etc.
- Destruct1 16y ago
  I think the Java culture plays a big part in the whole mess. It would be easily possible in other languages to write 4 implementations of a basic list or public setter/getter for every member or buffered stream interfaces for all kinds of I/O. Its not done because long solutions are frowned upon.
billswift 16y ago
This is a large part of a post I made April of last year: KISS: Keep It Simple and Succinct Succinct means brief and concise, to the point. A succinct argument is one that more directly addresses the point under discussion. The "traditional" meaning of KISS completely misses the point. The biggest problem KISS addresses is over-complication of plans - and it is not a problem of stupidity. Those most prone to over-complicate are the more intelligent, especially the highly intelligent and highly educated, but lacking in practical experience. Experience, especially wide experience, is the best prophylaxis for over-elaborate plans. http://williambswift.blogspot.com/2009/04/kiss-keep-it-simple-and-succinct.html http://williambswift.blogspot.com/2009/04/kiss-keep-it-simpl...
efsavage 16y ago
TLDR: Don't solve for problems that don't exist.
- stcredzero 16y ago
  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!
  - sapphirecat 16y ago
    > 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.
    - stcredzero 16y ago
      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.
telemachos 16y ago
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 why not prepare now? Decouple that code. Use more patterns. Hoist that jib. (All driven by the question, "What will your code/software/app do if...?") I read type 1, and it (often) sounds convincing. I read type 2, and it (often) sounds convincing. I get a fucking headache from the cognitive dissonance. I make more coffee and get back to work, no wiser than before.
- edw519 16y ago
  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 of both Type 1 and Type2. [EDIT 1: stcredzero, in reference to cousin comment, my personal metric is n=2. I never want the same line of code more than once. I'm sure there are good arguments for other values of n, but this has always seemed to work well for me.] [EDIT 2: I try to make a point to never say "Not Hacker News" or complain about content. Conversely I should be quick to claim "Not Not Hacker News". This is a great thread! About stuff near and dear to this programmer's heart. Keep 'em coming.]
  - stcredzero 16y ago
    As I say in a cousin comment: an easy way to get the best of both worlds is to wait until you have an apparent problem. The 4th time you start writing that same switch statement, maybe you can tell you're going to be doing this a lot more and it's time to bring out Strategy. Doing it sooner is too likely to be premature. The advantage of this approach: you never have to prognosticate. Hindsight is 20/20, so use it! EDIT: I used to use n=2 as my threshold, but I found it much better to have a slightly higher n in Smalltalk. I am spoiled, though because I have such lightweight but powerful (syntax-aware) tools for searching such patterns.
clark 16y ago
I think frameworks have to be engineered carefully; the use of the strategy pattern in the example is a typical and is very soundly used in a framework. I think the problem is that developers write far too many frameworks than they should. Interestingly enough, it's code that isn't extensible that ends up being a framework -- mostly because the authors have time to focus on documentation, support, user interface and the like.
herrherr 16y ago
In this context "The Evolution of a Python programmer": http://gist.github.com/289467 http://gist.github.com/289467
Sandman 16y ago
I agree with the article... up to a point. Write your programs to be as simple as possible - but not simpler.

116 points by moconnor 16y ago

I completely disagree with the example given in this blog. I don't have time to give a full explaination but I believe the google clean code talks gives a far better arguement than I ever could. On the general principle I agree that overengineering is to be avoided, but I actually think the example shows a clear disregard for Object Orientated principles. http://www.youtube.com/watch?v=4F72VULWFvc http://www.youtube.com/watch?v=4F72VULWFvc

ErrantX 16y ago
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"
- jonsen 16y ago
  In some sense that's what the second O says, isn't it? It's not called Object Programming, but Object-Oriented Programming.
  - bediger 16y ago
    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.
    - stcredzero 16y ago
      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.
- edanm 16y ago
  Tell that to Java developers :)
- stcredzero 16y ago
  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 more things objects. (jk - everything is an object in Self.) Objects aren't quite as easy to use in C++ and Java. The cost is higher, so the opportunities to use objects with a good cost/benefit payoff are fewer. That's all there is to it. Does this generalize? In most Functional languages, functions are really easy to use, and can be used in flexible and powerful ways. What's the best way to program in them? Why, using functions! Yup, seems to work. Fancy that!
  - infinite8s 16y ago
    Also, functions + closures = objects
  - ErrantX 16y ago
    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 :)
  - hboon 16y ago
    In Smalltalk, everything is an object.
arethuza 16y ago
So what's wrong with using a switch statement if all you have are 3 operations? Even if more operations had to be added I'd probably let it grow to the point where the method the switch is in was getting a bit unwieldy then look at refactoring it using a pattern if I really thought it would be worth it.
- jedbrown 16y ago
  Depends whether it's in a library where extensibility is a feature.
- jemfinch 16y ago
  > 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. > Even if more operations had to be added I'd probably let it grow to the point where the method the switch is in was getting a bit unwieldy then look at refactoring it using a pattern if I really thought it would be worth it. Why not just do it right from the start? It's extremely simple, it's a pattern every OO programmer is familiar with, it's more computationally efficient and has other advantages as well. It's also not nearly as complicated as the linked Strategy code. The appropriate analogue to the author's switch statement (in Python, since I'm not a Java programmer): class Op(object): def eval(self, a, b): raise NotImplementedError class Add(Op): def eval(self, a, b): return a + b class Subtract(Op): def eval(self, a, b): return a - b class Multiply(Op): def eval(self, a, b): return a * b It's twelve non-blank lines, more than half of them boilerplate; translated into Java it would probably gain a few keywords and a couple lines of ending braces, but would not grow significantly. Compare this to almost that many lines for the switch version (note that the OP left out the declaration of the enum, the function boilerplate, etc.) for something less maintainable, less extensible, less idiomatic, and with lower performance.
  - arethuza 16y ago

jewbacca 16y ago

I don't think I've ever read a rant about code smells which couldn't be trivially fixed with basic functional programming principles.

stcredzero 16y ago
It also depends on the language. I bought a book about functional programming in Java once. I found it painful.
- tkahn6 16y ago
  You should seriously consider checking out Clojure. It's awesome.

Silhouette 16y ago

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 makefile several times longer than the whole effort should have been, and seemed to be claiming some sort of profound revelation from doing this! The quote is also a succint analysis of why C++ and Java are becoming less useful every year, relative to the field of programming languages as a whole. And of course, as in the example in the article, it's good for bashing people who think tools like design patterns must be used everywhere, regardless of whether they actually help to keep a design clean and maintainable.

ajdecon 16y ago
Out of curiosity, can you post a link to the "hello, world" article?
- Silhouette 16y ago
  Your wish is my command. :-) http://blog.objectmentor.com/articles/2010/05/20/hello-world-revisited http://blog.objectmentor.com/articles/2010/05/20/hello-world...
  - jimbokun 16y ago
    I kept looking for the give away that this was some kind of sick parody. But no, it seems totally sincere.
    - Silhouette 16y ago
      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. ;-)

gfunk911 16y ago

Part of the problem is that a language like Java: 1. Is verbose by its very nature 2. Has language characteristics that push the developer in the direction of using design patterns at every opportunity. So what might be a 1000 line program in Ruby is a 3000 line program in Java (translated as directly as possible), but then the deficiencies of the language turns simple idioms in a powerful language into complex design patterns in Java. See: closures, lack of duck typing/deficient type system, etc.

Destruct1 16y ago
I think the Java culture plays a big part in the whole mess. It would be easily possible in other languages to write 4 implementations of a basic list or public setter/getter for every member or buffered stream interfaces for all kinds of I/O. Its not done because long solutions are frowned upon.

billswift 16y ago

This is a large part of a post I made April of last year: KISS: Keep It Simple and Succinct Succinct means brief and concise, to the point. A succinct argument is one that more directly addresses the point under discussion. The "traditional" meaning of KISS completely misses the point. The biggest problem KISS addresses is over-complication of plans - and it is not a problem of stupidity. Those most prone to over-complicate are the more intelligent, especially the highly intelligent and highly educated, but lacking in practical experience. Experience, especially wide experience, is the best prophylaxis for over-elaborate plans. http://williambswift.blogspot.com/2009/04/kiss-keep-it-simple-and-succinct.html http://williambswift.blogspot.com/2009/04/kiss-keep-it-simpl...

efsavage 16y ago

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

stcredzero 16y ago
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!
- sapphirecat 16y ago
  > 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.
  - stcredzero 16y ago
    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.

telemachos 16y ago

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 why not prepare now? Decouple that code. Use more patterns. Hoist that jib. (All driven by the question, "What will your code/software/app do if...?") I read type 1, and it (often) sounds convincing. I read type 2, and it (often) sounds convincing. I get a fucking headache from the cognitive dissonance. I make more coffee and get back to work, no wiser than before.

edw519 16y ago
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 of both Type 1 and Type2. [EDIT 1: stcredzero, in reference to cousin comment, my personal metric is n=2. I never want the same line of code more than once. I'm sure there are good arguments for other values of n, but this has always seemed to work well for me.] [EDIT 2: I try to make a point to never say "Not Hacker News" or complain about content. Conversely I should be quick to claim "Not Not Hacker News". This is a great thread! About stuff near and dear to this programmer's heart. Keep 'em coming.]
- stcredzero 16y ago
  As I say in a cousin comment: an easy way to get the best of both worlds is to wait until you have an apparent problem. The 4th time you start writing that same switch statement, maybe you can tell you're going to be doing this a lot more and it's time to bring out Strategy. Doing it sooner is too likely to be premature. The advantage of this approach: you never have to prognosticate. Hindsight is 20/20, so use it! EDIT: I used to use n=2 as my threshold, but I found it much better to have a slightly higher n in Smalltalk. I am spoiled, though because I have such lightweight but powerful (syntax-aware) tools for searching such patterns.

clark 16y ago

I think frameworks have to be engineered carefully; the use of the strategy pattern in the example is a typical and is very soundly used in a framework. I think the problem is that developers write far too many frameworks than they should. Interestingly enough, it's code that isn't extensible that ends up being a framework -- mostly because the authors have time to focus on documentation, support, user interface and the like.

herrherr 16y ago

In this context "The Evolution of a Python programmer": http://gist.github.com/289467 http://gist.github.com/289467

Sandman 16y ago

I agree with the article... up to a point. Write your programs to be as simple as possible - but not simpler.