Versus Software

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.

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.

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.