4 ms·

Wow, the author of this seems to have an incredibly inflated sense of the value of his or her opinion, and seems to have very hostile preconceived notions of te

by mlthoughts2018 8y ago

Wow, the author of this seems to have an incredibly inflated sense of the value of his or her opinion, and seems to have very hostile preconceived notions of teammates’ errors and shallowness of their reasons for defending their choices. Not to mention that this part, at least, seems completely wrong, > “But an even slower way to uncover problems than argument is implementation.” Nope. Argument and architectural documents invite all manner of bikeshedding, often wasting time when you could just implement things and adjust the parts that end up causing problems. This is especially critical for taking a YAGNI approach. Architectural designs are such a slow waste of time that ends up leading you down a path where you don’t need various abstractions or extensibility hooks for reasons that only become clear after getting a minimal prototype going, looping in business team feedback, and seeing what fails or works. Basically, most arguments (in the way the author means it) are a really irritating form of premature optimization, and just implementing a first bad version is way more efficient.

agentultra 8y ago
Does this approach work for all software? I’m trying to think of whether I’d trust an autonomous vehicle if the authors followed this practice. There are methods to testing out designs that point us away from the diagrams and bikesheds. I’m drawing on my own experiences with various levels of formal methods of software construction.
- mlthoughts2018 8y ago
  The first bad version need not be production-facing or operating in a situation with the same costs or risks. In fact, ideally it isn’t, and the feedback of the bad versions that get iterated is what actually ends up saving you from releasing a production beta version or something that injures somebody because you thought you spec’d everything in the architectural documents and the test plan, but of course you didn’t. I’m not saying arch planning has no place, only that it’s not a substitute for iterating on prototypes, and arguing about arch plans is often a waste of time.
  - agentultra 8y ago
    Thank you for the clarification. I think I understand what you mean. Where it makes sense I work from prototypes up refining the specification as I go. Often a decent type system helps in this regard as it works as a loose, informal specification language. However for some problems I find programming languages incapable of expressing sufficiently high-level concepts and turn to model checking to assist me in shooting holes in my ideas. Either way; a working model seems more useful than arm-chair debates, hand-waving, and glorious boxes with arrows.
motohagiography 8y ago
This reasoning works until you need security, privacy, or any cryptography in the solution at all. Then it is farcically irresponsible. There is a technical play I have seen over and over again, which is just this: create a terrible prototype, add stakeholders with promises of functionality - use this momentum to bulldoze appeals to quality and common sense. It is a way certain kinds of engineers create a crisis that has them in the middle of it, and ensures they maintain control and indispensability in the ensuing chaos. If only there were a word or trope for it.
- mlthoughts2018 8y ago
  > “This reasoning works until you need security, privacy, or any cryptography in the solution at all.” This has not been true for me and my team generally, where privacy and security are up-front, primary concerns given the customer data that powers several machine learning features and data ingestion services we maintain. Treating these aspects of the problem as just yet another thing to throw into the prototype and iterate on has worked extremely well. Meanwhile other teams in my company have been caught out by nasty over-committment to certain security patterns that were then totally taken away from possibility when devops changed container-based deployments. Had they just not over-committed to a fixed, ahead-of-time design, they might not have been set back as many months of reworking it. > “create a terrible prototype, add stakeholders with promises of functionality - use this momentum to bulldoze appeals to quality and common sense.” Well I think you falsley mention quality and common sense at the end in a way that makes it seem like you’ve got an ax to grind against approaches that don’t prioritize long-term design, and that last sentence doesn’t fit in with the rest. Apart from that, I actually think the approach you describe is great and works really well to create robust and safe software, because it actually allows the team to generate buy-in from other business teams and product teams, and creates chances for the team to solve things in a high-quality and best practices focused way. If instead you slowly start out with architectural debates, product or business people assume the solution can’t be done on their unrealistic timeline and just force the team to pivot to the next unrealistic project, and you just flop around endlessly managing the tension between product people who want crappy prototypes that can be diff’d against changing requirements, and engineers who want stable requirements to pin down best-practices-compliant architectural documentation. In the end, overpromising on a threadbare prototype and working iteratively on it is way better, and is not at all some disingenuous attempt to create a fiefdom or a personal walled garden sort of project. It’s a technique for actually delivering the business result.
