According to Wikipedia: ‘Object-oriented programming (OOP) is a programming paradigm using “objects” – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.’

OOP is supposed to be a practical way to organize a program into hierarchies of objects where similar objects can inherit behavior from each other and override that behavior when necessary. Objects can also contain other objects and that is a technique called composition. Certain programmers pick up OOP and fall in love with the rule-set without fully understanding it, or they over-apply the principles. These people are cargo cult programmers.

I have met programmers who believe that anywhere there is a conditional statement in OO code, there is cause to subclass, “because that is the OO way! ™”. And they will defend it against any pragmatic reasoning. So anywhere you see an if/then/else or a switch statement, you should find a way to break the logic into seperate objects to avoid the logic. The dogma here is that conditional statements complicate things and are not strictly OO, so they must be minimized and preferable erased.

A Car and a Train and a Truck can all inherit behavior from a Vehicle object, adding their subtle differences. A Firetruck can inherit from the Truck object, and so on. Wait.. and so on? The thing about inheritance is that is so easy to create massive trees of objects. But what OO-bigots won’t tell you is that these trees will mess you up big time if you let them grow too deep, or grow for the wrong reasons.

Programming like this might not be a problem on a small to mid-sized one-man project, since there will be a limit to how much you will need to subclass to get a viable solution to whatever problem you are attacking. But on a 100KLOC+ sized project with thousands of classes, you get into big trouble. The project transforms from manageable inheritance trees and simple classes into an unmanageable mess, with stack traces so deep you need diving skills to reach the offending code. If you are really OOP obsessed and have been using interfaces to avoid being implementation-dependent, then you are in for a real treat. You will end up at the bottom of the stack trace looking at some offending code that clearly fails, but when backtracking to figure out how it got in this state all you encounter is interfaces. So you spend half the time finding out what implementation of said interface is being used and then find out that it is calling super.somemethod(..) which again calles super.somemethod(..) and so on all the way up the inheritance chain.

And then there is the issue of needing to change something in an object near the top of the inheritance stack, which in turn changes the behavior of the objects below in sometimes undefined ways. The deeper the inheritance tree, the worse things get when changing top-level objects. You can of course (and should) have unit tests and regression tests to ensure that the behavior remains the same, but these tests are just crutches that will help you dig yourself into a deeper hole.

The real problem here is that using inheritance too aggressively to simplify the internal logic of individual objects is a bad move. It’s using the KISS (Keep It Simple Stupid) principle, but in the worst way possible. You might think you are adhering to good OOP practice, and your classes might be simple and conditional-free, but no one (including you) will be able to change or debug your code in a painless manner, even with unit tests and regression tests.

When wanting to keep things simple you should try to let the code flow in a linear fashion. Any related logic code should be kept as close as possible, even if it means using conditional statements. It is a lot easier to read code if most of the important bits are in the same object or file instead of spread out between multiple classes. You should of course use inheritance, but moderately and when necessary. You should also abstract out logic into appropriately named methods to keep a readable level of abstraction. And you can also use composition to add behavior to your objects. You want to maximize readability because that is what matters later on when you are maintaining or debugging. That is the pragmatic approach.

No one is impressed by how OO your code is if it is impossible to debug.

It also means that I can  tell you this dirty little secret without too many people choking on their agile-conference-coffee:

TDD, XP, Scrum, Kanban (and the rest) are all processes and tools. All their proponents claim you *have* to follow the process, no matter what. If Agile fails for you, then it is because you are not following the process!

The Manifesto for Agile Software Development tells us that we should value ”Individuals and interactions over processes and tools”.  How is it that the Agile community has accepted the rigorous following of strict processes? I think it is because there is a market for selling processes. And those in the game of selling processes won’t tell you that sometimes the process just doesn’t work. The same way Toyota won’t tell you that sometimes their cars unintentionally accelerate and can kill you.

The real secret is that it’s the people that matter, not the process! Process is good. Formalizing development methods is good. But if you have the wrong people you will fail, no matter what process you use. Conversely, if you have the right people it doesn’t really matter what process you follow. You will most likely succeed.

It is time we stopped selling processes as the magic bullet. Agile is great, and methodologies like Scrum, TDD and XP can be good facilitators for getting from concept to release. But they do not solve the fundamental problem that   a bad team fails no matter what process it uses.

