Month: January, 2012

Live hard, pivot hard

From my days as a games developer for PC, PlayStation 2 and Xbox (classic), about 10 years ago, I remember reading some interesting advice from the famous game designer Peter Molyneux, which may come handy now in the world of startups.

See, when creating video games, one of the most important elements to giving players a compelling experience is to reach the correct balance. All the different parameters in the game have to be just right: difficulty, rewards, comparative power of the different options available to players, etc…  it’s really hard to get this right, and a significant part of the development process must be devoted to getting this right. Game developers and designers who can do this well outshine the competition.

In thist context, the advice from Peter Molyneux was something like this: “When you are balancing a game, don’t do small adjustments. They take you nowhere, and you can’t really even know if you are on the right path. If you need to increase the cost of some element in the game, do not add or remove 10%, make it double or half.”

This stroke me back then as genius advice, and it came from someone who really knew what he was doing. It has stuck around in my memory since then, and in twisted comeback, it has resonated with me lately, as it is quite applicable to our situation in our start-up. Let me explain.

Read the rest of this entry »

Quick reflections on yesterday’s post

I really enjoyed the conversations resulting from publishing “I want to fix programming“, and I’ve come to a few quick conclusions I want to share:

  • It’s great to have so much intelligent feedback, both on Hacker News and on the post itself. Very smart and knowledgeable people, some of them having explored the same area. Lots of insights. Lots of pointers to interesting projects. Proposals for approaches to get somewhere. I’m really happy to have brought this up in the open. There are a few “haters” there too, but I guess it’s the price of being out there – and this is key to getting the invaluable feedback from other people!
  • Raganwald suggested that just the notation could be useful. Invaluable advice. Maybe that should be the first goal. Still, I plan to publish the full series with my progresses so far before really getting down to work, so this is some time away. Also, Raganwald is probably the only person who uses github as a blogging platform.
  • Gruseom suggested the great idea that restricting things to a given problem space could be a great way to get somewhere practical.
  • There is interest out there. Many people are (more than reasonably) skeptical, but many other people would love to see some advance in this area and are happy to contribute ideas, etc… this is great.

I do not have an academic background, and I sure lack some or many of the necessary skills. But I’ve done my homework, or at least a lot of it. I have insights and approaches that can add some value. I may be able to contribute a “general sketch” that can help in building a practical tool. But in any case, attempting this here in the open and without any commercial interest can be the best way to advance!

Now, since we are launching a new startup and product later today, please excuse me from this topic and I’ll get back to posting on this topic in a few days. Thanks for all your comments.

I want to fix programming

(The SB series, part 1 of 7)

Programming is broken. Completely broken. The very way we write code today is just so broken that it makes you want to puke. I’ve been saying for years that I hate programming. I am and have been a fulltime developer for over 20 years, I don’t regret it, and I still love what you can do with programming. Still, I hate programming.

The way code is written is just braindead. At each step of the process, you can crash the program, be it by filling up all available memory, accessing a stray pointer or reference, or entering an infinite loop. No doubt programming feels like walking barefeet in a floor filled with broken glass. One tiny inch out of the right place, and bang, you nearly lose one of your toes.

Every step of the way, in every statement, line of code, function call or sequence-point, if you want to write good code, you need to think about all the different possible states of the whole program. This is invisible and impossible to define. Provably. Always. In all existing languages. That’s the reason 100% code-coverage unit-testing doesn’t guarantee bug-free code, and it never will. This is also the reason bad programmers don’t become good: they just can’t think about all those possible cases in a structured way.

(By the way, this only gets about a thousand times worse with multithreaded code – so it’s not getting better, it’s getting worse.)

The problem is that the fundamental way that code is written is wrong. It’s just wrong. You write a bunch of instructions, step by step, which supposedly result in a given wanted state. But each step is separate from all others, it is only understood by the compiler/interpreter separately, and it’s almost easier to screw things up than to get them right.

Read the rest of this entry »

Starting a new blog

I have reflections to share. Stuff I’ve been mulling over for the past few years. Let’s see if I can share these matters in a way you can get some value from what I write. I’ll be happy to host, read and respond to your comments. Mistakenly, I’ve done too much one-way communication in my life. It’s now the time to try and get some two-way communication rolling.