Monthly Archives: October 2013

OnRef – The Mythical Man-Month

One of the first books I was ever recommended in my first job was Frederick P Brooks’ The Mythical Man-Month. In this book, the former development manager for IBM’s System/360 mainframe, offers a series of essays on software development.

Though some of the technology and processes in these essays may seem odd to modern developers – dating between 1975 & 1995 as they do – many of their concepts are still insightful and refreshing. Indeed, as my understanding and experience of software development grows, it is a book I find myself returning to again and again.

Good cooking takes time. If you are made to wait, it is to serve you better, and to please you.

– Menu of Restaurant Antoine, New Orleans

More software projects have gone awry for lack of calendar time than for all other causes combined. Why is this cause of disaster so common?

First our techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well.

Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.

Third, because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoine’s chef.

Fourth, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.

Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.

– Frederick P Brooks, Jr. The Mythical Man-Month

Read more about Fred Brooks here.

OnRef – 21 Rules of Thumb

I really cannot recommend this blog post, 21 Rules of Thumb – How Microsoft develops its Software by David Gristwood more highly. It republishes Jim McCarthy’s original article encompassing 21 simple concepts on shipping great software on time.

We’ll be revisiting some of these rules from time to time in relation to various subjects but, in the meantime, if you want more from Jim McCarthy then he has a couple of books too:


So two interesting things just happened:

1) A games company decided to advertise exactly how much crunch one of their current projects required before release.

2) With the wall of silence truly blown, a stream of public condemnation then followed on Twitter under the #RyseFacts tag.

Why these are interesting I’ll reflect on in another post but follow the story on Twitter & Gamasutra.


I find it increasingly hard to play games these days. The problem is that I know too much, I’ve seen behind the curtain. I spend so much time thinking about how the game was put together, which bits I like and which bits I don’t. The bits that are good present me with no problems – I just want to lap them up. It’s the bits that are bad that I find the problem – I can’t change them.

I’ve got so used to the cycle of daily play testing and iteration in my work that when I come across a game in my spare time, where there is frustration or over-complication in the design, I just have an involuntary reaction to design out the problem in my head and then I want to go and fix it… only most of the time I can’t.

It didn’t used to be this way. Games on PC were either pretty easy to modify or in the best cases had specific tools released by the developer in order to gain access to their systems. The art peaked in the late 90’s with the Quake, Unreal and Neverwinter Nights engined games being almost totally configurable into new and exciting flavours far beyond the imaginations of the original designers & implementers.

To a large extent those tools spawned the developers and games that are the most dominant in the current market place – the Call of Duties, Mass Effects & World of Warcrafts. As the profits & investments increased though, developers and publishers started to get nervous about such free access to their ever more valuable IPs and so the boxed product culture has evolved from a means of shipping media to end users to become a locked unit. An evolution inversely proportional to and as a direct consequence of the freedom with which that data could be distributed. With the best fans never being able to extend the fiction through mods or subvert it entirely with total conversions.

For many years I was all about that transformation into uber-games, I was thrilled by the shared, hifi, sofa experiences of Halo, Star Wars: Knights of the Old Republic & Call of Duty: Modern Warfare but it just doesn’t cut it for me any more. The blockbusters can never match their ambition and never will – the budgets just won’t scale. The only hope is the fanbase.

Some people never forgot that, the PC gaming hardcore who never abandoned their dat file editors and script debuggers. The Valves, Bethesdas & Mojangs of this world kept making tools for their audience and through that, communities have flourished. GTA & Saints Row might talk about their sandboxes but it is the games with dev tools that are the place where real creativity is unleashed.

I never again want to make a game where the experience starts to die on the day the last publisher funded DLC ships. The future is in the freedom of the community to evolve the experience beyond the ego of its creators. The ship date is no longer the big event, it is the inception of the idea and the tools need to be their to support it.

That means shackles need to be removed from content & code. The big question is how to tie that in with the continued integrity of a game’s service model that will support the long term life of the developers but to unite the two ideas must be the goal.

Some such efforts include community moderated, user generated content approval, revenue sharing, experimentation sandboxing & single licence, shared platform ownership exist (e.g. Microsoft XNA, Valve Greenlight) but their boundaries are often  hard and discrete.

The broader, more continuous and seamless the range of options that exist between a game’s ‘Approved’ & ‘Wild West’ states can only be a benefit to the health and vibrancy of a game’s community.

The economy of a game has to evolve from purely equating revenues to also include the health of the community through time investment. Free 2 Play game models have started to understand this and it is a trend that will surely continue. Whales are not just the people willing to spend $500 on boosts & swag but those that foster the community through forum moderating, event hosting & content creation. Which user is worth more to a game: the one that buys every map pack or the one who makes a popular community map? Maybe your game doesn’t even charge money for community maps but if one community made map becomes more popular than all your official maps put together and gets played by 5 million users, then what is the value of that to your game?

Users have to be given every opportunity to contribute to the long term life and evolution of a game through tools, community sites & distribution methods. But what if your game is released on a platform that doesn’t suit an editor? Does it really make sense to release dev tools on a console or mobile phone? Perhaps not, but that is where second screen can be such a powerful concept. It doesn’t have to be limited to fiddling around with your avatar’s loadout on the bus. It can mean play on your telly, play on your phone, develop on your PC, develop on your tablet. Transmedia is hot.


// What is OnDev?

  • A bunch of essays on subjects relating to software development.
  • A bunch of links to things that are interesting.
  • Random snippets of thoughts.

// Why is that a good idea?

  • Sharing ideas starts a conversation which can lead people to a broader understanding of aspects of a subject.
  • Questioning a subject is both good for validating a previously held position or changing that position according to new understanding.
  • A thought can spark an idea which can create a movement.