What are the valuable lessons of history in programming and software engineering?

Question

As you've often heard, those who don't know their history are doomed to repeat it.

Not wanting to be doomed to repeat history,

• What are the valuable lessons of the history of our craft?
• How does the working programmer most efficiently go about learning them, and keeping their understanding current?
• In particular, how does the young programmer of the newest generation go about learning the lessons of time, not having the benefit of having had experienced them first hand?

If there was one lesson of history you wish you'd known when you started programming, what would it be?

Answer 1

• Testing only at the end => low quality
• Long projects with long iterations => wrong expectations, big miss on estimates, and again low quality
• Manual builds => deployment issues (another form of low quality)
• Add extra features or code that aren't needed => big costs and low profit (or loss)
• Failing to consider businesses continuously change

Current practices are meant to avoid those issues:

• Continuous Integration
• Short Iterations
• YAGNI, KISS, TDD ...
• Agile

Answer 2

KISS - Keep it simple stupid

Answer 3

It's worth learning about the things the previous generation wanted to do but couldn't because the processors of their day weren't up to it. There's a whole bunch of interesting algorithms that were worked out in some detail before the technology caught up with them. Some are still impractical, but more and more of them are within reach every day.

Also, learning about the failures of the past can be very instructive. There were literally hundreds of attempts to make "visiphones" before someone realized that the trick was to point the camera away from the person using the phone. People want to show the person they are talking to what they are seeing, but more often than not don't want to be seen themselves. Some of these early attempt even presaged webcams, but they almost always had the camera fixed in position and this met with great market resistance.

Answer 4

"Fail again. Fail better"

Samuel Beckett

Answer 5

The Therac 25 disaster is a classic example of poor quality control and poor understanding of concurrency.

Answer 6

Write your tests first as often as possible.

Answer 7

When I was a little kid, I got this old radioshack "color computer" from the 80s for $15 that came with a bunch of programming books on basic. Soon I was using trigonometry formulas even before I got to Algebra I in school. I moved on to QBasic in DOS and when I finally got a windows desktop computer with internet access, I was faced with a choice; Continue programming in the basic family using VB, or learn C/C++. I chose VB because I was familiar with it and C/C++ seamed complicated...

It is my belief that one should not be afraid to learn as many programming languages as possible, especially C/C++ when your ready for it. Even if you never plan on using a language much, learn how it's internals work. You will soon have a good understanding of how programming languages work underneath the higher-level syntax, and you can quickly become a better programmer.

Answer 8

"Premature optimization is the root of all evil."

--Donald Knuth

Answer 9

Don't be afraid to start over from scratch when it gets messy!

You would be surprised at how fast you can re-write your code in a clean and reorganized way once you have hacked it out the first time. I always force myself to spit out a bunch of code as quickly as possible the first time around, then completely start over from scratch, cannibalizing and drastically improving upon the previous version of the code.

Many times what once took weeks to write, can be re-accomplished in hours in a much more clean an organized way with less bugs.

Answer 10

There was an 'old' but great article on software development in IEEE Software Magazine, Volume 1, Issue 1: "Hints for computer system design"

One of the more interesting ideas was hinting, here is a brief summary:

Use Hints - Much like caching, hinting involves using a lookup table for expensive computations. However hinting involves using a lookup table that is not guaranteed to be correct, and so there must be a way to check correctness before performing the computation.

Another important one was about generality:

Don't Over Generalize - This means don't generalize an implementation to something that handles cases you don't need to account for. Adding additional power has no advantage unless you know how to implement it and you know it is necessary.

This over-generalization topic had one particularly inspiring example, where a combination of overly general operating system features, allowed passwords to be guessed one letter at a time. (like in the movies).

Answer 11

Always mount a scratch monkey.

Answer 12

If you don't make your programs efficient, they'll bite you in the butt.

Answer 13

I'm not advocating TDD but prior to sitting down to write something that will be fed to users, you should establish a strong scope of what you're actually hoping to accomplish then stick to it.

Don't meander off on "that would be cool's" .. write the goddamn thing, then add stuff. If you later meander into an idea for some great plug in architecture .. be ready to throw everything you've done down the drain and start over. If that happens, well, why didn't you design it to add stuff in the first place? Talk about learning from mistakes :)

But, don't throw stuff that works away too often on 'future' whims, make sure it really warrants a blender.

Answer 14

"Thank goodness we don't have only serious problems, but ridiculous ones as well." - Dijkstra

To me, it means enjoying the ride while I can.

Answer 15

Many valuable lessons were published in Alan Davis's classic book 201 Principles of Software Development (McGraw-Hill 1995). ACM is trying to freely release the book's text as part of its classic books series. Until that time, you can find them summarized in this blog entry.