Benefits of Laziness... and other stuff

Technical Programming
1

Ok, lets see what people think about this one…

Also… lets put this limitation on it as well…

Hacking in the sense of “putting it together quickly”.

Now please note I am not advocating sloppy coding practices and not commenting… as a person who programs mostly in assembler I know the value of comments! Writing without a purpose is pointless! Writing without comments is especially useless! As far as coding practices go, everyone should have some kind of coding style they adhere to and stick to it… otherwise you’re going to get confused when you look back on it… and obviously if the project calls for something else, then use that style…

Sure… you could probably phrase “laziness” better, but im lazy…

2

No. Actually read some of the posts in http://www.chiefdelphi.com/forums/showthread.php?t=23052, and realize that a good chunk of them are coming from people who have degrees in computer science/software engineering and/or who work every day as programmers in industry. Feel free to disagree w/ me all you want as I’m just a lowly freshman CS major, but to argue with people like Dave Flowerday is arrogant and egotistical. One thread has already been poluted by this pointless debate, do we really need another?

3

I will disagree…

Yes, perhaps its arrogant and egotistical to argue with people who have doing this for longer than perhaps I’ve been alive… however, discussion is a good thing. On the team I’m on, everyone is allowed to question anyone else for the benefit of learning. Obviously if they’re wrong (and persist in it) then the other person can be put to silence very quickly. Either way everyone learns. Besides, having everyone’s opinion concentrated in one area could help people struggling with the problem of being sloppy or whatever. Its better to have the pointlessness concentrated in one thread. Besides… thats why I made it a poll :slight_smile:

4

(now my posting is just going to make things confusing with names…)

If you want to program haphazardly for your own projects, thats your own choice. Personally I think it is a bad habit (One that I am trying to break myself (as I throw stones inside my glass house)), but to each his own.

That being said, personally I feel that following good design principles is easier when working in a group. That is most likely due to the fact the when on a team, you need do at least some basic design to get everyone headed in the same direction. And for me, once I am doing that on paper, it is only a minor step more to get the design completed.

However, when working alone I have a tendency to hash out the design in my head (with maybe a little paper). Because of this I tend to end up in a Build & Fix mode, a fault which I am trying to fix (See aforementioned bad habit).

5

I think there’s a difference between sloppiness or sloth and “creative laziness”. Sloppiness and sloth lead to all sorts of evil like undocumented code and the indiscriminant use of GOTO. Creative laziness is really applying the mind to make the task easier to accomplish and ultimately results in less effort expended. In general this is a good thing.

Here’s a historical example:

Around the turn of the last century, there was a young man who wanted to go to college and become educated. However due to family circumstances, at the last minute he could not go and wound up getting a job as a hod carrier. That is, he spent his day carrying bricks and mortar to brick layers who were building buildings etc. Being an intelligent guy, he pretty soon started making suggestions to his supervisor on how to make his job and the job of the bricklayers easier. The supervisor told him to shut up and STOP BEING LAZY. So he went back and kept thinking of other ways to do the job easier while carrying all that stuff around. He also kept pestering the supervisor.

Finally the supervisor called his bluff. He was told that he had one day to prove his ideas and if they didn’t work he would shut up or be fired. Then he was given the slowest bricklayer on the job for his test. After some instruction and I think a trip to the hardware store for some minor items, our hero was ready for the test. That day the slowest bricklayer on the job laid more bricks than the fastest guy by a significant margin, like 30%. The supervisor shut up and let our hero do things his way.

Eventually the young man stared his own company and trained his own bricklayers. It is reputed that he never lost a bid. He could afford to under bid everybody because his workforce could lay 30% more bricks in a day than his competitors. Later he sold the construction firm because he was he was more interested in making life easier for people than in putting up buildings.

So he went into the consulting business and became an “efficiency expert”. His name was Frank Gilbreth, and he was one of the founders of what we now call Industrial Engineering.

Mr Gilbreth did nothing to change the way the buildings were designed or constructed. His bricklayers laid straight, even courses just like the other bricklayers of the day. They did not get their increased productivity through sloppiness. In fact, because of his radical methods he was more closely scrutinized than he would have been otherwise. The only place he changed things was in how the bricks and mortar made their way from the delivery pile to their place in the building. He reduced that labor drastically and made it so that bricklayers could spent their time laying down mortar and brick and not picking up bricks and moving them into place.

Now that’s what I call laziness…a supreme effort to not do work that is unnecessary or counterproductive. But because it often requires time observing and thinking, not doing, this effort looks an awful lot like sloth to the uninformed.

I could give other examples, but this post is long enough.

6

I guess in one sense of the word you could say Im a lazy person:

  1. I dont like to debug my work
  2. I dont like to think harder than necessary
  3. I dont like things to be complex if they can be simple
  4. I dont like to do things over
  5. I dont like to have to figure out what I was thinking (esencatailly having to re-invent it)
  6. I dont like to throw away something and start over from scratch

