Why You Shouldn't Hire More Developers • Hacker News Board

Re: Why You Shouldn't Hire More Developers

#41

Post by Tommabeeng » Fri, Feb 03, 2012, 6:56 PM UTC

michaelochurch wrote: post #31

Tommabeeng wrote: post #27

"Improving the productivity of a software team is hard. It involves understanding the business, the team, the history, the obstacles blocking progress. It is a complex, context-sensitive problem." TRUE. Hiring more devs won't solve the complexity problem unless you happen to lasso a few certain devs with the right experience, perspective and willingness that can identify the true core of a problem and solve it fully…

Sadly many ("smart", "rock star") devs I've seen are content with shortcut, local maxima solutions that only buy a little bit of time before the team starts hurting again. I don't know why this is. Maybe b/c it's more fun (or feels safer) to code and produce behavior than to do the vigilant things required to stave off complexity. General intelligence is a necessary condition, but far (very, very far) from a sufficie…

Alan Kay expresses something similar:

http://tele-task.de/archive/video/flash/14029/

"Knowledge is silver. Outlook is gold. IQ is a lead weight." (~00:30)

Re: Why You Shouldn't Hire More Developers

#42

Post by EGreg » Fri, Feb 03, 2012, 6:58 PM UTC

Funny enough, we never seem to have such major problems.

Perhaps because we have a framework and documentation and a guide to get new hires up to speed. Also we have documented our practices, the tools we use, etc. And the new hires are instructed to do a project before joining the team. Once they have done the project they are familiar with a large part of the framework.

And as for those "business edge cases", new hires and all developers are personally given tasks by me, and we make sure to QA their work and code-review work by new hires.

So these are the main factors for why hiring new people has so far been relatively smooth. Still, let's not maintain any illusions -- new hires will need months to really get to the same place as existing developers.

But you don't have to have your own documented framework to do it. If you are using an open source framework and sticking closely to its principles, if you have documented your company's systems and made it clear what is expected of developers, hiring can be a great thing!

Re: Why You Shouldn't Hire More Developers

#43

Post by michaelochurch » Fri, Feb 03, 2012, 7:00 PM UTC

Tommabeeng wrote: post #41

michaelochurch wrote: post #31

Earlier quoted context omitted.

Sadly many ("smart", "rock star") devs I've seen are content with shortcut, local maxima solutions that only buy a little bit of time before the team starts hurting again. I don't know why this is. Maybe b/c it's more fun (or feels safer) to code and produce behavior than to do the vigilant things required to stave off complexity. General intelligence is a necessary condition, but far (very, very far) from a sufficie…

Alan Kay expresses something similar: http://tele-task.de/archive/video/flash/14029/ "Knowledge is silver. Outlook is gold. IQ is a lead weight." (~00:30)

That was a great talk. It was really interesting to me that the initial vision behind object-oriented programming was diametrically opposite to the disaster that it has become.

Re: Why You Shouldn't Hire More Developers

#44

Post by matwood » Fri, Feb 03, 2012, 7:07 PM UTC

roc wrote: post #32

matwood wrote: post #18

Earlier quoted context omitted.

Failure point: You waited too long to hire a new developer. This is what I was coming to say. Of course Alice is going to take some handholding because she's new. She could be an A+ developer and will still require team time to help her get up to speed. The problem is that the team in the article waited too long to bring Alice on. They were already far too behind the 8 ball to have any time to get her up to speed. If…

But the corollary is that the longer they wait to hire Alice, the worse the situation gets. That is: they should have hired her yesterday and hiring her today won't help the current cycle , but you have to hire her today to have any hope for the future . [1] [1] Unless you have incredibly isolated projects, in which case you can arguably put off hiring Alice until after the release, but you'll still need to bring her…

Yeah, I should have been more clear. I agree with you that hiring Alice then was the right thing to do even if late. Worst case is she can start learning the code base on her own until the current cycle finishes and the team has more time to spend with her.

Re: Why You Shouldn't Hire More Developers

#45

Post by dustingetz » Fri, Feb 03, 2012, 8:04 PM UTC

nhashem wrote: post #38

Why You Should Hire More Developers: Because it's easier to convince the company's executives to do that than fix the systemic issues that are truly eating up software engineer bandwidth. Let's assume this company has nobody with a true technology background at its leadership level, because if it did it you wouldn't have this mess to begin with. That means it's basically never an option to say, "can we stop working o…

> can we stop working on business projects for two weeks so we can fix problems with our infrastructure that will make us more efficient later on

this attitude is contributing to the problem; it takes continuous and disciplined investment in quality. the idea is that slowing everything down (forever) by a linear factor of two or three will cause exponential returns in productivity later.

Re: Why You Shouldn't Hire More Developers

#46

Post by rwos » Fri, Feb 03, 2012, 8:37 PM UTC

nhashem wrote: post #38

Why You Should Hire More Developers: Because it's easier to convince the company's executives to do that than fix the systemic issues that are truly eating up software engineer bandwidth. Let's assume this company has nobody with a true technology background at its leadership level, because if it did it you wouldn't have this mess to begin with. That means it's basically never an option to say, "can we stop working o…

> It's politically easier to bring on someone new, deal with the productivity hit, and then have them start addressing the systemic technical issues.

I can see the reasoning behind that and it would be wonderful if that tactic actually worked. In my experience however, it does not.

