Posted on February 18th, 2008 by Chris.
Categories: Chris, Programming.
Do you work in software engineering? Have you ever heard a coworker say, “I’d do X, but then I’d have to rewrite everything?” Truth is, it’s easier to rewrite everything than make small changes sometimes.
How could I justify something so outlandish? Simple. The difficulty of a change (how many hiccups, how many bugs) depends not so much on its scope as it does on how well planned it is. Inevitably, we underestimate how much planning small changes take, and overestimate when we see big, scary changes. Does this mean rewrite is easy? Of course not. But it’s not impossible, or as costly as we think, and just the opposite is true for minor changes.
*The usual caveats: If you have a problem that can be solved with a small change, I recommend sticking to that before resorting to bigger changes. But once you start seeing so-called small changes multiply, you may have hit the stall point.
Posted on January 23rd, 2008 by Chris.
Categories: Chris, Product Design, Programming.
How do you decide when to throw out your code/idea and sleep on it/do a rewrite?
Most people intuitively know when they’ve gotten stuck. Suddenly, after plowing through mountains of work, returns suddenly diminish dramatically. People who program late at night will recognize this phenomena; coding turns from an art to a masturbatory exercise in frustration. (This also comes up when doing late night work as a student, interestingly.)
The reason people can overlook the stall point is that it’s not one point. If we got pitched headlong into a freezing room, we’d be far less likely to leave the thermostat alone.
Being acutely sensitive to even the smallest amounts of frustration is a good way to pick up on incoming stall points.
Be intolerant of annoyances.
Posted on January 8th, 2008 by Tim.
Categories: Programming, Tim.
I don’t think the Hardy Boys ever had to deal with a command prompt. Evan ran into some strange problems with his environment variables, and has posted an interesting write up, markruss style.
Posted on November 22nd, 2007 by Chris.
Categories: Chris, Games, Programming.
I wrote this a while ago, posted without revision. I think I would change it now, so you’re still a programmer, but you have a sword and stuff.
For fun, I’m creating a role playing game. But in this game, you won’t be a sword fighter. You’ll be a programmer.
Working for a company making a role playing game.
Basically you’ll get to play a number of classes: sales, marketing, product management, engineer. With each, you’ll be able to upgrade the same skills, but some of them will go up quicker than others. (Though it’s true that in Morrowind, this sort of excessive flexibility was criticized for not giving a player a good focus, I’ll make sure that your role is more dictated by your job than your skills).
The first criticism you might have–this is total garbage. Why would you play a game that doesn’t involve killing anyone? I think I can provide an appropriate response in the form of this. Everquest also has crafting, where you put together items to produce a greater whole. We’ll expand on this concept.
The difficulty will be how to make this a challenge like in real life. I think this is a matter of pitting people against each other or together with each other, so we can leverage human AI instead of coding our own, first of all. Then we have to make the RPG a useful creative experience. One thing that we might do is have competing organizations, and a customer base. Basically, you’ll have customers if you have good sales, but you’ll have to work together with good engineers, because engineers can produce useful gadgets. Oh, and you won’t be able to do it all; upgrading some skills will push the others down automatically.
Anyways, the prototype will be based on the following:
- Sales: You need to be able to sell things well, which may not involve being realistic. It also involves being a good communicator, and finding contacts.
- Product Management: You need to be able to manage timelines and put things together. This involves being organized, and being able to empathize with two groups. The more you empathize with engineering the faster and better things may get produced, but the more you empathize with the customer the more likely they’ll be to approve of the product.
- Engineering: Basically, the better you are the better you are. I think Gas will know more about this.
- Testing
OK, so my new game is gonna be about music.