Y'all are a bunch of wankers!

Do stupid people always try to act smart?

Or are they just smart by making things so complex?

Based on the numbers I am going to have to go with stupid people doing complex things.

For example, J2EE is stupid.

J2EE developers doing stupid things for several years of J2EE work == very stupid creating complex things that no one will understand.
Permalink Bot Berlin 
March 10th, 2012 5:47pm
The thing that made me question their (J2EE devs) sanity is a zillion small classes, each with about 30 lines of real code in it.
Permalink Send private email xampl9 
March 10th, 2012 6:25pm
"The thing that made me question their (J2EE devs) sanity is a zillion small classes, each with about 30 lines of real code in it."

There is nothing wrong with classes if you want to separate out logic.  Classes should have a specific use-case as opposed to big ball of mud large classes.
Permalink Bot Berlin 
March 10th, 2012 6:27pm
If you have a large number of very small classes, what you get is a giant ball of mud, only split into classes.

There is a sweet spot between many small things and a few large things, and it's a non-trivial task to find it.
Permalink Quant 
March 10th, 2012 8:15pm
For example, J2EE is stupid.

J2EE developers doing stupid things for several years of J2EE work == very stupid creating complex things that no one will understand.

If doing something stupid pays more than something smart, I prefer to do so.  I was in J2EE stacks for few years because of nothing but SOA(aka $OA. Its concept seems good, but it's hell of complexity).
Permalink DanielChein 
March 11th, 2012 3:17am
I just love those script kiddies who wine "it's so complicated, nobody can understand, what moron built this!!!" when faced with anything more complex than their PHP app.
Permalink Quant 
March 11th, 2012 8:43am
I'm fairly sure Bot is referring to those people named as "Architecture Astronauts" from the father of this site :D

Check out daddy's article: http://www.joelonsoftware.com/articles/fog0000000018.html :P
Permalink Io 
March 11th, 2012 1:29pm
And a closely related article, by his (until recent) business partner: http://www.codinghorror.com/blog/2004/10/were-building-the-space-shuttle.html
Permalink Io 
March 11th, 2012 1:33pm
> "it's so complicated, nobody can understand, what moron built this!!!"

The script kiddies are right. Unmaintainable architectures are a sure sign a moron built something.

Most coders are morons.

Imagine if they designed an automobile. In order to change the oil, you'd have to disassemble the frame to get to the engine, remove the engine, disassemble the engine, replace oil in sealed contained deep within, then rebuild the engine and reconstruct the car around it.
Permalink Idiot 
March 11th, 2012 1:51pm
> I am going to have to go with stupid people doing complex things.

I believe that the majority (90%) of developers retain an incorrect intuition that more complexity indicates more robustness and better code. Everyone will pay lip service to phrases like "simple elegance" but in practice they are absolutely terrified of it when push comes to shove.

The "ten percenters" - the highly productive and effective top end of the bell curve - know otherwise and have the correct viewpoint. But they often - usually - aren't the ones leading or running projects. The likelihood is that members of the mediocre 90% will be the ones dictating coding standards.

Complexity like the hundreds of very small connected classes comes about due to graduality. The mediocre average coders start coding small parts of the system, and they believe and tell each other that they are creating simple elegance because of the very short classes. When actually they are creating a large tangle in the macro view. But there is nobody available with the perceptiveness to see the truth.

'Twas ever thus.
Permalink Bored Bystander 
March 11th, 2012 1:54pm

One of the space shuttles was destroyed when a small screw rolled into the space between the console and windshield. The space shuttle is bigger in space, when it came back into the atmosphere, the object was compressed between, making it impossible to remove. It was not safe to relaunch. They spent several million dollars trying to remove the screw and then mothballed that shuttle since removing it would require diassembling most of the shuttle and rebuilding it, costing billions.

There's a case of something not being built for maintainability.

Likewise the Tesla Roadster's interesting problem where if you let the battery run down, it costs $40,000 to fix.
Permalink Idiot 
March 11th, 2012 1:54pm
"The mediocre average coders start coding small parts of the system, and they believe and tell each other that they are creating simple elegance because of the very short classes."

Those guys read the book "The Pragmatic Programmer", which is a poorly written cult book. Also "Agile" and "X-Treme" programmers do that. They advocate not using comments at all. Instead you should make your method names really large, to be the comment. No method should be more than 10 lines of code, that's a "code smell" that means you are "not professional".
Permalink Idiot 
March 11th, 2012 2:11pm
Examples of retarded crap programmers:


> Elwyn Malethan's musings on software development
> Comments have no place in code


> Code can and should be readable on its own. If code needs comments, that's a sure sign the code needs to be rewritten or restructured to make its intention and workings clearer.
Permalink Idiot 
March 11th, 2012 2:13pm
That dude Elwyn Malethan is a n00b with an attitude, lol.

What a tard.
Permalink Dr. Horrorwitz 
March 11th, 2012 2:34pm
Although he has a point.

Ten years ago I wrote this:

The Three Fucks

A good thing to know for aspiring programmers are a few coding style rules. I call them "the three fucks", and they are:

- What the fuck
- Why the fuck
- How the fuck

Almost no bad programmer practices the three fucks, and all good programmers practice them. (For those bad at logic: This does not imply that practicing those three rules by themselves make a good programmer!)

#1: What

It should be perfectly clear, two decades after code has been written, well after the original coder has been hit by a truck, for a non-domain expert to understand what the code is doing. With all comments stripped from the source.
The only thing to achieve this is meaningful method- and variable names. "I have heard this all before" you say and "I do give my identifiers meaningful names". No you don't. I dare you, prove to me that you do. Prove it to yourself at least. Most likely, you can't. Long names are not the same as descriptive names. Especially not for someone who has to maintain your code.

Every time you give a function a name, you have to think of something that explains exactly, in detail, what that function will be doing. That is a talent most often associated with folks that write headlines for newspaper articles. This talent is so rare that most good journalists don't even possess it. It's left to the pro's. What makes you think you can do it? I am sure you can't if you haven't done several years of hard effort and especially refactoring.

When maintaining legacy code, I often come across names like: "PrepareDatesForBubbleDiagram". I am sure the Original Programmer thought he'd done a good job in providing a descriptive function name, but in fact this name isn't worth the bytes it occupies. It says nothing about what the function does. That the function "prepares" dates can be learned at a glance, but WHAT does it do to those dates? Complicated stuff, that's for sure.

In Delphi and other languages, "DateTimes" are floating point numbers, with the part behind the decimal point being a fraction of a day. You can imagine that juggling around with fractions, doing all kinds of arithmetical operation on those numbers easily results in something that can't be easily understood merely by looking at the code. 791023.47104 simply does not look like August 12, 2005, 13:45, and adding some of those numbers and then rounding the result to two decimals is NOT going to tell the casual observer what's going on.

"PrepareDatesForBubbleDiagram" could, with the same clarity have been called: "DoSomethingSecretWithTheDatesForBubbleDiagram". Most code is full of those "descriptive" names.. Of course the right way to name such a function would be "NormalizeDatesToExcludeWeekends" or "ModifyDatesToFiveMinuteResolution". But that takes a bit more thinking and we are not prepared to do it, hyped-up on caffeine as we are or preferring to browse for funny video's on the net. To provide more clarity as to what the function does, also name variables that are not used as simple counters properly. Meaning that from their name should be exactly clear what they do. If that means a variable name takes 20 characters, so be it. Camel-capping is your friend.

#2: Why

"Why" is almost as important as "what"

If I don't know why something is done, I might just as well rip it out completely, see what happens and rewrite the whole thing, making it ten times faster in half as many lines. That's what I usually do when something doesn't work and I have no clue why because the OP abandoned the project.

Let's take "NormalizeDatesToExcludeWeekends" as an example. DateTimes are removed when they fall in a weekend, that I can deduce from the source and the name. But WHY?
Is it because an associated component can't handle them, or because the customer does not want to see weekends, or because the data on weekends is unreliable, or because weekends are not working days and 30% of space can be saved?

When people are working on your old code, it's often because it is buggy, or it's too slow, or features need to be added to it. It would help if it were clear what the code is is supposed to do in the first place. This is why comments have been invented. Some say "It's easy to abuse/overuse comments" but that's just as abusing/overusing money. There is no such thing as "too much money", only money ill-spent and ill-invested. The same goes for comments. There is not such thing as "too many" comments, only unclear, superfluous or misplaced comments. Comments are much less used for the "what" part as for the "why" part. "what" is taken care of by the code itself, the identifier names. "why" is of secondary importance and due to the verbosity involved, comments are better suitable for conveying "why". "Why" should cover the following:

A) Why the code does what it does
B) Why it is coded the way it is coded (including improvement suggestions)

