(…continued from part 1)

First off, this implication that number of hours you work has absolutely zero relation to the level of talent you possess. I’ve worked with talentless hacks that “worked” 60-80 hour weeks and still achieved less than everyone else. I’ve worked with amazing people who worked bang on 9-5 Monday to Friday and were some of the most able and committed developers. Of course there are extreme cases – talented folks who love their job so much and are willing and eager to work extra hours, just as there are people who are so apathetic about their work that they don’t even want to do their contracted hours, and coast at every opportunity. Talent and the number of hours worked are independent variables. To try to connect them is not only foolish, it’s selling your employees short.

The coasters need to be sacked, plain and simple. Those who work extra hours but aren’t very good should be given the chance and help to improve, but if they can’t they need to go too. Those who work the 40 hour week and produce are the core of your business, and need to be treated like the stars they are: not only are they good at producing, they are sensible enough to do it in a sustainable way. Those who are great and want to work all hours can be gems, but only if they are managed properly. Try to keep them to a sensible working week, and they’ll stay gems for longer; if you don’t they’ll last a while, and then burn out.

Burning out

We’ve all seen it, many times. Constrain their hours and they’ll find other ways to excel; they’ll cram the same amount of work into the time they have, or they’ll go away and enjoy their evenings, eager to come back in the morning, brimming over with good ideas that they’ve been thinking up while they were away from work. But most importantly they’ll have had a life outside of the work, and that will make them happier with their lives and happier with their jobs. If you let them work those crazy hours, you are both taking advantage of their generosity, and setting an unreasonable precedent that other individuals on the team should be doing the same. No matter how much you tell your employees that 9 to 5 is fine, they’ll look at the long hours those few are putting in, and feel that by not doing those hours they aren’t pulling their weight.

Most of all I detest the idea that making games is special, and that somehow by getting to make games we forfeit some of our rights because we get to do work that we enjoy. Screw that. I make games for a living because I love it. I’ve already sacrificed the higher salary I could get in the regular software world. I’ve sacrificed the stability you get outside the games industry. Now you’re trying to tell me I should sacrifice my quality of life as well? And to top it all off, I should be thankful to those who pay my salary for the priviledge of doing my job? No thank you.

When I’m making games, I’m doing a job. I deserve to be paid for the job I do. You want me to sacrifice quality of life, you pay me for the priviledge. My love for what I do comes out in the quality of the products I make, and that’s the only outlet there should be for it. Making games needs passion because the games themselves need love to make them good. By asking for ridiculous working hours or low wages, you are asking me to be less passionate about my job because to do it I need to accept being screwed on pay and conditions.

I’m not some idealistic student, I know that it’s not as simple as just clicking your fingers and suddenly we’re all working standard hours for good wages. The business needs are always going to come first. Sometimes the deadline will loom, or things will go wrong, and we’ll have to work long hours to put it right. We are dedicated people, and exceptional circumstances require exceptional measures. But right now, the individuals working in games development are being regularly asked to subsidise their employer’s costs by means of their own time and effort. Worse than that, many of those employers think this is fine and right and just the way things are. Wrong. The sooner we accept that abusing our staff is unprofitable in the long term the better off we will be as businesses. The sooner we accept that the 40 hour working week is the norm, and everything we do should be trying to get us closer to that norm, the better off we will be.

And so the perennial topic of working hours comes back to us again, this time as a result of some spirited discussion from the IGDA. The exact nature of the discussion has been covered well elsewhere, but suffice to say that an IGDA board member (Mike Capps of Epic) has been lambasted by the game developer community in general for his statement that Epic doesn’t want to hire the sort of people who just work 40-hour weeks.

 

Slaves to the Grind

There are two parts to this issue really, the first fairly obviously is the problems that this has raised in the IGDA itself. Rather than take what seems to me the obvious route (make a public statement that Epic, while being free to run their studio any way they see fit, is choosing to operate in a way at odds with the IGDA’s stand on quality of life for developers), when pushed on the matter, the rest of the IGDA board has essentially folded, almost entirely on their QoL position.

