Many hands make light work… sort of

John Heywood was the person that first penned the phrase “many hands make light work” (as a matter of fact, he has written some of the more iconic phrases that we still use today). That phrase was told to me many times by my parents, and it made sense to me. We lived on a small family farm in central California. If work was going to get done then that was because you went out there and did the work. When it came time to harvest the walnuts or almonds, it meant we were all out there on our hands and knees picking up the nuts off the ground. When it came time to weed the garden, we were all out there pulling weeds or using hoes to get the rows clear. If one of us didn’t go out there then that meant the others had to do more work. We all pulled our part to make the work “light”.

Does that translate to software development? Not according to Fred Brooks. If the name sounds familiar, it’s because he is the guy that everybody quotes yet have never actually read. He is the author of the book “Mythical Man Month”, a treatise on software development allocation. His classic quote is “adding human resources to a late software project makes it later”.

One of the big fallacies is that in order to speed the project up, you can always just split the tasks into smaller amounts and add more people to accomplish them. The example against this is my favorite: pregnancy. Brooks points out that while it takes one woman nine months to make one baby, “nine women can’t make a baby in one month”. And my wife, having recently given birth to our first child, can confirm that’s not how it works. Though she would have loved the extra help to reduce her pregnancy time.

We’re Not Digging Ditches Here

Need to dig a ditch faster? Get another guy with a shovel. Your output just doubled. This makes complete sense. And it is great in a family setting where you are trying to motivate all the members of the family to pitch in and complete a menial task. But we’re not digging ditches here, nor are we picking up walnuts, from my youth. It doesn’t always transfer to other projects.

In the world of development (Adobe Experience Manager or otherwise) just throwing more bodies at a problem doesn’t make the problem go away, it oftentimes makes it worse. IMO most of the problems stem from either unclear or unstated requirements, or developers splitting their attention across multiple projects.

Sometimes things can only be done by one person. Or only one person can do one particular task. Certain things just take time, and having more people messing around with them can make things get ugly, very quickly. As anyone who has ever been working on the same file at the same time as someone else can tell you. Merge conflicts. Overwriting previous work. Authoring the same component or page. All of them are a pain in the butt.

A good developer should be able to break things down into smaller chunks. But just because you do that, doesn’t mean that you can throw several people at those smaller chunks. Often a developer is going to make decisions on one chunk that will impact the way it must be done on another. So having someone else work on those could be disastrous.

So What?

So what is the take away here? Developers and Architects need to give better estimates. Business owners need to be more patient, manage their expectations, and plan a buffer. Otherwise the outcome is not going to be good for either side, and the project/deliverable will suffer because of it.

Our process is to keep our AEM development teams as lean as possible, giving clear and frequent communication updates so that business owners can strategically plan for the future. Are you looking for an AEM implementation partner that does that?

We do. We’re Hoodoo.