Slashdot Mirror


Dr. Dobb's Calls BS On Obsession With Simple Code

theodp writes "Over at Dr. Dobb's, Editor-in-Chief Andrew Binstock has a nice rant on The Misplaced Obsession with Simplicity. 'Any idiot can write complex code,' goes the old maxim, 'the true art is writing simple code.' Right, Andrew? Wrong (mostly). Binstock explains, 'It's not true that any idiot can write complex code. Complex code is difficult, often very difficult, to write. It's entirely true that it's more difficult to maintain, too. But that's the nature of complexity. Some things are intensely difficult to express in code and they require complexity, simply because they're not inherently simple.' After citing the complex-but-necessarily-so code of Al Aho and sometimes-misguided reverence for cyclomatic complexity limits to help make his point, Binstock concludes, 'My view of simplicity is unemotional and free of idolatry because I define it with respect to complexity, rather than the other way around: Simplicity is the quality of code that is no more complex than required to express the underlying complexity. In this way, simple code can be intensely complex. There is no inherent good/bad dichotomy.'"

17 of 381 comments (clear)

  1. To quote Einstein by BenSchuarmer · · Score: 5, Insightful

    Everything should be made as simple as possible, but not simpler.

    1. Re:To quote Einstein by girlintraining · · Score: 5, Funny

      That quote is attributed to Einstein, but you should know by now a great many quotes are attributed to him, but very few can be proven to have been from him. -_-

      "There's no such thing as a correct quote citation on the internet." -- Abraham Lincoln

      --
      #fuckbeta #iamslashdot #dicemustdie
    2. Re:To quote Einstein by Spy+Handler · · Score: 5, Informative

      It's paraphrase of Einstein who said something like that at various times in his life, but not those exact words.

      Here's an exact quote from Einstein:

      "It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience." - From "On the Method of Theoretical Physics", Oxford, June 10, 1933.

    3. Re:To quote Einstein by lgw · · Score: 4, Insightful

      Arguing against stupid "complexity metrics" is fair. A programmers job is to game the system. Give him a metric other than making the customer happy, and it will not end well.

      But I've seen far too much code that was simply far more complex than it needed to be. Stop tripling the size of your code for use-cases that no one has asked for, people!

      If you can make assumptions that significantly simplify your code, and those assumptions fit within the actual, stated requirements of the work (ignoring requirements that exist only in your head), for goodness sake make those assumptions.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    4. Re:To quote Einstein by internerdj · · Score: 4, Insightful

      Not all customers are smart enough to know to ask for everything. Even a smart customer may not be able to give you a real answer for what happens in X cornercase. Presumably you (or someone like you) are being paid to hash out all the hidden requirements and assumptions to achieve the customer-stated requirements.

    5. Re:To quote Einstein by Zalbik · · Score: 4, Insightful

      Presumably you (or someone like you) are being paid to hash out all the hidden requirements and assumptions to achieve the customer-stated requirements.

      Yes, but this should be done prior to code writing.

      Far too often I've seen extremely complicated code designed to handle "what-if" scenarios that never happen.

      i.e.
      Developer: "I wrote that configuration module in case they ever need to change the parameters of X"

      Me: "Did you ask if X would ever need to be reconfigured?"

      Developer: "Of course! And the client said that sure, if I could make it configurable, go ahead and do so"

      Me: "And did you ask how likely it would be that X would need reconfiguration? Or under what circumstances X would need to be reconfigured? Or what types of 'reconfigurations' they think they would need? We're looking at 2 man-months of code, plus testing, plus implementation time here....was any kind of cost-benefit analysis done to see whether it was worth it to write this?"

      Developer: [blank stare]

    6. Re:To quote Einstein by Honclfibr · · Score: 5, Funny

      Clearly, not taking his own advice here...

    7. Re:To quote Einstein by lgw · · Score: 4, Interesting

      Those things aren't part of the formal requirements in your world?

      --
      Socialism: a lie told by totalitarians and believed by fools.
    8. Re:To quote Einstein by gstoddart · · Score: 4, Interesting

      Those things aren't part of the formal requirements in your world?

      I've never seen formal requirements which detail every edge case I need to account for.

      There's an assumption we'll be writing robust code, and as it gets created we build in as much error checking and handling as we can think of, and over time you usually end up adding more.

      If coders had to be told in writing every error condition to check for, there wouldn't be any -- because the client wouldn't know (especially true when you have to create a library to do some of the work), and the developers would just say "not in the spec".

      Come to think of it, I've never seen formal requirements for much more than the really high-level systems stuff. From my perspective, a system which has been fully designed and spec'd out before anybody writes code is a myth.

      --
      Lost at C:>. Found at C.
    9. Re:To quote Einstein by ZahrGnosis · · Score: 5, Insightful

      I think you're confusing feature-creep with a comment that was meant to be about edge-scenarios. Allowing someone to configure parameters that were never spec'ed to be configured is feature-creep (gold plating, extra coding, call it what you will), and I agree should be avoided and adds unnecessary (or not obviously necessary) "complexity".

      Handling an edge criteria that was implied but not explicit in a specification is what is typically meant of "corner case", and is not the same thing you described. Recognizing that the customer asked for something logically impossible (they want two data sets to reconcile, but they are at unexpectedly incompatible cardinalities), or something that, upon investigation while building an app, wasn't precise enough (they asked for this to be their standard green, but their standard list only includes red and blue).

      It's nearly impossible to specify all of those prior to coding, which is why the typical "waterfall" development techniques have fallen out of vogue. You're always going to learn things while coding, and this is one of the main contributors towards apparently unnecessary complexity. If I design version 1 of a program perfectly, and customers have new requirements for version 2, it's unlikely that the "simplest" implementation of version 1 will be the one that is most conducive to an upgrade. You end up with a choice between refactoring completely or sacrificing some efficiency and simplicity to graft the new features onto an otherwise good version 1.

      I think Dr. Dobbs is nitpicking, though. There are definitely many ways to address, measure, or understand simplicity, and I agree that it should not be THE goal in and of itself. But the idea of making code easy to read, easy to understand both in the micro and macro sense, and just generally "simpler", has many merits.

  2. Meh by Anrego · · Score: 5, Insightful

    Interesting article, but this seems an issue of a very pedantic interpretation of a common idiom.

    When I (or I suspect most) whine about pointlessly complex code, it's just that. Code that is more complex than is reasonable for the problem. No one expects a simple solution for a challanging problem. It's an overly complex solution to a simple problem which we complain about...

    1. Re:Meh by T.E.D. · · Score: 4, Insightful

      Do you re-use your functions, or do they only exist to break apart a single operation into smaller blocks? If it's the latter, then he may have a good point

      I disagree, strongly. Breaking a large routine into smaller ones abstracts away what those smaller routines are doing. It puts a boundry around their interaction with the rest of the code, and puts their code away somewhere that I don't have to worry about, unless there's some reason I want/need to know the details of how that routine accomplishes what it does.

      If you put it all flat into one big routine, I have to read and grok everything in that routine, if only to reassure myself that none of it has interactions with the one area I care about.

      We actually have terms for this stuff: Cohesion and Coupling. Cohesion in particular is an important concept here.

      I find it amusing that the author's big example is Aho's parsers. Parsers are one of those special cases, as lexical analysis is a problem that is generally best solved by state-machines. I've tried for years, and really there aren't a lot of good ways to code lexer state machines that aren't either way slower than the typcial implementations, or a web of control flow that looks like a huge mess to those of us reared on structured programming. It isn't talked about much, but lexers (and some parsers) unashamedly make use of goto statements as their core braching mechanisim. Using Aho's awk parsing code as an example of why "clean" code isn't always desirable is like using the US Marines as an example of why killing people is often a good option for solving disputes. Perhaps its true in a technical sense, but its really crappy advice to be giving the general public.

  3. Agree, but not completely by parallel_prankster · · Score: 5, Insightful

    I have often noticed that complexity is added to code when it grows over time. Typically, a project starts off very well. We have requirements and we use the best possible design with limited future expansion capabilities and come up with simple code that works well. However, over time, things change and we come across situations that the original code cannot handle. But instead of writing from scratch, we hack it and that is how complexity and subsequently bugs get added. In my experience, the base infrastructure code for any system always looks simplistic and beautiful. The ugly part is often how it has been used over the years.

  4. "rant" is a nice way of putting it by girlintraining · · Score: 5, Insightful

    "Simplicity is the ultimate sophistication."
    -- Leonardo da Vinci

    "Plurality should not be assumed without necessity."
    -- William of Ockham, often referred to as Ockham's Razor -- the simplest explanation is usually the right one.

    "Everything should be made as simple as possible, but not simpler."
    -- Attributed to Einstein

    "If you can't explain it to a six year old, you don't understand it yourself."
    -- Albert Einstein (attributed)

    "Truth is ever to be found in the simplicity, and not in the multiplicity and confusion of things." -- Issac Newton

    "Beauty of style and harmony and grace and good rhythm depend on simplicity."
    -- Plato

    "The greatest ideas are the simplest."
    -- William Golding, Lord of the Flies

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage to move in the opposite direction."
    -- E.F. Schumacher

    "Those guys are all wrong."
    -- Andrew Binstock, Editor in Chief, Dr. Dobbs

    Choose well, reader...

    --
    #fuckbeta #iamslashdot #dicemustdie
  5. He just redifined everything. Its a strawman. by Karmashock · · Score: 4, Interesting

    When you redefine your opposition's argument and then knock it down with your own argument it is called a strawman. That's what he just did there.

    No one is saying in regards to simplicity that all programs should be two line bits of nothing.

    What people are instead saying is that code should be efficient, tight, and achieve the end goal as simply and directly as possible.

    What we are and have always been talking about is efficiency. It goes back to the first computers that had very limited memory. They required VERY efficient code because they simply didn't have the storage or memory to run anything that took up more space. As a result, code for those machines tended to be very very efficient. It was a requirement.

    When we complain about complexity, we are not complaining that the task of the program is too complex. Rather, we're complaining that the program is badly coded. We are complaining that it is inefficient and disorganized.

    So nice try. Try again.

    --
    I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
  6. he'd still be wrong, see machine code by raymorris · · Score: 4, Insightful

    Compare .NET code to the compiled machine code.
    Which is easier to understand and work on? The .net runtime is nothing but a set of functions in a separate file. using simple functions means main()can be an outline of the program, for example .

    By any measure, Linus Torvalds is an incredibly successful programmer. His guideline is 6-8 lines per function or so.

    Consider these two example programs:
    Stand
    Turn left
    Walk four steps
    Turn right
    Walk two steps
    Turn right ... 1000 more lines

    Vs:
    heatlunch()
    readslashdot()

    Even if the function heatlunch() is used nowhere else, using it makes the program far more understandable than inlining the walking code to get to the microwave.

    1. Re:he'd still be wrong, see machine code by DahGhostfacedFiddlah · · Score: 5, Insightful

      On the other hand, even if code isn't used in more than one place, that doesn't mean it's not "expressing something concisely".

      Additionally:
      1) Methods are great ways of naming orthogonal snippets of code, rather than using a comment that may become obsolete.
      2) Breaking large methods into smaller ones increases maintainability by enforcing certain constraints such as not reusing variables declared 100 lines up just because they happen to serve similar purposes.

      I agree that you don't want to just arbitrarily break your method up for the sake of smaller methods, but I don't think reuse is necessarily the best way to judge whether methods should be refactored.