Programming is a human activity, as described in the classic book ‘The Psychology of Computer Programming” by Gerald Weinberg. Therefore the human and psychological aspect needs to be considered when forming a team.

The fact is: Some people don’t work well together no matter how well their skill sets match. Some people are useless within certain processes. And there are also people in the programming field that could be of more use doing something completely different.

We should strive to create the perfect team, not the perfect process.

Having been one of the original members of the team and one of the founders, I felt the urge to tell the story of the making of Darkfall.

This my personal account, but I have tried to tell the story as accurately as possible. There are enough details to fill a book, so I have selected the parts that are important to me in order to fit this into a readable post.

Click here to read ‘The making of Darkfall – One developers perspective’

I recently released a small XNA-based game together with my friends at Badgerpunch Games, and have been following the indie game development community through forums and twitter. Game developers are very concerned about performance, mostly for good reason. No one wants a game with choppy framerate. Because of all this worrying about performance, there is an array of optimization tips and articles that get passed around to alleviate the problem. The majority of the tips and articles are informative and useful, but hardly any of these articles touch on the main issue of optimization: When not to optimize and why not.

The thing about optimization is that you almost always can optimize code, but time-spent vs pay-off quickly goes bad. I remember when I was active in the Amiga Demo scene back in the early nineties. I had this 3D rotation assembly routine that I spent probably half a year optimizing. It ended up being about as optimized as was possible. The first few weeks I was cutting away at cpu cycles at a fantastic rate! The last couple of months I didn’t really save any cycles, and in the end I gave up.. My routine was super-fast, but still, other coders had 3D graphics that were faster, and I couldn’t understand how that was possible.

I found out how it was possible a few years later when learning about matrices in college. My routine with 9 multiplications per 3D point was an unoptimized matrix, and could be shortened to 6 multiplications  and two adds, saving hundreds of cycles per point.. man that pissed me off!

The moral of that story? You can optimize your code till it shines like a star, but if someone else has a better algorithm that does the same job faster, then you still lose.

Or do you lose? Only if it matters. In the story of optimizing performance of 3d-rotation on a limited 16-bit machine, where the fastest routine makes the most leet programmer,  then it matters a lot.

Which brings us back to the beginning. Don’t optimize – if it doesn’t matter. The important thing is keeping your code simple, easy to read and easy to change! When your code has these three properties it doesn’t matter that it isn’t optimized.

If the code is too slow, pick up a profiler and find out where you should optimize. Sometimes you don’t need a profiler, but you *always* need to base optimization on real data. When you identify the problem areas, you fix them in the simplest way possible, and see what effect it has. Eventually you should get to the point that the code does what it should with acceptable performance. And if it doesn’t, you might need to change the algorithm you based your code on. That is one reason to keep code simple and easy to change.

The main reason to keep the code simple, easy to read and easy to change is that finding bugs is an act of reading and changing the code. The easier it is to read, the easier it is to fix. It’s a no-brainer.. and still people insist on making things as complicated as possible just to stroke their own egos! I once saw a piece of Java code with  recursive multi-layered inline if-statements. One of the worst examples of unintended code-mangling. And of course full of bugs… almost made me cry.

Another reason to keep code simple is to inform the compiler in the simplest way what your intent is. A complier will have a better chance at optimizing simple code. And if you are running under a virtual machine with a JIT compiler, it is ever more important. With virtual machines and on-the-fly compilation then your code might run on a plethora of different versions of the VM. Most likely the newer the VM and the simpler your code is, the better chance that it will be optimized when run.

The early Java Virtual Machine versions did little compiling and no optimization, so things like backwards-counting for-loops were early tricks to save a few cycles. But the latest versions compile and optimize on the fly, and they optimize the most common for-loop variations. If you mangled your for-loop to get it running a few cycles faster in an early VM, your code might actually run slower today than a more common for-loop variant. Performance is a moving target on Virtual Machines, and code trickery might not pay off in the long run.

It all boils down to this: Don’t optimize until you know what to optimize. This does not mean you shouldn’t be thinking of performance. You should always have performance as a consideration. It should be a concern when choosing algorithms, designing and implementing, but your main focus should be keeping the code simple, easy to read, and easy to change.

I was involved from the very beginning, in 1999 when we were a bunch of young inexperienced guys with a a dream of making “the best game evah” ™. We started a company here in Norway in 2000, moved to Greece in 2003 and released Darkfall, a badass full-loot player versus player  mmo, on the 25th of February 2009. That pretty much amounts to 10 years making one single game.