anotheryou 8y ago
This also changes with more contact points to end users. good discussions about ux can simplify it and uncover e.g. difficult states that need to be handled. If it proofs to be non trivial a mockup or clickdummy also helps. in general writing a high level concept and discussing it with stakeholders and developers i find super crucial for a smooth implementation.

agentultra 8y ago

Does this approach work for all software? I’m trying to think of whether I’d trust an autonomous vehicle if the authors followed this practice. There are methods to testing out designs that point us away from the diagrams and bikesheds. I’m drawing on my own experiences with various levels of formal methods of software construction.

mlthoughts2018 8y ago
The first bad version need not be production-facing or operating in a situation with the same costs or risks. In fact, ideally it isn’t, and the feedback of the bad versions that get iterated is what actually ends up saving you from releasing a production beta version or something that injures somebody because you thought you spec’d everything in the architectural documents and the test plan, but of course you didn’t. I’m not saying arch planning has no place, only that it’s not a substitute for iterating on prototypes, and arguing about arch plans is often a waste of time.
- agentultra 8y ago
  Thank you for the clarification. I think I understand what you mean. Where it makes sense I work from prototypes up refining the specification as I go. Often a decent type system helps in this regard as it works as a loose, informal specification language. However for some problems I find programming languages incapable of expressing sufficiently high-level concepts and turn to model checking to assist me in shooting holes in my ideas. Either way; a working model seems more useful than arm-chair debates, hand-waving, and glorious boxes with arrows.

motohagiography 8y ago

This reasoning works until you need security, privacy, or any cryptography in the solution at all. Then it is farcically irresponsible. There is a technical play I have seen over and over again, which is just this: create a terrible prototype, add stakeholders with promises of functionality - use this momentum to bulldoze appeals to quality and common sense. It is a way certain kinds of engineers create a crisis that has them in the middle of it, and ensures they maintain control and indispensability in the ensuing chaos. If only there were a word or trope for it.

mlthoughts2018 8y ago
> “This reasoning works until you need security, privacy, or any cryptography in the solution at all.” This has not been true for me and my team generally, where privacy and security are up-front, primary concerns given the customer data that powers several machine learning features and data ingestion services we maintain. Treating these aspects of the problem as just yet another thing to throw into the prototype and iterate on has worked extremely well. Meanwhile other teams in my company have been caught out by nasty over-committment to certain security patterns that were then totally taken away from possibility when devops changed container-based deployments. Had they just not over-committed to a fixed, ahead-of-time design, they might not have been set back as many months of reworking it. > “create a terrible prototype, add stakeholders with promises of functionality - use this momentum to bulldoze appeals to quality and common sense.” Well I think you falsley mention quality and common sense at the end in a way that makes it seem like you’ve got an ax to grind against approaches that don’t prioritize long-term design, and that last sentence doesn’t fit in with the rest. Apart from that, I actually think the approach you describe is great and works really well to create robust and safe software, because it actually allows the team to generate buy-in from other business teams and product teams, and creates chances for the team to solve things in a high-quality and best practices focused way. If instead you slowly start out with architectural debates, product or business people assume the solution can’t be done on their unrealistic timeline and just force the team to pivot to the next unrealistic project, and you just flop around endlessly managing the tension between product people who want crappy prototypes that can be diff’d against changing requirements, and engineers who want stable requirements to pin down best-practices-compliant architectural documentation. In the end, overpromising on a threadbare prototype and working iteratively on it is way better, and is not at all some disingenuous attempt to create a fiefdom or a personal walled garden sort of project. It’s a technique for actually delivering the business result.

anotheryou 8y ago

This also changes with more contact points to end users. good discussions about ux can simplify it and uncover e.g. difficult states that need to be handled. If it proofs to be non trivial a mockup or clickdummy also helps. in general writing a high level concept and discussing it with stakeholders and developers i find super crucial for a smooth implementation.