9 ms·

What If? Driven Development

50 points by ingve 4y ago

ouid 4y ago
The example root cause is not even close to the "root cause", this is just the root cause that auto-dealerships would like to sell you. An additional why yieles something like: 6) Regular maintenance is often more expensive than repairing the car on failure, or buying a new car, and when maintenance predicta that a part is going to fail, the solution is still to replace it
- moring 4y ago
  Also, there often isn't a single "root" cause. Causality is a DAG. To start, the alternator belt can simply break even when well-maintained. It can break when under stress due to another part that isn't working correctly. The alternator belt could be a well-known source of problems in this particular model, or could have been replaced by a cheap one by a previous owner, or could have been exposed to corrosive airborne chemicals due to where the vehicle is typically parked. Likewise, in the ID parsing example, there is a quick jump to "It should ignore values past &, Because & is the field separator" without asking why a field separator gets into this parsing function at all. Is this function expected to handle strings that contain such a separator? (All code operates on certain assumptions, so it is futile to expect a parsing function to handle "all" cases -- there simply isn't a useful definition of "all" that could be the basis for that.)
- taeric 4y ago
  I love when folks argue that I should replace my working vehicle because the engine may go out and I would have to do a several thousand dollar replacement. Which, yeah, would suck. But how in the world did we start accepting the path to financing a new vehicle as the answer?
eterps 4y ago
Reminds me of: https://github.com/roc-lang/roc/blob/main/FAQ.md#why-doesnt-roc-have-a-maybe-or-option-or-optional-type-or-null-or-nil-or-undefined https://github.com/roc-lang/roc/blob/main/FAQ.md#why-doesnt-...
- nivertech 4y ago
  Error Handling in Elm https://twitter.com/nivertech/status/1413392990211657729 https://twitter.com/nivertech/status/1413392990211657729 It looks like Maybe/Option is just a Booleans-in-disguise. As I'm in favor of banning Booleans (and if-statements), so it makes sense to ban Maybe/Option-s also.
  - mrkeen 4y ago
    > It looks like Maybe/Option is just a Booleans-in-disguise. This is a unique take. Care to expand?
    - 0x457 4y ago
      Not the person you're asking, but I may have insight. Realistically, it's no different, checking if something is null or None. Yeah, some languages have a lot of sugar around optional thanks to rich type systems. Imagine the following pseudo rust code: if let Some(x) = x {} is not that different from if x != null {} Or any other type of boolean check. I think you have to be around optional long enough to understand the benefits.
      - mrkeen 4y ago
        > Realistically, it's no different, checking if something is null or None. That is correct. However, what languages with null lack is a way to say "See this String here? This is actually a String - not the absence of a String". It is nonsense to encode both A and lack-of-A as A.
        0x457 4y ago
        Yeah, and it's annoying. One of my most hated things about proto3 - is this string empty or just not set? (they added optional back now, but everything is already optional)
      - mathgladiator 4y ago
        But it is different because you can't dereference x without the check. In other words, you can't really make an accident. My language has maybe<T>, and I have automatic "re-wrapping" (not sure if there is a better term). where For example, with record R { int x; } maybe<R> r; I can access r.x yet the type is maybe<int>.
ChrisMarshallNY 4y ago
> But to prevent the car breaking in future, you need to proceed to 4 and 5, to discover that the car needed more regular maintainence. That's the theory behind highly mature CMMI levels. 5 means ongoing process analysis. That said, I hate CMMI (and I took the course, and drank the Kool-Aid). It's hunting mice with a ten-gauge, for almost every project, excepting really large, multidisciplinary ones. I have worked on those (that were badly in need of process maturity). Most projects that I've worked on; even fairly ambitious shipping products, would have benefitted from improved process maturity, but CMMI 4/5 or ISO9001 were way too burdensome. Agile, I think, has tried to improve process, but it has been turned into something that I don't think was originally envisioned.
- AstralStorm 4y ago
  Unless you happen to find yourself coding safety critical software. Such as in actual medical industry where failures can cost life.
  - ChrisMarshallNY 4y ago
    Yup. Good point. I suspect that NASA is CMMI Level 6.
pphysch 4y ago
Correctness advocates like the author tend to take the concept of "correct" for granted. 99% of software projects don't have a reliable definition of "correct". They don't have a watertight ontology that you can infer types from. Requirements continuously change. Your "Whys" quickly end with "because so-and-so said so", and will change tomorrow. "What if?" Driven Development presumes that there is a finite and known set of states that you can design around. Most software development (outside of extremely well-studied domains, like financial exchanges and aerospace) occurs in the absence of well-defined specifications. That's the fundamental reason why correctness-oriented paradigms and languages aren't popular and never will be. And that's okay.
- goostavos 4y ago
  I'll give a slightly different take. I work on large financial systems at $MegaCorp. Even though requirements change all the time (often because "the government said so"), are ephemeral at best, and frequently contradictory due crossing entire teams, orgs, and charters.... Stealing every possible tool that can move the needle towards "correctness" has been crazy valuable in my experience. I've gotten on board the TLA+ train. Just the act of formally specifying what you do know makes everything you don't painfully obvious. Formal models also make dealing with that constant change easier, because The Rules live in one concrete place, in a formal modeling language, and free from the ambiguities that requirements expressed in English prose are subject to. It's not a perfect solution, but it can help cut through the noise.
  - pphysch 4y ago
    More power to you in specifying your processes. A potential issue here is that your bosses and other stakeholders aren't part of the specification meta-process. Can you talk TLA+ with your boss? What about your boss's boss? Do they even care? A bad specification is worse than no specification; this was one of the lessons of OOP-mania (a rigid ontology works great, until it doesn't, and then it's a disaster). An ostensibly correct "specification" inferred by a lone engineer could become Wrong tomorrow after stakeholder input. That's why I would recommend against these sort of correctness-oriented paradigms unless there is widespread buy-in and understanding from your stakeholders, company culture, etc. Of course there is merit to using tools like TLA+ to model distributed systems and assist development, but that shouldn't be conflated with having a well-defined specification from the get-go.
kstenerud 4y ago
> All this, without touching any tests. I didn’t need to - because the types provided the direction. Which is all great and wonderful - until things change, and requests can suddenly come in without an ID - meaning that you must assign them an ID in your response. Not so easy to model using only the type system! And then later as session support is added, there are now two IDs, but one of them must be omitted if the session is not already active in the system. So now you must either make your request aware of the session system so it can check, or you must move the validation out of the request. Your type system is no longer helping you avoid erroneous conditions, and your lack of tests leaves you exposed. It's all great when the system is small and easy to model...
- turboponyy 4y ago
  Depends on the type system - sounds trivial in dependently typed languages.
- angarg12 4y ago
  Here is a sharp take in the types vs tests debate https://www.destroyallsoftware.com/talks/ideology https://www.destroyallsoftware.com/talks/ideology
  - drewcoo 4y ago
    Now do one on attempting to make a simple point via scannable/searchable text essays versus video-only content. I take a hard stance on that debate.
- mrkeen 4y ago
  > Which is all great and wonderful - until things change, and requests can suddenly come in without an ID But this is where type systems shine! You create a RequestWithoutId and let the boundary accept it (per your scenario). Hit compile and see what fails, in this case, calling the next method into the system will fail, because it expected a different type. Now you can choose to keep plumbing RequestWithoutId through the system - guided only by the type-checker, or you can write a RequestWithoutId->RequestWithId implementation. If your system functions correctly for-all RequestWithId, and you can make a conversion for-all RequestWithoutIds, then your system will function correctly for-all RequestWithoutIds. But can you turn a RequestWithoutId into a RequestWithId? Inspect the type of Id. If it's a UUID, it's most likely safe to generate in-place, and you're gold. If it's a String or an Int or an Any, then it's no longer mechanical and you probably need to start thinking.
robertoandred 4y ago
A hyphen, a hyphen, my kingdom for a hyphen.
d--b 4y ago
Maybe the author doesn’t realize this but “what-if-driven development” is one of the worst programming advice one can give. The problem is that it gets interpreted as “I’ve been asked xxx but what if what they really want is yyy”. And this leads to missed requirements, premature optimization, and all other evils.
- kuratkull 4y ago
  “I’ve been asked xxx but what if what they really want is yyy” - in my experience they usually want yyy, xxx is just how they managed to write it down using existing terminology/environment.
- moritzwarhier 4y ago
  I agree, but I think this is one of these topics where company structure, the domain of the project and the mindset of participating developers all play into what "what-if-driven" means. 1. Sure, never add code and complexity for features that were never requested. Don't implement "anticipated requirements" 2. Sometimes, clients or stakeholders need to be reminded of a bigger picture to make clear that the design decisions they suggest would cause hard-to-maintain code, security problems or bad UX, proposing to modify or clarify the requirements. 3. I'll try to add some (wildly different) examples to 2: - This form needs no server-side validation as long as it can only be submitted with a valid login. - This form does not need a save button. Let's just save on input / field change (not regarding context and field types, or integrity constraints, or UX in edge cases, or complexity) - We already have this similar-looking UI element, so we can just reuse and adapt it - Can't we just let the customer define validation rules in an excel sheet using a very specific syntax that we define - Please use this combobox/multiselect design and implement it perfectly. It's beautiful. (Design has no indication of selected values while closed) - No user will ever click this button so fast, let's ignore that case There are some bogus examples in there where most developers would seek dialogue to improve on the requirements, or which wouldn't occur given a healthy PM and development culture. Or would they?
deleted 4y ago
[deleted]

50 points by ingve 4y ago

ouid 4y ago

The example root cause is not even close to the "root cause", this is just the root cause that auto-dealerships would like to sell you. An additional why yieles something like: 6) Regular maintenance is often more expensive than repairing the car on failure, or buying a new car, and when maintenance predicta that a part is going to fail, the solution is still to replace it