I work at a company that is heavily driven by a non-technical management. They don't understand the concept of "technical debt" and your characterization of how it is to work at such a company is _exactly_ like I have experienced it. But: the managers/MBAs/what-have-you at my company are not idiots. The problem is: if they bring in a new hire into a team (which happens fairly often, we went from ~100 engineers to more than 250 in 2011 alone), they also raise their expectations of said team's output.

The team-leads (which is the highest technical position in my company) do, of course, try to fight that back and try to use the plus in productivity for fixing underlying technical problems (of which there are plenty). Sadly, they have a hard time explaining even the productivity drop that stems from bringing the new team member up to steam. After that, there is just not enough argumentative leverage (I hope that's a term that exists) left to explain why we could not move even faster, now that we are one engineer more.

So, in the end we are exactly where we were - and find ourselves longing for another new hire to work exclusively on the technical debts.

Re: Why You Shouldn't Hire More Developers

#47

Post by moconnor » Fri, Feb 03, 2012, 8:37 PM UTC

What's all the fuss about getting new developers up to speed? This time last year we added two new hires to a team of three, working on a ~500k LOC project. Unlike this example, our project wasn't late and adding them didn't slow us down, it sped us up.

They both delivered valuable new features in the next release a few months later, fully pulling their weight. Now, they're bringing new hires up to speed.

We spent a long time (several months) looking for very good people. We imported one of them from Germany. Perhaps Brooke's law only applies because the sort of developers you can hire in a hurry aren't the sort of developers who are going to hit the ground running.

TL;DR In my experience you really should hire more developers and you should do it before anybody starts working a 60 hour week.

Re: Why You Shouldn't Hire More Developers

#48

Post by mattcofer » Fri, Feb 03, 2012, 9:34 PM UTC

rickmb wrote: post #39

pinaceae wrote: post #11

This is very interesting, however there seems to be a bit of magic going on. It is observed that the time fixing bugs can be used in a more productive way. But those bugs still needs fixing. Quote: "If your team is spending time any significant amount of time fixing bugs, it has much more capacity than you realise. That’s not to say it’s an easy reserve to tap into, but it is there." Ok, I agree. So how exactly do yo…

Q&A doesn't fix any problems, it merely identifies them before they go into production. If a significant amount of time is spend on fixing bugs, the problem is elsewhere in the process. Solving that problem should be the highest priority, because that's were things will continue to escalate.

I agree. A lot of bugs could indicate one of two things. First you need to differentiate between bugs caused by developer error and bugs caused by lack of project planning/scope. For example, a bug report that complains 'columns in the grid do not support sorting' is not a bug. They are feature requests not originally defined in the scope of the project. Bugs such as one where 1+1=3 due to a developer's bad algorithm are actual bugs. There is a big difference here. These are the bugs that should be caught by QA long before the release and while the project and algorithm are still fresh on the developers mind. There needs to be accountability for lack of planning or assuming that every time a developer uses a widget that it will have every feature possible for that widget to have.

Re: Why You Shouldn't Hire More Developers

#49

Post by rpwilcox » Fri, Feb 03, 2012, 9:46 PM UTC

nhashem wrote: post #38

Why You Should Hire More Developers: Because it's easier to convince the company's executives to do that than fix the systemic issues that are truly eating up software engineer bandwidth. Let's assume this company has nobody with a true technology background at its leadership level, because if it did it you wouldn't have this mess to begin with. That means it's basically never an option to say, "can we stop working o…

> Because it's easier to convince the company's executives to do that than fix the systemic issues that are truly eating up software engineer bandwidth.

Yes and no. Politics and systemic issues are hard to face up to, but sometimes they make the problem worse, so they really do need to be fixed to make the problem any better.

Say you have everyone working 70 hours a week, and someone thinks to throw more people at the problem. You start interviewing.

2 weeks later, Bob quits in a fit of rage. (Or maybe hospitalized for exhaustion and quits. Whatever.). Now you're down an engineer, and you have to find two more engineers, making the HR department work even harder.

3 weeks later you find _one_ developer. You can't seem to find another - between good talent being hard to find, and people suddenly getting cold feet after doing face to face interviews with your blurry-eyed engineers... well there's a talent crunch going on after all, don't ya know? ;-)

And you're now 6 man weeks behind (and no closer to your goal of another engineer).

Boy, this new guy better hit the ground running, because you really need the help...

Re: Why You Shouldn't Hire More Developers

#50

Post by ecocentrik » Fri, Feb 03, 2012, 9:48 PM UTC

nahname wrote: post #12

ecocentrik wrote: post #5

The article is full of useful observations. The one issue I have is that presenting us with the worst possible management scenario for a new developer and using that to build a separate argument about the misuse of resources before that developer was hired is a little convoluted and even fallacious. The section about hiring and mismanaging the new developer can be removed and restructured as a separate article on the…

Do you mean the anecdote about hiring a new developer or the general guidance? Assuming the anecdote, I thought it was a useful example that I have seen occur too many times. I am also sorry to inform you that the scenario presented was actually quite ideal. In all likelihood, the new developer would be incompetent. At the very least, he/she would have a personality conflict with the team and/or argue with them about…

Yeah, I'm referring to the anecdote about hiring the new developer and expecting them to immediately contribute to bug fixing a mature project. Forget about any disruptive personality flaws the programer might have (which I agree is probably another factor to consider), I read this anecdote as an avoidable worst case management failure scenario and a potential straw man for his argument. So, maybe a little to negatively ideal to serve as a point of reference for his argument.