Versus Software

A few days ago while I was waiting for the the bus so I could go to work, I saw on the other side of the street a taxi driver trying to parallel park his car.

He initially used to wide of an angle to try to get into the parking spot, so after maneuvering the car in, he kept moving back and forth, trying to adjust the cab to the right spot. Unfortunally, since his initiall angle was so wide, no matter what he did he could not get the car close enough to the curb.

He kept going, back and forth for at least 2 minutes, until finally he moved the car completely out of the spot, took the right angle , and managed to fit the car perfectly in the parking spot this time.

Now I don’t know about you, but when I saw that I thought : “That’s a perfect software enginnering metaphor.” And indeed it is, heres why.

You see the vast majority of software managers when trying to do their job, aka manage software development, they usually list the things they should estimate: functional requisites, prototype, develop code, refactor, etc. They usually forget one simple and yet crucial thing:

You will throw code away.

Every software that’s used requires maintanance. Maintanance requires to increase or change the scope of software. As you do that, previous software under that new scope doesn’t function or isn’t the best for that system. They have to re-write things, start again, but with the new goal in mind.

But software managers usually don’t like the sentence “Throw code away”. It implies an idea of waste of time, or that any system can be adapted, it’s just a matter of figuring out how.

Those managers are doing exactly what that taxi driver was trying to do. Going back and forth with their code, hopeleslly trying to get their software/taxi in the right spot. They never will, and regardless of how many factors point to it, they won’t admit they’re bad drivers. To them the car will eventually set in the right spot, while in reality they should restart the parking procedure as a whole.

Those usually are bad managers, ones that I try to avoid. If they can’t park a car right, how the fuck do they plan to manage software development?

While riding the subway today I saw a man my age holding a book titled “Agile Software Development, Principles, Patterns and Practices“. This reminded me of a few opinions I had about software enginnering. I talked on a previous post that it’s important to take into consideratoin the final product that’s going to be developed in order to choose a proper software Engineering methodology.

Today I’d like to keep talking about that but focusing more on the technological nature of that which is being developed. Here’s a short story to better explain why:

While I was working on Conira, early on I decided just for the hell of it that this game would be multithreaded. Given my previous experience developing the Solis engine I saw that you could dissect the game engine into three threads.

1. One that renders all the objects in the game, be it sprites, particles or models. This thread uses the ‘get’ methods each object had.
2. Another that updates all the objects in the game, their displacement, acceleration, hit detection, etc. This thread uses the ‘set’  and ‘get’ methods each object had.
3. One thread that takes care of loading/unloading objects and handling the Operating System calls like windows and messages.

Initially I thought this would be a good design. I elaborated on how the threads would communicate, tried to figure out and reduce potential deadlock /livelocks and set off to code!

It wasn’t but one day later that I had to redo the whole design.

You see there is a technical limitation when dealing with rendering systems, threads and the Win32 specification. MSDN clearly states that “the same thread that RENDERS the objects MUST be the same thread that CREATES the WINDOW and handles its OPERATING SYSTEM calls.” In other words, thread 1 and 2 had to be same. In the end it wasn’t a big alteration, meerely trivial given the design I had but it did bring me into re-thinking certain software engeneering practices people take for granted.

When I was in college I was basically told that “code development is a final product of a series of design decisions”. You figure out your system first, its classes, structures, layers and then the code you write is merely an extension of that. In other words, take the broad view of a project and as you develop it, handle the inner details and its intricancies as they come. But that type of methodology fails to work in development environments where those same inner details and intricancies are what actually defines the system as whole.

I think Agile Software advocates say the same thing but with different words. “Work on the code first, let the inner details of a system be delt as they come, so don’t worry about documentation, design, etc. Code, code and code!”. They also usually point cases where such methodologies worked. However they fail to point out the architecture of the system in which they developed. Most, if not all, of those success stories I heard were either web applications or with an interpreted language such as Java or C#.

Well it makes sense for those projects to work on those scenarios! They were built on top of languages where it is expected to delegate the inner details of a system to whomever is handling it. So all they have proven is that those agile methods work on those environments, which is ok, but not that agile methods work as a whole, which is what they usually advocate. Honestly, I’m yet to see an long run story of a sucessfull low level driver or high optmized high-level assembly language project using Agile methodologies.

Don’t get me wrong, I’m not saying that Agile methods suck or that they don’t work. They do and can work quite well but one must understand the context in which they work, or else failing into the trap of beliving that they work in any environment.

If one doesn’t take into consideration the end product as well as it’s internal architecture while taking enginnering decisions, he’ll end up eventually just making bad or lucky engineering.