these are all good reasons to use a diciplined structured approach to your work. When I was taking computer science classes in college, I had one project where I got the assignment, went to the computer lab, sat at a terminal and started writing code.

It was a nightmare - it took me so long to get that code right, to debug it, to even understand what I had written to be able to document it - I had learned my lesson

the next semister I got a big CS project, I went home, worked out the flow of the algorythm, worked out data structures that would make the algorythm clean, wrote out the code on paper (didnt have my own PC back then) - went to the computer lab, typed my code in, fixed a few typos

compiled it. It ran. Got the test vectors from the professors account, ran them through the program. hand checked the answers, they were correct. Turn the assignment in.

About two weeks later when the professor was handing back the graded assignments, she didnt give me mine. She glared at me and said “I want to SEE YOU in my office after class”.

Hmmmmmmmm?!

In her office she told me “I want to know who you bought your program from?”

Huh?!

“I want to know where you got the assignment you handed in!”

what do you mean? I wrote it myself!

She then pulled out a computer listing and said" this is the amount of time each student has spend on a terminal since I gave that assignment out. The class average was 40 hours, some have spent 80 hours and still arnt done yet, the second lowest was 9 hours

and you spent 4 hours on the terminal! There is NO WAY you could have written that code in 4 hours.

So I had to explain to her what I said above, how I did the program flowchart… wrote it out by hand…

I pulled out all my notes, the flow chart, the hand written code (always keep an excellent notebook - It has saved my behind many times :c)

she looked at all this and said:

Oh!.. well,…OK then

you got an A+ on the project

you can go now

(She seemed a little dissapointed that she would not be able to use her harpoon today).

The point is, doing it right, doing it in a clear well thought out manner IS the easy way.

This is why companies have all these guidelines and policies - they have spent millions of $$$ in the past, learning the hard way.

But now that this has all been explained to you, you dont have to learn the hard way too :^)

7

Okay, the last post in the other thread I was somewhat rushed, so I’ll repeat it here in detail. Anyway, programming isn’t just about laziness: that’s only 1/3 right. According to Randal Schwartz in the Camel (about perl, for those not familar with it), the three virtues of a programmer are Laziness, Impatience and Hubris, in that order. What! Say you? Well, let’s take a look at what is meant by these words, before a heated battle ensues … you’ll find that these tend to reinforce the whole idea of structured, encapsulated, reusable programming …

LAZINESS: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it. Hence, the first great virtue of a programmer.

IMPATIENCE: The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least that pretend to. Hence, the second great virtue of a programmer.

HUBRIS: Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won’t want to say bad things about. Hence, the third great virtue of a programmer.

8

Whatever gets it done works fine, most the time.

comments are the devil.

Oops, typo, i meant to say “you should always make your code readable and well commented to promote good programming practices”. Man, those keys are just too close together. :wink:

9

See… this is what I was originally talking about… I just was too lazy to look it up and write what I meant… lol. Oh well…

10

Looking at the other posts on this thread, I think we have come to some agreement. Namely that laziness, if carried out in a disciplined manner, is a good thing. If it is not carried out in such a manner, the result is frustration and gnashing of teeth.

I think it boils down to thinking about what you are going to do. Define the task, what goal are you trying to accomplish? Then figure out how you are going to accomplish it, and what resources you need to do so. The think some more and see if you can take anything out. When you can’t see how you can do any less, then and only then are you ready to start doing something. This IS engineering.

By the way I was a little inaccurate in my recollections of Mr Gilbreth’s work yesterday. He didn’t improve the productivity of bricklaying by 30%, it was more like 300%. Before he came along the fastest bricklayer could lay 120 bricks per hour. The record using his methods was 450. He had a very precise process and used special scaffolds to keep the bricklayer at the proper working height in relation to the building, there are at least 10 versions of that scaffold on the market today.

11

Laziness does not always mean unstructured and unreadable programs that are hard to modify. When I write programs I am lazy and do what requires the least amount of work overall.

Last semester in my Computer Science class we had five projects to do over the course of the semester. These involved keeping a database of movies and the showtimes of these movies. The first would just read in from a file, storing them in an array, and writing them back out when the program was told to. The next 3 programs involved a different way of storing the movies (linked lists, simulated linked lists, and binary trees), with a little more added functionality (e.g. add, delete, search, save back to file, etc.). The final project was to put a GUI on this program.

I took the lazy way of writing this by designing my program so that I could just swap out the storage code with any of them and it would function the same. It was a little more work for the first project, but for the following projects, I just rewrote the storage mechanism with the same public API, and added a couple of functions for the additional features in the assignment. By doing this, it only took me a couple of hours to write a new storage class, and a quick addition of some functions for the additional functionality while others in the class who did not structure the program and mix the storage code with the logic code had to nearly completely rewrite their program.

By writing a well structured program, I was able to maintain and debug the code with much less work, thereby taking the lazy way out.