Saturday, August 10, 2019

Farewell to an Amazing Job

I have an amazing job. I work as a game developer in the new games studio for one of the leading mobile games companies in the world, experimenting with different game ideas to find the next big hit. While that is awesome, the company also earns an insane amount of money, so I can pretty much get whatever I want, as long as I can motivate it. Could it be better? I don't know, it sure seems pretty good when I put it that way. But still, that apparently isn't enough, because I just resigned. Am I crazy? Yeah, probably. Anyway, as some people have asked, here's my reasoning.

First of all, I've been here for more than five years by now, and as this is my first job in the games industry I'm kind of curious to learn how other companies operating in the same area do it. The new company I'm going to work for is also making mobile games, but they do somewhat different games and they do it in a completely different way. While the game engine is the same as I've been using the last few years, the team size and composition is very different. And I'm really curious to learn what else is different.

Second, while being this successful and having all the money in the world is kind of convenient, it also makes it very hard to really make an impact. Making a new game or a feature that earns a million dollars in a company valued to more than five billion dollars is something else than doing the same in a company valued to 35 million dollars. Also in a less monetary sense, you're a much bigger part of the company when there is less than a hundred employees rather than over two thousand. I'm hoping that will also make the company more personal, with less policies and processes that can't be bent and more space for doing the smart choices.

And third, it come down to the actual games in the making. The company I am joining have a strategy to focus on social multiplayer games, something that is very dear to me. While my current company also have an ambition to do that, it just doesn't seem to really happen. To be fair though, it is more easily done with the games of the new company, where you actually play with others, compared to the primarily single player games we make here and add a social meta layer on.

So, to sum it up, I'm leaving a great place with great people, to learn more, to have a greater opportunity to make a difference, and to make games I can be even more passionate about. I really would like to thank everyone here for this amazing time, and for all the faith you've put in me. It's been a blast!

Sunday, June 16, 2019

Reboot Complete

Last I posted here was five years ago when I published My Reboot Manifesto.
Geez, what happened?

I guess it would be fair to sum it up real quick with these words;

I have not regretted for a single second that I took that leap. I learned so much and met so many great people. I've made an impact on so many millions of peoples lives and helped make tons of money to both the company and to charity, and a little bit to myself too. And it totally drowned me in swag! It has sure been the ride of my life!

But it is coming to an end, and with that I thought it would be interesting to revisit the "manifesto". So let me just walk through it bullet by bullet, and please comment if you don't agree so we can talk it out. =)

Working with products for my employer instead of consulting for external clients

Round one is definitely for the better, for me I might add. I really enjoyed working for my own company's good rather than helping others, and with the added benefit of no time reporting it wasn't even a close game.

Using a MacBook Pro with OS X instead of a Dell with Windows

Another win! I generally don't really like Apple to be honest, but the MacBook Pro is an outstanding product, both the hardware and software. I really don't want to go back to Windows ever again.

Programming in Java with IntelliJ instead of C# with Visual Studio

This is a closer one. I didn't really become friends with Java, but I did like IntelliJ. However, the way it went down I only stayed with Java for about a year, after that I changed position and did C++ for a couple of years - where I used AppCode (also from JetBrains that do IntelliJ), and after that I actually came back to C#, but now using Rider (also from JetBrains) as editor. And I must admit C# is the better of these languages, but as the JetBrains products are superior to Visual Studio I'm gonna call this a tie.

Writing tests with JUnit and Mockachino instead of NUnit and FakeItEasy

This one was for the worse. While JUnit and NUnit is kind of the same, Mockachino had nothing on FakeItEasy. Also I do like the testing syntax in C# better than in Java, it's even more for the worse. Luckily that sorted itself as mentioned in the previous section.

Persisting data with Hibernate to MySQL instead of Entity Framework to MS SQL

To be honest, I can't really remember this in enough detail to judge it, as it was only during the first year I did any persistence using database. After that I've been working with mobile client as platform, where I've either persisted on the device as files or by rpc calls to a server where the actual persisting was made by our backend developers.

Having SCM in Mercurial with SourceTree instead of Subversion with TortoiseSVN

