re: What are the least intuitive fundamentals and best practices in software development? VIEW POST


Probably the idea that adding more developers to a project slows it down.

We've all heard the quote about how nine women can't make a baby in one month, but it can be hard to understand why it's applicable to developers too.


Pretty obvious actually. The number of communications scales quadratically so then you need to put them into teams to stop them talking to each other at which point you've got multiple projects so then you need to manage the interface which means people have to talk to each other...


This 1000%.

I'll compound it with: hiring a junior will never speed up development. Hire juniors when you have the time and breathing room to train them.


I think juniors are often better off working on their own projects if possible, rather than integrating into a larger project. Ideally these should be small and comparatively simple, and they can work their way up to larger projects. Code reviews would allow regular feedback on code quality and allow for potentially problematic code to be identified and refactored away.

I'd only feel comfortable bringing a junior onto a large existing project in cases where I already had good test coverage and continuous integration.


I disagree with this. Unless your hiring practice is broken, or your code is in awful shape, hiring juniors should add immediate benefit to a team. They may not be as productive as existing team members, but they should definitely improve total output.

You don't need to devote lots of time to mentor newcomers. I've never really had it interfere with my own work.


This has to be tempered with how many you are adding. If you have a small team, say 3-5 programmers, adding another programmer should definitely speed up development.

If this is not true, then it's a reflection of your code, processed, and organization. If you are in this, then try bringing somebody on with the key purpose of fixing this state. It'll bring rewards quite quickly.


Certainly it's not an absolute.

If you have a project with clean code, good test coverage and continuous integration, then bringing someone else on board can be pretty painless.

Under other circumstances, it can be downright excruciating. I'm working on a Zend 1 legacy code base with some downright awful code that I inherited, as well as horrible jQuery spaghetti code, and bringing someone else on in the project to do some of the front end work did mean I had to take some time out to bring them up to speed on various aspects of how it worked, which in turn slowed me down.

I think that would probably trigger my problematic code consideration. I'm not saying it won't slow you down on some projects, only that clean projects should benefit.

Though, even here, how long did it slow you down for. Do you think the junior won't contribute more overall than the time you invested?

In this case, it wasn't too bad because:

  • The new functionality was a new home page, so I'd built it in React as opposed to the PHP and spaghetti jQuery of the rest of the site
  • The developer brought onto the project is experienced. She hadn't used React, but had used Vue, and could easily draw parallels between the two
  • The division of labour. My CSS skills have never been that robust and I'm happy to stick to writing server-side code and Javascript, so I just put together some basic React components for the front end and left it to her to style them.

In this case, most of the loss of velocity came from things like the adjustment to React and explaining the downright awful application structure. It was definitely worth bringing in someone else - it'd take me a lot more time and hassle to do a much crappier job of the front end.

However, if it had been a case of bringing in another back-end developer to work on similar tasks to me, I'd have had to spend a lot of time explaining what I could, going through the awful parts of the code base, and avoiding stepping on each other's toes.

code of conduct - report abuse