I moved back to Norway when Darkfall was released, and continued working remotely for the company until September 2009 when I took a job as a IT Consultant, working mainly with insurance companies.

That was quite a career change! Or was it? Well, yes and no.. I am basically doing the same technical job (solving problems and programming) and am working with great people, but I am working less and being payed more. I love computer games, but my passion for programming is what counts. As an IT consultant I suddenly had a completely different set of problems to solve, using new set of libraries and tools, in a very different domain.

Coming from a game developer background I had a lot to learn, and the last year or so has been a great challenge in that respect. I also got to see the way the Dark side does things. Dark as in enterprisey, and enterprisey as in lets-use-this-overrated-bloated-library-to-solve-this-insignificant-problem-as-difficult-as-possible. The game developer attitude of lets-just-get-this-shit-working-don’t-look-at-the-spaghetti-code attitude doesn’t work that great either. I am exaggerating of course, but there are clear differences in attitude between these two camps, and coming from one to the other is a good way to evolve as a programmer. Being able to see the differences I am also aware of how both could become better by embracing some of the “methods” of each other.

The game company I helped build and worked for already has most of the traits it needs, and from what I have heard is continually improving after I left. A game company is agile by default, as a necessity. There is no known way yet to completely pre-design a game and then just start developing it without significant changes to gameplay and/or concept. Darkfall went through many changes from the original idea to the end result. Most of the changes were small things, and the main concept was kept throughout, but still, it meant the game design was a moving target, and we had to factor that into the implementation. The project started with no version control, no proper backup mechanisms, no test-servers or testers, but as the company evolved, all of these points were solved.  Now the team even runs Scrum sprints, embracing the true agile spirit!

Coming to an insurance company as a consultant, I was worried that everything would be designed top-down, full of bloated frameworks, and old enterprisey code, and I would be sifting through megabytes of xml to find the actual problem whenever anything bad happened. This is probably true for a lot of old insurance companies, but didn’t hold quite true for me. It turned out that while bloated Java web-frameworks were there and some people still adhered to omg-we-need-a-framework-for-this solutions, there are forces working to simplify things, cut the bloat and make things more agile. I am lucky to be working closely with some of those people, learning the domain and hopefully contributing a little too. Recently we introduced distributed version control and converted a bunch of projects, and started using the Play Framework too, which is great!

All in all, my experience in switching from game developer to IT consultant has been a pleasant one, and it gives me more time with the family too! Well, except for the fact that I am now making casual games in the evenings, under the banner of BadgerPunch Games.

Maven does a good job of including all the transitive dependencies, but sometimes it resolves itself in such a way that Maven selects an older version of a library when given the choice between two different versions of the same library. This is extremely annoying when the older version contains bugs or lacks features that it’s dependent library needs.

A good colleague of mine, Morten Kjetland, has created an excellent Maven plugin called ‘deptools‘ that solves this issue by raising a compile error if it detects that an older transient dependency has been chosen instead of the newer version.

Deptools has saved us from a lot of head-scratching and frustration, and could potentially do the same for you, so head on over to the GitHub deptools repository and download it. It is open source and written in Scala, but works as any other plugin for Maven 2 or 3.

Colosseum was the most impressive building. Even today in its broken-down state, it still is incredibly impressive. I would love to be able to take a 3d-tour of the place as it was when it was built. A good second best will be watching The Gladiator again soon!

Saturday and Sunday consisted of highly concentrated sight-seeing. And then on Sunday evening a visit to Ristorante Mirabelle, a restaurant that carries a Michelin star. The food and wine was fantastic, and the view was to die for.

I had a walk around some of the small and atmospheric streets of Rome on Monday before catching the plane back to Bergen.

All in all a great trip! I will definitely be going back to Rome.

Here are some pictures of Rome, and a picture taken while flying over the alps (taken with a HTC Hero cellphone camera, so not great quality):

The so-called "wedding cake" building.

Obelisk at Piazza Navona

Piazza Navona

Flying over the alps

• Emergent Design — Neal Ford
• How we blew our shot at beating Spotify, spending two metric truckloads of cash doing it — Espen Dalløkken
• It Is Possible to Do Object-Oriented Programming in Java — Kevlin Henney
• Leveraging Open Source – Everything You Wanted to Know About Open Source that Nobody Told You (including getting paid to do it) — Jeff Genender
• Hacking Your Brain for Fun and Profit — Nathaniel Schutta

