[DrImplausible]

Thanks for sharing; it was a good quick read, and I found it instructive.

What I'm not sure is how the lessons of a material production culture might translate to the digital one that most of HN (presumably) interacts with. Version control, getting rid of legacy systems, concentrating on the high-margin products that keep the business going. These could all be applied, correct?

[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.

[actionscripted]

I was trying to figure a few of these out myself as I was reading the article...

Dropping low-margin products/services could mean companies stop making small websites or apps for local companies. Keeping organized could mean making sure AWS assets are tagged and tracked or that all code is version-controlled with proper branches and deployments. Knowing the numbers could mean being able to say at any given point in time how your revenue stacks up against your costs (again maybe with AWS). Keeping things clean could mean consistent file organization, tidy personal machines or servers without stray SSH keys or software.

I definitely feel like whenever I watch shows like The Profit or Restaurant Impossible I learn the same lessons: personal issues manifest and destroy, keep an eye on margins, don't be afraid to manage, keep things tidy.

[eldavido]

I think about this a lot. And I don't think it transfers at all.

Software is a design business. You win by building the thing people want and selling a lot of it. The hard problem is identifying a real need and getting whatever it is to market ahead of your competition. If you're doing it right, cost control isn't that important.

By way of contrast, any business that touches inventory, you're dealing with suppliers, margins, shipping, waste and spoilage, credit lines, labor management (unions!) and a whole bunch of other stuff with zero analog in software. Most people aren't that good at this stuff or can't be bothered with it so industries just sort of go on and on without much change.

The thing most people outside of software aren't used to, is that software is INTENSELY competitive. People in older industries talk about "going global" like it's something they have to do. Software people should rightfully laugh at that. When you make bits, you're competing with the entire world from day 1. Most other companies just don't have nearly this level of competition and would get crushed by it, except that "local" is usually somewhat of a barrier to competition.

[newfoundglory]

I’d say most software isn’t global because it works with the real world - uber, Amazon, Facebook, all of them started local.

[joshmarlow]

You may be interested in "The Phoenix Project" [0] which tries to apply some lessons from factory management to IT organizations.

My biggest take-away (and it's served me well as a team lead) is minimize work in progress (WIP). In practice, that meant encouraging contributors to focus on getting opened PRs reviewed/merged/deployed rather than opening new ones - which has cascading benefits.

A related takeaway is that when resources (engineers, key machines) are planned to be at capacity, they have no slack for dealing with unplanned work, so it's good to plan for resources to be under-utilized at certain times so that they can be more agile.

I've never seen "The Profit" but I'm looking forward to watching it now!

[0] - https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...

EDIT: for link to book

[jaggederest]

My tongue-in-cheek simple rules:

1. Charge more for your product than the marginal cost to provide it to customers.

2. Get rid of complexity and overhead, streamline systems.

3. Manage your cashflow, I've seen amazing things done with e.g. trade credit, annual subscriptions, etc. to turn a break-even business into a cash-flow-positive business.