Pebble Theory of Coding

There is a story of a man on a beach trying to figure out how to move just these large pebbles scattered all over the beach and leave the sand. This man can get a big front-end loader to remove all of the rocks.  Or this man can hire 100 helpers with wheel barrows and remove the rocks one a time using manual labor. Or, lastly, this man can remove several rocks every time when he visits the beach.

Most programming problems are based on the pebble theory of coding.

We can buy a very expensive tool to look at code to find our problems as well as help us develop code. This tool's purchase will have to be justified as to why it is needed with management which will be an arduous process. This tool will do the job but might report back false positives during code review.  Additionally, this tool may have a huge learning curve that will cause very few programmers to take the time to learn and use it. The question remains: is the beach, in this case the code, still usable.

This is what large or small shops do.  Given the size of the programming project, they may hire 10 or 100 programmers to do this task.  They give them cheap or open source tools to do the job because they have spent the money on labor. The project gets done in a few months or years depending on management changes and direction. The question remains: is the beach, in this case the code, worth the labor cost to get it done.

A single programmer over the history of programming has always created better and more innovative code than groups. Part of the reason is that a single programmer does not have group focus but a single focus on the task at hand and is able to get from point A to Z via D and M rather than going through the whole alphabet. Even this singularity may produce bad results or incomplete code but on balance should produce a better software product because their is only one person to blame.  The question remains: is the beach, in the case the code, worth it since the code might be much smaller and consistent.