Now for an organisation that has put QoL very high up on its list of priorities, this is a real problem. The developer community (or at least, that part of it that I hear from and talk to) has always struggled to see the value in an IGDA membership; it doesn’t provide much in the way of tangible benefits, and the social and networking aspect varies massively based on the activity of the local chapter in your area. Certainly the IGDA doesn’t provide anything like the benefits that a union would, as it’s specifically written into its constitution that it cannot become a union or anything like one. But the IGDA’s advocation on quality of life issues has always been one of the big pluses for it in my book – it occupied a niche in that it is placed to represent the best interests of its member developers in campaigning for a better industry for us all. To take away that advocacy position seems to me removes the biggest reason to support or recommend membership to others.

The furore surrounding both the original statement by Mike Capps, and the subsequent IGDA refusal to condemn his stance on general principle is what confounds me though. There is no reason why individual members of the IGDA, even board members, have to work for studios that slavishly follow ever policy that the IGDA might recommend. And with that in mind, it’s perfectly acceptable for Mike Capps to remain a board member, even when his employer’s position conflicts with the recommendations of the IGDA. The next time the elections come around, the IGDA membership will think long and hard about whether or not it’s a good thing to have a board member whose personal policies conflict with such a high profile policy of the organisation. Great. That’s democracy in action.

No, what bothers me is that the other IGDA board members have steadfastly reversed their own organisations positions rather than criticise another board member. They even seem to have gone so far as to implicitely defend Epic’s policy. What, exactly, is the point of saying “all studios should aim for a 40 hour week, because it’s better for everyone involved”, if you then follow it up by saying “oh, unless you’re an IGDA member already; in that case you can run your studio however you like, and I’m sure Epic have a good reason for preferring a longer work week, they do seem to be quite successful and all.” The whole discussion on the IGDA forums has been flabbergastingly forthright in its defence of the over-working of individuals in games development.

The board members, and other senior figures in the IGDA, all seem to be quite surprised at the vehemence with which they’re being attacked. They don’t seem to see their own stance as hypocritical, but attempts to get them to justify their position have resulted in only anger and latterly heavy-handed moderation to quell the continuing argument on their own forums. More recently they have come out with public statements to clarify their position, and to attempt to re-assert their original position on QoL issues, but it all smacks of too-little-too-late unfortunately. The board’s own defence (both implicit and explicit) of Epic’s practices have in my opinion exposed their stance on QoL as nothing more than lip-service towards the ideal, despite the obvious importance the issue has with their (non-management) membership. If that membership hasn’t already voted with their feet and left by the next elections, I hope they show their dissapproval and vote out the incumbent board members in favour of some who actually believe in the policies the IGDA publicly endorse.

All that said, I’m not an IGDA member, and with all of this, I have no intention of becoming one now. No, what worries more is the attitude shown originally by Mike Capps, and latterly people on the IGDA forums. That somehow a person who only wants to work a 40-hour week is just a jobsworth, there marking time and collecting a pay-cheque but with no real passion or involvement with the work they do. That somehow the number of hours you work is linked to your talent. That somehow the fact that the job is making games makes it special, and exempt from all of the normal moral implications of taking advantage of your staff. 

(continued in part 2…)

We were having a discussion this morning about the perils of building your business around a popular tool that you’ve made, and I thought it might make a good blog post. Really this is inspired by the impending upgrade I’m going to need to do to SmartSVN 6, despite having only just bought a SmartSVN 5 licence. It’s a nice package, especially the diff tool. And there are times when you really do want to navigate the changed files in a large tree of directories, and TortoiseSVN and the command line shell really suck at that.

My problem comes in that pretty much all of the functionality I needed from the tool has been present since version 3. Sure some of the new features are nice, and the overall application is prettier now. But mostly what has come in subsequent versions has been for me superfluous bloat. It means the installer is bigger, it means the application is slower to respond, and more complex to navigate the interface. And really what I actually would most value is if I had pretty much the exact same set of features, but a) bugs were squashed and no new ones added, b) the support for the underlying system (in this case Subversion) had been kept up to date, and maybe c) the interface was improved and streamlined.

