Why Small Companies Succeed
Entry posted by Josh ·
9,001 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.
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.
--Edit--
I posted this article on GameDev.net and got a few interesting responses:
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.
-dpadam450
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.-wicked357
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.-ELawson
32 Comments
Recommended Comments