6 ms·

I think it happens a lot more than people want to acknowledge. I worked on a discount calculating service with no prior knowledge.It was supposed to replicate

I think it happens a lot more than people want to acknowledge. I worked on a discount calculating service with no prior knowledge.It was supposed to replicate an existing system, so we went through the oroginal specs and general litterature to get a sense of what we were supposed to make. First day of test with a employee in the field, and it appears that they have specific calculation rules that are so obvious to them that it didn't warrant to be written. Welp. And a few iterations after we were still hitting blocks of "what ? didn't you know that in case of X you do Y?" due to us being outside of their field. Real world systems are hard. I'd still blame Amazon for not having caught these issues very early in the process, that's on them. But bugs and gross calculation errors are par for the course.

radicalbyte 5y ago
This is a universal problem, it's so universal that there's even a field of development which solves the problem - Domain-Driven Design. It's not exactly rocket-science either - you basically involve domain experts in the development proces directly, and codify their knowledge in a form that they can understand (be that very explicit models, or focussed domain-specific languages).
- rob74 5y ago
  Sounds good, but I can see several obstacles to this, especially when it's not an internal tool (and most of the time it isn't, unless you're Amazon): e.g. that the people talking to the customer are not the same people developing the application (maybe the people on the customer's side are not the real domain experts either); or that the customer has a mentality of "we hired these guys to develop a shiny new system for us, but our guys are much too busy to act as counselors for them" etc.
  - radicalbyte 5y ago
    In the first case: natural selection sort of works for products. If you want to survive you need to find a way. In the second case: that is a massive smell and time to find a new job. Which from the comments regards turnover at Amazon seems to be the case :-)
  - ajmurmann 5y ago
    > that the people talking to the customer are not the same people developing the application I think there can be some slack in this. I've had great success when product managers and UX designers worked closely tightly with engineers but were the only ones talking to customers/users. As long as their focus is on deeply understanding the domain and user needs it can work really well. I think XP describes this as something like a standin customer.
- makeitdouble 5y ago
  You're right, but I think the hard part is still to find people to bridge the gap between the system experts and domain experts. An extreme example would be if you're trying to introduce a logistics management system in a shop that was exclusively using pen and paper. You'll need someone with a foot in both world to even get to the point where they can look at your models and/or documentation and say "yes, it matches the business". Or one of the participant in the project will need to become that person (ideally the client, we can dream).
  - hvidgaard 5y ago
    Usually this is solved by including domain experts on the development teams. Their responsibility is not to program, but to document and verify that the test cases are adequate. This is well known, but often ignored because it's expensive.
  - withinboredom 5y ago
    As someone who has done this a few times from pen/paper/excel to actual DDD software, it's really not that hard to shoulder surf and ask lots of questions about edge cases. At least initially. Though my favorite answer to those questions is: "never happens." Thus you end up with `BobSaidNeverHappensException` just to be cute. But really, the software is there to solve a problem, so you end up shoulder surfing while the "expert" uses both systems simultaneously, and they're asking you questions and you're thinking about how you may rearrange the UI from their feedback. It's extremely iterative. The "domain expert" also becomes an expert with the software as they learn about all the things you implement.
- morelisp 5y ago
  Sorry, but domain-driven design is actually when you have "class Licensor; class Licensee; class RoyaltyPayment". What you're describing is competence and attention to detail, and that's too much to expect from development teams.
  - regularfry 5y ago
    And that's why DDD doesn't just involve development teams. It explicitly calls for people who are competent in the domain and know the details that need attention to be involved in the design process.
  - Aeolun 5y ago
    > that's too much to expect from development teams Wut? The development team is capable of dealing with that just fine. It’s the business unit throwing requirements over the fence and hoping it’ll magically be OK that’s the problem.
- AitchEmArsey 5y ago
  > Domain-Driven Design > It's not exactly rocket-science either I'd imagine that occasionally "rocket science" is exactly what it is!
  - IgorPartola 5y ago
    This always baffled me. Rocket science is basically F = GMm/d^2 with m changing over time as you burn fuel and also thrust vectoring. Where is the complexity?
    - hattar 5y ago
      Aerodynamics issues likely add a lot of complexity, though I’m sure there are plenty of other factors that make launching a rocket hard.
    - pc86 5y ago
      This might be the most stereotypically HN comment I've ever read. Not in a good way.
      - samatman 5y ago
        Well, if you picture a spherical, frictionless rocket scientist, in a vacuum...
    - ateng 5y ago
      If you just model rocket science as a point mass with variable m then yes… But it’s more than that. To name a few: * How does one raise the thrust temperature as high as possible without melting the engine to maximise thrust? (The burning temperature IS already higher than the engine material melting point) * how does one reduce the redundancy (both system wise and material wise) to minimise weight while ensuring the rocket won’t fail?
      - IgorPartola 5y ago
        Ah so you want aeronautical engineering, not rocket science!
