Versus Software

Today I finished reading this book: Writing Secure Code vol 2.

I picked it up when I went to the mall with my sister and a friend of hers. While they were chit chatting I was browsing the book store and started reading it. The first 50 pages felt rock solid with materials on how buffer overflows, off-by-one rounding errors and heap overflows could give users overwhelming potential risk over your system. So I bought it expecting to learn more on how to write good, solid and safe code.

After reading it I can definatly say that I did learn that, both the authors have extensive knoledge on this topic. What I really did enjoy though is that as the authors went further with the topics at hand they started giving personal experiences they had with software security and vulnerabilities.

They talked about the Microsoft Push Security Move, what they learned, common mistakes other developers told them, bets they made to see if anyone could crack their systems, etc. It’s filled with amazing little side stories on how certain issues rise from common misconceptions and how the authors dealt with them.

One of my favorites was when one of the authors found a critical security flaw on the software he and his team were developing. He discussed this issue with his  managers, but they saw no threat in it and told him to ignore it. So he used that exact bug to invade the general manager’s computer, proving his point on how deadly this bug was. The issue was then promptly resolved.

I think one of the implicit ideas both developers taught in this book is that for a manager to know how to deal with the management of developing safe software, he needs to understand how safe software is developed. In other words, and extending the idea to a broader term:

Good software managers are good software developers.

And I couldn’t agree more.

Today I’ll review another book I read, Software Engineering for Game Developers.

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.

Today I’ll review two books I read:  Professional Assembly and Assembly Language Step-By-Step.

One interesting thing is that both approach the same topic, teaching assembly language, from different perspectives. Step-by-step takes care of explaining the history of Intel’s CPU architecture, from the segmented mode to flat mode, detailing the intricacies of segmented programming along the way. It takes over 150 pages just to get to the first line of assembly code in the book.

Professional assembly on the other hand is a rocket ship, taking no apologies and going full throttle into Intel’s assembly structures and the GNU’s assembler (gas) syntax.

Step-by-step takes care of explaining basic computer architecture so that in the end you can understand assembly and it’s logic. Professional assumes you know that and blasts off, which I think in the end makes it a better book.

You see I’ll probably go back to Professional Assembly when I need a reference or review a topic, because Step-by-step while good at explaining things, once you got them there ain’t much left to go back to. Now you may ask me, which one should you buy? My answer is:

Both.

You see, one thing that I learned is that it’s good to study a particular topic several times, even if you are already familiar with it. An authors approach, no matter how good it is, will not be universal. That’s because it’s his approach to the topic, there are other things that can either be better explained or better elaborated upon.

And the more you look and study at a particular topic, the more universal your approach to it will be.

I finish reading Write Great Code Vol2 yesterday. I must say it’s a good book, although with one complaint.

Let’s start with the good side. It’s very well written and throughly elaborate on explaining how your compiler turns the high-level language statements into low level assembly. It then goes on for hundreds of pages explaining how to optmize that, from function calls,  arrays, structures to small if/else jump conditions, local, static and global variables differences. Basically covers most of the issues a programmer will face or would ask himself “how will this turn into assembly”.

The only complaint I have is not in the book itself but the author over and over and over and over again telling you that if you want to look further into a particular topic that the book doesn’t cover (like line caches) he states that you should get his other book, Write Great Code vol1. I don’t really have anything against good advertisement, but it just gets tiresome after the 10th time he does that.

Still It’s a good read and I enjoyed it. My copy of WGCvol1 is already on the way from Amazon and i’m pretty sure it’ll be a good read as well.

Like I said on my previous post, I`ve been reading Write Great Code Vol2. One of the ideas behind reading it was gaining more assembly knoledge and being able to write and optmize better assembly code. That is happening, at a small pace but gradually, though something more interesting began to happen that I wasn`t really expecting.

I`m now am able to read my compilers assembly output and have a better understandment of whats going on behind the scene. Now this may not sound like a big thing, but take the following example:

I was coding a particle engine for a new game i`m working on. Now I wanted this game to be a particle fest, like Geometry Wars. You could describe the basic particle loop engine as:

1. update particle position
2. render particle
3. repeat for every particle

Steps 2 and 3 are a bit of self explanatory, but i was spending way to much time on step 1. Out of curiosity I started looking at the assembly code on that section and saw that the debug build was taking way more overhead than necessary.

You see each particle is an object, and I was accessing its position via setters and getters. That was slowing way to much the debug build because of all the function calls. On the release the compiler would optmize it away, but since I tested the debug version more than the release, it slowed down the development process as a whole.

So I made a decision that most software engineers wouldn`t recommend and made the particles position public instead of private, and accessed them directly. Alas the debug version speed up!

I thought to myself that when trying to write fast code, sometimes giving up good software practices might do the trick. I was a bit skeptic at first, but ironically I ended up reading the exact same statemnt on Write Great Code Vol2. The author even used the same example of setters/getters.

Regardless of if this is a good practice or not, I`m glad I`m able to have a better undestandment of my code, how it works and to know what kind of choices should I take as each situtation arises.

I`m defiantly going to pick up Write Great Code Vol1 after finishing this one.