Skip to content

Category: Values

What I learned from game developpment

A decade ago, while I was finishing my master’s degree, I also started developing games with a few friends. Nowadays, I can’t overestimate the benefits those years of late-night-coding brought me, and here are a few lessons I learned in the meantime:

Data is important to the user

In online games, players are your customers, and they pay the high price of their free time to use your product. As most of us know, free time is a scarce resource, and your players won’t stay for long if you mess with their time, such as because of a bug, they lose all their possessions (technical issue), or if their character is killed too often (game logic issue), …

Having no backup of your database is the surest way to lose all your players at the first server crash.

Lesson: backup systems should be designed at the same time as your product, so you never lose a customer because you screwed up 10 years of accounting and the backups are unreadable.

Data quality is important to the coder

If you want to know where you are going, what happens in your game, and feel the effects of the changes you make to the world, you need some feedback systems. And there you start to pull your hair when you try to automate checks or data aggregation with non normalized data. For instance, if you want to make statistics over genders of in-game characters, and let’s say gender is a free-text field, then you’re in trouble: most people won’t fill the box, some will fill garbage, and some will try to fill it, but are not able to spell properly (yes, it happens). Therefore, you have useless statistics, stating that 30% people play a girl, 60% a boy, 1% a ‘dude’, and 9% of players actually play a droid.

Lesson: the earlier you freeze possible entries for your data, the less corruption you will have in the future. You never know what data could be useful one day.

“Hell is other people”

Amongst all the different behaviors you can meet, the script kiddie is the most difficult you can have to deal with. This guy will try to input all kind of data into your forms, hoping it will crash and get him access to something interesting. He will hammer your server with requests, because he read somewhere he could become root somehow by doing it.

Needless to say, he will more often crash your game than root it, and also make a lot of people frustrated because they just try to play and the game is down again. He will also create a myriad of fake game accounts, and automate them so he becomes a one man army.

Lesson: you should build your security model first, and then add features on top of it it, not the other way around, or there will always be a hole in which a malicious user will try to sneak in.

Copy-Paste is your best friend as long as you’re not sleep deprived

“I’m in a rush, I’ll just copy this old code and change it so I’m done earlier”. Except you don’t change it. Or worse, you don’t change it enough, and suddenly have all those crazy bugs coming from everywhere. You check and double-check the changes you just made, but can’t find where the issue is. Usually, it’s because you just replaced 3 parameters, but forgot the 4th, and your brain skips it every time you read it.

Lesson: instead of copy-paste, think about refactoring your code, write generalist functions and don’t duplicate code anymore !

Version control or die

There was a time, I did not know about version control at all, and trusted my luck to revert changes made over 3-5 files. It can sometimes work, but sooner or later, you’ll forget one of the changes, and then you’re stuck in a looong bug hunt. Repeat again, and then your entire code base start working against you, showing incorrect data to your players, or granting them with unwanted powers. This actually happened to me, and I decided to restart the whole project, from scratch, but with version control from day one.

Lesson: programming without version control is like walking on a tightrope: one day or another, you’ll fall, and this day, you’ll regret not to have a safety net.

Comments closed

Why we do what we do

Yesterday, I went to a Master degree graduation ceremony at the local university. The introduction speech addressed to the soon-former-students was extremely interesting.

It recalled me why we work.

If  you listen to the biblical sayings, it’s because mankind is a band of sinners that were  thrown out from Paradise. However, there are still people when given the opportunity not to work at all that still find some occupation instead of just sunbathing on a mexican beach.

The speaker made a clear distinction between “job” and “work”, between what he called “paid work” and “life work”.

For many of us, working is a kind of prostitution of ourselves: we trade our time against money. But maybe there’s more than just money ? Maybe there are greater extends, greater causes, greater expectations ?
For many of us, working is just what we were told to do to “earn” our life, but in the end, is a life spent hunting for our food is a life worth living ?

For many of us, we could completely miss the point of our own life, because the society says we shouldn’t look for our inner desires, dreams and thoughts, and instead get rich so we can afford everything salesmen try to sell us, like a new(er) mobile phone, a bigger car, a bigger house to put our bigger LED 3D TV.

Or … maybe there is some art to do in this world. Maybe there is some mystery awaiting for us to solve it ? Maybe we could replace the word “work” by “craft”, that conveys a totally different meaning ?

Maybe we can use our work as a medium to express ourselves, to add meaning over marketable work.

As Leonardo da Vinci said:

As a well-spent day brings happy sleep, so a life well spent brings happy death.

