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

"The sooner you start to code, the longer the program will take." – Roy Carlson ⏱⌛️

— Programming Wisdom (@CodeWisdom) April 5, 2016

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

"Walking on water and developing software from a specification are easy if both are frozen." – Edward V Berard ❄️⛄️

— Programming Wisdom (@CodeWisdom) April 9, 2016

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

"If carpenters made buildings the way programmers make programs, the first woodpecker to come along would destroy all of civilization." -WSL

— Programming Wisdom (@CodeWisdom) April 2, 2016

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”