Here's another tough one. Mercurial was quite confusing to me at first, but I eventually got to know it pretty good - just in time before we decided to change to Git. After that Git was quite confusing to me, but now I've gotten to know it pretty good too... but it sure took some time. Subversion was so much easier, and the time spent on helping less technical team mates was a lot less. And in our case I'm not really sure if the benefits of the distributed SCM was actually something we benefit from. Now when I'm comfortable with Git I kind of like it, especially I like the partial commits and the rebasing, but it does come to a cost. Think I'll just call this a tie, as it depends on the situation and skill levels.

Doing CI with Jenkins and Ant instead of CruiseControl and Make

I'm afraid I have to give this to CruiceControl, mainly due to all the problems we have had with Jenkins here. I really like Jenkins when it works, especially the Jenkins Pipeline, but CruiseControl just worked, and that's actually the top most feature I want in a build server.

Handling sprints and issues with Jira instead of Redmine

What to say about this one... I guess I don't really like either of them. Well, actually I guess I don't really like bug-tracking-systems at all. I think that Jira has the upper hand on Redmine though, as it's so much more widely used, and it's so customisable and have so many plugins, so it is hard to be a competitor.

Monday, March 17, 2014

My Reboot Manifesto

So, I wanted to learn something new.
An opportunity appeared and I changed employer.
And with that, everything changed!

Working with products for my employer instead of consulting for external clients
Using a MacBook Pro with OS X instead of a Dell with Windows
Programming in Java with IntelliJ instead of C# with Visual Studio
Writing tests with JUnit and Mockachino instead of NUnit and FakeItEasy
Persisting data with Hibernate to MySQL instead of Entity Framework to MS SQL
Having SCM in Mercurial with SourceTree instead of Subversion with TortoiseSVN
Doing CI with Jenkins and Ant instead of CruiseControl and Make
Handling sprints and issues with Jira instead of Redmine

That is, while there is great value in the items
on the right, the items on the left are new to me.

I'm in for a real deep dive, and I love it!

Now I learn a lot every day!

Monday, February 11, 2013

My concern about Story Points proved right!

This months PragPub Magazine contains a great article by Ron Jeffries called "Estimation is Evil". It contains a couple of great quotes I'd like to share, and also proves my concern about Story Points right.

In my previous post "Story Points vs Hours" about a year ago I wrote:
"The more unreasonable reason is that as estimates are hard to do, you put a metric on them that is hard to understand to get away with them easier. If you say that something will take three days it's easy to see if you were right, while estimating it will take three Story Points will keep you safe. Who are to say how long a Story Point is? Hardcore agilists laughs at such a silly question."
In Ron's article he writes:
"There are a number of ideas about how to estimate using something other than time. Points, Gummi Bears, Fibonacci numbers, T-shirt sizes. These were originally invented to obscure the time aspect, so that management wouldn’t be tempted to misuse the estimates. (I know: I was there when they were invented. I may actually have invented Points. If I did, I’m sorry now.)"
Wow! Reading that just forced me to write this post!

However, since I wrote my previous post I've had the chance to use Story Points and was pretty happy doing it. We started with the assumption of a story point being half a day. That way, when estimating, we could easily transform our estimates, and thinking about "half days" instead of hours made the estimations simpler. "Would you finish this is half a day? One day? Two days?" is more tangible and easier to answer than doing the same with hours.

The story point estimates keeps being translated to hours on another level though, and my most frequent question is what formula to use for that transformation now. That's alright with my though, I can stick with estimating in half days and calling it Story Points. I'm just not sure about the formula, is half a day 3 hours, 3.5 hours or 4 hours? We started with the assumption of it being 4 hours, but as we usually are faster than we estimate with that formula I'm about to lower it...

Well, back to the article... Here are some other great quotes from it:
"Most of us were taught to write down all our requirements at the very beginning of the project. There are only three things wrong with this: “requirements,” “the very beginning,” and “all.” At the very beginning, we know less about our project than we’ll ever know again."
"Anyone who has ever looked at a list of “requirements” has seen some items that were very important, and some that were—well—not so important. Not so important like 1/100th as important as the most important things. Not so important like downright bad ideas. There is a very strong “80-20” rule at work in requirements lists. The bulk of the value comes from a very small subset of the so-called requirements. So these other things aren’t “requirements” at all. They’re ideas, and some of them are not very good."
"It seems that “they” often want to know how long something is going to take, and how much it will cost. My view is that “they” don’t even know what they want, so we bloody well can’t possibly know how long it will take. However, “they” are often powerful and have the money we need, so we need to answer their question, even though we cannot."
It's a really long article, but well worth reading. You will find the full article here:
Estimation is Evil (PragPub)

