Articles from April 2010

Master of Blocks

My last game written in Lua got accepted to App Store. Get it before Apple removes it :)

Destroy a mortal or try to survive the wrath of God as long as possible. Classic game turned into an awesome two player game.

Are you the Master of Blocks against AI opponent and your friends. See who can master the blocks.

When you play with a friend using Bluetooth, the other player plays God and the other one plays mortal.

Price: 1.59€/$1.99

View in App Store

  • Share/Bookmark

How to Avoid Meetings

I just watched a video from Jason Fried talking why people cannot actually work at work. He explains how they try to avoid interruptions at their company, but most people cannot affect the way other people communicate in their office.

Meetings are the biggest interruptions for people without “Manager”, “Director”, or “VP” in their title. Most meetings are useless or take way too much time, still a lot people get dragged into meetings as experts, and they might not actually say anything during the whole meeting.

Try these tricks to avoid meetings.

1. Don’t go

If there are more than three people at the meeting, they probably won’t need you anyway. See, if anyone notices that you are not there. If they really need your opinion and input, they will come pick you up.

When you do this often, people will stop inviting you to meetings, because they know that you won’t show up, unless you are physically dragged to the meeting. You might get the reputation of someone who hates meetings, but don’t we all? You are just expressing your opinion better than others.

2. Ask for a clear agenda when you are invited

If there isn’t a clear agenda for the meeting, you are better of doing something else. Meetings without agenda get easily sidetracked and nothing gets decided.

The agenda should also say what is the actual goal of the meeting. If there is no goal, don’t go. You don’t need to waste your time listening to other people talking about their hopes and dreams.

3. Say you need to get some actual work done

You might be surprised that this actually works. When you say this to people they might actually realize that they shouldn’t just randomly invite people to meetings. If they keep arguing that the meeting is really important, then ask why is it more important than the work you are doing. If they can answer this question, then you might be out of luck.

4. Don’t obey your managers like in the army

Stand up to your manager, and explain how going into a meeting will interrupt you from getting your work done. Most managers should shield their employees from meetings, but if they don’t, you need to voice your opinion. Most people act like whatever the boss says is the law. Wake up! It’s not the army, unless you are, of course, working for the army. Show some backbone and stop acting like a lamb.

5. Make a mockery of meetings

This tactic will not win you any reputation points, but at least it should get you out of boring meetings. Question the usefulness of the meeting in the meeting. Show that you are actually angry that you were invited to waste your time. When someone gets sidetracked, ask if you can leave, because your time is being wasted. This, of course, requires some balls, but balls will get you out of meetings.

You can also bring your laptop with you, and not pay any attention to the actual meeting. When you show people that you have better things to do, e.g., harvest your Facebook farm, you won’t get that many invitations to meetings anymore.

6. Switch your job

This is the last choice, because some companies are so obsessed with meetings that there might be no way to avoid them. Life is too short and precious to spend it in meetings. Find another job from a company that has a better understanding of the true value of meetings. You should ask in the job interview what is the company policy and opinion about meetings.

I don’t think people want to tell their grandchildren that they spent most of the their work-time in meetings. People want to get things done. They feel good about themselves after a work day, when they actually accomplished something. Nobody feels good after a day of meetings.

  • Share/Bookmark

Apple May Have Lost the Mobile Game Business

Apple has admitted that it does not make money with App Store. They make money with the number of devices sold. So the whole purpose of App Store is to sell as many iPhones, iPod Touches, and iPads as possible.

It’s in Apple’s best interest that there are as many good games as possible in the App Store. The mobile gaming industry is still growing strong. Apple has the chance to become the biggest player in the market with App Store, but they need game developers’ support.

Writing games only in C, C++ or Objective-C is, of course, doable, but without the possibility to use scripting languages, it’s not the most convenient way to develop games. Scripting languages are the heart and soul of games these days. The speed of development increases, when the game can be scripted. Frameworks, like Unity3D, are a big reason why there are so many games available in App Store.

Games don’t need support for multitasking from the OS. Games don’t run in the background. Games are always multi-platform; they don’t rely on native UI components. Most game code is game logic, or graphics.

All the reasons that people have given for Apple’s decision to limit programming languages do not affect games. Apple just made developing games a lot harder for iPhone. With the limitations, game developers have to decide, if they want to write games exclusively for App Store. It’s, of course, possible to use the same code base, written for example in C, with other platforms, but it will be a lot harder to develop games that way.

Apple was in a good position to challenge Nintendo as the leader in mobile gaming business, but now that might not happen with Apple’s decision to piss of game developers. We just have to hope that Nokia doesn’t make another pathetic attempt to enter mobile games like it did with the Nokia N-Gage. It will also be interesting to see, if Android starts to gather some momentum in mobile games.

  • Share/Bookmark

RIP Lua Programming on iPhone

It’s over. Steve killed you. We had a good run, but it came to an end sooner than I expected. I was always worried that something like this might happen, but it was still a surprise.

We knew each other only for a couple of months. Those months were the best time of my life. I will always remember the fun we had. I can still remember asking you to create a complete table including the data model with just one line of Lua code. You did all the hard work for me. I never knew what was happening behind the scenes. I bet your autopsy will reveal thousands of lines of ugly Objective-C code, but I don’t care. I will always remember you and your clean and nice Lua interface.

I remember when we did the multi-player code. You just said that I should give you the function that will be called on the other iPhone. It worked beautifully. I could just run code over the network as I did locally. I suspected that you did something against the rules, but I was ignorant and trusted you. The autopsy will probably show me the nasty details how you implemented this.

