A Spectacular Failure

Back in the day I worked with the startup independent developer Limebird Entertainment, we entered into a few game development competitions. You know the kind — make a game, show it off together with lots of others and then a group of people select the best ones for some prize.

Usually, the competitions themselves were not that exciting, but you know you take what you can get in terms of exposure and if you’re making a game anyway, then why not enter it into the competition? So we did.

The immediate result of this is that we now had a deadline. Deadlines can be incredibly healthy things because they force you to pull together and produce something solid. It doesn’t matter how many subsystems you have in place or how brilliant they are unless you’ve got something you can actually show off to impress people.

Another thing about deadlines is that you’re always behind for them. We were no exception here… I’ve done some crazy crunching at my current job, but for a single crunch, the one we did on Velox for that competition must be the absolute worst kind of crazy. The setup of the competition that year was that you bring your machine in (unless you liked the ones they had), and you show off the game on a big projector screen.

velox-racerWe worked incredibly long hours the week leading up to that deadline. The game was coming together really well, but we were working ourselves dead. We didn’t really have all the stuff in that we wanted, however, and the deadline loomed. We worked all through the night to the presentation day, and then finally packed up our demo machine and left for the presentation.

At this time, I’d been awake and at work on this thing for about 30 hours. I was dead tired, and I’m sure my colleague wasn’t much better off. I was running on fumes and Coca-Cola.

Anyway, we set up the game, show off our menu system, host and join a network game and fly around for a bit in the hovercraft. Really high-tech stuff for the kind of level the competition was at, but it was also pretty rough around the edges. A minimap bug led to us having a hard time finding each others, for instance. Also, not having prepared any presentation as such, we sort of played around for a bit and showed off most of what we had in a rather unordered manner.

Then I went home, slept for 4 hours or so, got up, fixed most of our major bugs, and slept for another 10 hours.

The competition? We lost it to a team who’s game was an un-innovative re-make of an old game and whos engine was basically a Maya file viewer that needed really top-end hardware to even run properly, despite the really simple stuff they were doing.

So just what happened there?

box_eThe first thing to take away from this story is hidden in what happened after the demo. I slept for just a few hours, and was so conditioned to working with the game that I went back to it, even though we didn’t have a deadline anymore. But something had changed — I wasn’t dead tired anymore, so my mental clarity was much much better, which meant I could do much more good.

If you ever think about doing an all-nighter to hit a deadline, think again. If you’re crunching hard for long periods of time, stop to think, because chances are you’ve crunched so long that you now produce less in 12 hours than you normally would in 8.

The second question is the key to why we lost the competition: Polish and show. We failed to analyse the situation of what our target was, so instead of locking down early and polishing what we had, we forged on adding stuff to our game. If we’d come to our demo in a better shape with a presentation we’d practiced for beforehand and a polished game, we might have done a lot better. Now our high-tech stuff just looked bland next to the shiny effects of the winner-to-be (as did many other teams’ high-tech stuff, by the way).

Whenever you’re up against a deadline and need to show off what you’re working on, take a few minutes to identify what could give you the maximum impact with the people who’ll be watching and judging your stuff. Focus on the right things.

And have a good night’s sleep before you go there.

How It All Went Wrong

A man unexpectedly entered the office. Afterwards, no one could tell how he got there or how he left — he wasn’t supposed to be there, no one was supposed to get in without an appointment. The walls were lined with framed CDs and behind a large mahogany desk sat the label CEO in his luxury leather armchair. Surprised, he listened to the mysterious man begin,

Dear Mr. Record Label Executive, let me tell you something. You should listen to me, because I can tell you why it’s all wrong now. I can tell you how it all went wrong, when it went wrong and what effect it has on the world today. I am the messenger of the future.

Who are you?” said Mr. Record Label Executive, clearly not used to being in this position. “And how did you get into my office?

That is of no importance,” the man answered. “You can call me Lime, if you need something in the way of a name. What is important is my message. Your problem is that the youth refuse to buy your records. They download them, file share them, and refuse to pay. Correct?

Confused, Mr. Record Label Executive nodded.

People have been asking for paid download services for a decade, yet you were too afraid to let them have it — afraid they would just file share the downloaded music — so you gave them nothing.

Ah, but we created…“, Mr. R. L. E. started.

Nothing of sufficient quality“, the enigmatic Lime cut him off. “You gave them nothing that could match what they sought. So they kept downloading, they kept file sharing. For free, because that was the only available way.

It went on for a long time like this. Kids grew up, who’d never bought a CD in their life. They too started file sharing. For free, illegally.”

