Over Spring break I’ve been reading the older archives of own of my favorite blogs: Coding Horror. Though a lot of the posts are worth reading for anyone involved in computer programming, one that I feel is especially worth mentioning is Development is Inherently Wicked. The article talks about how it is almost impossible to fully plan out a complete software project and then have that plan hold throughout the process of creating the software. Though I’ve personally never been involved in a large scale software project, I’ve come to realize how true this is even with small projects.
For the past week I’ve been busily writing a Python package to allow interaction with a Hemisson robot. My initial planning was very simple: I would have only a very simple function-based interface. The actual hardware interaction would be separate from the part the user used and there would be a simple configuration file which the user could edit. Was this enough planning with which to start writing code? I was afraid it might not be, but in the end it turned out to be a good thing. I managed to write the hardware interface in just a few hours and in just about 80 lines of code. It would have taken far less time, but there was some ambiguity in the Hemisson documentation that made me fiddle around directly with the robot to get things right.
It was when I started to build the configuration system that I had to deal with the other side of the coin. It was very tempting to jump in and quickly come up with some sort of config file syntax and then write up a parsing routine for it. It would have worked and it probably would not have been much work. But I decided to fight the temptation to hack away and instead read up on Python tools for doing this sort of thing. After reading about online and posting to the Python-tutor mail list I came upon a simple, more elegant solution: the config file would be a Python file itself and I would make use of Python’s intrinsic ability to import modules stored in external files to access it and read. A little bit of planning thus eliminated the need for a rather large amount of complexity and code to handle that complexity. I’ve just finished another round of coding: a part of the actual module that the user will be using. I’ve managed to create simple functions for moving the robot and for accessing its sensors. However since the robot does not include any hardware to keep track of its position, writing more complex functions such as turning through a particular angle will be significantly more challenging. Once again, I need some planning and research.
The lesson I’ve learned is that doing a good job of making software involves a fairly fine balance between making careful plans and just sitting down and pumping out some code. So how can you know which one is more important? The answer is two-fold. Firstly, its a mistake to think that planning and coding are separate actions. They are part of continuous loop and a healthy software project must treat them as such. There has to be a decent level of feedback from the code to the plans and the plans have to make sure that bad code isn’t written just because it is easy and the first thing that comes to mind. Even while I was writing my hardware control routines I had to think about how I would deal with different hardware configurations and how to let the program parse and adapt to the configuration information. Like a lot of computer science, this is a good example of choosing the middle path: realizing that either extreme can lead to a badly implemented or even incomplete project and that staying close to the middle is the best way to go.
If you’re interested in learning more about this approach to programming projects, read though the entire article and Coding Horror and the book that it references.