Read The Mythical Man Month quite a long time ago. One of the assertions in the book, since much repeated, is that “super programmers” are an order of magnitude more productive than average programmers.
While I know that I have always been more than usually effective, an order of magnitude felt like an overstatement.
The last project offered two examples that seem to confirm the multiplier.
At the beginning of the project, I assigned the simplest part of the project to the team member whom I suspected was the least capable (and who later became the group manager). A few months in he was joined by a new hire just out of college. Their assignment was to write a thin adaptor layer to hide version differences in the high-end backup engine we were using.
For several months, I was off doing other tasks. When those were completed, I wrote two exercises. The first exercise was to completely introspect a cloud (VMware vCloud), and log the complete set of responses. (This later proved useful in finding the chain of requests needed to fetch needed items.)
The second exercise, building on the first, was to discover and back up all the virtual machines in a cloud. For that I needed the backup engine adaptor. They had code, but it did not yet work. I found the problems, and filled in the gaps. Made a lot of changes. Figured that using their code as a base saved me about two weeks over starting from scratch. After two weeks, I handled back a fully working version of their code.
Collectively they put in about 12 man-months, before I looked at their work, and it was not yet working. Compared to the month I estimated of my time.
Later in the project, I spent a few months writing the REST API for the majority of the objects supported by the service (schedules, templates, application, datacenters, etc.) along with the synchronization logic to efficiently update many backup engines. (Clouds can be large, so you need to scale the number of backup engines along with the cloud size.) Bit tricky, but finished in the time alloted (a few months), and built tests to flush out the majority of problems.
Sketched out, but left incomplete, support for replication objects, as the backend support was not yet ready. I figured the remaining work was about a month, maybe two. Two programmers were assigned to the task. After about a man-year, I merged in their work, and wrote tests to verify … and the tests failed badly. Took me about a month to rip through their code (ripping out a lot along the way), and make the code pass the tests. In the end, I was not sure if using their work as a base was faster than writing from scratch.
So again, about a month of my time, versus a man-year of others.
Looking through their code, I could see where they lost the thread. While they generally knew what was needed, they got lost on the specifics. They did many things that were not needed, and missed needed bits. As I read through their code, I could feel where they had lost the narrative.
You could argue that I should have done a better job laying out the work, for others, and more closely watched their progress. And I would agree. Not really a part of my past experience, as I much of my past work was large episodes working mostly on my own.
I made the mistake of assuming others could do what I can do, readily. Seemed too much like ego to assume less. Seems now as Fred Brooks was more right than I expected.