3 ms·

I think the solution depends on the type of problem you have. If your problem is reliability then increased testing and handling edge cases (or avoiding code th

by xmprt 2y ago

I think the solution depends on the type of problem you have. If your problem is reliability then increased testing and handling edge cases (or avoiding code that even hits those edge cases) will help. But if the problem is uncertain requirements, then more testing will just add to the amount of code you're going to throw away and refactoring will only become harder. The problem is that often times in software engineering both problems happen in tandem - you're improving reliability while also trying to change how your system works as new feature requests come in. The solutions are almost diametrically opposed.

IanCal 2y ago
More testing can help show the uncertain requirements in more concrete ways. What should happen in these cases? Now we have this list in one place does it seem unusual or inconsistent? Bonus points if you can have more general tests (like property based ones) that let you test broader statements. I always fall back to this example but I built a testing lib for a stack we had a UI framework in. It helped because we could write a test like: "For any UI, if the user moves right and the focus changes then when the user moves left the focus goes back to the original item" And then we found a bug in the spec with: For any series of API calls that build a UI, and any series of user interactions, one of the following is always true * There are no items in the UI * There is exactly one item with focus Being able to specify things at this level resulted in us being able to define the major behaviours succinctly and that made it easier to have them be consistent.
- Nemi 2y ago
  I see the parent commenters point as being more of the “can’t see the forest for the trees” type of uncertain requirements. To go into more detail, it is the type of uncertainty about whether you are actually solving the right problem or if it really is a problem. While what you suggest does help ferret this out, what you are suggesting can also prolong the process of getting the code in front of a real end user to see if they use or adopt it the way you are expecting. It allows you to quickly throw away ALL the code and get to solving the right problem. Another way to put it, the more the problem space is unknown, the faster you should get the code in front of someone and delay the edge-case discoveries.

by xmprt 2y ago

IanCal 2y ago

More testing can help show the uncertain requirements in more concrete ways. What should happen in these cases? Now we have this list in one place does it seem unusual or inconsistent? Bonus points if you can have more general tests (like property based ones) that let you test broader statements. I always fall back to this example but I built a testing lib for a stack we had a UI framework in. It helped because we could write a test like: "For any UI, if the user moves right and the focus changes then when the user moves left the focus goes back to the original item" And then we found a bug in the spec with: For any series of API calls that build a UI, and any series of user interactions, one of the following is always true * There are no items in the UI * There is exactly one item with focus Being able to specify things at this level resulted in us being able to define the major behaviours succinctly and that made it easier to have them be consistent.

Nemi 2y ago
I see the parent commenters point as being more of the “can’t see the forest for the trees” type of uncertain requirements. To go into more detail, it is the type of uncertainty about whether you are actually solving the right problem or if it really is a problem. While what you suggest does help ferret this out, what you are suggesting can also prolong the process of getting the code in front of a real end user to see if they use or adopt it the way you are expecting. It allows you to quickly throw away ALL the code and get to solving the right problem. Another way to put it, the more the problem space is unknown, the faster you should get the code in front of someone and delay the edge-case discoveries.