[tlb]

Software companies have similar inefficiencies, but they're harder to see and measure. Instead of piles of rotting inventory they live in bug trackers and post-it notes and long meetings. Managing to metrics is harder, because the metrics (bugs retired, KLOCs written) are so meaningless and easily fudged.

Also, good programmers tend to be undisciplined. Good programmers are good because they're creative and they can keep a lot in their head, but that makes it hard to get them to follow processes and track everything rigorously. Replacing them with mediocre but disciplined programmers doesn't usually improve things.

It's such a hard problem to run an efficient software shop that most companies don't even try -- instead, they only go after businesses with 80% gross margins.

[GVIrish]

> Managing to metrics is harder, because the metrics (bugs retired, KLOCs written) are so meaningless and easily fudged.

Agreed, managing to team metrics is usually the road to hell. But tracking some metrics can uncover problems. Maybe your team is bad at estimating. Or there's a lot of rework to new functionality due to shifting requirements. Or maybe there are a lot of bugs after a release because the engineering process is broken somewhere.

> Also, good programmers tend to be undisciplined.

I find this to be untrue. You're not really a good programmer if you ignore the ancillary activities that contribute to a high-functioning project/team, unless you're someone who is writing code only for yourself. Communication, coordination, documentation, and following good processes wastes less time, reduces mistakes, and reduces the damage done when someone leaves the team.

The cowboy programmer can do a good job writing code but if they're not attending to all of the other stuff a software engineer needs to do, they are dragging down the productivity and resilience of the organization.

> Replacing them with mediocre but disciplined programmers doesn't usually improve things.

Yes you'd certainly rather have a good programmer who needs to improve on process than someone who can barely program. But even better to have someone who is both disciplined and good.

[dsr_]

"Maybe your team is bad at estimating."

To a first approximation, everyone is bad at estimating software development times.

See: https://news.ycombinator.com/item?id=12149515 and https://news.ycombinator.com/item?id=4328660 and http://www.romenrg.com/blog/2015/09/28/why-asking-developers...

and The Mythical Man-Month, too.

[GVIrish]

Certainly there's a lot to estimating in software dev, but I'm talking about when estimates are regularly wildly out of whack. Where someone or a team regular estimates something will take a few days but then it takes several weeks or months it indicates there's a problem or problems somewhere.

Maybe requirements are shifting too much. Maybe there's a lot of hideous technical debt. Maybe the wrong technology is being used to build the product. Maybe there are people on the team that don't have the skill level they need.

There could be a lot of things at play there, but the point is that there may be issues that need to be addressed. When you see wildly inaccurate estimates it means the root cause(s) should be investigated.

[dmix]

> Also, good programmers tend to be undisciplined.

I'm curious if that's coorelated to ADD. As I definitely fit into this category.

Most startups I've worked with utilize product managers to compensate for this, coordinating the work of engineers, which can be helpful. But in many situations I've found the engineers knew what was best for the product than these guys, who were typically older non-technical types with business experience (typically at larger firms). Largely because engineers have lived and breathed software since they were kids, tried to understand them, and know what makes good products intuitively. Plus they're usually smarter in general.

So I believe the best product managers are ones who seek input from developers as equally as they delegate/manage tasks. The worst ones are the ones who think they always know best and see the engineers as merely workhorses who are there to implement their (and the founders) vision. As middlemen they create a disconnect between programmers/designers and the founder. Or, worse, just saddle engineers with endless tickets with no clear vision or higher level thinking.

The very worst are the ones who think everything is about setting up processes and systematizing everything. Which they learned working at big companies and then try to pigeonhole it onto fast-moving startups... ultimately slowing everything down for little benefit, creating more risk out of failed attempt to manage/minimize future risk.

[eldavido]

Having survived a few startup disasters, I also resisted the imposition of process.

Looking back, I think it was a mistake.

[joshmarlow]

It sounds like our experiences were similar; I was very anti-process, but now see the value.

I read about a really interesting concept - "the null process" [0] - recently. The idea is that there is always a set way of doing things (a process) whether it's documented or not.

[0] - https://kateheddleston.com/blog/the-null-process

[majormajor]

The danger of process is that while some amount of official process is super valuable, it's very very very hard to only have a little process.

Once you start hiring for people specifically responsible for managing the process, you've got people whose incentives line up more with "furthering the process" than "furthering the underlying enterprise."

But yeah, places that say they have no process are falling into the same trap as places with "flat orgs" - there are always some power brokers once you're over 10 people or so, it's just not always documented (and even a non-flat org can hide the true power holders).

[joshmarlow]

Yeah, as in all things in life, balance is required.

That sounds like a pretty good heuristic, btw - when you are hiring people who only manage process, question your amount of process.

[woolvalley]

You can measure on metrics such as:

* code performance (speed, CPU, memory, frame drops, network speed, etc)

* hardware cost efficiency

* outage rates

* crash-free rates

* app freeze rates

* error rates

* general developer waiting times such as checkout times, build times, CI waiting times, IDE indexing times, build-run-test cycle times, etc

* Engineer % time in meetings based on calendars

* Amount of employee time spent interacting with bug tracker websites

You can also measure on business metric improvements such as profitability, increased revenues and so on.

These aren't good for measuring the productivity of any specific engineer, but they are great for measuring the productivity of the team / firm as a whole. You can also do projects to explicitly improve these metrics. And since they are numbers, they are far more attractive to managers to look at.

[elgenie]

> Good programmers are good because they're creative and they can keep a lot in their head, but that makes it hard to get them to follow processes and track everything rigorously.

Being creative but undisciplined makes someone mediocre at best.