I was just reading an article on The Reinvigorated Programmer about Where Dijkstra went wrong: the value of BASIC as a first programming language.
I thought this was particularly interesting:
It’s a horrible way to program, and I am delighted that I don’t have to do it any more. But it’s a fantastic exercise. It develops mental muscles that you’re going to need all through your career and which you’re not likely to develop while doing any of the more productive activities you spend time on.
That article led me to poke around a bit here: Dijkstra on Wikiquote.
“How do we convince people that in programming simplicity and clarity —in short: what mathematicians call “elegance”— are not a dispensable luxury, but a crucial matter that decides between success and failure?”
— Edsger Dijkstra“Simplicity is prerequisite for reliability.”
— Edsger Dijkstra“The competent programmer is fully aware of the limited size of his own skull. He therefore approaches his task with full humility, and avoids clever tricks like the plague.”
— Edsger Dijkstra
When I’m working in a shared public space (i.e. cube farm) I like to have a spot on my cube labeled “The Wall” where I hang a half-sheet of paper with the odd quote or bit of news. These quotes would have been perfect for that. I don’t necessarily agree with everything the man said, but some of these are real gems.
It brought to mind a recent discussion about when and how to “bake out” repeated tasks in a program. I’m not trying to start a religious war here, so I’ll just cut to the chase.
It is almost always a good idea to move repeated processes into methods or functions, but everyone has a different tipping point on the simplify/complexificate axis. I’m sure we’ve all been in the meeting where everyone is agreeing, heads are nodding, and everyone is saying “yes, let’s simplify this some more.” At some point, someone will flip to “no, no, no, we’re breaking this out into too many pieces” and the argument will start.
This usually happens when the discussion has been framed using emotional terms — “simplify,” for example. I recognize it is my nature to simplify code well past the point of diminishing returns, so I try to keep the specific goal in mind. Am I trying to:
- hit a deadline?
- save time?
- avoid repetition?
- reduce documentation requirements?
- reduce test exposure?
- centralize functionality?
- provide a tool for future use?
- demonstrate my l335 h4XX0r sk1zs?
All the above are important, and I’m sure there are other objectives we could consider — but simplicity is a value judgment. It should be a guiding principle, not dogma.
Simplicity, elegance, and reliability are great goals and are absolutely important but, like any other tool, they can be misapplied. It’s easy to make something simple, elegant, and reliable that is also too complex to easily understand, too hard to use, and took way too long to complete. To me, one of the things that marks someone’s transition from “coder” to “programmer” to “developer” etc. is when and how they “simplify.”
By way of example (and just to make sure there’s some actual code in this post) where do you fall on the axis between typing $x=~s/^\s+//; a zillion times and constructing a flexible, robust, documented, tested, CPAN-ized object model for managing arbitrary collections of pre- and post-string cruft removal?
More as it happens.
—
Bob Simpson
Thanks for the link-love! The three-word title of your blog entry made me think of the cover of Kernighan and Pike’s _The Practice of Programming_: it has a cartoon flipchart on the cover with three words written on it: Simplicity, Clarity, Generality.
Oh yes, I remember that book! I’m sure there’s a copy around here somewhere. It wouldn’t surprise me at all to discover I have a whole “Kernighan” section. (Collect the whole set!)
“Clarity” is a great word. I use it when my head’s in code-space, meeting-space, or I’m indulging in some other form off geeksqueal to remind myself the things I know may be things someone else doesn’t know they don’t know, and I really need to stop and make sure everyone’s on the same page.
There’s a more complete discussion of that thought by Steve Schwartz in his post, No One Knows What the F*** They’re Doing (or “The 3 Types of Knowledge”). It called to mind news articles discussing the research about completence floating around a while back that seemed to boil down to: competent people question their competence, less competent people don’t.
It’s interesting how being forced to explain something helps bring a whole constellation of things you thought you knew into sharper focus. I like to think I helped create better documentation (and better software) by making the developers expain what they thought their code was trying to accomplish rather than just what it did. I always found it gratifying when the engineers felt they had a better understanding of their project after “the docs guy” forced them to explain it.
I try to keep that in mind when someone trys to make me explain my code, too. 🙂