deleted 5y ago
[deleted]

radicalbyte 5y ago

This is a universal problem, it's so universal that there's even a field of development which solves the problem - Domain-Driven Design. It's not exactly rocket-science either - you basically involve domain experts in the development proces directly, and codify their knowledge in a form that they can understand (be that very explicit models, or focussed domain-specific languages).

rob74 5y ago
Sounds good, but I can see several obstacles to this, especially when it's not an internal tool (and most of the time it isn't, unless you're Amazon): e.g. that the people talking to the customer are not the same people developing the application (maybe the people on the customer's side are not the real domain experts either); or that the customer has a mentality of "we hired these guys to develop a shiny new system for us, but our guys are much too busy to act as counselors for them" etc.
- radicalbyte 5y ago
  In the first case: natural selection sort of works for products. If you want to survive you need to find a way. In the second case: that is a massive smell and time to find a new job. Which from the comments regards turnover at Amazon seems to be the case :-)
- ajmurmann 5y ago
  > that the people talking to the customer are not the same people developing the application I think there can be some slack in this. I've had great success when product managers and UX designers worked closely tightly with engineers but were the only ones talking to customers/users. As long as their focus is on deeply understanding the domain and user needs it can work really well. I think XP describes this as something like a standin customer.
makeitdouble 5y ago
You're right, but I think the hard part is still to find people to bridge the gap between the system experts and domain experts. An extreme example would be if you're trying to introduce a logistics management system in a shop that was exclusively using pen and paper. You'll need someone with a foot in both world to even get to the point where they can look at your models and/or documentation and say "yes, it matches the business". Or one of the participant in the project will need to become that person (ideally the client, we can dream).
- hvidgaard 5y ago
  Usually this is solved by including domain experts on the development teams. Their responsibility is not to program, but to document and verify that the test cases are adequate. This is well known, but often ignored because it's expensive.
- withinboredom 5y ago
  As someone who has done this a few times from pen/paper/excel to actual DDD software, it's really not that hard to shoulder surf and ask lots of questions about edge cases. At least initially. Though my favorite answer to those questions is: "never happens." Thus you end up with `BobSaidNeverHappensException` just to be cute. But really, the software is there to solve a problem, so you end up shoulder surfing while the "expert" uses both systems simultaneously, and they're asking you questions and you're thinking about how you may rearrange the UI from their feedback. It's extremely iterative. The "domain expert" also becomes an expert with the software as they learn about all the things you implement.
morelisp 5y ago
Sorry, but domain-driven design is actually when you have "class Licensor; class Licensee; class RoyaltyPayment". What you're describing is competence and attention to detail, and that's too much to expect from development teams.
- regularfry 5y ago
  And that's why DDD doesn't just involve development teams. It explicitly calls for people who are competent in the domain and know the details that need attention to be involved in the design process.
- Aeolun 5y ago
  > that's too much to expect from development teams Wut? The development team is capable of dealing with that just fine. It’s the business unit throwing requirements over the fence and hoping it’ll magically be OK that’s the problem.
AitchEmArsey 5y ago
> Domain-Driven Design > It's not exactly rocket-science either I'd imagine that occasionally "rocket science" is exactly what it is!
- IgorPartola 5y ago
  This always baffled me. Rocket science is basically F = GMm/d^2 with m changing over time as you burn fuel and also thrust vectoring. Where is the complexity?
  - hattar 5y ago
    Aerodynamics issues likely add a lot of complexity, though I’m sure there are plenty of other factors that make launching a rocket hard.
  - pc86 5y ago
    This might be the most stereotypically HN comment I've ever read. Not in a good way.
    - samatman 5y ago
      Well, if you picture a spherical, frictionless rocket scientist, in a vacuum...
  - ateng 5y ago
    If you just model rocket science as a point mass with variable m then yes… But it’s more than that. To name a few: * How does one raise the thrust temperature as high as possible without melting the engine to maximise thrust? (The burning temperature IS already higher than the engine material melting point) * how does one reduce the redundancy (both system wise and material wise) to minimise weight while ensuring the rocket won’t fail?
    - IgorPartola 5y ago
      Ah so you want aeronautical engineering, not rocket science!

deleted 5y ago

[deleted]