Dustin Freeman

Your code doesn’t need to be THAT good

I’m currently crunching to finish a software project. It’s my first time collaborating with a large number of non-co-located people with a shared repository. It’s been interesting and frustrating to manage tasks and larger-scale goals across such a group. One of the problems is that different members have different aesthetic values on what “good” software is. Here’s my definition:

Completed on time, and does what we want it to.

There’s been a few check-ins that have been very aesthetically oriented, focused on refactoring for neatness, or on renaming project files to remove confusing references to sample code we’ve borrowed from. This is for a project that needs to be ready for a certain large-scale art event in Toronto in a few days.

In the past, most of the code I have written is for a some crazy prototype that I need for a demo or a video or a study before a nearby deadline. I’ll either throw this code away, cackling, or spend a long time cleaning it up it for further work after the deadline passes. This cycle: (very pragmatic crunch coding, optimizations/improvements only later) has strongly affected my aesthetic.

Case in point:
I had to write a function that rotated an array representing an image by 90-degree increments. This is just an O(n) loop where I’m just transferring pixel values from one position in the array to another; I have to solve a mapping problem. The 180-degree rotation is the easiest, since you just to reverse the order in the array. The 90 degree and 270 degree rotations are a little harder. I got the 90 degree rotation working, then paused. My TODO list is full of requests from people I’m collaborating with. I would take me at least 5 minutes to test and debug the 270 degree rotation code. So, to rotate by 270 degrees, the function recursively calls itself to rotate by 90 and then 180 degrees. I felt plagued by guilt for a couple seconds over the blasphemy, but the function worked perfectly and the performance hit is negligible since the images are small. Now that’s good software according to me.

dustinfreeman

3 responses to “Your code doesn’t need to be THAT good”

  1. It also depends on the target users/tasks. I think if you have a deadline, you need something “working”, doing this is fine. However if you need for further stuff, or if your code may be used by womebody else, for something else, it has to be cleaner, and you should consider spending 5 more minutes (after the deadline) for a proper 270 degrees version.
    The question is: will the software be used after the event? If not why spending more time on this since you’ll have something working for that moment.

    But beware of the argument “the performance hit is negligible”. The problem is not if one hack has an impact, but if 10 or 20 hacks in the software have an impact together (added or merged). If so, at some point the performance hit will not be negligible, and at this point you will wonder what to improve.

    I think the most important thing is to be aware that you have a hack “there”, and if needed you could/have to fix it. The problem is that many developers (thinking they are good developers) write this kind of hack, and think it is the way to do things. Maybe with a JAVA philosophy it doesn’t matter. But with “real” programming it is a potential issue.

    Good luck with the project. I hope there will be videos on the web. Fanny told me about it, it looks cool. :)

    Cheers

  2. I like this, it’s a very important point to make. It reminds me of something that was discussed a lot in undergrad, under the name of “extreme programming”: start by building the test suite, and then hack hack hack until something passes the suite. Then refactor later. However in a lot of cases there will be little to no time or motivation to refactor later, and then after a few months the software becomes entirely useless: uncommented, unmodular, incomprehensible even to the author (a lot of this stems from the problem of lack of training or support for refactoring). So if you ever want to use the code again, it’s not just completed on time and does what it’s supposed to do. I think disasters relating to that are the reason why a lot of groups have half-assed standards for “good structure” or documentation in place: it slows you down, and it might be inconsistent, but if that’s your one pass through the code then its better than nothing. But this entry makes a great point that there are no absolute values for code, and oftentimes in research and business speed and functionality are the only meaningful virtues.