Wednesday, December 19, 2012

What is Agile?

So most companies now say they "use Agile". It's the new black! Every one does it. Or at least says they do... So, what is Agile?

In February 2001 seventeen people met to talk and try to find common ground. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened. What emerged was the Agile Manifesto.

So, Agile is what the Agile Manifesto values. It is also the twelve principles behind the manifesto. Nothing more.

Mistaken for being Agile

There are a lot of practices that Agile practitioners use, which are really good practices indeed, but doing a few of them does not make you Agile.
  • Daily stand up/Daily scrum is not Agile, it's a meeting to coordinate todays work.
  • Scrum board/Kanban board is not Agile, it's a board to track what's being done.
  • Continuous integration is not Agile, it is a server that builds your project.
  • Pair programming is not Agile, it is two people working closely.
  • Automated tests are not Agile, but they are really helpful!
  • TDD is not Agile, it is a practice for good design.
The list goes on and on. None of these are mentioned in the manifesto or the principles, but they all fit well while doing Agile.

Requirements for being Agile

While the practices above are good, and should be used in many cases, they don't make you Agile. Being Agile is following the manifesto values and the principles behind it. If you don't, here's some news: You're not Agile!

Here's a little list of interpretations I did from the manifesto and the principles.

You're not agile if...

  • Delivery of working software isn't done on at least a monthly basis
  • The progress isn't shown to the stakeholders on at least a weekly basis
  • You're not willing to change the requirements along the way
  • Business people and Developers don't talk to each other
  • Face-to-face conversations among team members are rare
  • The team or the stakeholders work a lot of overtime
  • You don't start simple, doing only the most important things first
  • Reflection on how you work, and adjustments accordingly, don't happen regularly


Please stop saying you do Agile Development based on having a daily standup meeting and a board with your stories divided into tasks. That is not what being Agile is. It would fit well in a Waterfall project too. Adding sprints and retrospectives takes you a little closer, but you're still not there. To be Agile you need to be able to check the list above on how you're not Agile... and if you're on the list, you're not Agile.

That being said, I don't want you to stop doing the practices you're doing. They are good practices, which will help you deliver better software. Just stop saying you're doing Agile unless you really do.

Monday, December 10, 2012

Beware the Agile Smells

For a while now I've been somewhat disturbed by all the methodologies I've so eagerly studied during the last few years. You know, the Agile movement and the Craftsmanship movement that's been coming on strongly. I've been troubled by all the time that is consumed with other activities than coding in my projects.

When I first saw the Programming Motherf**ker manifesto I thought it was ridiculous, but I'm not all that inveighs now. Even though I'd still call it silly it has some kind of point, because lately I've consciously been moving away from safety and coming closer to performing. I'm backing a couple of steps toward where I once was, the pragmatic programmer moving quickly just doing stuff. That was before I was infected by Agile.

Slowing down

Doing agile is a lot about safety where you time box stuff in short iterations with up front estimates, which is good in many ways. But when you spend too much time preparing, planning and estimating it stabs you in the back in the end. Your velocity would be better if you just did something, instead of four of us playing planning poker about if this is a one or two point story, and how you'd best divide it in tasks. I've also had problems with endless retrospective meetings and ad hoc discussions about how we work.

Also TDD and Unit Testing can have the same problem; it can easily be overdone. It's great in so many ways, but you need to keep a good balance between safety and productivity. I'm a big fan of Unit Testing, don't get me wrong, it's just that I don't think you need to test everything. Nor do I think you need to inject every single dependency. More on that later.

Speeding up

I came to notice a course by Dan North called Faster Software Delivery, held in Norway, which sounded really interesting to me. It seems to address exactly this! But since I live in Sweden I asked him on Twitter if there was any book or screencast on the subject, but unfortunately no. A book is in the writing though! However he pointed me to a talk he's been doing on a couple of conferences called Patterns of Effective Delivery. I found a good webcast of it here. You really should watch it when you're done reading this post!