As you can see, most of these talks don’t have much to do with Java, but they were all great and might make me a better developer if I take just a bit of the wisdom to heart.

I was particularly impressed with the professional execution of the conference. Just about everything went smooth as could be (well, wifi at conferences is always a nightmare). Dinner and lunch was served to two thousand attendees with no more than a few minutes waiting once you queued up!

All in all a great conference! I am already looking forward to JavaZone 2011.

PS! If any of the above talks sound interesting, all the talks have been made available as videoes linked from the Javazone main page.

PPS! Here is the JavaZone 2010 music video:

I remember reading articles about tools and methodologies to improve code quality back in 2006-2007. These articles included Martin Fowlers seminal article on Continuous Integration (CI), and I ended up installing Cruise Control and linking it up to my Subversion repository on a Linux box. It was a pain to setup, but it was great watching Cruise Control retrieve my code from Subversion and build it. I also set up Trac and had full source browsing and task tracking for my home projects.

The tool I learnt the most from was FindBugs, a static code analysis tool. It analyses compiled Java classes looking for patterns of bad programming and potential problems. I ran it on my projects at home and was pretty surprised with the results. While the FindBugs report does give you some false positives, it did find some potential flaws in my small projects.

The only problem was that I never had much time for my personal projects, and the fun of watching a build compile without errors or running FindBugs only lasts a little while.

I helped my company start using Trac, and we setup our own continuous integration build system. We would run FindBugs on our pretty large project now and again and find critical bugs long before they got us into serious trouble. These tools saved us a lot of problems.

By: TiareScott http://www.flickr.com/people/tiarescott/

Fast forward to 2009, and I am at a new company that also has Trac, Subversion, and a Continuous Integration server (Hudson). I had a look at the Hudson server, but based on my past experience, I didn’t see what a Continuous Integration server would do that I wasn’t already doing myself. I was doing a full Maven package before committing and deploying, and I was alone on my project, so build breaking wasn’t much of an issue.

A few weeks ago everything changed. One of the other developers installed the Continous Integration Game Plugin for Hudson that puts up a leader board link on the main Hudson page. This plugin scores your commits based on how good your code is, how much test-coverage you have, how complex the code is, and many other parameters. One of the tools it uses is FindBugs, and old friend and an excellent tool.

This turned Hudson into a completely different beast, at least from my perspective. Suddenly I could compete with the other developers based on code quality merits, and at the same be improving my code! Sonar, an “open source code quality management platform”, was also integrated with Hudson, giving a detailed breakdown of the code by the same metrics as the CI Game.

Playing the CI game inspired me to start unit-testing. I had been on the fence for a while, and quite honestly been put off by all the evangelism behind Agile, Extreme Programming and Test Driven Development towards using Unit Testing as some kind of silver bullet. Having been to a TDD & Web Driver workshop session a few weeks ago I was looking for a reason to start using unit tests, and this was the perfect opportunity.

I started by setting up JUnit in Eclipse and moving some of the sanity tests I already had into unit tests. I ran them locally through maven, and committed them. A few minutes later Hudson had detected a code-change in Subversion and built and ran the tests, and increased my score on the leader board. In a couple of days I went from 0% test coverage to 30% test coverage. At the same time I was fixing problems found by FindBugs and other plugins, and saw the code quality metrics climb steadily. It is actually a great feeling!

From a management perspective Hudson and Sonar can be a bonus or a scary peek into a bad code base, depending on management and of course depending on the quality of the code. But the good thing is that you can easily see where there is potential for improvement, and when things do improve it will make both developers and management happy!

So, if you want to motivate developers to improve their code quality, and make them feel better about it at the same time, the Continuous Integration Game combined with Sonar can be a very good motivator. If you get management on board then you have an extra reason to spend time on code quality issues.

Go play the code quality game!

I’ve had a long pause in writing anything in this blog. Mostly due to laziness, but other contributing factors have been Getting Darkfall Released, followed by Moving Back To Norway, and last but in no way least: Becoming a Dad for The Second Time. That’s a time-consuming trilogy.

Well, all that has happened, and now I am back. I fixed my website (yay WordPress!), and I am going to be writing bits and pieces here again. At some point soon I am also hoping to put my experiences in the making of Darkfall into a post. When I do, it will be posted here.

Anyway, until the next post:

Have fun and code hard!