Versus Software   game + free time = duck

Weeks before graduating from college, while I was handing out resumes and doing job interviews, my father, who has an engineering background, asked me the following question:

If I were a farm owner and wanted you to create a machine that sorted the bad potatos from the good ones, what would you do?

Seemed like a simple task so I thought about it for a few seconds. Initially I imagined a device that would take pictures of the potatoes and perform image processing queries on them. These queries could then figure out if there were any fungus or odd shapes in the potatoes.

When I told this to my father he laughed. He said: just throw the potatoes in water. The ones that don’t float are the bad ones.

Now this is a very simple example of an issue that I think rises with a lot of development and engineering teams. You see, had you had asked that question to an electrical engineer he might have thought if the current that passes in bad potatoes is different than in the good ones. A mechanical engineer might have thought about the weight difference between the potatoes, and so on.

People tend to face problems from their technical backgrounds, which is not particular a bad thing, but it is important to be able to extend to other areas of knowledge, even trivial ones. Had any of those engineers had asked a cook about the potato problem, they would have probably had the best answer.

And to me that’s the crucial point here. I think a lot of projects fail because people fail to assume some other realm of knowledge might have a better understanding of the problem they are facing. They assume they can ‘deal with it’ and in the end, all they get is a bunch of bad project decisions and thus, bad potatoes.

In my last year of high school I had your typical Brazilian literature teacher, where he used to praise Brazilian authors in contrast with foreigner ones. He used to denounce reading foreigner authors and that the Brazilian mass should enjoy more of its local authors.

I pretty much disagreed with most of the things he said, but he did say one thing that struck me as true and it’s pretty much the only thing I took with me from his classes. He said:

An artist writes how he feels and how he feels is a direct consequence of the environment he finds himself at.

In other words an artist’s background, culture and the society around him influence his artistic views. Makes pretty much sense doesn’t it? But people usually apply this to writers and the normal standard of an artist. The catch is that it affects all creative thinkers, this includes engineers and software developers as well. Here’s an example.

Every now and then I read some article comparing the PlayStation 3 architecture with that of the Xbox360. Makes sense since they were both platforms developed to handle massive amounts of data. Usually those comparisons involve a instruction/triangle/frame/shading per second/pass view or how the 6 synchronous SPU cores compare with 3 asynchronous cores.

It’s all quite interesting, since for on one hand you have an architecture that’s basically massive raw power, running at the highest possible clock speed, with tons of ram. Big and bulky American muscle. On the other side you have a series of smaller cores, that require a more ellaborate design, streched throughout each individual node. Less but more refined, efficiency through group effort. When I see these sorts of things I think of only one thing: Motorcycles.

You have the classic American choppers, big bulky American muscle. Lots of fuel, big engine cylinders, raw power per torque. Made to last.

And then you have the Kawasaki’s lines. Less fuel per cycle, more refined in it’s architecture. Made to run fast.

Each of those types of Motorcycles present its ups and downs. With one you can go from coast to coast and back again. The other you can only go from one to state to the other but at top speed. They’re the same type of vehicle but the catch is that they were designed by engineers of different nationalities.

I’m not trying to throw the cliche dilemma of East vs. West here because I see it more as a general social example. Both engineering teams were given the same task: built me a motorcycle, but their final product is obviously different in terms of style and scope. To me a big part of it is that both teams had different cultural backgrounds, were in different societies and had thus different views on how to solve the same problem.

I think the same happened with the Xbox 360 and ps3 teams. Both had the same task: build me a video game, and the final product is obviously different.

Both systems have it’s ups and downs but the point I’m trying to make is that I think an ideal developer/engineer would be able to go beyond his cultural heritage and be able to reach the same conclusions the other team had, and in the end make the best overall decisions.

Generally I think a good artist is not bound by the limitations he found himself at. He is able to roam freely from it and create an art that doesn’t speak to only those individuals in his current social realm, but to all individuals. To me a good artist is universal in his approach of seeing and making art. As James Joyce put it brilliantly:

When the soul of a man is born in this country there are nets flung at it to hold it back from flight. You talk to me of nationality, language, religion. I shall try to fly by those nets

I think it’s a beautiful quote and strikes at the core of that which I spend so much time thinking about. Joyce is a relly good read, though unfortunally I don’t think my Literature teacher would read him.

At least you understand now why I disagreed with him so much.

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.

Few days ago I got fan mail from a game I developed, Solis.

The e-mail I got basically complemented the game, saying he liked the style but thought it had too much text hahah. Always good to get feedback from my projects.

Solis is sort of a special project to me. It was the first BIG project that I developed and every now and then I check how many downloads it managed to get (5000+ and counting). It`s not a big project and it ain`t no RPG Maker killer but it was a fun game to make.

With this game I learned 3 very important things:

1. No matter how close you are to finishing a project you will only, and only after you finish it, be able to learn and truly take a critical perspective of it. This is the sort of thing you can’t really explain why. Basically you know why when it happens to you and after that you understand why it can’t really be explained.
2. Different games take different amount of resources. Quite obvious, but it’s the sort of issue that gets commonly overlooked. Solis was a 2D rpg game, and with it came hundreds of sprites, tiles, images, maps, sounds… The list just kept getting bigger and bigger and I was soon to find that I needed an artist.
3. Know your user base before doing the project. During halfway through developing the Solis tool set, I thought I had actually found a development niche. You see, people make RPG maker maps and images all the time, write tutorials about it, etc. But most of them use pirated versions of it. I thought an open source RPG maker would fill that need and actually be able to create a community out of it.
   Boy was I wrong heh. The RPG maker community is mostly of artists and script writers and since Solis was written in C++ that didn’t really appeal to them. Maybe if I kept investing into it I could have pulled that one off. But after such a long development process, I felt I wanted to do something else.

And I guess that`s it. There was one interesting side effect of developing this game though… and hasn’t faded yet:

I never managed to play a JRPG again. Ever. I finished Solis and could not stand looking at JRPG…. Pretty weird heh.

Ever since I read this book a long time ago, I’ve always enjoyed art history and it’s analysis. I like how art, specially painting and drawing is a form of craftsmanship, how one evolves with it in time. I do enjoy looking at great contemporary artist like

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.

I was having a chat with my good friend this afternoon. He was having some trouble getting the XML parser on the iPhone to work and I tried to help him out where I could. I gave him the tip to always check for the xml error parser code, when something goes wrong, even if most likely nothing will.

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.

Hello everyone!

Welcome to Versus Software, my humble blog. Here I’ll talk about the games I’ve created, the current projects I’m messing and other things that generally interest me. Guess that’s it for now!

Until then.