21 ms·

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

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?

actionscripted 9y ago
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.
jaggederest 9y ago
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.
tlb 9y ago
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 9y ago
  > 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_ 9y ago
    "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 https://news.ycombinator.com/item?id=12149515 and https://news.ycombinator.com/item?id=4328660 https://news.ycombinator.com/item?id=4328660 and http://www.romenrg.com/blog/2015/09/28/why-asking-developers-for-time-estimates-in-software-projects-is-a-terrible-idea-and-how-to-bypass-it-with-scrum/ http://www.romenrg.com/blog/2015/09/28/why-asking-developers... and The Mythical Man-Month, too.
    - GVIrish 9y ago
      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.
eldavido 9y ago
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 9y ago
  I’d say most software isn’t global because it works with the real world - uber, Amazon, Facebook, all of them started local.
joshmarlow 9y ago
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-Business/dp/1942788290/ref=sr_1_1?ie=UTF8&qid=1522875899&sr=8-1&keywords=the+phoenix+project+book https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine... EDIT: for link to book

actionscripted 9y ago

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.

jaggederest 9y ago

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.

tlb 9y ago

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 9y ago
> 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_ 9y ago
  "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 https://news.ycombinator.com/item?id=12149515 and https://news.ycombinator.com/item?id=4328660 https://news.ycombinator.com/item?id=4328660 and http://www.romenrg.com/blog/2015/09/28/why-asking-developers-for-time-estimates-in-software-projects-is-a-terrible-idea-and-how-to-bypass-it-with-scrum/ http://www.romenrg.com/blog/2015/09/28/why-asking-developers... and The Mythical Man-Month, too.
  - GVIrish 9y ago
    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.

eldavido 9y ago

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 9y ago
I’d say most software isn’t global because it works with the real world - uber, Amazon, Facebook, all of them started local.

joshmarlow 9y ago

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-Business/dp/1942788290/ref=sr_1_1?ie=UTF8&qid=1522875899&sr=8-1&keywords=the+phoenix+project+book https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine... EDIT: for link to book