Hey, I made a pun!

 

A while back I noticed the coolant level was dropping on the '97 Chrysler Sebring that my oldest daughter has "claimed" as her car.  I added some coolant and checked the level a couple of days later, whereupon it was low again.  Hmmm.  Don't see any coolant on the ground, and the exhaust smoke isn't any whiter (is that a word?) than usual.  Where is the coolant going?

 

This continued for a couple of weeks, and I noticed the coolant level was dropping faster and faster.  Finally last Friday the leak got bad enough that I was able to see the coolant dripping from underneath the car--dripping down the right (passenger) side of the oil pan.

 

Hmmm.  The thermostat and coolant inlet/outlet are on the left side of the engine.  The water pump is on the right side of the engine.  I wonder what could be leaking...

 

So, for the last couple of evenings I've been disassembling the right side of the engine in order to get to the water pump.  It's been a reasonably fun adventure, since I only rarely work on cars these days.  But removing the power steering pump got me thinking about the mindset of the engineers who designed the car.

 

See, I first tried to remove the power steering pump bracket, but that wasn't going great because some of the bolts are difficult to get to, and there's a bolt I couldn't see because it's under the pump itself.  So, I decided to just take the pump out of the bracket first, then remove the bracket.  Started out ok, there's three bolts on the pulley side of the pump that are accessible through a slot in the pulley.  But wait--there's also a bolt on the back side of the pump, it's easily seen but it turns out that it's really hard to loosen because 1) it's hard to get a box-end wrench in there (sockets are out of the question) and 2) even if you could get the wrench in, you don't really have enough room to swing the wrench to loosen the bolt.

 

So, I pulled the intake plenum, which overall wasn't too bad.  Then I removed the bolt on the back of the power steering pump and.... DOH!  The stupid fuel rail runs over the power steering pump, preventing the power steering pump from being removed from it's bracket!.  So in the end I had to pull the intake plenum and fuel rail/fuel injectors just to get the power steering pump out.

 

I can't get that fuel rail out of my head, though.  Why did the engineer route it over the power steering pump?  Why didn't he or she route it around the base of the power steering bracket?  The rail is specifically designed to clear the power steering pump, so obviously the engineer knew it was there.   Are they just playing tricks on the mechanics?  Or is it an ulterior motive to help drive up revenue at the service department?

 

