4 ms·

Part of the problem is that software is never really "done" -- older software needs a ton of maintenance and support, and new features are restricted by existin

by csense 11y ago

Part of the problem is that software is never really "done" -- older software needs a ton of maintenance and support, and new features are restricted by existing code's technology choices, design decisions and architecture. So pennies in later systems never fall onto the truck and get delivered to the customer, rather they fall into the final state and randomly teleport back into earlier stages as teams that implemented them start getting support work. Unfortunately you're not going to be as productive when you're developing a new product against a background of supporting multiple existing products / customers, as you were when you were developing your startup's initial product without much else going on.

humanrebar 11y ago
> Part of the problem is that software is never really "done" Absolutely. The cognitive dissonance is bad enough that we might be overdue for a change in vocabulary, starting with the word "done". Even hypothetically perfect code needs to get ported to a new architecture, OS, VM, and/or compiler at some point. I think we, as technical experts, do a terrible job explaining that every piece of code old and new has an ongoing cost. The discussion points should be about which costs are higher and whether trade-offs are worth it. Are the ongoing costs (is the team even aware of what they are?) lower than the cost of change (how do we know it was worth it? can we change our mind if it wasn't?). While the article brings up many good points about bottlenecks, estimation, and allocation of resources, I find that bad mental models of how software development works costs far more, albeit in subtler ways, than "Heather can do 12 units of work but we only gave her 8 and she blocked a lot on task Alpha instead of moving on to something else". Though your mileage certainly varies.
- alsetmusic 11y ago
  Continuing that line of thinking, one of my epiphany moments when I first arrived at a dominant player was the acceptance that we would ship with bugs. The way to stay at the front of the race is to prioritize your bugs and fix the right ones in the time that you have because if you think you'll get them all, you'll never ship. Get the ones that have the highest probability of causing your customers pain and know that you aren't ignoring the ones that are scheduled for your next maintenance release. Debate intelligently if you think something needs to be reclassified as a higher priority and learn to accept that there might be a couple that you don't win so you can get on with covering as much of what remains as possible.
- Terr_ 11y ago
  > we, as technical experts, do a terrible job explaining that every piece of code old and new has an ongoing cost. It's always hard to find good metaphors for programming programming as a craft, but I liken it to a factory or campus. Even when it is "built" and producing value, there are always issues with maintenance and renovation and replacement. "Technical debt" isn't just maintenance costs, but the restrictions placed on what you can do next. Ran an electrical line straight across the lawn? Now you have to black-out a building to progress.
teekert 11y ago
"The perfect is the enemy of the good" is what we often tell each other.
bsbechtel 11y ago
Wouldn't this ongoing support requirement in software be analogous to customer service/maintenance departments at an auto dealer, or the customer service hotline for other manufacturing products? I wouldn't say this problem is unique for software.
pinaceae 11y ago
that is why software development is not engineering (yet). constructional engineering has the benefit of clear physical limits, you cannot fiddle with a building after its release too much - add more stuff on top and it will crash down. people get that, by now. same with software - everything gets added in, email, chat, video, whatever. then it becomes a bloated mess, and a new product, lean and simple, comes along. rinse, repeat. they will ruin Slack, for example, guaranteed, and not even that long from now. the thinking of constraints, of boundaries of growth, has not been established in software yet. UNIX had it, but that mindset got lost as moore's law kicked in. but the constraint is the human mind, groking what the fuck those millions line of code actually do.
- nawitus 11y ago
  Are you suggesting going back to waterfall development?
ryandrake 11y ago
Software can be "done". It depends on the software. Any embedded software that's not field-upgradable is done when the device ships. To take an extreme example, the software on a space probe that gets launched into space and cannot update itself definitely needs to have a "done" date.
- meesterdude 11y ago
  > the software on a space probe that gets launched into space and cannot update itself definitely needs to have a "done" date. Actually, those get updates too. As scary an idea as that is. NASA engineers are some crazy folk. But I don't disagree that software can be done. It depends on the software, and the supporting ecosystem just as much. A microwave doesn't need or get updates, but it's also not networked, or rendering across different browsers, or needing to support a lot of users. But I think in the larger sense, done is relative. There is always a vision, and growth. And deadlines. This isn't such a problem so long as you are always working at making it better. But if all you ever do is ship features and never address the underlying design... good luck.
  - antod 11y ago
    * > But I don't disagree that software can be done. It depends on the software, and the supporting ecosystem just as much. A microwave doesn't need or get updates, but it's also not networked, or rendering across different browsers, or needing to support a lot of users.* That's for the copy of the software deployed on a specific microwave. Presumably though the team that wrote that code are doing some ongoing work adding new features and fixing bugs for new model revisions and brand new models. As well as changes to keep their tooling and development environments up to date or at at least supportable.
- humanrebar 11y ago
  > Software can be "done".... Any embedded software that's not field-upgradable is done when the device ships. That's a perfect example of an that proves the rule. Saying that, even within that ecosystem, there are libraries, ports, oops-it-blew-up patches, builds against emulators because the hardware isn't ready, etc. You don't write a new codebase from scratch for every device you ship. Parts of that "done" code end up in next year's model.
jt2190 11y ago
Add to that the problem that "productive" is not the real goal. Businesses can survive and even thrive with sub-optimal processes as long as those processes deliver value that exceeds their cost. (We see this in early stage startups, i.e. "Do things that don't scale".) Needing a development process to run optimally in order to deliver value suggests that the marginal value may be far too small for a custom software solution.

by csense 11y ago

humanrebar 11y ago

> Part of the problem is that software is never really "done" Absolutely. The cognitive dissonance is bad enough that we might be overdue for a change in vocabulary, starting with the word "done". Even hypothetically perfect code needs to get ported to a new architecture, OS, VM, and/or compiler at some point. I think we, as technical experts, do a terrible job explaining that every piece of code old and new has an ongoing cost. The discussion points should be about which costs are higher and whether trade-offs are worth it. Are the ongoing costs (is the team even aware of what they are?) lower than the cost of change (how do we know it was worth it? can we change our mind if it wasn't?). While the article brings up many good points about bottlenecks, estimation, and allocation of resources, I find that bad mental models of how software development works costs far more, albeit in subtler ways, than "Heather can do 12 units of work but we only gave her 8 and she blocked a lot on task Alpha instead of moving on to something else". Though your mileage certainly varies.

alsetmusic 11y ago
Continuing that line of thinking, one of my epiphany moments when I first arrived at a dominant player was the acceptance that we would ship with bugs. The way to stay at the front of the race is to prioritize your bugs and fix the right ones in the time that you have because if you think you'll get them all, you'll never ship. Get the ones that have the highest probability of causing your customers pain and know that you aren't ignoring the ones that are scheduled for your next maintenance release. Debate intelligently if you think something needs to be reclassified as a higher priority and learn to accept that there might be a couple that you don't win so you can get on with covering as much of what remains as possible.
Terr_ 11y ago
> we, as technical experts, do a terrible job explaining that every piece of code old and new has an ongoing cost. It's always hard to find good metaphors for programming programming as a craft, but I liken it to a factory or campus. Even when it is "built" and producing value, there are always issues with maintenance and renovation and replacement. "Technical debt" isn't just maintenance costs, but the restrictions placed on what you can do next. Ran an electrical line straight across the lawn? Now you have to black-out a building to progress.

teekert 11y ago

"The perfect is the enemy of the good" is what we often tell each other.

bsbechtel 11y ago

Wouldn't this ongoing support requirement in software be analogous to customer service/maintenance departments at an auto dealer, or the customer service hotline for other manufacturing products? I wouldn't say this problem is unique for software.

pinaceae 11y ago

that is why software development is not engineering (yet). constructional engineering has the benefit of clear physical limits, you cannot fiddle with a building after its release too much - add more stuff on top and it will crash down. people get that, by now. same with software - everything gets added in, email, chat, video, whatever. then it becomes a bloated mess, and a new product, lean and simple, comes along. rinse, repeat. they will ruin Slack, for example, guaranteed, and not even that long from now. the thinking of constraints, of boundaries of growth, has not been established in software yet. UNIX had it, but that mindset got lost as moore's law kicked in. but the constraint is the human mind, groking what the fuck those millions line of code actually do.

nawitus 11y ago
Are you suggesting going back to waterfall development?

ryandrake 11y ago

Software can be "done". It depends on the software. Any embedded software that's not field-upgradable is done when the device ships. To take an extreme example, the software on a space probe that gets launched into space and cannot update itself definitely needs to have a "done" date.

meesterdude 11y ago
> the software on a space probe that gets launched into space and cannot update itself definitely needs to have a "done" date. Actually, those get updates too. As scary an idea as that is. NASA engineers are some crazy folk. But I don't disagree that software can be done. It depends on the software, and the supporting ecosystem just as much. A microwave doesn't need or get updates, but it's also not networked, or rendering across different browsers, or needing to support a lot of users. But I think in the larger sense, done is relative. There is always a vision, and growth. And deadlines. This isn't such a problem so long as you are always working at making it better. But if all you ever do is ship features and never address the underlying design... good luck.
- antod 11y ago
  * > But I don't disagree that software can be done. It depends on the software, and the supporting ecosystem just as much. A microwave doesn't need or get updates, but it's also not networked, or rendering across different browsers, or needing to support a lot of users.* That's for the copy of the software deployed on a specific microwave. Presumably though the team that wrote that code are doing some ongoing work adding new features and fixing bugs for new model revisions and brand new models. As well as changes to keep their tooling and development environments up to date or at at least supportable.
humanrebar 11y ago
> Software can be "done".... Any embedded software that's not field-upgradable is done when the device ships. That's a perfect example of an that proves the rule. Saying that, even within that ecosystem, there are libraries, ports, oops-it-blew-up patches, builds against emulators because the hardware isn't ready, etc. You don't write a new codebase from scratch for every device you ship. Parts of that "done" code end up in next year's model.

jt2190 11y ago

Add to that the problem that "productive" is not the real goal. Businesses can survive and even thrive with sub-optimal processes as long as those processes deliver value that exceeds their cost. (We see this in early stage startups, i.e. "Do things that don't scale".) Needing a development process to run optimally in order to deliver value suggests that the marginal value may be far too small for a custom software solution.