
Criminal Overengineering - moconnor
http://coderoom.wordpress.com/2010/06/23/criminal-overengineering/
======
telemachos
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.

~~~
radu_floricica
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.

~~~
j_baker
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.

~~~
radu_floricica
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.

~~~
j_baker
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.

~~~
jacabado
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).

------
Silhouette
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
Out of curiosity, can you post a link to the "hello, world" article?

~~~
Silhouette
Your wish is my command. :-)

[http://blog.objectmentor.com/articles/2010/05/20/hello-
world...](http://blog.objectmentor.com/articles/2010/05/20/hello-world-
revisited)

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

~~~
Silhouette
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
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
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
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-
simpl...](http://williambswift.blogspot.com/2009/04/kiss-keep-it-simple-and-
succinct.html)

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

------
jewbacca
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
It also depends on the language. I bought a book about functional programming
in Java once. I found it painful.

~~~
tkahn6
You should seriously consider checking out Clojure. It's awesome.

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

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

~~~
stcredzero
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
> 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
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.

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

------
VBprogrammer
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>

~~~
ErrantX
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"_

~~~
stcredzero
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!

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

