"Lazy" software

February 7, 2013 9:32 AM

When programmers say that good software is "lazy," what exactly do they mean?
posted by thecolor12 to Technology (16 answers total)

Are you sure that you're not mistaking the saying that good programmers are lazy? That usually means that they never want to do a task ever again, so they build their program to do it right and handle it in any conceivable scenario.
posted by thewumpusisdead at 9:38 AM on February 7, 2013 [2 favorites]

I'm a programmer. I don't know that I've heard programmers say this, actually - but what I have heard us say, and have said myself, is that programmers by our nature are lazy. By which we mean that we hate doing unnecessary work, and we'd rather build a tool that accomplishes a task than actually do that task ourselves. Instead of "go check the contents of this file and send it to Bob if it has any errors," we write a script that runs automatically and checks the content of the file for error messages and, if it finds any, sends an email automatically to Bob. Left to our own devices, many of us will script and automate the living daylights out of everything around us, just to save a few clicks here and an annoying daily task there.

There are other contexts where "lazy' might come up in programming - "Lazy loading" basically means "don't set up data until you actually need it" - but that's relatively jargony and it isn't using "lazy" in the normal English sense, it's more like "at the last minute."
posted by Tomorrowful at 9:39 AM on February 7, 2013 [4 favorites]

I've often heard that good programmers are lazy. (i.e. instead of doing lots of stupid/hard/repetitive work they will make the computer do it)

Lazy has a specific meaning in some software contexts, basically meaning 'don't do work until you need to' (i.e. if you were writing software to display student grades, you wouldn't load the list of all students, and you would wait until the last second to load the student record and only the records you could display on the current screen).
posted by wrok at 9:39 AM on February 7, 2013 [1 favorite]

Best answer: I haven't heard anyone specifically say anything about lazy software, but I suspect it's related to a quote from Bill Gates: "I will always chose a lazy person to do a difficult job, because, he will find an easy way to do it."

A lazy piece of code is one that's reusable because I don't want to have to write the same thing with a different name next week. It's readable because if I can find it again in 10 months, I won't have to think about what it does. It's clean because I'm going to find the simplest way to get the work done instead of the most impressive way. It's concise because I don't want to fill it with bells and whistles, I just want it to be DONE.
posted by specialagentwebb at 9:42 AM on February 7, 2013 [12 favorites]

"Laziness is a virtue" -- this is for programmers, not software per se.

1) Don't exceed the spec -- you can't really predict what will be needed in the future
2) Do the upfront work to make the majority of your work easier, less time consuming and less mistake-prone

More on #2: Upfront work is establishing design patterns, building libraries, writing down easily forgotten points and procedures to enable to build out the bulk of the application without writing a lot of repetitive code which is time consuming and mistake prone and which necessitates touching multiple places when change becomes necessary. Put your code in source control so that your changes are tracked automatically. Perhaps integrate it into an automated build system so you don't have to constantly do a lot of fiddly work to deploy testable builds of your software. Basically, set everything up to eliminate as much of the mistake-prone drudgery as possible to free yourself to focus on the important stuff and increase the likelihood that you get to go home at 5 every day and decrease the likelihood of panicked calls in the night and an eternity of questions from the people that have to maintain the code when you're gone.
posted by rocketpup at 9:42 AM on February 7, 2013 [1 favorite]

This probably isn't what you're asking about but there is a principle in computer science called "lazy evaluation" where compilers or interpreters attempt to put off doing calculations at run-time as long as possible in the hopes of avoiding doing them at all.
posted by GuyZero at 9:51 AM on February 7, 2013

I'm a programmer, I've never heard the phrase. My only guess would be what specialagentwebb said -- good code is often simple code that can be reused or easily adapted to suit many situations.
posted by PuppetMcSockerson at 10:00 AM on February 7, 2013

In algorithms, the term 'lazy' has a very specific definition, but I don't think that anyone would say that a program that executes a lazy search is better than a program that executes some other kind of search.
posted by muddgirl at 10:15 AM on February 7, 2013

I have been a programmer for a long time, and have heard this often about programmers, not software. This is the quote I always think of, which used to be pretty well known:

"The three chief virtues of a programmer are: Laziness, Impatience and Hubris."
- Larry Wall
posted by dhalgren at 10:16 AM on February 7, 2013 [2 favorites]

Another facet of laziness in programming: don't re-invent the wheel! If you need to (for instance) parse XML files, you could spend weeks rolling your own regular expression based parser, which is likely to work in only ideal conditions, and fall down horridly when encountering goofy things like invalid markup or an unexpected tag or maybe single quotes instead of double quotes or whatever. Instead, you could use an existing library and get on with implementing the actual business logic. Alternatively, if there isn't a library already, write the library (as in, implement re-usable, well-designed code) while you're solving the problem, so you'll only have to solve it once and can reuse/refine that library code later.
posted by Alterscape at 11:26 AM on February 7, 2013

Laziness is also virtue when it means you spend an hour writing a script to do something repetitive that would take 10 minutes by hand.
posted by unix at 1:06 PM on February 7, 2013

I have heard some developers I work with refer to 'powerful' (i.e. hundreds or thousands of features, usually accessible with Byzantine key combinations) versus 'consumer' or 'dumbed down' software (dozens of features, 90% unused by most people, mostly accessible through windows, icons and menus). They're the kind of people who can't understand why everybody doesn't write everything in MultiMarkdown in vim or emacs. But I think the other posters have it.
posted by Happy Dave at 1:41 PM on February 7, 2013

Why Good Programmers Are Lazy and Dumb has been widely linked in the past.
posted by xiw at 2:15 PM on February 7, 2013

Lazy is good because:

- What specialagentwebb said
- What alterscape said
- What xiw said (though I'd rephrase it as "apparently dumb" - asking "stupid questions" in the right way)

Programmers should always find existing solutions rather than inventing their own; Work with the software, and not against it; The hard bit is actually understanding the libraries and code that you're importing - and why it might or might not suck as a solution.

For example - I had to write a stopgap solution to Twitter deprecating support for RSS feeds yesterday - I wrote probably 50 lines of easily modifiable and adaptable code based on libraries written by people a hell of a lot more motivated and smarter than me. Most of the day was actually spent researching and evaluating other people's libraries, solutions, and understanding the pitfalls underneath.

(Twitter's going bang in a big way on March 5th by the way! And oAuth is a great idea)
posted by BigCalm at 3:17 PM on February 7, 2013

My thoughts match mudgirl's and GuyZero - this may be gaining currency because of the rise (again) of functional languages such as Clojure. Is this in a parallel programming context?
posted by BillW at 5:56 PM on February 7, 2013

Maybe this is a reference to static vs late binding. The former is more rigorous, the latter more convenient.

This connects to the "lazy evaluation" concept cited by Guy Zero, above. You see, in programming, you often don't have all of the requirements sitting in front of you. You have a few bits about what the thing is supposed to do. Other bits may be bolted on later. So: given what you do know, let's write a function/object/entity/whatever that can deliver the goods we agreed on in our staff meeting last week.

There was a time, in the days when COBOL and FORTRAN ruled the earth, when specifications were delivered, whole and entire, to your desk, with a might thump! But in the more agile reality we live in now, we contract with our future selves: look, dude, this is what they asked for! And, hey, if you just fiddle with this sub-class a bit, you are gold!

All constants are variables. You dig?
posted by SPrintF at 8:52 PM on February 7, 2013