Violating My Own Coding Principles
Jul. 11th, 2003 04:01 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jducoeurAh, the joys of huge, interdependent programs.
I've spent the past week writing my side of an enormous and critical new feature for our product -- arguably the most important single feature, which happens to be going in very late largely because it took the business side a long time to decide exactly what they wanted. (And because we had to get all the stuff it depends on in first.) Problem is, the guy writing the user interface is the most overloaded, so the UI came in last. Which means I've spent the past week writing vast amounts of code that I had no way to test, as have a couple of other guys working on this.
So now I start a true hurry-up-and-wait, which will probably take all weekend. My code is at the center of it all (I'm in charge of both the scripting engine and the scripts that run on it), so I'm the frontline debugger. I get to try the feature out; figure out where it broke; figure out who's responsible for that part of the code; wait for them to fix it (unless it's me, in which case I just deal); and start over again. Over and over and over again, trying to get through something like 2500 lines of entirely untested new code, until at least the major bugs are gone.
Sigh. This is why I prefer to unit-test everything as I go, so I can at least be confident that my own code is right. Unfortunately, the schedule is now so constrained that I don't have the time to write a proper test suite for this feature until after the next release...
I've spent the past week writing my side of an enormous and critical new feature for our product -- arguably the most important single feature, which happens to be going in very late largely because it took the business side a long time to decide exactly what they wanted. (And because we had to get all the stuff it depends on in first.) Problem is, the guy writing the user interface is the most overloaded, so the UI came in last. Which means I've spent the past week writing vast amounts of code that I had no way to test, as have a couple of other guys working on this.
So now I start a true hurry-up-and-wait, which will probably take all weekend. My code is at the center of it all (I'm in charge of both the scripting engine and the scripts that run on it), so I'm the frontline debugger. I get to try the feature out; figure out where it broke; figure out who's responsible for that part of the code; wait for them to fix it (unless it's me, in which case I just deal); and start over again. Over and over and over again, trying to get through something like 2500 lines of entirely untested new code, until at least the major bugs are gone.
Sigh. This is why I prefer to unit-test everything as I go, so I can at least be confident that my own code is right. Unfortunately, the schedule is now so constrained that I don't have the time to write a proper test suite for this feature until after the next release...