Enjoyment
When I was studying Japanese, a good part of that work was pretty arbitrary: kanji are practically random, vocabulary is essentially arbitrary (although neither of those are quite true, it takes quite a bit of investment before they begin to bear fruit). Rote memorization wasn’t only the cornerstone of my efforts; it was the better part of them.
But I always enjoyed it. I grumbled, but I never got so annoyed with the project that I felt like it wasn’t worthwhile. With a world of things I could have studied, I never felt like the Japanese language really had to justify the investment. I took it in stride.
My attitude towards some of my work is very different. I read people’s code, and think, this is just pointless. They could have done a nice job here, actually captured these ideas in a clean way, but they couldn’t be bothered, and now it’s up to me to wade through their half-baked mumbling and make some change that I’ve almost forgotten the reason for.
Is it possible to enjoy the challenges of mediocre code in the way that one enjoys the study of a spoken language? They’re similar artifacts, in the sense of being shaped more by the need to actually work than by the need for clarity or consistency.
June 27th, 2007 at 7:28 pm
One reason you might react differently to them is that even though languages look arbitrary, you know there’s often a deeper pattern underneath. While studying them, your mind is in “hungry for patterns” mode, and it can have faith that it won’t be disappointed if it studies enough. Whereas with code, sometimes the more you study it, the less pattern you find, so the progression is toward disappointment rather than fulfillment.
Isn’t that cheery?
June 27th, 2007 at 7:43 pm
That could certainly be true.
June 28th, 2007 at 1:28 am
On reflection, I think I was too pessimistic. Your original analysis makes sense: that working with a program should reveal patterns, that what looks like a mess at first should make more sense the better you get to know it.
It would be nice if we had a mediocre language to compare with the languages we actually learn today. But presumably all the mediocre languages in human history are gone now (or are no longer mediocre).
July 1st, 2007 at 11:36 pm
I like it that I can clean up mediocre code in a way that I can’t clean up languages. Then again, I wouldn’t particularly want to clean up a language.
I wonder what a mediocre language would be like? Are there shifts in characteristics of languages over time? (E.g. from highly inflected to less inflected?) Also, not sure why we should assume that mediocre languages are gone now - I bet there’s a lot of long-lived mediocre code out there. But languages have been around a lot longer than code, to be sure, giving evolutionary pressures a lot longer to work.
Or not. Maybe junk DNA is the mediocre code of our body…
July 3rd, 2007 at 11:45 am
How do you justify the cost of cleaning up code to management? (Digression? Me?) This is a rat-hole question, but having followed David’s blog, I expect him to have something cogent and interesting to say about it.
Without wanting to accept responsibility for defending the concept of a mediocre language: I expect natural spoken languages to be extremely comfortable and expressive, because there is natural variation present, and because people with a command of the language choose the most comfortable form for each expression. And as the spoken language affects the written language…
July 5th, 2007 at 12:17 am
Prefatory comment: the main business benefit of clean code is that clean code is easier to work with in the future: easier to understand, easier to extend, easier to test, easier to find and fix bugs. These are all important benefits to my boss, and he accepts that clean code is important in achieving those benefits, so in my particular case, I don’t have to spend much time actively justifying the effort.
With that in mind:
If the cleanup is of a small scale, I don’t have to do any justification. My boss expects my team to deliver a steady stream of output. I expect that, as part of that output, my team will try to keep code clean, and periodically clean up small bits of dirty code. As long as we can do that while delivering a steady stream of features and bug fixes, my boss doesn’t spend time asking about details. (He does spend time asking to make sure that we’re keeping our test coverage up to date.)
If there’s a large area of code in need of cleanup, I do have to justify it to my boss: he’s in charge of priorities, and if the cleanup is big enough to appear on the schedule, then he has to know about it. We have one such effort currently, and I wish I’d been able to find more time for us to work on it. It initially arose in team retrospectives, where it was clear to all of us that we were scared to work on the code base in question; my boss could also see this showing up in bug court, where I had a hard time giving even vague estimates as to how long it would take to fix bugs in that area. When I raised this issue to my boss, he was very supportive of us budgeting refactoring time in that area, and continues to be supportive. I have to remind him in planning meetings that we want to set aside time, but he says yes when I remind him.
I used to do more big refactoring projects at work, just for fun. That has changed since I became a manager and started getting serious about scheduling tasks based on business priorities, rather than on individual areas of expertise. If I could justify a refactoring project based on business priorities, I would do so, and did on a few occasions. (Frequently occasions where one person had been in charge of an area of code, and that person was had left the team.) But otherwise, I wouldn’t: entertaining David wasn’t a good enough reason by itself, especially given that I managed to find many other ways to entertain myself.
(I still wish I’d gotten all the decode_line_1 cleanups into GDB. Such is life; I’ve been extremely impressed by the recent cleanups that I’ve seen going by.)
July 5th, 2007 at 11:16 am
Thanks very much for that — it’s illuminating.
Am I right in thinking that “a steady stream of features and bug fixes” is the anchoring concept in all of this?
July 5th, 2007 at 3:38 pm
Yes, that’s a great way to look at it. (Though I hope that the bug fixes part will diminish over time; I think it is, but we have a ways to go.
)
I claim that the benefit of clean code is that it will help us do future work more quickly and more predictably. My boss might worry that the cleanups will be a short-term waste of time with no long-term benefit. So I address his concern by showing him several bits of concrete non-cleanup progress every week; if I can do that, he’s willing to let us incorporate cleanups into our ongoing work.
The steady stream turns out both to be my evidence that our process (including cleanups) is working well and his hedge against our spending time on unproductive tasks.