“Write simple code” is a thing almost everyone believes, but nobody really investigates why code becomes complex in the first place. It isn’t just magpie syndrome or schedule pressure; some problems can only be solved with complex code. Some common circumstances (like logging or good error handling) make code more complex too.
Features change over time. At work, our initial product was caller name ID—transforms a phone number into the “owner’ of the number. The only complication [1] is that our product was (and still is) on the call path—that is, we’re called when a phone call is begin made. But conceptually, it’s easy—get the phone number, look up the name [2], and return it. Advance a few years and a new feature is added—phone number reputation, yet another lookup [2].
So then the requirements change, and depending upon the originating number [3] and terminating number [4], we have to:
fire off both lookup requests at the same time;
Only do the reputation lookup;
First do the reputation, then the name lookup.
The reason—cost. Everything on the phone network costs. And in our case, we’re also under a time constraint as we’re in the call path. Fun times.
[1] Well, actually there were several, like transferring names longer than 15 characters, or transferring a picture.
Some common circumstances (like logging or good error handling) make code more complex too.
I always wish that some how when you write a function you can ‘layer’ them in such a way that the logic is separated from the logging and error handling and testing.
I don’t think the page is about the complexity of the programs. To me it’s about complicated code (the way it’s written), which is an unambiguously bad thing, even if sometimes justified.
My favorite example is fast inverse square root. It’s disgustingly complex: no one can guess how that code works or even what it does just by looking at it. However, a simple solution wouldn’t be appropriate in the times of slow floating point division.
It’s also a perfect example of how complicated code doesn’t age well. Today a sufficiently smart compiler runtime would correctly map that to a hardware instruction if one is available, but original code will not benefit from improvements in either hardware of libraries.
The hard part is knowing when a simple solution will work and no complex one is needed.
It’s also a perfect example of how complicated code doesn’t age well. Today a sufficiently smart compiler runtime would correctly map that to a hardware instruction if one is available, but original code will not benefit from improvements in either hardware of libraries.
I’d say that aged pretty well, actually! According to the article the algorithm first appeared almost fifteen years before the first corresponding hardware instructions appeared in cpus. Add in time for those CPUs to enter wide adoption and the time for compilers to get “sufficiently smart” enough to handle this and you’re looking at the code aging well for at least two decades.
I checked around a bit and it looks like this is still a common technique for mobile devices, too.
Oh, that one is still applicable in some circumstances indeed. I’ve seen code that would have been rendered unjustifiable complex by hardware and/or compiler progress within years, and worse, code that was complex for the same of “optimization” that already could be done better by the compiler its authors used.
Other cases include not knowing classic approaches and language features. One language written like it’s another is a very common case of code complex in bad ways.
And there are times when simple means that someone else ate the majority of the complexity for you, until it leaks out. And there are other times where something is complicated for non-obvious reasons.
It’s hilarious that an article about ‘writing simple code’ doesn’t work at all if javascript is disabled. The article is text, you don’t need javascript. Do simple things.
This isn’t an article by the website maker – it’s a wiki page with many authors.
This website, wiki.c2.com, was created in 1995 and was the first wiki ever made. The site used to be written in Perl and did not require JS, but in 2015 it was rewritten as a single-page application so it could integrate with the author’s JS-powered Federated Wiki project.
“Write simple code” is a thing almost everyone believes, but nobody really investigates why code becomes complex in the first place. It isn’t just magpie syndrome or schedule pressure; some problems can only be solved with complex code. Some common circumstances (like logging or good error handling) make code more complex too.
Features change over time. At work, our initial product was caller name ID—transforms a phone number into the “owner’ of the number. The only complication [1] is that our product was (and still is) on the call path—that is, we’re called when a phone call is begin made. But conceptually, it’s easy—get the phone number, look up the name [2], and return it. Advance a few years and a new feature is added—phone number reputation, yet another lookup [2].
So then the requirements change, and depending upon the originating number [3] and terminating number [4], we have to:
The reason—cost. Everything on the phone network costs. And in our case, we’re also under a time constraint as we’re in the call path. Fun times.
[1] Well, actually there were several, like transferring names longer than 15 characters, or transferring a picture.
[2] Via DNS. No, really, that’s how it’s done.
[3] The one making the call.
[4] The one receiving the call.
I always wish that some how when you write a function you can ‘layer’ them in such a way that the logic is separated from the logging and error handling and testing.
I don’t think the page is about the complexity of the programs. To me it’s about complicated code (the way it’s written), which is an unambiguously bad thing, even if sometimes justified.
My favorite example is fast inverse square root. It’s disgustingly complex: no one can guess how that code works or even what it does just by looking at it. However, a simple solution wouldn’t be appropriate in the times of slow floating point division.
It’s also a perfect example of how complicated code doesn’t age well. Today a sufficiently smart compiler runtime would correctly map that to a hardware instruction if one is available, but original code will not benefit from improvements in either hardware of libraries.
The hard part is knowing when a simple solution will work and no complex one is needed.
I’d say that aged pretty well, actually! According to the article the algorithm first appeared almost fifteen years before the first corresponding hardware instructions appeared in cpus. Add in time for those CPUs to enter wide adoption and the time for compilers to get “sufficiently smart” enough to handle this and you’re looking at the code aging well for at least two decades.
I checked around a bit and it looks like this is still a common technique for mobile devices, too.
Oh, that one is still applicable in some circumstances indeed. I’ve seen code that would have been rendered unjustifiable complex by hardware and/or compiler progress within years, and worse, code that was complex for the same of “optimization” that already could be done better by the compiler its authors used.
Other cases include not knowing classic approaches and language features. One language written like it’s another is a very common case of code complex in bad ways.
And there are times when simple means that someone else ate the majority of the complexity for you, until it leaks out. And there are other times where something is complicated for non-obvious reasons.
It’s hilarious that an article about ‘writing simple code’ doesn’t work at all if javascript is disabled. The article is text, you don’t need javascript. Do simple things.
This isn’t an article by the website maker – it’s a wiki page with many authors.
This website, wiki.c2.com, was created in 1995 and was the first wiki ever made. The site used to be written in Perl and did not require JS, but in 2015 it was rewritten as a single-page application so it could integrate with the author’s JS-powered Federated Wiki project.
It doesn’t bode well that the first wiki ever made can’t even display text anymore without requiring the execution of a bunch of arbitrary javascript.
Related: Simple Made Easy. A talk by the creator of Clojure on the difference between easy and simple.