B is most often ignored, even in the rare event of observing A.
With B, it becomes much easier to make refactoring decisions and discover bugs that pertain to algorithm and architecture.

#3 How

The deepest level of detail is the "how" of the code.
To be able to modify/bugfix code instead of replacing it completely, we need to know how it achieves a purpose, or, more accurately, how the author intended the code to work.
"How" is also covered by comments, and we again need to know two aspects:

A) How the algorithm is supposed to work (a description)
B) How the algorithm is implemented with sufficient detail for a non-domain expert to maintain its code.

An example of how the three fucks are covered in a piece of code:

* Sorts on urgency using CombSort, about as fast as QuickSort but faster in case
* of an (almost) sorted list. Algorithm so simple that it can be easily memorized.
* CombSort is a classic BubbleSort, modified to use a variable comparison gap.
procedure SortRepliesOnMoveUrgency(var replies: TReplyArray);
  sorted:      Boolean;
  i, gap:      Integer;
  arrayLength:  Integer;
  reply_t:      TReply;
  reply_i:      ^TReply;
  reply_g:      ^TReply;

  arrayLength := Length(replies);
  gap        := arrayLength;
  sorted      := (arrayLength < 2);     

  while not sorted do                    // sort until no gap and no swap
    gap    := (gap shr 2) + (gap shr 1);  // fast division by 1.33
    sorted := (gap < 2); 

    case gap of
          0: gap :=  1;
      9..10: gap := 11;                  // 11 faster than 9 or 10

    reply_i := replies;
    reply_g := replies; Inc(reply_g, gap);

    for i := arrayLength - gap downto 0 do
      if reply_i.urgency < reply_g.urgency then
        sorted  := FALSE;

        reply_t  := reply_g^;
        reply_g^ := reply_i^;
        reply_i^ := reply_t;


