Opinion: My Producer Hates Me

Author: by Byron-Atkinson-Jones

[Xiotex Studios programmer Byron-Atkinson-Jones talks about how and why project scheduling problems can arise between coders and producers, in this #altdevblogaday-reprinted opinion piece.] My producer hates me. No, it's true. He hates me because I am the only coder on the current project I am on, and he has to ask me every now and then how long something will take and I invariably can't answer him. It's not as if I am a new coder; I've been coding commercially for something like 15 years, so what gives? I went to university to study Software Engineering, but I had actually been coding since the age of 12 (I'm now rapidly approaching 40) when I had the amazing Sinclair ZX81. Okay, the code was nothing like it is now, but the point is that I am mostly a self-taught coder, and most of the time coding for me is just like driving a car -- I can do it without having to deeply think about it. I just get into the zone and out of the other side pop's code. This doesn't mean I don't plan code; on the contrary, I have sketchbooks full of designs for systems, but they are not formal designs in the sense of UML, Z, Yourdon or SSADM. They are more diaries. The upshot is that I don't think of code in terms of systems, but rather I visualize what the end result looks like and start pumping out code until that end target is reached. Along the way I will create or reuse systems to help achieve that visualization, but I discover I need that along the road rather than pre-plan them. The closest analogy I can think of is when novelists say that the books almost write themselves. I'm not going to claim that my approach to coding is great; in fact, when I look over old code, I ask what the hell I was thinking of, but with time, experience gets better and better as do my coding skills. And I practice hard. I code all the time. I just love making games. It also causes issues at interviews when one interviewer called my attitude to coding "cavalier". I'm sure a lot of you will find my approach totally alien and possibly negative, and I'm not advocating it, simply saying that this is how I do it. However, getting back to my producer and how he hates me. The issue here is that because of my free-running approach to coding, I don't know how long it's going to take because there is no definite plan. I prefer to list a set of features (the visualization), and then set a defined target date when those features have to be complete. I then do whatever is necessary to hit that target. With experience not only came a more refined level of coding but also a back-catalogue of writing the same kind of code, so when I set target dates these days they are usually correct. If they are wrong, then I have learned another lesson and the next time I am in a similar situation I can be closer to the right answer. Am I Alone? Even though my approach doesn't lend itself to being able to specify how long a certain bit of code will take, I don't think that for some developers the situation is any different. Cliff Harris of Positech games once wrote this in a blog post: "When a coder tells you they don't know how long something will take they are not being obtuse, they really don't know." There was also a conversation I heard when the coder told his lead coder: "Just pick a random number because that's all I'll be doing." It would be interesting to one day do some kind of survey just to see how comfortable developers are about providing timescales. What About The Poor Producers And Project Managers Out There? In a fit of drunken madness, my boss once made me the producer of the company's main project. So, I've had the opportunity to see games from the dark side, and I can tell you they have it pretty tough too. In fact, in an ironic way, they get asked exactly the same question as they ask us but on a higher level. They can only answer their question by asking us questions, and if we say we don't know, what are they to do? What was really interesting in my time as a producer were the various reasons why I could not be given a time scale, some of which I used to give to my producer when he asked me. I was in a meeting recently with three levels of authority present, with mine being the lowest. When the topmost were presented with the reality that game development is a hit and miss affair and we can't accurately schedule everything, their response was that that kind of answer doesn't help them plan a marketing strategy. It's a stark reality that while as a developer I may prefer to live in my own bubble of code, I am in fact a part of a wider business plan. It's easy to lose sight of the fact that while I may enjoy making games, it is in the end a business and it's my job, not a hobby I am indulging in. Okay, It's Bleak, But What Can We Do About It? I can't even pretend to have all the answers to this or in fact that my solutions will apply in all cases. The creative nature of games means that as developers we are under a whole different set of stresses than a pure business led application. We are prone to subjective criticism that can have far reaching effects on the game and it's development. If somebody in power plays the game and comes to the conclusion that it's not "fun", then that usually bubbles down to us workers on the front-line in the form of a command like "change the game to make it fun", which in turn has an impact on the schedule. Except, it can't because the end-date is an immovable object. Catch-22. My personal opinion is to accept that, for the most part, attempting to schedule a game down to the smallest details is not likely to be a scientific process but an exercise in compromise. If you are going to approach individuals and try to elicit details from them, then approach them in a manner that is suitable for them. I was speaking to a fellow developer from my days at Lionhead studios, Phillip Hounslow, about just this issue and this was his take on it: "Personally, I want my producer to listen and to believe in me as a senior programmer that my time estimates are as accurate as I make them. If they aren't what he wants to hear that's a different matter, but they are a point of negotiation, not a fact." The comment about "if they aren't what he wants to hear" is a common one, and it's one that leads to unrealistic schedules. We've already covered that the producers and project managers have to report to their superiors about the schedule, but what happens if a coder gives an amount of time that the producer doesn't like? I've heard responses like "we can't do that" or "we need to squeeze that down", and rather than actually try to deal with the issue, often the developer is pressured through guilt to give a value that is more palatable. I've seen instances where developers often drop their estimates by as much as 50 percent or greater. This pleases the interrogator, but is it really an accurate estimation or a good way to go about getting an accurate estimation? To make matters worse, some developers will start by routine to give time values that they think the producer wants to hear. The Practical Bit I was serious above when I said I couldn't even pretend to have the answers to all these issues; I can only present how I cope. Ultimately it's up to you to find your own path and way of working. If you can, adapt to how your team works since that will be the path of least resistance. Having said that, I'm a great believer in being who you are, being truthful in what you say and do, and above all be confident in that role. The moment I start to doubt myself, I find myself failing at what I do, panic sets in, and then I am no good to anyone. The point is that I have to be confident enough to present a workable solution to the schedule that the producer can understand, and if they can't understand, then it's my job to pitch that solution to them because ultimately the alternative is to work ineffectively. I feel uncomfortable supplying what I feel are inaccurate timescales, and when forced to break them down to fine-grained atomic tasks I always end up giving very pessimistic values. If the producer is aware of this, then they may be more inclined to work with me rather than try and force me into another model of working. I am not trying to suggest this should be a one-way street; there has to be a measure of compromise on both sides. While I am educating them on how I work, I am also learning how they need facts presented, and if along the way I learn how to break down my high-level view into atomic tasks with timescales, then all the better. Strategies All this is very idealistic, and the reality you are in may be that you don't have the luxury of being able to mould the way you present schedules. In this case, you have to cope the best way you can. These are some strategies I use in these situations If you get surprised with an estimate for a task that you haven't seen before, then you can either give it your best guess or simply say that you need time to think about it. If that fails and they insist you give them a number, then do what I do and point out that the number I am about to give is going to be a pessimistic worst case guess and can in no way be regarded as a realistic value. And if having heard that they are happy to continue then at the end of the day it's on their head. I usually go back with realistic value once I have given it some thought. Monitor your progress throughout the task. Look at where you are and try to assess how close you think you are to the end. If it looks like you aren't going to make it, then communicate this fact as early as you can. Even though this information may not be well received, getting it in early means that something could be planned to help rather than blundering into the end and admitting that it's not ready. Fight the temptation to be the hero and give values that you think management wants to hear. Ultimately, this will just end up with you being the enemy for having broken the schedule, or at worst you end up pulling stupid hours to try and compensate. When you are considering a task, what in reality are you thinking about? Are you thinking about in terms of it being 100 percent complete, integrated, and tested? Or are you just thinking in terms of the task in isolation? his may not be important, but it's one aspect that inexperienced developers often fall foul of and producers fail to properly specify: the task may not be just be about building a discrete system; it may also include the time it takes to get it fully integrated into the game. This one used to catch me out all the time. Learn from those around you. I learned all I know from reading as much as I can and picking the brains of everybody around me. In that sense, I have an insatiable thirst for knowledge, but because of that, I also believe that I should be sharing what I learned. The more we share the better we get at this. Whenever I find somebody particularly good at scheduling, I grill him or her for as much information as I can. Finally I can't get away with talking about schedules without at least looking at the issue of crunch. I'm not going to lie, my particular way of working does lead me to having to do crunch, but that's my choice. As I get better and better at predicting how long I will take on a task, it happens less and less, but the things I can't predict are clients pulling deadlines forward or something in the design changes. Those are facts of life, stuff happens. You could build contingency space into the schedule, but how much space do you allow? I've tried to get those managing projects I am on to build in redundancy, but it's a hard sell. Their reasoning is that instead of it actually being a buffer, the work will just naturally spread into it. I have heard of some places that claim to have eliminated crunch, and even better than that, I have been in interviews where they go over the top to extol the virtues of their studio and that they don't do it, only to accept the job and within a week of being there find myself having to do crunch to cope with a task who's fate was decided long before I joined the company. I am sure that there are places that genuinely don't do crunch, and I would love to hear how they do it. How do they cope with change? Do they build it into the schedule to begin with? Unless you get some kind of pleasure from crunch (it does happen), then it's in your best interest to try and avoid it, and to do that we need to schedule better. Good luck. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]