By now, the man in the luxury leather armchair was leaning forwards over his large mahogany desk, nodding.

Lime impatiently paced the room. “You see, there’s a new generation out there, who’s always downloaded music for free, because there were never any legal paid download services out there to download from. Don’t you see what you’ve created? A whole generation who’s never paid a dime for music, who has been taught that music is free, without value. You taught them.

Now wait a minute! How can they think they can just steal the music artists have put so much effort into?” Mr R L E protested.

They’re not stealing anything. You never gave them options, so they all learned that music was free. You taught a whole generation that music and other entertainment had no value. That is when it all went wrong!” He paused to look at the stricken man before continuing, “as you hunt them now for what they feel is natural and right, all they feel towards you is disgust, fear and anger for your greed. Imagine, all those millions of potential customers out there who are now lost to you because you didn’t take the chance of selling them what they wanted, out of the fear of what might happen if you did.

Now they’re a million very angry people instead, who want only to see your empire crumble.

Mr R. L. E stared at him aghast as the realization dawned. They looked at each others in silence for a while.

I see that you understand,” the mysterious man finally said and headed for the door. “Millions of angry people,” he repeated. As he closed it behind him, he added, “and now you’ve given them martyrs.

The Economics of Making Your Customers Hate You

The spectacular trial and marketing disaster against the Pirate Bay continued today, with the verdict of the first court (no doubt this will be appealed a few times around).

The three guys from the pirate bay, and their internet co-location and bandwidth provider were sentenced to one year in prison and a total of 30 million SEK of damages today. Whatever you think about the pirate bay, the sentencing of their internet provider is nothing short of incompetency from the Swedish court.

But let’s put that aside for a moment.

Let’s just look at the costs and benefits. These guys now have to pay 30M SEK for their sins of building a search engine. Let’s put that into perspective, shall we? 30M SEK is (with today’s exchange rate) €2,680,246. Contrast this with the spendings of the industry: 75M Pounds is what the record industry spends each year hunting pirates, apparently (only the record industry… who knows what the international movie associations’ and games associations’ and writers’ associations are spending…). With today’s exchange rate, that’s €81,466,099.

That means it’d require 30 such spectacularly unpopular court cases against major file sharing sites won just to win back the costs spent on hunting pirates. Really, who is it that thinks this is a good idea?

In other news, if you’re going to pirate a game, please do it off the ‘net and where it wont hurt the companies that tries to support it for the people who buy games. If you pirate a game and then try to get support for it, you’re a real asshole.

Trying the Open Source Shortcut

Jeff Atwood relates the story of an anonymous open source developer, who has done code and design on several open source projects and wanted to use this as a good reference for job interviews.

One company seemed impressed with my enthusiasm for the job but it was part of their policy to provide coding tests. This seemed perfectly reasonable and I did it by using the first solution I thought about. When I got to the phone interview, the guy spent about five minutes telling me how inefficient my coding solution was and that they were not very impressed. Then I asked whether he had looked at the open source projects I mentioned. He said no – but it seems his impression was already set based on my performance in the coding test.

The anonymous programmer then goes on to ask if Open Source experience is overrated? I’m sure it isn’t, but just like Jeff writes, you’ve got to pick a good project — one that will impress me by its result. The thought that having done Open Source software development will somehow get you out of having to perform well on a coding test and on interviews is kind of peculiar.

In a recruitment situation, what you’re looking for is not only someone who’s skilled enough, but also passionate enough about getting that job to prove it. Joel Spolsky calls it pickiness. Now going back to what our anonymous coder wrote:

I did it by using the first solution I thought about

I’m not surprised about the result. Caring about the code you’re doing and the job you’re applying for shows, both on coding test results and on your cover letter.

Open Source development does look good on a resume to me, but I’ve also seem some people with impressive resumes completely fail at implementing a very simple coding test. I absolutely understand the recruiter in the quote above — if your coding test result is bad, I’m not going to take the time to give more than a cursory glance to your previous projects, especially if you can’t answer well about why you wrote it the way you did.

It’s also a somewhat weird expectation from his side. Reading code you don’t know is hard and takes lots of time so the chance I’m going to download your open source code and actually read through it is virtually zero. If you haven’t done anything that actually achieved something, why should I care?  Even if you have, why would that matter if you just proved to me that you’re not what I’m looking for? Trust me, reading the results of a coding test is hard enough work, and if you have a fair few candidates, you’re not going to want to do much more than that.

He continues:

One of the reasons I worked so hard on open source projects was to make job interviews easier. By providing prospective employers with large samples of publically available working code, I thought I would give them something more useful to think about than my performance on a particular coding test or whether the acronyms in the job skills matched my “years spent”.