It’s not just SmartSVN though, it’s lots of applications. GetRight, ACDSee, Word/Excel/Office, all of which have gone through many revisions, each one adding more and more features that I don’t really need or appreciate. In the case of ACDSee the later versions actually made the interface worse, which effectively removed the one feature that people bought it for – the quick and easy way to mouse-scroll through whole directories of images.

The problem here is that what the end users want is fundamentally at odds with what the business needs to do. The end user would be quite happy having the same application and just keep using it forever. But for the business that authors the application, that’s a losing proposition. They’ve made one sale, and they get no more. What they really want is to be able to sell more things to the same user. If they make a new version of the tool, they can put enough new features in to persuade the user that it’s actually a new application. The user isn’t an idiot though. They know it’s not a whole new application. Maybe they need or would like some of those new features, maybe not.

Most likely they’re buying the new version because it fixes bugs in the old version, and is better supported. I’d even go so far as to say that they’d be willing to pay for those bug-fix and maintenance updates – not as much as they’d pay for a whole new version, but something at least. Some companies, like Whole Tomato (who make Visual Assist) have a refreshingly straight-forward approach to this: you buy the application, and you get X months of updates along with it. After X months, you have to pay again a smaller amount to keep getting updates.

Even Whole Tomato though are guilty of the most annoying of the application developer’s sins (from an end user’s point of view at least) – feature creep. Every development has a Request For Enhancement list which is used as a back-log of items that might make their way into the application at some point. Anything reasonable the end users request goes on that list. And because the developer is a business, that makes its money from cranking out new versions of the application, they work through that list, pretty much endlessly. So an application which is clean, usable and decently featured in version 3 can turn into a Swiss-Army-Knife of an application by version 8; bristling with functions, features and options, which the majority of users, other that one user who requested it originally may never touch.

It seems that very rarely is the decision taken to just draw a line in the backlog and say “it’s good now, let’s just stop adding features”. Keep selling it, keep maintaining it, putting out bug-fix and maintenance upgrades, but no more features. What, I ask, is wrong with making compact applications with specific and targetted functions? Even if there are valuable features to be added, why not ask if there is value in maintaining a Core and a Premium version of the application? Or even multiple Premium versions? Find your users and target the groups who want to buy your product. Give them each their own version. Discontinue versions that don’t sell well, and maintain versions which have.

A well architected software development can maintain development on multiple branches simultaneously with not too much extra effort, certainly there is a cost but I believe there is also a reward. Give your users exactly what they need and no more, and you avoid becoming the behemoth application that is under-cut by a spunky fresh new competitor, that didn’t have all of your features but had “just enough” to be valuable, was cheap enough to develop to undercut you on price, and flexible enough due to its small size to adapt quicker and better to changing technology than you did.

Some discussion on the Chaos Engine about code reviews and check-in process had inspired me to write up a post on my thoughts on this, but on my morning trawl through my RSS feeds this morning it looks like Lee Winder has beaten me to the punch. He pretty much covers all of my thoughts on the matter, and I don’t think I disagree with any of his opinions, so hey, job done. 🙂

In summary if you don’t want to follow the link though, I’d say code reviews are a good thing, especially as teams scale and there are differing levels of skill and familiarity with the code-base. They get everyone on the same page about what is being written and how it is being built. Pretty much all of the criticisms levelled at the process are from people who have had bad experiences due to issues completely outside the scope of the process. If your code review was useless because the reviewer was being a) petulant and petty, b) disinterested, or c) unable to comprehend the issues involved; then the issue is with your team ethos and make-up, not with the review process.

I want to write up my thoughts on the ongoing IGDA debacle, but suffice it to say for now that any interest I had in re-kindling the Scottish chapter have been well and truly snuffed out.

So it seems that aside from just the usual wildlife inside the office (i.e. the ubiquitous Edinburgh mice), we have some visitors from outside as well.

Isn’t that one chubby squirrel? Tim reckons that he just does the rounds of all the windows nearby, and lives off the generosity of the locals who like cute squirrels. He certainly doesn’t seem afraid of us…