All Those Bugs…

This is a game about managing a software company from 1980 to today. You can acquire projects, hire developers and have them work on the projects. You’ll have to work with computers of that time, like the Apple II or Atari machines (400 & 800). Developers have different skills and that forces the player to move developers to the projects that are best suited for them. Projects consist of different tasks that have to be finished before the project is considered to be “done” and can be delivered to the customer, who will pay you and enable you to hire more developers to work on more complex projects. Developers learn while they work on projects, so you can “develop developers”. Like in real software projects, bugs are created during the development. You are responsible to find those bugs (“Testing”) and of course to fix them (“Bug Fixing”).

New projects will appear during the game, as well as new developers.

That is more or less the content of the current version of the game. In a future post I will show the list of tasks that I have in mind for additions to the game. (Lots of ideas…)

So this is a blog about developing software demonstrated with a game that is about developing software…

This is not a full-fledged game (and probably will never be). It is actually meant as a “design study” for WPF/MVVM applications. Therefore the concepts presented are not “how you should do it” concepts but more different approaches to common MVVM problems.

You can download the current version of the game (without sources at the moment) via this link: ATB Download

The ZIP file also contains a quick start guide to get you up & running. Simply unzip the file and double click the ATB.EXE file. No installation is necessary (yet).

Note: at the moment the game stops on January 1st 1983; up to this date new computer models will appear frequently. The more computer models are entered the later the game will end in future versions.

The most important aspects of software development to me are simplicity, readability and therefore maintainability and extensibility. That’s one of the major reasons why I’m not using any additional libraries, like PRISM etc. – they can help in some situations where you need maximum flexibility but they tend to make the sources harder to read and more difficult to understand and in most cases you will only need one or two classes from those libraries; if sources are hard to read, you will discover that the more the project advances, the longer it takes to implement things and the more bugs you get. (Keep that in mind when you decide to use additional libraries.)

And therefore I also rarely use LINQ. It’s not that I don’t like it, but LINQ statements tend to grow into horrible and unreadable (and unmaintainable) creatures. (With same problems as above…) LINQ is perfect for simple queries, but I’m normally using ordinary loops instead, when things get complex. That takes a little longer to write but it’s a lot easier to read (remember? Most of the code we write once and read often…). Funny side note: Just because loops consist of more lines than a “compressed” LINQ statement, that doesn’t mean that it takes longer to understand them – just the opposite is the case. The more functionality you press into a single line, the more time it will take to understand it a couple of months later (or for other developers).