I agree with Jeff that working on an open source development project is a good way to boost your resume — but it’s not a shortcut through having to perform well in all other areas. My tip is if you care about getting that job, put as much effort into the application and coding test as you would on any project code — open source or closed.

Design Fundamentals: Encapsulation

EncapsulationEncapsulation is one of the core design patterns of Object Oriented programming. The point of encapsulation is to split a large program into a number of smaller, independent parts to reduce complexity. In a sentence, encapsulation is hiding the implementation details of a module from its user.

The point of doing this is that it’s easier to use a module with a well defined interface and it’s easier to change the implementation if fewer things depend on it. If you expose the implementation of a module to its user, you can bet the user is going to end up in some way or other dependent on the implementation details. This means that the risk of breaking something increases every time you make a change to the module.

Why does this not become an apparent problem for a new programmer? There are two major contributing factors. One is that new programmers tend to write small to medium sized programs, and that dependency-based problems tend to become apparent only in large applications. In a small application, you’ll have a few users of your module, and when you break the implementation dependency, maybe one of them breaks. You fix the error and move on. Simply put: You don’t need design skills to write “Hello, World!” applications.

Experienced Software Engineers tend to write large to massive program systems. If you have a lot of things dependent on the implementation details you’re changing, chances are a lot of things will break, and maybe some of the errors won’t be apparent until much later. Even better, if all your components are dependent of implementation details of others, every change you make is virtually guaranteed to break something.

The second reason initiate coders fail to notice the need for encapsulation is that the errors that spring from this are delayed. There’s nothing immediately wrong with your code — it works. That’s why this is a question of design, not of code.

So how do you properly encapsulate code? Start by looking at your interface for the class. How does one interact with it? Consider what it means — does the interface tell you what it’s doing, or how it’s doing it? If you find it’s telling you anything at all about how it does things, consider what you could do to hide it.

Another useful way to think about a class interface in terms of encapsulation is “how could I break this object’s functionality“? If you find you could break it, something’s wrong with your encapsulation. A properly encapsulated object guarantees the consistency of its own state at all times. This way of thinking about a module leads to robust interfaces and code.

A good starting point for encapsulation is to make all your internal data private, and to expose only retrieval methods for those things the outside world has any business knowing about (languages with Properties like C# avoid this, but without them you’re better off doing this). Remember, one point of encapsulation is that you should be able to change the implementation without changing the interface, and if your internal variable are public, you can’t change how you store data.

There’s a tendency to expose other complex objects that your class owns by direct accessor functions as well. This is usually a mistake. In essence, you’re giving up control over these objects, which means you can no longer guarantee your internal state is consistent and you can’t switch to a different kind of object.

Consider an example of a logging facility that has an output stream. There might be a temptation to do something like this:

log.getOutStream() << "Testing, testing";

This is where you break encapsulation, becaue suddenly you have no idea what’s being done to the log stream. Maybe someone saved a reference to it somewhere? Is it safe to delete it? Did someone start a row and leave it unfinished (like I did above)? Dunno.

Also, you’re now stuck unable to change to logging over a network, onto a printer, into a GUI or whatever else could be useful to do (unless you want to derive your own iostream, which I wouldn’t recommend).

An option is to encapsulate the logging service fully, and only provide an interface to do things with (log text):

log.addTextRow("Testing, testing");

This way, whatever you do in addTextRow() is your own business, as long as logs get made.

As with most design issues, getting the design right when it comes to encapsulation is hard the first time around. You’ll almost never get it right the first time around. That doesn’t mean you shouldn’t try your best though — the reason you get it right the second time is that you notice what happened the first time you tried.

Many new coders tend to mix up project process with design process. Hearing about waterfall (and it’s negative sides), they say “I’m not doing waterfall”, which to them means not to do any design up front. This is a big mistake — think about your design all the time. When you sit down to write a new class, you should have a design idea in mind — trying to nail on design onto a kludge of code is a lot harder than to rework a bad design into a good one.

What does this have to do with encapsulation? It means you should make your variables private from the start, and immediately start thinking about your interface. That way, you’re not going to have to realize halfway through that you’ve missed encapsulating things. Nearly always, the key to getting the design right is to start thinking about the design.

When I recently sat down to implement a new feature of a side project I’m working on, the first thing I did was create 10 empty files, because I’d already thought the design through enough to know I’d need those classes. That doesn’t mean you should do all your design up front, and never touch it again (waterfall-style), it just means there’s nothing wrong with thinking about design before you start coding. In fact, I very much encourage it.

WordPress Themes