3 ms·

Thank you for this comment. I was reading the article and couldn’t agree more. Theres a place for hacking towards a goal theres a place for reliability. If you

by mr-ron 4y ago

Thank you for this comment. I was reading the article and couldn’t agree more. Theres a place for hacking towards a goal theres a place for reliability. If you can only do one, then you are only half an engineer. If success isn’t defined and these paths are left to individuals, then it seems like you have a problem with project scope and product management.

lightbendover 4y ago
> Theres a place for hacking towards a goal theres a place for reliability. Most engineers and managers believe this. Nobody agrees where that place is located.
maerF0x0 4y ago
> hacking towards a goal theres a place for reliability Yes, but in professional software engineering[1] where the roadmap exceeds 12 weeks, and the cost of a bug is non-zero, and you realize that in software engineering we do far more Reads than Writes to the code), then there are also dominant and dominated strategies[2]. Prototypes should be crafted from large blocks like low/no code solutions or generation... But once we have validation typically this is where good software architecture, and systems architecture come into play. Both the properties of the code that is written eg SOLID[3], and also the emergent properties of a collection of implementations. All of this feeds into the total ROI of the engineering process. Quality issues lead to both churn[4], and slower roadmap (which means you lose out to competitors). People tend to think that "just make it work" is faster, but time and time again I've seen that only to be true in approximately the 6-12week time span. Hacky is fast until it needs to change, until someone else has to read it, until you realize there is a bug. As well, it turns out that expertise in doing things well makes you faster the next time you go to do it well. I sometimes wonder if people doing things hacky/poorly is only faster because they've practiced it so many times? Often times well structured code is easier to read/write, fewer lines, easier to test, easier to morph into the next evolution. As we practice coding styles that give us these properties, we get faster at it. So while yes there are tradeoffs, I don't think there are very many ways to take on lower quality implementation for time speed ups, both short and long run. Yes of course there are features you just don't need (your blog doesnt need to use CRDTs to update your post). And that tends to just having discipline in your Executive/Product team-- only ask for something if you have the research to make you think it will work, and the spine to stick it out to implementation. Engineers can also focus on stopping making bespoke software for prototypes. Pre GA mock ups should probably be using almost entirely light weight proxies for the product -- ui mock ups, generated code, SQLLite/PostgREST, low/no code solutions etc. to get strong data about usage patterns, user's needs etc. [1]: "Software engineering is what happens to programming when you add time and other programmers." via https://research.swtch.com/vgo-eng https://research.swtch.com/vgo-eng .. I don't really care what you do in your spare time or on v0.0.0, but when we're on a journey as professionals to craft tools that 1000s to billions will rely on there's something more than just "it compiles, works on my machine" [2]: https://martinfowler.com/articles/is-quality-worth-cost.html https://martinfowler.com/articles/is-quality-worth-cost.html [3]: https://simple.wikipedia.org/wiki/SOLID_(object-oriented_design) https://simple.wikipedia.org/wiki/SOLID_(object-oriented_des... [4]: (which means you cannot pay high CAC because you'll lose them before recouping cost)
tremon 4y ago
If you can only do one, then you are only half an engineer In a proper engineering discipline, the only place for hacking towards a goal is within the confines of the lab.

by mr-ron 4y ago

lightbendover 4y ago

> Theres a place for hacking towards a goal theres a place for reliability. Most engineers and managers believe this. Nobody agrees where that place is located.

maerF0x0 4y ago

> hacking towards a goal theres a place for reliability Yes, but in professional software engineering[1] where the roadmap exceeds 12 weeks, and the cost of a bug is non-zero, and you realize that in software engineering we do far more Reads than Writes to the code), then there are also dominant and dominated strategies[2]. Prototypes should be crafted from large blocks like low/no code solutions or generation... But once we have validation typically this is where good software architecture, and systems architecture come into play. Both the properties of the code that is written eg SOLID[3], and also the emergent properties of a collection of implementations. All of this feeds into the total ROI of the engineering process. Quality issues lead to both churn[4], and slower roadmap (which means you lose out to competitors). People tend to think that "just make it work" is faster, but time and time again I've seen that only to be true in approximately the 6-12week time span. Hacky is fast until it needs to change, until someone else has to read it, until you realize there is a bug. As well, it turns out that expertise in doing things well makes you faster the next time you go to do it well. I sometimes wonder if people doing things hacky/poorly is only faster because they've practiced it so many times? Often times well structured code is easier to read/write, fewer lines, easier to test, easier to morph into the next evolution. As we practice coding styles that give us these properties, we get faster at it. So while yes there are tradeoffs, I don't think there are very many ways to take on lower quality implementation for time speed ups, both short and long run. Yes of course there are features you just don't need (your blog doesnt need to use CRDTs to update your post). And that tends to just having discipline in your Executive/Product team-- only ask for something if you have the research to make you think it will work, and the spine to stick it out to implementation. Engineers can also focus on stopping making bespoke software for prototypes. Pre GA mock ups should probably be using almost entirely light weight proxies for the product -- ui mock ups, generated code, SQLLite/PostgREST, low/no code solutions etc. to get strong data about usage patterns, user's needs etc. [1]: "Software engineering is what happens to programming when you add time and other programmers." via https://research.swtch.com/vgo-eng https://research.swtch.com/vgo-eng .. I don't really care what you do in your spare time or on v0.0.0, but when we're on a journey as professionals to craft tools that 1000s to billions will rely on there's something more than just "it compiles, works on my machine" [2]: https://martinfowler.com/articles/is-quality-worth-cost.html https://martinfowler.com/articles/is-quality-worth-cost.html [3]: https://simple.wikipedia.org/wiki/SOLID_(object-oriented_design) https://simple.wikipedia.org/wiki/SOLID_(object-oriented_des... [4]: (which means you cannot pay high CAC because you'll lose them before recouping cost)

tremon 4y ago

If you can only do one, then you are only half an engineer In a proper engineering discipline, the only place for hacking towards a goal is within the confines of the lab.