We also had fun, when we tried to hide you from Steve. We obfuscated the Lua scripts and put them inside the binary. Now, even that wouldn’t do the trick anymore, because running strings command on the binary, reveals that Lua library is inside the binary. I don’t know, if Steve’s minions would actually do this, but I am not going to risk it.

You showed me your true powers with closures and metatables. I was amazed, how you could do so many amazing things, when you seemed so simple. I felt that I was cheating, because programming with you was too easy. Most people think that programming for mobile devices is supposed to be hard, but you proved them wrong in your short visit on this planet.

We had our problems also. Remember, when I tried to use timers that were released. I would use pointers after you thought no one was using them, and cause you a lot problems. We talked about fixing this problem in your next version, but we didn’t even get to start working on that; your end was so sudden.

I hear there’s a new kid in town called Android. From what I understood, he doesn’t kill stuff like Steve. I hope I can resurrect you with Android. It might be dangerous, but I have to try it. I grew so fond of you that I cannot see myself coding in Objective-C or Java. They are just too verbose. You were so simple and elegant, but I guess Steve didn’t like the competition advantage you provided for people like me.

I will always remember you and keep a copy of you in my version control close to my heart. I will leave everything the way it is now. If I try to resurrect you with a new device, I promise I will use Git this time. I will let you have your peace in SVN.

  • Share/Bookmark

12 Problems with Software Estimation

Software estimation is hard, really hard, but still many software companies rely heavily on software estimations. I will present twelve big problems that come with software estimation. The list could easily have 20 or 30 problems, but I limited the list to only twelve problems.

I will not suggest any solutions to these problems yet; that is the topic of another post.

1. It is impossible to estimate the unknown

Every software is unique, and it is impossible to estimate a software accurately, when it’s being done for the first time. Even if the requirements are given, it is really hard to estimate a complex system that is going to be built with the given requirements.

Software can be programmed in so many different ways, and usually design decisions, which are not known during the time of estimation, have a huge impact on the duration of the project.

There are, of course, different kind models and methods to make the estimates more accurate, but even with the perfect method, the estimates are still only guesses, because of all the things that are unknown when the estimates are needed, which is usually before the development starts.

2. Estimates are usually optimistic

Most programmers make optimistic estimations. They either think they are more productive than they actually are, or they do not understand the complexity of the software.

This usually leads to padding. The person who receives estimates from the programmers might multiply the estimates with a magic number just to make the estimates less optimistic. This is also very bad, because everyone doesn’t make optimistic estimations.

3. Estimated time is always used

Most programmers also tend to spend the allocated time on a task. If something is estimated to take two days, the programmer makes sure that it takes two days. Even if he finishes early, he will tune and polish his solution, or just slack off, until the allocated time is spent.

This creates a situation, where nothing gets done faster than the estimates, but some things will take longer than the estimates.

4. Business relies on estimations too heavily

Product launches are scheduled based on estimates. Trade shows are booked based on estimates. In some companies the whole sales and marketing departments rely so heavily on estimations that any kind of delay will cause major problems for the company.

5. A lot of time is spent on things that are not estimated

Even if the estimates are perfect, a lot of time must be spent on things that are not estimated. Programmers need to do some maintenance for older versions, someone gets sick, and new tasks come up during the project.

Many companies add another padding for these things, but it does not make the art of estimation any better. If estimates are based on adding padding, and padding on top of guesses, it does not sound something that can be relied on very much.

6. Estimates are not treated as estimates

People do not understand the meaning of the word estimate. It should be taken literally, but the true meaning of the word is not understood nor is it respected. There shouldn’t be too many plans that rely on the estimates. If things that have estimates depend on other estimated things, it creates a chain reaction of delays, when an estimate cannot be reached.

7. Estimates do not consider productivity variations between programmers

This adds another level of difficulty for estimations. In traditional industry, you know the speed of the average bridge builder, but programmers differ so much in productivity that it is impossible to estimate accurately something when you have two unknown variables: the speed of development, and the required amount of work.

The situation is not that bad when programmers estimate their own work, because they might have a good guess on their own productivity, but when someone else does the estimation for the programmers, they could get equally believable numbers with a Stetson-Harrison method.

8. Changes in requirements do not reflect on estimations

Most projects have changes in requirements through out the project, but the estimations for the whole project are not changed. Every single feature added to project must have an effect on the estimates, otherwise the whole process of estimating things is a complete joke.

9. Truth is told when it’s too late

When programmers make their own estimations, they blindly believe that the estimates can be reached and the software will be finished on time. They won’t accept that their estimates were optimistic, until very late in the project, when telling the truth is already too late.

10. Estimates are not updated when they cannot be reached

When estimates are not reached, other estimates should also be corrected, because missing estimates is usually a sign of optimistic estimation. However, in these situations programmers blindly believe that they can do the rest of the tasks faster to make up for the lost time, when the opposite is usually true.

11. Programmers are blamed when estimates cannot be reached

When the whole success of the company depends on estimates, someone must be blamed when the estimates cannot be reached. Usually the finger is pointed to the people, who could not keep up with the estimates: the programmers. This will create a very unhealthy work environment, and programmers will pad the estimates just to keep their jobs safe.

12. Wrong people do the estimates

Estimates should be made by the programmers themselves. Sometimes team leads can do the estimates for them, but the game is lost, if someone with an MBA does the estimates. Run and don’t look back, if this is happening in your company.

  • Share/Bookmark