I am the first to admit when I am wrong (well, at least one of the first.) I was a huge advocate of "slash and burn" coding (where you delete all the old code and rebuild from scratch.) There are still times when that may be appropriate, but I will be a lot more choosy with it in the future.
Currently, I am in the process of refactoring one of our game systems to be simpler and easier to use. I started off with the idea of "slash and burn", but with the lack of time I had to work on it and the lack of progress, I was forced to roll-back my changes and try a different approach. The approach I took is to go one step at a time. I started off by picking one thing and fixing that in the code. Once I had that working, I picked the next thing and got that working. Today, I managed to factor out two different classes that were not really needed and greatly simplify the architecture. Tomorrow is the last day I have to work on the system and, although I won't get everything done that I wanted, I will have at least made progress. And ultimately, progress is what matters.
Seems obvious, but it is easy to get caught up in the rush of doing something new. It is important to know when to rewrite and when to refactor.
Monday, July 28, 2008
Tuesday, July 22, 2008
Rewrite? Good luck...
I have a problem. When presented with code that I don't believe is very good or well designed my natural reaction is to want to rewrite it. This is not always the best approach. Especially when there are deadlines/feelings involved.
Take, for example, my current job. The engine we are using has been developed in-house over the last few years and it does have some cool technology features that other people don't have yet. However, there are some systems that are just horribly complex and convoluted. Some systems were designed by people who had never worked on a video game before and had little experience. Some try to be overly clever or flexible and end up wasting tons of memory and cycles. Worst of all, some system barely do what they are supposed to do and making them do what our designers would like is no easy task. (In short, it looks like almost every other game engine I have worked with.)
Clearly, this is a case where rewriting these systems makes sense. Or does it?
I'm finding that my job is no longer about writing code. It is about figuring out what is possible, both technically and, more importantly, politically. Technical problems can be solved given enough time and the right people. But what if you don't have enough time? What if you have the right people, but they are busy doing other things and you are left with the wrong people? What if there are no people? How do you balance designer demand and production capability? When is it "good enough"?
That is the issue I am facing. In our recent milestone I signed myself up to rework our weapon system (which almost everyone agrees is overly complicated and doesn't allow for change) and our input system (which doesn't support all the features we want, such as multiple configs and binding multiple inputs.) Out of the last three weeks I have had about four days of actual time to work on it. My time has been spent in meetings and preparing for meetings and dealing with scheduling. (I can't help but smack myself for making such a rookie mistake of overestimating how much time I would actually have to work on these problems.) Since our deadline is next week I have had to report that my part is slipping because I just haven't had the time to work on it. I set out to rip out the current inventory and weapon system and I have managed to do that, just no time to actually put a new system in place.
Time is running out.
My manager reminded me of this today. For about half an hour. In his office. With the door closed.
There was no yelling or cursing. He just explained how nervous he was about my trying to rewrite systems. That our longer term milestones are not going to move and we have to hit them. We may not like the code, but we have to ship, and there are a lot of features that are still not implemented.
I had to sit and think. I guess mostly because I knew, deep down, that he was right.
The moral of the story here is this: People don't like other people's code. It is ugly, badly done, and doesn't do what you think it should do the way you think it should do it. You could obviously make it better, but don't. Make it work. The people who pay the checks don't care. They want results and it's rather unlikely they will be happy if you spend a month rewriting a system that mostly worked in the first place. Besides, you have better things to do, like the other features that don't yet exist.
Take, for example, my current job. The engine we are using has been developed in-house over the last few years and it does have some cool technology features that other people don't have yet. However, there are some systems that are just horribly complex and convoluted. Some systems were designed by people who had never worked on a video game before and had little experience. Some try to be overly clever or flexible and end up wasting tons of memory and cycles. Worst of all, some system barely do what they are supposed to do and making them do what our designers would like is no easy task. (In short, it looks like almost every other game engine I have worked with.)
Clearly, this is a case where rewriting these systems makes sense. Or does it?
I'm finding that my job is no longer about writing code. It is about figuring out what is possible, both technically and, more importantly, politically. Technical problems can be solved given enough time and the right people. But what if you don't have enough time? What if you have the right people, but they are busy doing other things and you are left with the wrong people? What if there are no people? How do you balance designer demand and production capability? When is it "good enough"?
That is the issue I am facing. In our recent milestone I signed myself up to rework our weapon system (which almost everyone agrees is overly complicated and doesn't allow for change) and our input system (which doesn't support all the features we want, such as multiple configs and binding multiple inputs.) Out of the last three weeks I have had about four days of actual time to work on it. My time has been spent in meetings and preparing for meetings and dealing with scheduling. (I can't help but smack myself for making such a rookie mistake of overestimating how much time I would actually have to work on these problems.) Since our deadline is next week I have had to report that my part is slipping because I just haven't had the time to work on it. I set out to rip out the current inventory and weapon system and I have managed to do that, just no time to actually put a new system in place.
Time is running out.
My manager reminded me of this today. For about half an hour. In his office. With the door closed.
There was no yelling or cursing. He just explained how nervous he was about my trying to rewrite systems. That our longer term milestones are not going to move and we have to hit them. We may not like the code, but we have to ship, and there are a lot of features that are still not implemented.
I had to sit and think. I guess mostly because I knew, deep down, that he was right.
The moral of the story here is this: People don't like other people's code. It is ugly, badly done, and doesn't do what you think it should do the way you think it should do it. You could obviously make it better, but don't. Make it work. The people who pay the checks don't care. They want results and it's rather unlikely they will be happy if you spend a month rewriting a system that mostly worked in the first place. Besides, you have better things to do, like the other features that don't yet exist.
Subscribe to:
Posts (Atom)