Had he only done his job (painting, sculpting), even very well, he wouldn’t have achieved such fame as he has now, as museums are filled with less famous artists, but who had of course great skills. What made the difference is that da Vinci was inventing new techniques that made his work astoundingly better that any competitors. He spent his life looking at the World straight in the eyes, and constantly invented new painting techniques, described physical and biological principles, designed music instruments, bridges and weapons, etc…

He was well paid to do so, but even the most well paid engineer wouldn’t spend his life working in such way if it wasn’t coming from within his own self. I don’t think Leonardo felt he traded his time for money. I believe he would not have stopped if the payment stopped, because it was a personal quest for beauty and knowledge he was on.

Masterpieces are always made by passionate people, who are not looking for money, but to achieve a higher level of mastery in their “art”, artistic or technological.

So now, what about transforming our daily job into masterpieces ?

1 Comment

Myth of the genius programmer

This session held at Google I/O last year brings so many important ideas to become a better programmer that is should definitely be shown in CS classes (and in some IT shops :p).

Thumbs up guys !


Comments closed


IT projects, like tattoos, are commitments. You wouldn’t accept that kind of answer from a tattoo artist, it’s your body, you have the right to change your mind as long as the ink is not under your skin. Why would that be different for software development ? Why would requirements be written into stone once they were signed ?

One could explain the too common attitude towards change by two main factors:

  • process momentum
  • stability issues

Process momentum is the consequence of everyone trying to protect their butt from backfires in case of project failure. As long as you can blame someone else for failure, you think you are safe, but in companies, the way to design the scapegoat is by signing contracts, SLAs, and other forms of paperwork. Every time you make a change in the requirement, someone can feel the contract terms have changed, and therefore, his paper walls are not protecting him anymore. Therefore, either you don’t make changes, either you spend a lot of valuable time to sign agreements.

Stability issues are the quicksand in which developers who don’t practice testing at a sufficient level are thrown when the requirements drift too much from the initial requests. That’s the typical “We will soon release a patch to fix the bugs introduced by previous patch. Sorry for the inconvenience.”. When you designed things like this and they end up looking like this.

The Agile manifesto states “Customer collaboration over contract negotiation”. Customer don’t change the requirements because they are evil, or helpless, but because they found a new way to improve their work. That’s what we do, helping them get their work done, and if possible, done better than their competitors. Don’t think of change as a mutation, but as an evolution.

If our quadruped, monkey-smelling ancestors decided that “walking on our rear limbs was not part of the original design”, just imagine where we would be now. Evolution is the way every live being manages to keep up with changes in its environment. Not changing (or changing two years too late), means putting your own kind in danger. If you eat beef and the new breed of beefs grows two more legs, you’d better find a way to continue chasing them, either by becoming smarter, either increasing your muscular mass (or number of legs, but that’s just gross).

If you eat money, and the competitor grows a new technology to eat more money than you (and possibly start eating your money), you’d better evolve your own tech right now !

Comments closed


Note: this post is part of a planned series on what values I wish to promote through my daily work

What do I mean by transparency

Based on my quite short but wide experience in the IT business, I must say that sometimes (not to say often) people do business like they play poker. The purpose of poker, like most games, is winning against your opponents. The provider tries to win against the customer, the customer tries to win against his own employees, etc…

To make successful business, we should open our eyes and realize that we don’t play against each other, we play in the same team.

Obviously, it only works when everyone keeps playing fair with others, and follow the game’s rules. Let me states some of them:

  • accept that a bad work shouldn’t be awarded
  • accept that getting more implies giving more
  • accept that others can also be right
  • accept that money cannot buy everything, nor that you are allowed to sell anything for money

That’s mainly humanism applied to business: remain fair with the others and no one will try to fool you. If you send the signal that you don’t respect people, don’t be shocked when people lack respect for you.

Some solutions for a better IT world

Here are a few ideas I try to spread around me on what we could to at any level to improve the current IT ecosystem:

Open formats

Most of my customers don’t see the issue when they build their whole business around proprietary formats.

Actually, they don’t see the issue while they do it, but after a few years, when the format has become extremely deeply rooted in the company’s flows, then they start to see that they have shot themselves in the foot.

Proprietary formats don’t play well with others, so it’s sometimes difficult, not to say mind-boggling to read them with an application that was not patented to do so. Business processes cannot be then automated (or only partly), what leads to more manual operations, more points of failure, more sources of errors, insufficient testing, and finally chaos (to stay polite).

And that’s not yet-another-open-format-geek’s rant, you don’t have to blindly believe in what I say, but just ask around you how many times a closed format was one source of major development delay, or was preventing/hindering automation, you might find the results interesting.

