What managers need to know about writing features

When it comes to writing a feature, and when it comes to getting that feature out the door, and usually when that feature should have been out the door yesterday, managers very often tend to "solve the problem" by adding more "resources" or by adding more "senior resources" to the problem.

There are multiple things wrong here:

1. "Resources" are actually humans
2. "More" or "more senior" is not a guarantee for anything
3. Features are not "problems" that get solved by simply throwing "more resources" at them
4. Features are not "things" that get resolved in a randomly allocated set of time which was determined by someone who has never touched the code (cough cough, e.g. managers or even worse finance departments)
5. Features are intricate and complicated - you could even argue they are an art form, and this needs to be understood!

Stop treating people like resources

These so-called "resources" that mangers work with are actually human (who would've thought?) They can hear, they can see, they can touch, they can smell, they can taste - and, they can even "break", "malfunction" or "simply not work". If a manager assumes: "I have one developer here, and I can add another one here and then perhaps a third, then I will have exactly 300% output - or perhaps even 350% depending on the so-called seniority. Brilliant!" Then that assumption is wholly flawed!

"Resources", aka developers, aka humans, have very different approaches to solving problems, writing features and creating art. Some might love building nice-looking features, some might prefer practicality over aesthetic, some might prefer speed over function, some might not even care about the feature, some might want to paint the inside of the box even though no one will ever see the inside of the box, etc. etc. You get the point.

Knowing the people that you have working on writing features will help you understand how to resolve problems without necessarily throwing more people at the problem - as your general approach!

And usually, the more people that are involved in writing a feature the more difficult it will be for them to complete it.

Think of a feature like writing an essay

Would you rather have 10 people write an essay, or three, or rather one?

If you have one person writing an essay (regardless of the length or complexity of it) you'll most likely end up with an essay that has great coherency. If you have three, you might still have the same coherency but the writing styles might differ or it might seem like different people wrote the essay. If you have 10 people writing the essay, heck, you might end up with a poorly executed ChatGPT essay which you've explicitly told to be unreadable and incomprehensible.

Perhaps you have a person that's really good at writing the entire essay. And maybe that person is also really fast and can always tackle an essay on their own. But maybe you have an essay that needs to be a 1,000,000 words long and it needs to be done yesterday. In such a case, don't simply" add 10 more people.

People have different strengths and quirks - and things take time. There is no magic "reduce the amount of time it takes to complete" button - we would have all pressed it a long time ago!

One person might be really good at writing introductions (starting the feature), another might be really good at writing the body, yet another might be really good at fleshing out sentences and filling them with emotions and capturing a reader's attention, yet another might be a better grammar police than any online grammar tool.

If one person is slow, another might be quicker, but therefore sloppier. One person might not be able to express sentiment in coherent sentences, let alone write a word, and is being asked to write a really short and simple introduction. All of these things matter! The people might not even like working with each other. Some might not have the right tools, some might need "bringing up to speed" (lol - should've been done yesterday), some might need to jump off other things they're in the middle of. It's really a bit of a jungle and simply "adding 10 more people in the last minute" will not get the feature done more quickly!

Don't add more, add better

It takes great skill to find and encourage people to work together on something as seemingly simple as a feature.

Given that each person has their own strengths and that each person approaches problems differently one has to make room for interactions that take place outside of the "writing the feature" part - and those take time and need that time. No amount of "it needed to be done yesterday" can speed this process up.

Next time you want to "simply add another person" purposefully allow for extra time to overcome the initial complexity which you are disruptively adding into the mix before expecting even a single line of hoped-for "quicker code" to be implemented.

There is always a trade-off where adding more people will simply result in a communication and complexity overload which, sure, by your calculations would just be a matter of "add more", but in the end will result in something more along the lines of "should've added better".