This code is also an example of "coding hygiene". Assignments and declarations are logically grouped and column-aligned and logical groups of statements are separated by newlines.
Type declarations come in order of "complexity", pointers below their simple type.

Enforcing a 80-column width is counter-productive with today's hi-res screens. We don't live in the 80-column punch card era any more.

Using braces in expressions, even though operator precedence does not require it, makes clear what is intended, very important when bugs have to be fixed later on.
You can put statements on the same line to show they are related but remember that the debugger won't be able to step through the source line by line in that case.

The goal must always be writing the clearest code possible, not to save keystrokes. Most of your time should be spent designing a solution - on paper - anyway. Clean code saves time debugging but - most importantly - it saves a massive amount of time refactoring when it has become "legacy".
Permalink Dr. Horrorwitz 
March 11th, 2012 2:37pm
"Using braces in expressions..."

Just an FYI:

braces = {} = curly brackets
parentheses = ()
square brackets = []
angle brackets = <>
Permalink Q 
March 11th, 2012 10:55pm
Doc, your code has reasonable chosen method names and sparse but present comments.

These other dudes are advocating no comments at all.

I've seen their code, there's a lot of it around.

Uncommented code used to be called "bullshit unprofessional crap code". Now it is "best practice". That shows you how unhinged from reality this industry has become.
Permalink Idiot 
March 12th, 2012 12:01am
> braces = {} = curly brackets
> parentheses = ()
> square brackets = []
> angle brackets = <>

Dutch language at least has a proper name for curly brackets: 'accolades'.

French language has even more proper names for brackets:

{} : accolades
[] : crochets
<> : chevrons
() : parenthèses
Permalink Attila 
March 12th, 2012 8:16am
>>Do stupid people always try to act smart?

Generally speaking, yes.  Smart people rarely act smart.  The more you know, the more you question what you know.
Permalink Kenny 
March 12th, 2012 10:51am
Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.

-Alan Perlis
Permalink JoC 
March 12th, 2012 6:27pm
Yeah like me with my database.

I found a way to have no tables at all and still be able to have sorted lists, sorted on any field.

A truly genius idea (not gonna tell you how it works).
Permalink Dr. Horrorwitz 
March 12th, 2012 6:35pm

This topic is archived. No further replies will be accepted.

Other topics: March, 2012 Other topics: March, 2012 Recent topics Recent topics