4 ms·

Once when I was working at a game publisher I thought it would be fun to help an indie game project anonymously. At that point I had designed or produced many

Once when I was working at a game publisher I thought it would be fun to help an indie game project anonymously. At that point I had designed or produced many games, but the job was going through a dull phase. So I picked out a project on sourceforge (this was a long time ago) and offered to help out. Pretty much all they were doing was recreating all the UI widgets in any OS (buttons, pull down menus, etc.). Everything was less than half done and there was a lot of work put in. I suggested maybe prototype some gameplay.. No, it was important that they start from a clean code base.

bartread 9y ago
On the one hand that's sort of mindblowing, on the other not that surprising, and reading the original article just underscores my (thankfully brief) experience of working in a large enterprise: the one thing you can absolutely trust is that when it comes to product development a senior enterprise developer or architect will always focus on the wrong problem. I find their approach to software development in general, and product development in particular, to be both asinine and perverse, and despite banging on endlessly about architecture and agile none of them seems capable of delivering even mediocre software, let alone anything you'd call good, in anything other than a geological timescale. Applying those observations to this case: they should have focussed on creating a fun game, i.e., on what users want. Instead they focussed on technical and architectural issues and built something that sounds like an impressive piece of software but which is not fun, and which doesn't feel terribly polished or playable. In other words, they failed, although at least they have the stones to admit it. This is enterprise software all over. Seriously, if you want to build good software, where "good" means 10x value adding in your domain of choice, and which users love, do NOT work in a large enterprise, and do not work with enterprise developers. These people will waste your time, hold you back, and drag you down. (All of that being said: interesting article, and a worthwhile read if only as an illustration of how not to do things, and hopefully the author really has learned something useful.)
- ryandrake 9y ago
  There is value in writing clean, impeccably-designed, beautifully architected, const-correct, lint-free software. Just not much business value in it. I have unreleased hobby projects sitting on my hard drive at home that are works of art (if I must say so myself!), and were great learning experiences, but are commercially pretty much valueless. That's OK. You need to have a goal and adapt your software writing to that goal. If your goal is to make the next Flappy Bird and pull in $100K revenue per day, you probably don't want to be spending your time figuring out why "the time between ticks increased to 20-30 ms and then it dropped again." Your time would be better spent slapping together version 0.01 of about 40 games and shipping them, hoping one of them takes off. Needing to optimize and rearchitect something is a problem you have after you get U$ER$.
  - hyperpallium 9y ago
    Businessvalue-only code can get complex though, and difficult to work with. But, maybe, when the value/intention is clear, it makes it easier to understand. (That is, until there's years of accumulated complexity).
  - a_t48 9y ago
    > you probably don't want to be spending your time figuring out why "the time between ticks increased to 20-30 ms and then it dropped again. When I was in mobile games (3D) we saw a direct correlation between framerate and revenue. We released a patch that (accidentally) slashed the frame rate and our revenue tanked. We released a patch that did nothing but fix the performance and our revenue went back up to previous amounts.
- zebraflask 9y ago
  @bartread That's an awfully high and mighty opinion, don't you think? Sounds like annoyance over the fact that things that work reliably aren't "cool" enough.
  - bartread 9y ago
    It's certainly annoyance - and a good amount of it - but cool doesn't come into it. What I'm really railing against is people who talk a good game but seem to be incapable of delivering anything but bad software (regardless of whether what it does is supposed to be "cool", whatever that might mean when taken in context), and includes unreliable. I have to admit that it may not be entirely they're fault: organisational culture shapes you whether you want it to or not. So perhaps what I'm really railing against is a culture of software development that tends to exist in larger organisations. Clearly this isn't universal though - just common. There are notable examples where very large organisations have been able to avoid these problems, at least for a while, even at scale: Google, BBC, parts of Microsoft (I can personally attest to this one), facebook (although hearing from a friend t sounds like they're getting sucked into it). I do find it frustrating that guys like this style themselves as thought-leaders - and often succeed - whilst unfailingly focussing on the wrong points, and making themselves a complete pain in the ass to everyone they work with. The other point is that as I've got older it's become starkly obvious to me that I only have so much time left. Obviously that's always been true but when I was younger I suppose I just didn't take it that seriously, and that's sort of a gentle regret. And that's really for everyone: you don't have all the time in the world so if there's something you want to do then get on and do it - sometimes you have to do things just to make ends meet but, as far as is possible, don't subject yourself to anyone who's going to hinder you on that journey.
    - louithethrid 9y ago
      Thanks for those words.
    - zebraflask 9y ago
      With that extra context, I agree. It can be quite frustrating to work with people who don't perform, or who don't understand where to focus their work.
greggman 9y ago
Just going to add my random 2¢ this is what engineers do (I'm an engineer). All they can see is the tech and ok, maybe that's that they enjoy but it really has little to do with a hit game (here come the comments ;) It's like claiming that most movies couldn't be made unless will build our own cameras from scratch. The thing is, building engines and tools is conceptually easy. It might be a lot of work but it's mostly known solutions so we (engineers like me) see a big todo list and just do it. We get in the flow. We get proud of our solutions (even though 40k new games shipped this month that some how solved the same problems). But arguably the real work is in design and design is much harder, at least for me, because it's a blank slate. I don't have to reinvent how to read joypads or stream files or serialize data. Sure I might write my own but it's arguably a waste of time. They real hard work is figuring out the game itself. Prototyping, trying out new ideas. Grab some working solutions (Unity, Unreal, or your favorite open source libraries, spend as little time as possible on tech and as much time as possible trying out ideas). Of course I write that advice and I've believed it for years but I still fall back to my engineering ways and find busywork to do like add some unit testing system or automate some other step. Meanwhile no prototypes. No games.

bartread 9y ago

On the one hand that's sort of mindblowing, on the other not that surprising, and reading the original article just underscores my (thankfully brief) experience of working in a large enterprise: the one thing you can absolutely trust is that when it comes to product development a senior enterprise developer or architect will always focus on the wrong problem. I find their approach to software development in general, and product development in particular, to be both asinine and perverse, and despite banging on endlessly about architecture and agile none of them seems capable of delivering even mediocre software, let alone anything you'd call good, in anything other than a geological timescale. Applying those observations to this case: they should have focussed on creating a fun game, i.e., on what users want. Instead they focussed on technical and architectural issues and built something that sounds like an impressive piece of software but which is not fun, and which doesn't feel terribly polished or playable. In other words, they failed, although at least they have the stones to admit it. This is enterprise software all over. Seriously, if you want to build good software, where "good" means 10x value adding in your domain of choice, and which users love, do NOT work in a large enterprise, and do not work with enterprise developers. These people will waste your time, hold you back, and drag you down. (All of that being said: interesting article, and a worthwhile read if only as an illustration of how not to do things, and hopefully the author really has learned something useful.)

ryandrake 9y ago
There is value in writing clean, impeccably-designed, beautifully architected, const-correct, lint-free software. Just not much business value in it. I have unreleased hobby projects sitting on my hard drive at home that are works of art (if I must say so myself!), and were great learning experiences, but are commercially pretty much valueless. That's OK. You need to have a goal and adapt your software writing to that goal. If your goal is to make the next Flappy Bird and pull in $100K revenue per day, you probably don't want to be spending your time figuring out why "the time between ticks increased to 20-30 ms and then it dropped again." Your time would be better spent slapping together version 0.01 of about 40 games and shipping them, hoping one of them takes off. Needing to optimize and rearchitect something is a problem you have after you get U$ER$.
- hyperpallium 9y ago
  Businessvalue-only code can get complex though, and difficult to work with. But, maybe, when the value/intention is clear, it makes it easier to understand. (That is, until there's years of accumulated complexity).
- a_t48 9y ago
  > you probably don't want to be spending your time figuring out why "the time between ticks increased to 20-30 ms and then it dropped again. When I was in mobile games (3D) we saw a direct correlation between framerate and revenue. We released a patch that (accidentally) slashed the frame rate and our revenue tanked. We released a patch that did nothing but fix the performance and our revenue went back up to previous amounts.
zebraflask 9y ago
@bartread That's an awfully high and mighty opinion, don't you think? Sounds like annoyance over the fact that things that work reliably aren't "cool" enough.
- bartread 9y ago
  It's certainly annoyance - and a good amount of it - but cool doesn't come into it. What I'm really railing against is people who talk a good game but seem to be incapable of delivering anything but bad software (regardless of whether what it does is supposed to be "cool", whatever that might mean when taken in context), and includes unreliable. I have to admit that it may not be entirely they're fault: organisational culture shapes you whether you want it to or not. So perhaps what I'm really railing against is a culture of software development that tends to exist in larger organisations. Clearly this isn't universal though - just common. There are notable examples where very large organisations have been able to avoid these problems, at least for a while, even at scale: Google, BBC, parts of Microsoft (I can personally attest to this one), facebook (although hearing from a friend t sounds like they're getting sucked into it). I do find it frustrating that guys like this style themselves as thought-leaders - and often succeed - whilst unfailingly focussing on the wrong points, and making themselves a complete pain in the ass to everyone they work with. The other point is that as I've got older it's become starkly obvious to me that I only have so much time left. Obviously that's always been true but when I was younger I suppose I just didn't take it that seriously, and that's sort of a gentle regret. And that's really for everyone: you don't have all the time in the world so if there's something you want to do then get on and do it - sometimes you have to do things just to make ends meet but, as far as is possible, don't subject yourself to anyone who's going to hinder you on that journey.
  - louithethrid 9y ago
    Thanks for those words.
  - zebraflask 9y ago
    With that extra context, I agree. It can be quite frustrating to work with people who don't perform, or who don't understand where to focus their work.

greggman 9y ago

Just going to add my random 2¢ this is what engineers do (I'm an engineer). All they can see is the tech and ok, maybe that's that they enjoy but it really has little to do with a hit game (here come the comments ;) It's like claiming that most movies couldn't be made unless will build our own cameras from scratch. The thing is, building engines and tools is conceptually easy. It might be a lot of work but it's mostly known solutions so we (engineers like me) see a big todo list and just do it. We get in the flow. We get proud of our solutions (even though 40k new games shipped this month that some how solved the same problems). But arguably the real work is in design and design is much harder, at least for me, because it's a blank slate. I don't have to reinvent how to read joypads or stream files or serialize data. Sure I might write my own but it's arguably a waste of time. They real hard work is figuring out the game itself. Prototyping, trying out new ideas. Grab some working solutions (Unity, Unreal, or your favorite open source libraries, spend as little time as possible on tech and as much time as possible trying out ideas). Of course I write that advice and I've believed it for years but I still fall back to my engineering ways and find busywork to do like add some unit testing system or automate some other step. Meanwhile no prototypes. No games.