Facebook Poster
Another interesting talk I've found lately is this 10 minute speech from JavaZone by Christin Gorman. She complains about the way of coding taught by Uncle Bob where everything should be broken down in methods of ideally one line of code, and naming that method properly so it's obvious what it does, to make the code more readable. I'm not quite sure who's side I'm on, but I find the discussion really interesting, and the best way is probably somewhere between the extremes.

At Facebook they have a culture inherited from Mark Zuckerberg encouraging to do stuff fast. Mark has this saying, "Move fast and break things", claiming that if things don't break you're not moving fast enough. Just shortly ago we often saw that in production, but now it seems they've either slowed down or put a wall of testers between the fast moving programmers and the production environment as I haven't had much problems with Facebook lately. They also have it written on their walls that "Done is better than perfect" to remind themselves to always keep shipping... that's something I really can relate too and actually put up that poster on a wall next to my desk!

Agile Smells

Talking too much

Since I started doing Agile I've had a lot of more meetings than before. Meeting are good though, making sure we're doing the right thing and keeping every stakeholder up to date with the outcome. But since we have them frequently it's important to keep them short and to have them when needed.

Changing too much

Being open to change is a cornerstone in Agile, and we should be – both in what we do and how we do it. But if we’re too open to change it becomes a problem. It may be adopting a new hot technique without the need for it, merely because there’s a lot of fuzz around it. It may also be not giving the ideas from the previous retrospective a fair chance before changing again or changing back to normal as we can’t manage the work to apply the decided change.

Continuity is needed for any methodology to work, so we can’t expect something to solve the problem in the first week. If something is obviously bad you should of course drop that practice directly but make sure you give your ideas a fair chance before ditching them and trying the next.

Prototyping too much

Prototyping is generally a good practice, where we invest as little as possible to gain as much knowledge as possible. We need to make sure though that we don't invest too much in the prototype though, as it would take away the benefit. Prototypes should be quick to make and shown to the stakeholders as soon as possible, and once the general idea is decided it should be terminated. Optimal efficiency is reached when the prototype is hand drawn with the client present and participating.

In some cases it may also be advisable to use tracer bullets instead of prototypes, a technique from the book The Pragmatic Programmer. Instead of creating a prototype you start writing the code with a first decent idea of how it should be and forge it to perfection through continuous feedback as you go.

Estimating too much

Estimates come to a price, and that price is that it takes time. Hence, by estimating, it will by definition take more time to do something. The more time you put into the estimate the more time will be added to completing the task. Here you need to find the balance between certainty and effectiveness. How much is the estimate worth? And we all know that estimates, however much time was spent making them, are estimates and not promises.

Testing too much

Uncle Bob says he demands 100 % code coverage. What a terrible waste of time for most projects! If you do pacemakers or deal with nuclear devices, fine, but if you do a corporate web site? Hell no! Test logic, test states, but don't test that the text you enter in the CMS show up on the web page - you'd notice if it didn't - and no one would be harmed if it failed to!

Unit tests are great in so many ways, but you need to keep a good balance between safety and productivity. I'm a big fan of Unit Testing, don't get me wrong, it's just that I don't think you need to test everything. For example obvious things. Or tons of nuances. Find all paths through the code and make sure a test case cover them. Would ever a bug occur, add a test for it and learn from it what kind of test you were missing. Certainly a useful one.

Kent's tweet
Nor do I think you need to inject every single dependency. If you're in the top layer of the code, which will only be used in this specific project, it can be OK to call that static method in the core formatting library without making a wrapper that implements an interface that you can inject. And you do not need to inject a wrapper of the CultureInfo class to make sure that your test will still work if you'd suddenly would change culture (unless you have a geographically spread project of course).

Kent Beck sent out an excellent tweet a while ago; "First you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer". In the first 10 minutes it was retweeted by 91 and favorite by 24!


Agile is good in many ways, but agile doesn’t necessarily make you go faster. As a matter of fact it may very well slow you down if you’re not careful! By paying close attention to what you do and what value you get from it you will be able to be more efficient by being less agile. Or rather, being the right kind of agile. The right level is no fixed though, so I can't tell you that. I just urge you to be observant and find the right level for you.