3 ms·

I hear you, but the promise and curse of software is that it is malleable. We are not building bridges with extremely clear and obvious success and failure, we

I hear you, but the promise and curse of software is that it is malleable. We are not building bridges with extremely clear and obvious success and failure, we are creating user experiences that vary subjectively based on who is using them and what other digital or physical realities they interact with. It's an alluring fantasy that if we just let the seasoned experts design everything and gave them space to work, we could have better quality systems. This is not how it plays out though, you get burned from both sides. Inevitably some non-technical leadership stakeholders ask very fair questions about "why can't we just...", and they're not wrong about what's possible, it's just different from what came before and it's not possible to rebuild entire digital systems as quickly as the good ideas come. On the implementation side, details matter and abstractions leak, seemingly small requirement changes undermine assumptions behind major architectural decisions. The idea that you can have a handful of seasonsed experts guiding an army of low-skill builders just doesn't work out with the same economics of physical construction. The details matter too much, and the implications of pure logic are too diverse to be covered by the equivalent of physical building codes.

0xbadcafebee 3y ago
> we are creating user experiences that vary subjectively based on who is using them and what other digital or physical realities they interact with I don't believe that. When you create a coffee shop, you build it to have a specific, repeatable, singular user experience. Some may like it more than others, but if the experience is really good, people will keep coming. You don't keep changing your coffee shop week to week for years on end. The maintenance is in things like cleaning the floor, not changing the shape of the coffee counter, tables and chairs. > seemingly small requirement changes undermine assumptions behind major architectural decisions That's just poor design. Commercial buildings are built large and open so that the business renting them has the flexibility to change things around in the space without calling a general contractor to rebuild the walls or raise the ceilings. If you build your software with tiny rooms and load-bearing walls in the interior, yeah, you're gonna need to rearchitect to get more tables in there. The fatal flaw in these software systems is they're effectively a single business, who's hiring a general contractor, to build an entirely new building, with very specific use cases in mind. When their business finally grows, or they just want more natural light in there, they rebuild the building. It's just bad business sense. In the very worst case we should be renting out a new building, not building or rebuilding one. Only the largest businesses should consider constructing new buildings, and even then, they should be building it to last for a decade or more. (And this isn't even about real estate, it's about their business requirements, wasting money on construction, and the risks of construction delays and failures)
- dasil003 3y ago
  I agree with your final sentence that businesses often undertake very ill-advised software projects. However I don't think the building analogy is very illuminating here; the thing about buildings is that while they have complexity, the costs, benefits and use cases are a lot more intuitive and can be explained to an FP&A professional who can use pretty standard methods to project potential outcomes across a wide range of projects. Software is not like this as there is no limit to the scope that can be built in to a single app. You don't have the constraints of physical space, materials and human use cases and locality. The "load-bearing" aspects of software are not just physical infrastructure with CPU/memory limits, but also fundamental choices in the data model, some things more than others, and what starts out as a casual choice can become load bearing if further construction builds on that assumption. Buildings don't have legacy data. > When you create a coffee shop, you build it to have a specific, repeatable, singular user experience. I can't tell if you're suggesting software should be built this way, but after 25 years in the consumer space in multiple startups, scaleups, and largish companies, I have never seen any software company succeed based on rigidly adhering to singular user experience in this way. Even when you can describe the experience simply, the details and tradeoffs are enormous, and companies that win are the ones that are able to iterate quickly without letting the quality degrade to the point that the wheels come off. Facebook vs Friendster vs MySpace is a pretty good example. In my own founding experience, I was able to bootstrap a streaming service to 6-figure subscribers over 8 years leaving behind a graveyard of failed competitors because they couldn't thread the needle between good UX, good engineering, and the right content investment. I'm sure it's different in well established and standardized corners of B2B and industrial software where you are not subject to the fickle nature of consumers, but in B2C you are default-dead if you insist on some kind of fixed requirement and long-term vision that doesn't change.

0xbadcafebee 3y ago

> we are creating user experiences that vary subjectively based on who is using them and what other digital or physical realities they interact with I don't believe that. When you create a coffee shop, you build it to have a specific, repeatable, singular user experience. Some may like it more than others, but if the experience is really good, people will keep coming. You don't keep changing your coffee shop week to week for years on end. The maintenance is in things like cleaning the floor, not changing the shape of the coffee counter, tables and chairs. > seemingly small requirement changes undermine assumptions behind major architectural decisions That's just poor design. Commercial buildings are built large and open so that the business renting them has the flexibility to change things around in the space without calling a general contractor to rebuild the walls or raise the ceilings. If you build your software with tiny rooms and load-bearing walls in the interior, yeah, you're gonna need to rearchitect to get more tables in there. The fatal flaw in these software systems is they're effectively a single business, who's hiring a general contractor, to build an entirely new building, with very specific use cases in mind. When their business finally grows, or they just want more natural light in there, they rebuild the building. It's just bad business sense. In the very worst case we should be renting out a new building, not building or rebuilding one. Only the largest businesses should consider constructing new buildings, and even then, they should be building it to last for a decade or more. (And this isn't even about real estate, it's about their business requirements, wasting money on construction, and the risks of construction delays and failures)

dasil003 3y ago
I agree with your final sentence that businesses often undertake very ill-advised software projects. However I don't think the building analogy is very illuminating here; the thing about buildings is that while they have complexity, the costs, benefits and use cases are a lot more intuitive and can be explained to an FP&A professional who can use pretty standard methods to project potential outcomes across a wide range of projects. Software is not like this as there is no limit to the scope that can be built in to a single app. You don't have the constraints of physical space, materials and human use cases and locality. The "load-bearing" aspects of software are not just physical infrastructure with CPU/memory limits, but also fundamental choices in the data model, some things more than others, and what starts out as a casual choice can become load bearing if further construction builds on that assumption. Buildings don't have legacy data. > When you create a coffee shop, you build it to have a specific, repeatable, singular user experience. I can't tell if you're suggesting software should be built this way, but after 25 years in the consumer space in multiple startups, scaleups, and largish companies, I have never seen any software company succeed based on rigidly adhering to singular user experience in this way. Even when you can describe the experience simply, the details and tradeoffs are enormous, and companies that win are the ones that are able to iterate quickly without letting the quality degrade to the point that the wheels come off. Facebook vs Friendster vs MySpace is a pretty good example. In my own founding experience, I was able to bootstrap a streaming service to 6-figure subscribers over 8 years leaving behind a graveyard of failed competitors because they couldn't thread the needle between good UX, good engineering, and the right content investment. I'm sure it's different in well established and standardized corners of B2B and industrial software where you are not subject to the fickle nature of consumers, but in B2C you are default-dead if you insist on some kind of fixed requirement and long-term vision that doesn't change.