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?

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.

Anry Nemo

Daniel Lieske

As well as old wizards like Dali

and Caravaggio

One thing I find particular interesting is how clearly explicit is a GOOD artist from a good one. Sure we can go down the path of Picasso being top notch and a genius while not being the best painter in the world, but my focus right now is in skill.

You can see, an artist is good when he masters several techniques like body proportions, shading, lighting,  diffusion, blur, meaning, semantics, and so on. To me all the artist above mastered this and it’s clearly visible even to laymen their genius.

That’s a thing a I refer to as the difference between masons and sculptors. Both work with the same raw materials, sometimes even the same tools, but their product is what separates the Pieta from simply another wall.

A sculptor understands the material he works to a point of such mastery that there is no limitation to what he can construct, all he needs is just time and resources. A mason while he may be good at it and could even attempt such a feat, in the end he would never reach such level.

There is clearly a distinction between the two, but what causes it? This change, that makes a beginner that is once a mason become a sculptor? What is the road to mastery?

I ask myself this question because I often draw parallels in between art and software development. Because I could just as well ask the same questions:

What defines a master developer? How does one become a genius in software construction? What is the road to mastery?

It’s easy to discern a great artist from an average one, all we have to do is look at their work, but how could we do this with developers? I usually read this in forums or talk with colleges and it usually revolves around with –

A great developer:

• Knows many languages
• Knows difficult languages
• Develops a lot
• Develops for fun
• Knows a lot about development
• Read a bunch of books
• Wrote a bunch of articles or even books
• Develops big products
• Never/rarely has bugs

And so on and so forth. Personally I think these criteria are fine but in the end, with them, you can’t discern a good mason from a sculptor. Knowing many languages doesn’t mean mastery of software construction, developing big products can be bottled down to trivial tasks such as mundane functions, lack of bugs can be either due to an easy to work environment or lack of new challenges.

My point is you can counter each one of those statements, thus failing to reach anywhere when trying to label an individual as a mason or a sculptor. What I believe is the way to go is something more along the lines of:

• A mason, given time, is able to solve most if not all known problems.
• An individual that is in between the two finds problems that haven’t been asked before.
• A sculptor is able to answer them.

I say this mainly because of my reference of what I consider to be great sculptors and their history, guys like Carmack, Abrash, Sweeney, Bram Cohen and so on. These guys managed to find problems no one faced before, or if they did no one answered, and then managed to find a solution of their own.

They did this because they knew their developing languages, their work environment, the machine down to the bitwise, to the electrical signal, to its deepest mathematical roots.

That to me is mastery. These are great artists. These are software sculptors.

I once heard a tale of a famous soccer player named Zico. Never figured it out if it was true or not, but I thought it was an interesting tale. Basically goes like this:

On on particular soccer match Zico kicks off from the middle of the field, the ball barely hits the goal post and bounces back inside. It’s a goal and the crowd roars. After the match a reporter interviews Zico:

“Zico! That was one lucky shot mate, talk about luck! You kicked off and it luckly got inside! How do you feel?”

Zico replied :

“Well you know it’s interesting. The more I train the luckier people say I get”.

I think it’s a funny story and holds a very deep morale.

You see I think “luck” is an interesting concept but merely abstract. There’s luck in winning the lottery and then there’s luck in managing to get that one job position or meeting that one person that allows you to get in a big project. But to get such a “lucky chance” you obviously had to work a lot to even be able to have such an opportunity. And even if you don’t succeed once, if you keep working, eventually you’ll get another “lucky chance”.

Deep down, I think that lady luck tends to favor those who keep trying.

As a book that concerns itself with software engineering I say it does the job. It’s an 800 page beast covering topics from UML, resource management, project risks, stipulations and damage control. More interestingly enough it tries to tie that with actual game development. It goes quite in-depth in each of it’s topics and gives plenty of further references if any particular one interests you. Overall it’s a good book.

But that’s not really what I want to discuss about.

You see, the book comes with a game a small team of developers made using a variety of software engineering techniques. This serves to show how one can apply them into game development. The game is quite stable, performing well given the myriad of things attached to it (3d mesh loading, textures, events, GUI, scripts, etc). However there”s just one problem with it:

It’s not really any fun.

Now I’m sure the goal of the book  is to teach software developers techniques they can use in their own development, with the game being fun not a pre-requisite in this scenario. It had to be functional, not fun.

That’s one of the things game development as a software differs from others. If a program manager assumes that a project will take:

• w hours of development
• take y developers to develop it
• cost z dollars
• have k use cases

And it ends up taking exactly that, most likely that was a successful project.

The problem with game development is that even if you manage to make a game with all your estimates correct, if the game in the end is not fun than you still have an unsuccessful project. Sure it can still sell well, but it’ll probably take tons of marketing to make up for it.

Some could say that fun is a non-functional requirement, which is true. However it undermines it’s importance into the actual game development process. Sucesfull game companies have long realized this and build entire systems of software enginnering whose sole goal is to enhance and facilitate adding ‘fun’ to a game.

Valve software uses their CABAL system, ID software with their endless internal engine prototypes, Blizzard with their QA tests, and so on.

Which leads me to conclude:

Sometimes the most important aspect of a project cannot be expressed in a process or in a form. That is still not a justification to leave it out off processes and forms.

He said that he was doing this project solo, and that such verification wasn’t necessary. That’s when I remarked “Two months from today you will be another person working on this project.” He got the joke and we both laughed.

You see even when you are working alone, as projects evolve, change focus or simply take time, you will forget about different assumptions you had previously taken. You will also forget about previous remarks you had in your code, which functions should be called, by whom and so on.

A solo project is still being developed by a team of individuals. They’re just separated by the 4rth dimension.