Small and large projects

Oct 2, 2017

I prefer small projects. They tend to be more technically challenging, and also require working with fewer people. This seems like a contradiction to my preference to focus on the people instead of the machines, but actually, it's not. In large projects, you are a cog, and you get to fit into the processes. Whereas in small projects, you have more freedom to do what you deem right. And you can communicate more liberally.

I define small projects as something a single developer or manager can comprehend. If I'm the leader of a small project, I know every part of it. The whole specification, the general architecture, and I have a clear view what each proposed change will break.

Having a leader gives a single point of contact to the software. When a change is planned, that single person can tell you which parts would be affected. This helps avoid a lot of the surprises along the road that would otherwise poison the projects.

Contrast that with large projects, which are too complex to fit inside one skull. Those require an entirely different approach. The modus operandi is to cut the large project into small ones and assign someone to lead each part. In effect, this approach results in many seemingly independent parts. But in reality, this just makes the interactions more important than the parts themselves. Even though you think you have a bunch of small and effective projects, you still have a large mess.

This vastly different behavior between small and large projects leads to underestimation. The time estimations are made based on the best case scenario. That is a small project, and when all developers work together like a fine-tuned machine.

In reality, most projects start this way. And then realize that the communication overhead is way more than expected, and the initial specification seems incomplete, and its changes can not be overseen by a single lead.

This is the point where the different parts of the specification start to evolve independently of each other. I've seen this many times. When the left hand doesn't know what the right hand is doing. From the outside, this setting provides unexplainable results.

If the project was a small one, one leader could coordinate it. Any changes to the original specification would get back to them, providing central control. Saving the team the overhead and most of the complications.

Preferring either small or large projects is a matter of personality. Many people I know prefer the safe and predictable environment of the latter. They are responsible only for a small part, and can usually blame the management for all the problems.

Some people are more like lone wolves or have an inclination towards small teams. Preferring small projects, and the responsibility and the freedom they entail.

The important thing is to experience both so that you know which one is better for you.