I don't think I'm going to figure out the answer to this one :(

 

Ben

I hear this all the time from developers:  "This time, we're going to do things right way!"  I always find this intriguing--what is the right way?

 

First off, that implies that there's a single, correct way to build software, and any other approach is incorrect.  I tend to believe that any problem in software was many solutions, with perhaps a dozen that are acceptable solutions, and at least a couple that stand out above the rest.

 

For example, say we're implementing a dictionary-type object, which ties data to a scalar value.  What's the right way to implement this?  Certainly we could implement it as an array of keys we could scan every time we need to lookup data.  That would work, but it most likely wouldn't be optimal.  Superior approaches would be a sorted array or a hashtable, as either would greatly speed up the lookup process.  Which is best?  That gets complicated quickly as it depends on the distribution of your keys and the quality of the hash function; in most cases, either would be an excellent solution.

 

Nonetheless, I'll ask the person to describe the "right" way to build software.  Typically the exchange goes as such:

The thing I find most interesting is the fixation on front-loading processes, which is what dozens of developers have described to me when I ask them what the right way of building software is.  Where the heck is this coming from?

 

The best I can tell is that people have been trained to think in terms of mass production; that is, the most effective approach to building lots and lots of identical widgets.  And in that case, front-loading the process makes since the costs of setting up factories and tooling are huge, while the cost of each individual widget is small.

 

But software development is the converse of mass production--instead of building the same widget over and over again, we build less widgets and every widget is unique in some manner or another.  And because of that, most of the concepts used in mass production don't translate well to software development processes.

 

So, when you say you want to do things right--be careful what you ask for.

 

Ben

Spent a couple hours cleaning up code last night, mainly focused on how I keep track of objects that "live" in the game like powerups and laser bolts and the like.  Actually the goal was to unify the rendering code for powerups and video clips, since they're both billboard sprites, but I didn't quite get that far.

 

It's funny how my codebase has evolved--originally I was going to write everything in C#, but that died pretty quick because I really struggled with creating Direct3D textures in-memory and on the fly from the orignal, paletted textures found in the Descent data files.  So I switched to straight C, which was fun because it's been 10 years since I last did a straight C Windows app.

 

Pretty quickly, though, I started getting fed up with the limited scoping of C, since everything other than automatic function variables are either file-wide or global.  So, I started adding some C++ classes to help with scoping issues, which worked out great, and now am doing some (gasp!) inheritance for the game objects.  All pretty ironic for a guy who's been criticizing mainstream OO practices since late 1998.  ;-)

 

Actually, what receives the bulk of my scorn are the architects who believe that if some objects are good, then more objects must be better and if everything is an object, you've acheived true development panacea.

 

More than anything, though, writing in C++ reminds me how much I like C# over C++.  Sun did a great job getting rid of some ugly C++ syntax issues with Java, and then Microsoft went a bit a further and added some developer-friendly features.

 

Whoops, guess I got a bit off-topic there.  Next up for Descent is writing collision code to handle lasers hitting other ships and dealing with ship-to-ship collisions. I have a basic strategy in my head, but for some reason I haven't been real motivated to write this code.  I think I just realize how tedious it probably will be.

 

Ben

This is one of my all-time favorite questions, mainly because when I ask someone it, they look at me like I've just asked the stupidest question imaginable.  "Of course it's harder to walk up stairs, because you're working against gravity whereas gravity is helping you down the stairs."  Seems reasonable, right?

 

But it's not quite so simple; it turns out the that if you eliminate kinetic energy changes by keeping velocity constant, the amount of work done going down the stairs is equal to the amount of work expended going up the stairs.  Here's an analogy I find pretty useful:

 

Imagine you drive a vehicle at a constant speed up a hill.  The amount of work done going up the hill could be calculated by multiplying the horsepower produced by the engine, multiplied by the time it took to get up the hill.  Now let's drive back down the hill, using the brakes to maintain a constant speed down the hill.  It turns out that the in keeping the car from accelerating while going down the hill, the brakes need to generate the same amount of horsepower as the engine needed to produce to get up the hill in the first place!  Indeed if the brakes can't provide enough resistence (e.g. can't generate enough horsepower) the car will accelerate down the hill instead of remaining at constant speed.

 

Certainly there's a difference in how that energy is being transferred--going up the hill, the engine is utilizing a chemical reaction to provide power, and going downhill the brakes are dissipating energy mainly in the form of heat and to a much smaller extent, wear.  And to be honest, I'm also neglecting friction, which works against the engine going up the hill, but reduces the amount of work the brakes need to do going down the hill.  But that should be a pretty small portion of the total amount of work being performed.

 

Another way to look at it would be to imagine (don't try this at home, kids!!) if you walked up several flights of stairs to a platform and them jumped off the platform to the ground.  Obviously, very bad things happen when you hit the ground and you have to dissipate all that energy in a hurry--most likely in the form of broken bones and other bad things.

 

When you're walking down the stairs at constant speed, though, your body is dissipating an identical amount of energy as in the previous fall, but in a controlled manner--a little bit of energy is expended with each step.

 

Despite what you might be thinking by now, I'm not a complete lunatic.  I realize that running up a dozen flights of stairs is a hard, while going down that same flight of stairs probably won't raise your heartbeat a noticeable amount.  So the question still remains--why is it harder to go upstairs than down, since the amount of energy expended in either case is equal?

 

I certainly don't have the answer.  So far the best theory I've heard is surprisingly similar to the car analogy that I presented:  your muscles do all the work going up the stairs, which requires more oxygen, hence your breathing and heartrate accelerate  But, when you go down the stairs, the energy is expended through your tendons and joints, which probably dissipate the energy as heat. 

 

Seems reasonable to me.

 

Ben