I love good programming quotes. The best ones say something true about the craft of programming, usually both concisely and humorously. Recently I started following Programming Wisdom on Twitter. It’s been a source of many great quotes, but occasionally I have seen quotes that I think completely misunderstand the essence of programming. Here are three examples:
1. When To Start Coding
On the surface, this seems obvious. Of course you need to think about how your program should work, how it should be structured and so on, before you start coding. But that leads to the wrong conclusion. Programming is discovery as much as it is construction. As you code, you gain new insights, both on the problem and on how best to structure the solution.
Thinking that the key to a good program is to plan it out in advance, before coding, is exactly backwards. The program becomes good as you work with it. You obviously have to have some idea of what needs to be done before you start, but after that, you are better off coding than planning. Therefore, it would be better to say “the sooner you start to code, the sooner you have a good solution”.
2. Frozen Specification
This quote is related to the previous. The implicit assumption is that if we could only get a complete specification from the beginning, our jobs as programmers would be so much easier. This desire for frozen requirements leads to waterfall methodology, change control boards, and bickering about what is actually included in the requirements.
By instead acknowledging that requirements are seldom complete, that it is hard to know exactly what you want in advance, and that using software will affect how you think it should work, you get the agile approach. Paradoxically, by not insisting on complete requirements up front, the software produced becomes better, not worse.
3. Woodpecker Destroys Civilization
I have two problems with this old quote. Firstly, software is clearly hugely successful in transforming the world. Our modern world is unthinkable without software. Yes, software is not flawless. But neither is construction. Just as there are bugs and errors in software, so there are buildings and bridges collapsing.
Secondly, construction in the physical world is such a poor metaphor for programming. Software is not finished, it is continuously altered, adapted and expanded. Physics limit what is possible to build. In software on the other hand, the limits are much fewer (computational power, memory, bandwidth), which means a lot more is possible to do in software compared to what is possible to physically build. Furthermore, running software is a dynamic system with countless moving parts, whereas buildings are static structures.
Conclusion
Most of the quotes from Programming Wisdom are great. But it’s good to think about what each quote implies about software development. The three examples above rubbed me the wrong way. What are your thoughts? Agree or disagree? Are there other examples? Finally, we should also remember the wisdom of Voltaire: “A witty saying proves nothing”
Henrik Warne's blog 
I don’t think you’re interpreting the “frozen specification” quote accurately; I think the *point* is that requirements are almost never frozen, which is why the waterfall model fails (i.e. it’s easy to walk on water when it’s frozen, but everyone knows that in general, that’s not the case, which is why we consider walking on water impossible).
I think I also disagree about the woodpecker quote. It seems disingenuous to state that “Just as there are bugs and errors in software, so there are buildings and bridges collapsing.” Sure, bridges and buildings occasionally collapse, but it’s not terribly common. On the other hand, catastrophic software failures are pretty common (everyone is familiar with frozen computers, hard crashes such as BOD, etc), and bugs often have serious and widespread consequences (e.g. in the case of famous security vulnerabilities).
Thanks for commenting! Yes, your interpretation of the frozen specification quote is another possible interpretation. I still get a sense of “if they were just stable, everything would be fine”.
As for the failings of software systems – given the massive use of software in everyday life today, I still think SW is doing OK. But of course, any improvements in quality would be welcome 🙂
Pingback: プログラミングの名言をもう少し | 未分類 | POSTD
My approach with these quotes is not take them really seriously. They have some truth and make me smile. The last one that I read really made my day – https://twitter.com/CodeWisdom/status/723527415365046272/photo/1. I just had a similar experience these days.
Pingback: Danh ngôn lập trình – Giải thích và bình luận | Từ coder đến developer – Tôi đi code dạo
The first quote, and your response to it, are the opposing horns of a false dichotomy, and these days it is your position that is by far the most widely expounded. While programming is partly a process of discovery, you can do a certain amount of discovery by thinking through the problem and your anticipated solution, and sometimes more quickly than by coding up the first idea that crosses your mind. Doing the latter, you could go a long way down a dead-end. What you need is the good judgement to know when to switch from predominately analysis to predominately coding (and when to switch back for a while.)
Here is a case that illustrates the point:
http://ravimohan.blogspot.se/2007/04/learning-from-sudoku-solvers.html