I can remember sitting in one of my university lectures a long time ago being taught about development philosophies. It was all pretty standard stuff, we were walked through the “traditional” methods of development (basically the once through, waterfall technique) and then brought up to speed on the more modern iterative approaches. However one little soundbite always stuck out in my head and that was when the lecturer asked us who pays for rework when a product doesn’t fit a customer’s expectations? The simple answer was you, the one who developed it and it’s something that always plays over in my head when I’m working on a project, especially those ones I do at home.
I’ve been paying extensively for rework with my latest forays into the world of game development. My regular readers and Twitter followers would’ve noticed that I cheerfully announced my success in cracking the stable orbit problem. Indeed in a round about way I had, basically my Unity scripts would push the planet around until it hit a stable orbit and afterwards would calculate the required velocity before turning off completely, letting the heavenly body orbit in a near perfect circle around its star. This worked for the 2 planets I had in there but unfortunately the equations I had developed didn’t generalize very well and adding in planets at random locations with random weights led to all sorts of wobbly orbits with planets meeting both fiery deaths and cold extinctions at the cruel hand of my orbit stabilizer. I was back to square one and I spent most of the weekend trying to figure out a fix.
Eventually I came back around to the idea that my smart-ass subconscious came up with a while ago. I had tried to implement it before but I gave up in frustration when the results I got were no different than from my far more complicated “find the angle between the sun and body, increment it a bit, find the new position, create a vector to it then apply force in that direction” when in reality the fault lied in the orbit stabilization code. All that pushing and pulling that made the orbit look stable was in fact imparting all sorts of wild forces on the poor little planet, when in fact the best way is just to simply let gravity do the work for you. With this in mind I re-implemented my perpendicular force calculations and then devised a rudimentary equation that combined the mass, radius and a fudge factor that let me hand stabilize the orbit. In the past attempting to do this stuff manually took me an hour or so per planet, with this revised code I was able to do one in minutes and have developed a new equation that is able to accurately send a planet into a stable orbit no matter where I place it in the game.
This solution was far more simple and elegant than what I had been trying to do previously but the cost in terms of rework was tremendously high. I’m lucky in this respect in that the client for this is just myself and my friend at the moment but had this been for someone else with whom I had a contractual relationship with that kind of rework would’ve been extremely costly. Of course I could try to make the client pay for it but ask anyone who’s gone back to a client asking for more money after saying they could do it for a certain price and you’ll usually be laughed out of the office, if not walked out of there by security.
Working around this isn’t easy as clients will usually want to have a strict set of deliverables and time frames which seems to rule out any iterative or agile development methodology. It also pushes a team dangerously towards suffering from analysis paralysis as you agonize over every requirement to make sure it’s covered off in the final product. A healthy amount of analysis is good for any project, especially if it makes the product easy to maintain or modify, but it’s also incredibly easy to fall into a never ending spiral of pointlessness. Thankfully however I’ve noticed that clients are far more receptive to the idea of milestones these days which lines up well with any iterative process, skirting around these problems easily.
Going after the most simple and elegant solution might seem like the best idea at the time but in my experience it’s those kinds of solutions that take the longest to achieve. It’s almost always worth it, especially if all you’re spending is your own time, but when you’re working for someone else they might not be so keen for you to spend inordinate amounts of time chasing your white whale solution. This probably explains why a lot of software contains incomprehensible code riddled with bugs, but that’s a whole ‘nother ball game and a blog post for another day.
