Archive for the 'Software Engineering' Category

The Clean Coder

The Clean Coder

By Robert C. Martin


The Clean Coder is a kind of sequel to the famous Clean Code published in 2008. This sequel is a 200-pages-self-help book for programmers that’s sprinkled with biographical material. By and large, the mantra is: read this book and you’ll learn how to be a true professional programmer. To achieve that goal, the author shows a kind of ethic code for “true” developers in a world of sloppy programmers. The most remarkable aspect of the book is that is rather focused on psychology than in practical or technical stuff. Therefore, there are whole chapters dedicated to topics such as: when/how to say No to pushy managers, coding mental-state, etc.

I do support the idea of acting always as a professional no matter if you’re an entrepeneur, an employee working for a large company or a freelancer. One should have always in mind that every mistake we make has consequences and there’s no free lunch. However, I find the approach of this book is a little unreal, the programmer is presented as a kind of medieval knight or so.

To sum up, there are highs and lows in this book. While I enjoyed some chapters like “how to say no” or “how to estimate”, others are pretty much useless, like “Coding”, “Mentoring, Apprenticeship, and Craftsmanship” or the one about teams and projects which, to my surprise, is 4 pages long (!?). The reading is agile and even enjoyable but don’t expect to much and it won’t disappoint you. Usually I’m not very keen on this sort of books, but every now and then, I read one because we all have something to learn or get better at.

This is recent interview with Robert C. Martin:



Riptide GP: An Android Game Postmortem

The website Gamasutra frequently publishes articles where game creators talk about the development process of a game. These papers are called Postmortem because they are written once the game’s been finished/released and that’s precisely what it makes them so so valuable. They are no just about “how brilliant we are”, on the contrary, Postmortems usually focus on mistakes and lessons learned.

Although most of them may be considered a must-read, I’ve found particularly interesting the one about Riptide GP where the guys of Vector Unit describe the process of porting a 360 xBox game (Hydro Thunder Hurricane) to the Tegra 2 platform. Hot topics such as funding, monetization and piracy are also addressed in the write-up . Definitely a good read!

Postmortem: Vector Unit’s Riptide GP


Duke Nukem Forever: When Enough Is Not Enough

Duke Nukem Forever has been one of the most expected games ever. As every geek knows, it’s been by far the most infamous case of Vaporware as well. Many lessons can be taken from the story of the project and how the 3D Realms people managed it. In fact, I sincerely believe this story must be taught in every single Software Engineering Course as an example of unbounded ambition and perfectionism.

Even though 3D Realms was a highly talented and groundbreaking developer company, when it comes to the Duke Nukem Forever, they totally failed. Actually, they coined the dreadful sentence: “It’ll be done when it’s done” which represents the principle that drove this neverending project. It worths reading the whole story that has been told in a splendid article published by Wired Magazine:

Learn To Let Go: How Success Killed Duke Nukem


Panda Cloud Antivirus

After 18 months of hard work, the baby’s finally born!  This is my first project as Application Architect and I must say that it’s been quite a challenge for the whole team. Since we’ve built almost everything from the scratch, we’ve spent a good deal of time thinking and designing every little aspect of this piece of software. Of course, there’re still things to improve/fix/work on (like any Beta software) but, generally speaking, I’m fairly pleased with the result.

Panda Cloud AV

By the way, Panda Cloud AV has been released as a Public Free Beta so if you want to check it out, just visit the official site:

There is also a blog for testers in which you can find technical details about the product, e.g Security Model, Known Issues, Logging, etc.


Call It Anything

Building prototypes (if necessary) is considered best practice as far as software construction is concerned. Its usefulness lies in the lesson learned which can be applied later on. Therefore, you can develope prototypes in order to validate your architecture, testing performance aspects, selecting the right technology and so on.

So far so good. However, you must know the fundamentals of software prototyping:

  1. Partial functionality. Your prototype shouldn’t have all features. After all you’re trying to validate just one aspect of your future product, otherwise your working on a early version of your product.
  2. Doesn’t meet your quality standards. Since a prototype is not a product, there’s no point in making it perfect. Moreover, you need it to make a decision so you want it finished ASAP.
  3. Disposable. Because of point 2.
  4. You’re prototyping and that is crystal clear. Stakeholders (particularly managers and clients) must understand you’re working on something disposable.
  5. It’s part of your planning sheet. So everybody knows you’re going to spend some time on it.

If your so-called “prototype” breaks any of the rules mentioned above, it’s more than likely that it has nothing to do with a prototype.  If this is your case:

  • Do no refer to it as a prototype, call it anything. You’ll save yourself a lot of trouble.
  • Ponder using any of those incremental methodologies.

To sum up, just keep in mind the following:

It’s a prototype.

A cute prototype

It isn’t.

A cute product