Mental Procrastination
Musings of a corrupted mind.[ The Sprog Blog | Doi Bong | Digital Eye | MegaHAL | Mental Procrastination ]
Monday, August 21, 2006
Well, it's been a while since I've posted here. A lot has happened in the interim, some of which you'll get the gist of by reading my other blogs, which you'll find in the header above.
Why resurrect this blog now, you ask? The answer is simple. I've been thinking about hobby projects, thinking about the software development process, thinking about games programming, reading other software blogs, and thought that it's about time that I contributed my two cents. This probably makes you think that perhaps I might have something to contribute. I doubt it. Rather, I need a better way of thinking out loud than talking to myself while I'm taking a shower.
One thing I need to get straight from the beginning is this: I'm not a terribly gifted programmer. At work, I find myself surrounded by programmers that are better than me at the actual act of writing computer programs, pretty much regardless of which metric you care to choose. They can pump out code quicker than me, they are more insightful during debugging sessions, and their knowledge of the inner workings of compilers and computers is superior to mine. The thing that sets me apart from them is, I suppose, my love of writing programs that do interesting things, my love of different ways of writing software, and the way in which I actually go about it.
To me, programming is a craft, and good craftsmen pay attention to detail, and derive pleasure from building something that is beautiful, as well as being useful. Everyday crafstmen may pay more attention to building something in short order, or building something that goes faster. True crafstmen don't care about that. They labour over their work in order to create something that, in their heart of hearts, they are not ashamed of. True crafstmen don't quickly hack up a bit of code to get things working so they can move on to their next task. No, they polish the code until it shines, even if the difference is only apparent to themselves, and invisible to any external observer. I aspire to be a true craftsman.
I've been thinking about buzzwords used in reference to the software development process, and I've decided that all you really need to think about, day in, day out, are two things, and two things only.
Occam's Razor encourages one to write code that is simple. That is, of two possible implementations of a program, the one that is subjectively simpler is the one that should be pursued. This nicely embodies the points made in the Agile Manifesto, and recalls the oft-mentioned KISS methodology. Occam's Razor, which may be paraphrased as "the simplest code that works is probably the best code", also leaves it up to us to decide what exactly is meant by simple and best. Simple, for example, may be interpreted that the code should respect an established coding standard, and that we should minimise abstraction, while best may initially mean that the unit tests should pass, but, over time, may transform into meaning that the program should meet some minimal set of performance criteria. This nicely encompasses the good advice of "optimise last".
Dynamic Quality is an altogether different kettle of fish, and nicely balances the principle of Occam's Razor. It specifies that we should write code that is beautiful, in that undefinable, aesthetic sense of the word. The idea comes from Pirsig's "Metaphysics of Quality", where it is defined as that recognition of goodness that precedes intellectual thought. If we can recognise good music, good writing and physical beauty without thinking about what rules we're following in order to decide that we perceive goodness, then why not ask ourselves to write code that invokes similar feelings? Dynamic Quality, once studied, may be extracted into Static Quality, and thereby form part of the set of patterns that we apply habitually and consciously. Before this moment occurs, we can still recognise Quality, and we should still demand it of ourselves.
When a developer needs to fix a trivial bug in a short amount of time, and the code that they are working with is messy and convoluted, with layers of unnecessary abstraction and coupling, and so on, they have a choice. They can get their work done quickly, and move on to something new and more interesting, or they can role up their sleeves and do a job to be proud of, not only fixing the bug, but increasing the Quality of the system as a whole. The satisfaction that one experiences when working this way is a just reward, and makes typically boring monkey work much more interesting. Producing Quality work nicely balances the desire to ride Occam's Razor, as making things simple may negatively impact their Quality. Bearing both these in mind will, I believe, bear fruit.
This is, essentially, a Philosophy of software development.
Why resurrect this blog now, you ask? The answer is simple. I've been thinking about hobby projects, thinking about the software development process, thinking about games programming, reading other software blogs, and thought that it's about time that I contributed my two cents. This probably makes you think that perhaps I might have something to contribute. I doubt it. Rather, I need a better way of thinking out loud than talking to myself while I'm taking a shower.
One thing I need to get straight from the beginning is this: I'm not a terribly gifted programmer. At work, I find myself surrounded by programmers that are better than me at the actual act of writing computer programs, pretty much regardless of which metric you care to choose. They can pump out code quicker than me, they are more insightful during debugging sessions, and their knowledge of the inner workings of compilers and computers is superior to mine. The thing that sets me apart from them is, I suppose, my love of writing programs that do interesting things, my love of different ways of writing software, and the way in which I actually go about it.
To me, programming is a craft, and good craftsmen pay attention to detail, and derive pleasure from building something that is beautiful, as well as being useful. Everyday crafstmen may pay more attention to building something in short order, or building something that goes faster. True crafstmen don't care about that. They labour over their work in order to create something that, in their heart of hearts, they are not ashamed of. True crafstmen don't quickly hack up a bit of code to get things working so they can move on to their next task. No, they polish the code until it shines, even if the difference is only apparent to themselves, and invisible to any external observer. I aspire to be a true craftsman.
I've been thinking about buzzwords used in reference to the software development process, and I've decided that all you really need to think about, day in, day out, are two things, and two things only.
- Occam's Razor.
- Dynamic Quality.
Occam's Razor encourages one to write code that is simple. That is, of two possible implementations of a program, the one that is subjectively simpler is the one that should be pursued. This nicely embodies the points made in the Agile Manifesto, and recalls the oft-mentioned KISS methodology. Occam's Razor, which may be paraphrased as "the simplest code that works is probably the best code", also leaves it up to us to decide what exactly is meant by simple and best. Simple, for example, may be interpreted that the code should respect an established coding standard, and that we should minimise abstraction, while best may initially mean that the unit tests should pass, but, over time, may transform into meaning that the program should meet some minimal set of performance criteria. This nicely encompasses the good advice of "optimise last".
Dynamic Quality is an altogether different kettle of fish, and nicely balances the principle of Occam's Razor. It specifies that we should write code that is beautiful, in that undefinable, aesthetic sense of the word. The idea comes from Pirsig's "Metaphysics of Quality", where it is defined as that recognition of goodness that precedes intellectual thought. If we can recognise good music, good writing and physical beauty without thinking about what rules we're following in order to decide that we perceive goodness, then why not ask ourselves to write code that invokes similar feelings? Dynamic Quality, once studied, may be extracted into Static Quality, and thereby form part of the set of patterns that we apply habitually and consciously. Before this moment occurs, we can still recognise Quality, and we should still demand it of ourselves.
When a developer needs to fix a trivial bug in a short amount of time, and the code that they are working with is messy and convoluted, with layers of unnecessary abstraction and coupling, and so on, they have a choice. They can get their work done quickly, and move on to something new and more interesting, or they can role up their sleeves and do a job to be proud of, not only fixing the bug, but increasing the Quality of the system as a whole. The satisfaction that one experiences when working this way is a just reward, and makes typically boring monkey work much more interesting. Producing Quality work nicely balances the desire to ride Occam's Razor, as making things simple may negatively impact their Quality. Bearing both these in mind will, I believe, bear fruit.
This is, essentially, a Philosophy of software development.
Archives
September 2003 August 2006 February 2007 August 2011