No vendor lock

Although it’s tempting to secure your customer base by preventing them (sometimes contractually) to evaluate other offers, made by potential concurrents. We’ve all seen all the great “benefits” that came with monopolistic situations:

  • low customer support: you don’t need to sweat hard for you customers, it’s not like they could fly away
  • loss of competitive advantage: we don’t need new features, the old ones are still good enough for them
  • overpriced updates: “We know we have a bug on version 1. It won’t be fixed in this version, but we have version 2 that doesn’t have the bug. Of course it will cost you . Shall I send you an upgrade form now ?”

I know I am doing my job really well, my customers know it too, so they are willing to pay for my services.

If one day they find a guy who is better than me, then I think it’s fair he gets the opportunity to show his skills, but I also have the opportunity to improve myself to remain competitive.

The choice is on the customer side, not in mine.

Open source

This one should be obvious nowadays. We are all using open source code at some point in every project. Some people admit it, others are afraid to.

Come on it’s not something a smart developer should be ashamed of. Not working extra hard to reinvent the wheel will not get you fired. You don’t expect your surgeon or physician reinventing medicine for each patient, you just expect he understands enough of the key principles, has enough experience, and knows how to insert what he learned in your specific case.

The same goes for us: we are not the smartest guys on Earth, we cannot invent a new way to build an e-commerce website at each customer that asks one. So many other people already wrote one, failed, learned from that, failed again, etc. I prefer relying on those guys who devoted substantial amounts of time building the most secure e-commerce website known to man, and give them proper credit, while earning my money on what I am the best at: advising the customer, writing the tiny part of the application that is completely customer specific, help him link his website with his existing applications, etc.

And if I can help those guys a little bit by releasing, for example, a bug fix in their application, I see no good reason not to do so, they deserve it. Everyone is enjoying it because no one gets screwed.

“Open schedule”

This is an especially sensitive topic. It’s not specific to IT though, but to any subcontractor activity. I often wondered why some customers required me to work at their premises while the job could have been done elsewhere, like at my office. That’s because some customers fears that you don’t play well and bill them more than necessary. By keeping you under their physical, visual, constant control, they have the illusion that you are not stealing them.

I think this idea that you could be over billing comes from some bad players in the field, either disguised amateurs with no ethics, either crooks with no other intent than making money on customer’s back. Either way, they left a bitter taste to the customer that is now punishing all new contractors, and indirectly themselves, for those guys. The same goes for plumbers, locksmith, painters, … because of some bad guys, one can completely lose confidence in the profession, while 90% of them are honest and hard workers.

Here comes the RERO principle: “release early, release often”, that is fundamental in the Scrum method. If you are able to deliver working software on a regular basis, then you are not stealing the customer’s money. The opposite is not true however, keeping the contractors “in-house” does not ensure that the product will be faultless, only that you will be able to watch the developer’s back during the whole duration of the project (you wish he has a sexy back then).


Perhaps the most overlooked idea while the easiest to practice. There are situations where you can choose playing it open, or prefer hiding the issue and cross your fingers for the best outcome. This includes:

  • as a customer, not having enough cash to pay for all the requirements that were made
  • as a developer, not being comfortable with a new technology, or not having heard of it at all
  • as an employee, you find that working six days per week, ten hours per day is not a sustainable pace
  • as a sales rep, knowing your coders won’t deliver the product in time

That’s why people talk.

If you cannot pay for the full product, maybe we can remove some features and fall back in your budget.

If you don’t know a technology, maybe you can get a training with someone who does, and either share the training fees between you and the customer, either take it for you and assume lifting less profit this month.

If you are working in at death march pace, at one point, something will fail, either in your body or in your life. Reducing your workload will allow you to be more focused, less tired, thus more productive.

If you know you won’t deliver on time, again maybe we can remove some features, but you let the customer select which ones are important to him.

Failing to communicate is digging the project’s grave.

Don’t let your pride, ego, fear or whatever talk for you. Just make one step in the other’s direction and you might be surprised by the outcome. Even if it does not turn the way you expected, at least you remain professional, because ignoring possible risks is not something you should allow yourself to do.

Thank you for reading so far, I hope you found some points of interest, or already shared my views on the subject. As for everything, I don’t pretend holding the truth, that’s just my own observations, mixed with many things I read during the past months.

To get a bit further, I recommend:

Again, if you have comments about this post, ideas you would like to defend, opposite experience, feel free to express yourself in the comments below.

Comments closed