moring 4y ago
Also, there often isn't a single "root" cause. Causality is a DAG. To start, the alternator belt can simply break even when well-maintained. It can break when under stress due to another part that isn't working correctly. The alternator belt could be a well-known source of problems in this particular model, or could have been replaced by a cheap one by a previous owner, or could have been exposed to corrosive airborne chemicals due to where the vehicle is typically parked. Likewise, in the ID parsing example, there is a quick jump to "It should ignore values past &, Because & is the field separator" without asking why a field separator gets into this parsing function at all. Is this function expected to handle strings that contain such a separator? (All code operates on certain assumptions, so it is futile to expect a parsing function to handle "all" cases -- there simply isn't a useful definition of "all" that could be the basis for that.)
taeric 4y ago
I love when folks argue that I should replace my working vehicle because the engine may go out and I would have to do a several thousand dollar replacement. Which, yeah, would suck. But how in the world did we start accepting the path to financing a new vehicle as the answer?

eterps 4y ago

Reminds me of: https://github.com/roc-lang/roc/blob/main/FAQ.md#why-doesnt-roc-have-a-maybe-or-option-or-optional-type-or-null-or-nil-or-undefined https://github.com/roc-lang/roc/blob/main/FAQ.md#why-doesnt-...

nivertech 4y ago
Error Handling in Elm https://twitter.com/nivertech/status/1413392990211657729 https://twitter.com/nivertech/status/1413392990211657729 It looks like Maybe/Option is just a Booleans-in-disguise. As I'm in favor of banning Booleans (and if-statements), so it makes sense to ban Maybe/Option-s also.
- mrkeen 4y ago
  > It looks like Maybe/Option is just a Booleans-in-disguise. This is a unique take. Care to expand?
  - 0x457 4y ago
    Not the person you're asking, but I may have insight. Realistically, it's no different, checking if something is null or None. Yeah, some languages have a lot of sugar around optional thanks to rich type systems. Imagine the following pseudo rust code: if let Some(x) = x {} is not that different from if x != null {} Or any other type of boolean check. I think you have to be around optional long enough to understand the benefits.
    - mrkeen 4y ago
      > Realistically, it's no different, checking if something is null or None. That is correct. However, what languages with null lack is a way to say "See this String here? This is actually a String - not the absence of a String". It is nonsense to encode both A and lack-of-A as A.
      - 0x457 4y ago
        Yeah, and it's annoying. One of my most hated things about proto3 - is this string empty or just not set? (they added optional back now, but everything is already optional)
    - mathgladiator 4y ago
      But it is different because you can't dereference x without the check. In other words, you can't really make an accident. My language has maybe<T>, and I have automatic "re-wrapping" (not sure if there is a better term). where For example, with record R { int x; } maybe<R> r; I can access r.x yet the type is maybe<int>.

ChrisMarshallNY 4y ago

> But to prevent the car breaking in future, you need to proceed to 4 and 5, to discover that the car needed more regular maintainence. That's the theory behind highly mature CMMI levels. 5 means ongoing process analysis. That said, I hate CMMI (and I took the course, and drank the Kool-Aid). It's hunting mice with a ten-gauge, for almost every project, excepting really large, multidisciplinary ones. I have worked on those (that were badly in need of process maturity). Most projects that I've worked on; even fairly ambitious shipping products, would have benefitted from improved process maturity, but CMMI 4/5 or ISO9001 were way too burdensome. Agile, I think, has tried to improve process, but it has been turned into something that I don't think was originally envisioned.

AstralStorm 4y ago
Unless you happen to find yourself coding safety critical software. Such as in actual medical industry where failures can cost life.
- ChrisMarshallNY 4y ago
  Yup. Good point. I suspect that NASA is CMMI Level 6.

pphysch 4y ago

Correctness advocates like the author tend to take the concept of "correct" for granted. 99% of software projects don't have a reliable definition of "correct". They don't have a watertight ontology that you can infer types from. Requirements continuously change. Your "Whys" quickly end with "because so-and-so said so", and will change tomorrow. "What if?" Driven Development presumes that there is a finite and known set of states that you can design around. Most software development (outside of extremely well-studied domains, like financial exchanges and aerospace) occurs in the absence of well-defined specifications. That's the fundamental reason why correctness-oriented paradigms and languages aren't popular and never will be. And that's okay.

goostavos 4y ago
I'll give a slightly different take. I work on large financial systems at $MegaCorp. Even though requirements change all the time (often because "the government said so"), are ephemeral at best, and frequently contradictory due crossing entire teams, orgs, and charters.... Stealing every possible tool that can move the needle towards "correctness" has been crazy valuable in my experience. I've gotten on board the TLA+ train. Just the act of formally specifying what you do know makes everything you don't painfully obvious. Formal models also make dealing with that constant change easier, because The Rules live in one concrete place, in a formal modeling language, and free from the ambiguities that requirements expressed in English prose are subject to. It's not a perfect solution, but it can help cut through the noise.
- pphysch 4y ago
  More power to you in specifying your processes. A potential issue here is that your bosses and other stakeholders aren't part of the specification meta-process. Can you talk TLA+ with your boss? What about your boss's boss? Do they even care? A bad specification is worse than no specification; this was one of the lessons of OOP-mania (a rigid ontology works great, until it doesn't, and then it's a disaster). An ostensibly correct "specification" inferred by a lone engineer could become Wrong tomorrow after stakeholder input. That's why I would recommend against these sort of correctness-oriented paradigms unless there is widespread buy-in and understanding from your stakeholders, company culture, etc. Of course there is merit to using tools like TLA+ to model distributed systems and assist development, but that shouldn't be conflated with having a well-defined specification from the get-go.

kstenerud 4y ago

> All this, without touching any tests. I didn’t need to - because the types provided the direction. Which is all great and wonderful - until things change, and requests can suddenly come in without an ID - meaning that you must assign them an ID in your response. Not so easy to model using only the type system! And then later as session support is added, there are now two IDs, but one of them must be omitted if the session is not already active in the system. So now you must either make your request aware of the session system so it can check, or you must move the validation out of the request. Your type system is no longer helping you avoid erroneous conditions, and your lack of tests leaves you exposed. It's all great when the system is small and easy to model...

turboponyy 4y ago
Depends on the type system - sounds trivial in dependently typed languages.
angarg12 4y ago
Here is a sharp take in the types vs tests debate https://www.destroyallsoftware.com/talks/ideology https://www.destroyallsoftware.com/talks/ideology
- drewcoo 4y ago
  Now do one on attempting to make a simple point via scannable/searchable text essays versus video-only content. I take a hard stance on that debate.
mrkeen 4y ago
> Which is all great and wonderful - until things change, and requests can suddenly come in without an ID But this is where type systems shine! You create a RequestWithoutId and let the boundary accept it (per your scenario). Hit compile and see what fails, in this case, calling the next method into the system will fail, because it expected a different type. Now you can choose to keep plumbing RequestWithoutId through the system - guided only by the type-checker, or you can write a RequestWithoutId->RequestWithId implementation. If your system functions correctly for-all RequestWithId, and you can make a conversion for-all RequestWithoutIds, then your system will function correctly for-all RequestWithoutIds. But can you turn a RequestWithoutId into a RequestWithId? Inspect the type of Id. If it's a UUID, it's most likely safe to generate in-place, and you're gold. If it's a String or an Int or an Any, then it's no longer mechanical and you probably need to start thinking.

robertoandred 4y ago

A hyphen, a hyphen, my kingdom for a hyphen.

d--b 4y ago

Maybe the author doesn’t realize this but “what-if-driven development” is one of the worst programming advice one can give. The problem is that it gets interpreted as “I’ve been asked xxx but what if what they really want is yyy”. And this leads to missed requirements, premature optimization, and all other evils.

kuratkull 4y ago
“I’ve been asked xxx but what if what they really want is yyy” - in my experience they usually want yyy, xxx is just how they managed to write it down using existing terminology/environment.
moritzwarhier 4y ago
I agree, but I think this is one of these topics where company structure, the domain of the project and the mindset of participating developers all play into what "what-if-driven" means. 1. Sure, never add code and complexity for features that were never requested. Don't implement "anticipated requirements" 2. Sometimes, clients or stakeholders need to be reminded of a bigger picture to make clear that the design decisions they suggest would cause hard-to-maintain code, security problems or bad UX, proposing to modify or clarify the requirements. 3. I'll try to add some (wildly different) examples to 2: - This form needs no server-side validation as long as it can only be submitted with a valid login. - This form does not need a save button. Let's just save on input / field change (not regarding context and field types, or integrity constraints, or UX in edge cases, or complexity) - We already have this similar-looking UI element, so we can just reuse and adapt it - Can't we just let the customer define validation rules in an excel sheet using a very specific syntax that we define - Please use this combobox/multiselect design and implement it perfectly. It's beautiful. (Design has no indication of selected values while closed) - No user will ever click this button so fast, let's ignore that case There are some bogus examples in there where most developers would seek dialogue to improve on the requirements, or which wouldn't occur given a healthy PM and development culture. Or would they?

deleted 4y ago

[deleted]