Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.






Why Small Companies Succeed

Posted by Josh Klint, 26 November 2011 · 857 views

The development of Leadwerks3D seemed like an impossible task at first. Not only did I need to write a new 3D engine entirely in C++ mostly by myself, but I had to make it run on four platforms (Android, iOS, Windows, and Mac), with a scalability all the way from the fixed-function pipeline up to the very latest hardware tessellation features. All logical sense told me this was impossible. Even large companies with 100 programmers or more haven't yet been able to put out a 3D engine with the range of platforms and scalability I am targeting. What makes me think I can do it?

As we approach the initial release of Leadwerks3D, what I thought was impossible seems much more feasible now. During the course of development of Leadwerks3D, I've learned some important ideas that give a lot of hope to me and to indie game developers everywhere.

Systemic Interdependence
When managing complex tasks there's something called systemic interdependence. This refers to the idea that when you have many people working on one project, they are rarely isolated from one another. They often have to stop and wait for another person's job to be done before they can continue with their own, and programmers often end up stepping on each other's toes when they work together.

Even though only Aria and I are working on the source right now, we have experienced this. It's very important we keep busy with separate aspects of the engine. Aria works on platform implementation issues, I work on the core engine design, and we try our best to keep the source code repository in sync. So far this works well for us, but I could easily see a lot of problems arising if we had more people working on parts of the engine that aren't so easily compartmentalized.

Think about your own game. What if I told you I was willing to give you as much money as you wanted to hire programmers, (as long as your final project gave me a big return on my money). Sound great, right? So you go out and hire ten programmers. They come in every weekday, 9 to 5. They're willing to work, but you have to instruct them and keep them busy and productive. Don't have anything for them to do at the moment while you finish one little part? Too bad, they're still on the clock and you still have to pay them.

With ten programmers, would your game get done ten times faster? Almost certainly not. In fact, as you add programmers, your work output will probably look something like the graph below. With one programmer, we have an output of 100 arbitrary units. We gain efficiency with the first few programmers, but the effect lessens with each additional worker. They have to wait for another person to finish something. Now the code repository is conflicted, and you have to figure out how who added what code. You also have an increasing number of relationships and communication between individuals.

Attached Image

Once we get past five programmers, additional programmers actually have a detrimental effect to our output. If we continue adding more workers, we can reach levels of output that are below even that of a single programmer. Imagine if 30 people were working on your game. It would be chaos, and that whole time you would be burning money as they came in every day. Meanwhile, your investors would be sitting impatiently, expecting you to get back a lot more money than they put in.

My chart above isn't precise, and the number of programmers a project can support will vary based on its ease of compartmentalization, but the overall idea stands: Software development does not scale very well with additional manpower. This is why small companies are continually springing up and outmaneuvering larger ones. Android came from a small company. It was bought by Google, but only after a small team had built the foundation. Minecraft came from a very small company. Kinect originally came from a small company. Small companies with focused goals are able to compete with much larger companies because of the effect of diminishing returns.

Performance and Motivation
Another problem big companies have is motivation. In a professional software development environment, managers like to have measurable performance metrics to evaluate employee efficiency. These are used for performance evaluations, and are the basis for salary increases, promotions, and disciplinary actions. Managers set goals and milestones that can be easily measured after a period of time. Workers respond to this by doing exactly what management tells them because they get rewarded for it. If a worker has an idea for a new technique that might or might not work, they're not as likely to spend time on it in this environment. If it works, the company gets to keep their idea and they get nothing. If it fails, they've wasted time on something that doesn't fit into their manager's ideas of measurable performance. Now, a lot of tech companies do try to encourage innovation, but if a worker has an idea for something they really believe in, they are more likely to form their own company where they can be in complete control of their vision. The professional software development environment does not encourage risk-taking and innovation the same way small companies do, because they need easily measurable metrics to assess performance. They only get out of employees what they reward, and it's hard to measure the value of new ideas and attention to detail.

Conclusion
These ideas I've learned during the development of Leadwerks3D are directly applicable to your own game projects. Don't get discouraged when you run into a tough problem. Even if you had more help, you would still have to figure out a solution, one way or another, and you wouldn't be able to shift that responsibility off onto employees. You can do it, just be wise about where you focus your efforts and plan carefully.




