Live data from Hacker News

Why You Shouldn't Hire More Developers

blog.patchspace.co.uk

31–40 of 55 posts

Re: Why You Shouldn't Hire More Developers

#31

"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 sufficient one for being a good programmer. Most of the inept developers I've met have been smart. Intelligence wasn't the problem.

This is why I hate Java and C++. Because it's impossible to evaluate code for quality in these languages at 200-500 LoC (while you can easily do this in Python or Scala) you can't hire based on code samples. So you have to hire based on general intelligence + interviewing skill and you end up with about 15% of your team being outright duds (worse yet, intellectually brilliant and persuasive duds because they passed your hiring process, but still bad programmers and dismal architects) even if you're extremely selective.

Re: Why You Shouldn't Hire More Developers

#32
post #18
post #14

Failure point: You waited too long to hire a new developer. You thought you could handle it, but couldn't, and you should have seen this coming. The team leader failed here and let a severe issue (overwork of staff) cover his ass on costs. We always have an extra developer on every team, no one does crazy overtime. It's worth the extra $0-$30k for the intern/half-timer. The kid gets experience and we get a backup. Sh…

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 on well before the next one gets under way.

Re: Why You Shouldn't Hire More Developers

#33

Consider the point that Fred Brooks made in the Mythical Man Month: "adding manpower to a late software project makes it later." http://en.wikipedia.org/wiki/The_Mythical_Man-Month These debates are "evergreen" in the sense they will happen forever on tech sites. That is because they address an issue that is fundamental to the creation of software. There are 2 sides: 1.) most people can not work 60 hour weeks forever…

It seems like Greenspun is assuming that programmers are a fungible resource. In reality, it seems like avoiding burnout is not just a human need, but also a business need. Unless you're only going to run your business a year, of course, or if what you're working on is so generic that you're happy with a huge turnover.

Re: Why You Shouldn't Hire More Developers

#35
post #14

Failure point: You waited too long to hire a new developer. You thought you could handle it, but couldn't, and you should have seen this coming. The team leader failed here and let a severe issue (overwork of staff) cover his ass on costs. We always have an extra developer on every team, no one does crazy overtime. It's worth the extra $0-$30k for the intern/half-timer. The kid gets experience and we get a backup. Sh…

Yes. This is a theme in Tom DeMarco's book _Slack_.

It applies not just to developers, but office furniture, conference rooms, processes, and most other employee types too.

Re: Why You Shouldn't Hire More Developers

#37

Earlier quoted context omitted.

you are absolutely right, but there is a factual counterpoint: availability of those intern/half-timers in the region. we are located near SF, so far we had a hard time finding interns - cause the young kids are busy building start-ups themselves...

How much are you offering to pay them? When you say 'availability', do you really mean 'availability for less than market rates'?

This is actually a pretty good question.

Everyone has to weigh the benefits of starting a startup over having a regular job. If all the kids are starting startups, that indicates that the benefits of having a job are so low that it is always worth the risk of startupdom.

Money may not be the only consideration, but I'm sure it is a big one. Would these kids be all starting startups if the programming jobs paid, for instance, $500K per year?

Re: Why You Shouldn't Hire More Developers

#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 on business projects for two weeks so we can fix problems with our infrastructure that will make us more efficient later on."

Suggesting something like that never works because:

-- The idea of halting "forward progress" on "revenue-driving initiatives" is anathema to any executive. I've once worked on projects where the conversation with my manager has gone like this:

"[Executive] wants us to make progress on the SuperProfitGenerator Widget this week."

"On top of everything else? That's a HUGE project! How could we finish it this week?"

"She doesn't want it to b finished, she just wants forward progress."

"What's the definition of forward progress?"

"Well she just wants to know we're working on it and we're closer to finish than we were at the beginning."

"But I'm not supposed to have anything functional or anything, just 'forward progress.'"

"Yes."

"By what metrics? Lines of code? If I tell her I wrote 10,000 lines of code for the SuperProfitGenerator Widget, that will make her happy?"

"Yes."

"Wow. Okay. Um, yeah, we can squeeze that in."

[proceeds to create SuperProfitGenerator.pm class and copy-paste 10000 lines of Wikipedia into it wrapped in a "print" statement]

-- It's incredibly hard to quantify the actual efficiency gains and business people basically just assume engineers are lying anyway. Unfortunately I've seen this sort of Catch-22 play out -- it seems like the business will relent, but they want to try and quantify the efficient gains. The engineers give incredibly optimistic answers because a) we're typically terrible at estimating to begin with b) the rosier we can paint the picture, the more likely they'll finally buy-in. Unfortunately then it's very hard to deliver on those efficiency gains, and even if you do deliver, it's hard to make non-engineers realize the impact. Everyone realizes when an extra $50,000 is in the bank account. Not everyone realizes that 5 engineers have each saved 10 hours, even though an extra 50 hours of productivity over a year is easily worth more than $50,000.

-- Even if they do agree to let engineers start working on systemic/infrastructure problems, it's typically the first thing that gets prioritized. Some client will come in talking about some deal that could be worth some non-zero amount of dollars but requires additonal engineering work. The executives sit around looking at the current priorities and someone says, "It looks like the top priority right now is 'Data Model Refactor,' whatever the fuck that is. What the fuck is that? Oh it's something about database the engineers wanted to do? Fuck that, make them work on this instead."

So what can you do? If you have the option of fighting to get technical debt and infrastructure issues addressed, or just hiring more, than in an envirnoment like this it's almost always the better move to hire more. Hiring someone for a later project does make it later, but the OP is talking about a systemic overall inefficiency. It's very possible the new hire will come in and gum up the works for awhile during his ramping up phase, but on a long enough timeline they will eventually out-produce the overhead. It's politically easier to bring on someone new, deal with the productivity hit, and then have them start addressing the systemic technical issues.

Although the real answer to "what can you do?" is to not work at these kinds of companies to begin with. Companies with leadership that has true technology backgrounds don't allow these kinds of situations to arise to begin with, and if they do it's very easy for them to understand the cost-benefit analysis of dealing with them. This isn't the case at your typical organization led by a bunch of MBA idiots, unfortunately.

Re: Why You Shouldn't Hire More Developers

#39

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.

Re: Why You Shouldn't Hire More Developers

#40
post #14

Failure point: You waited too long to hire a new developer. You thought you could handle it, but couldn't, and you should have seen this coming. The team leader failed here and let a severe issue (overwork of staff) cover his ass on costs. We always have an extra developer on every team, no one does crazy overtime. It's worth the extra $0-$30k for the intern/half-timer. The kid gets experience and we get a backup. Sh…

Couldn't agree more. Also, why not let the new developer work on new features? What's even better, you can hire someone who specialize in that new feature that your client want (geocoding, mobile dev), instead of having existing developers to "learn" it (which by the way, is always the preferred but wrong way by the existing developer). The new developer doesn't have to know the details of the backup, just the interface or API of existing services. Existing developer works on bugfixing on what they are familiar with.
Post reply on HN