I've been saying this for years. Nobody seems to listen because they have never worked on their own projects. Only those who try their own work will ever understand. I work at about 60 to 100x faster on personal projects than I do at work. My graph would drop off after about 3 programmers though. You could be productive with 5, but your brains are less connected. 1 person can have a vision in which they don't have to communicate to anyone, 2 people share visions through talking and short meetings, 3 people is a discussion on mixing visions. After 3 people you need some longer group meetings.

One thing other than motivation you missed as well, is with a company of more than 10 people, people leave companies. So when you lose someone that built 1/3 to 1/10 of the entire code-base, no new hire will ever be 100% in tune with that persons code and know all the ins/outs, it is impossible unless you can physically read minds in the future.
I've personally experienced this at my current job. It is just me and another developer, but he designed the whole project and wrote almost all 30k lines of code. Getting me up to speed is nearly impossible, but I have been able to built new components for it and implement them. We have ran into a lot of repo conflicts a long the way. This is just 2 developers too. But I often spend more time reading the code trying to understand it then I do actual programming. I've probably added only 3 - 4k lines of code to this project so far. But we are slowly getting in sync with each other, it is quite the progress. Excellent read though, I am also way more productive on my personal projects then the ones at work.
Sad but true, I've spent many a lunch conversation on this topic. We tried to express these issues to corporate but it was too little to late, and now our studio has been "economically down sized" LOL good riddance
Curious, are you and Aria using a central (eg, Perforce) or distributed (eg, Git) source control solution?<br><br>To branch off your example, you wouldn't hire those 10 programmers all at once. You would hire them as your needs factor out grows your man power factor. You must also decide if the "need" is actually a need at that point in time. Yes, you may need a pipeline for getting assets into the engine, but you need a base class library or at least some sort of framework that handles IO, memory, etc before you even start down that road. With this route, those new programmers won't be waiting on anyone. Compartmentalization, just as you talked about.<br>
We use an SVN repository for source control. Of course, my article was not meant to declare a hard and fast rule that was accurate 100% of the time. Everything else being equal, a larger team will have a lower per capita efficiency than a smaller one. When developing a complex application with many interwoven systems (like a game) this loss in efficiency can be very significant. This article was written to explain some of the advantages people working in small teams have, so they can better understand their own strengths.

In the past I sometimes found myself engaged in wishful thinking that if only I had more manpower I wouldn't have to figure out some complex task...but more workers doesn't make design challenges go away. You still have to make all the design decisions, describe to your employees exactly what you want them to do and how they should do it, and verify that it was done correctly. Often times it's much easier to just do it yourself than try to assign, monitor, and evaluate someone else's work.
Good advice.

Game development favours parallelism in the development cycle; interdependency introduces a big communicate hurdle if you constantly have to check "are you doing this? 'Cus I'm doing THAT" kind of thing. So, yeah, smaller teams certainly get a big boon from not having to deal with that particular problem set. However, manpower does have it's advantages and, if used correctly, you will be able to do more and faster than if you had a smaller team.

The obvious conclusion is that you don't get things done "easier" if you have more people working on it, but you can get more if you can get several people working on multiple (different) parts simultaneously.

Motivation is a given whether it's the paycheck or the game itself that provides it - I would agree that the latter motivates innovative behaviour more often than not (which small companies often find useful; larger companies rather want work churned out than argumentive employees trying to 'change stuff').
Iif a person works alone, can work very fast. Even easilly keep up against teams with 10+ person, becouse large teams needs serious coodrination, wich affects the production badly. There is only 5 thing needed: knowledge, experience, vocation, time, and pizza.
One person alone, is so isolating, you build walls around you and your work - at least one more, and you bounce ideas off each other, its better
I love this journal entry ... and your tech looks amazing, great work! I think a super dedicated single programmer "team" can achieve the same output as a team of 10 or so less motivated and/or skilled people combined with the efficiency decreases you mention.

Good work...

- Dan
PARTNERS