3 ms·

> Honest question: you've never ran across a situation where varying business users are describing realities in the business which are inconsistent with one ano

> Honest question: you've never ran across a situation where varying business users are describing realities in the business which are inconsistent with one another in various ways? All the time. And whenever that happens it means either the software-system's domain-model needs revising, or the user's mental-model needs adjustment - or sometimes both simultaneously. > Because there's this whole school of thought that you can code around inconsistencies using various techniques... "coding around..." sounds like compromising the domain-model and/or brushing awkward details under a rug. > The issue here, however is that when we fix these inconsistencies in code we're taking what should be a business or analysis decision and sticking it in the solution framework. That works for a while until you create some monster nobody knows or can maintain. When the project becomes "a monster" it needs to be refactored - and then it will be knowable and maintainable again. Scope-creep is inevitable in every software project - we know how to manage it. > Let's say you have three customers. For various reasons they can't be in the room at the same time, so you're stuck listening to them sequentially describe some new CRM system you're building. Customer 1 tells you that the system should maintain an estimate of the total value of the new customer in dollars. You add in a decimal field to the system. Customer 2 comes by later and says nope, we need international currency support, so perhaps you add a currency type (insert lots of various possible solutions). Later still, Customer 3 comes by and gee, what was wrong with those guys! We actually deploy in a lot of places where barter is used, so the future value obviously needs to be expressed in farm animals. Maybe you switch to a string, screw 'em. Or maybe you have fun doing lots of coding stuff. We coders can solve anything given enough code. In all 3 cases, it is the system's domain-model that is inadequate, not the customers' requests (which are very reasonable, honestly). The SWE industry largely abandoned waterfall over a decade ago, and I'm also seeing declining interest in SCM (and I've personally never worked at an org that used SCM), so I'm not convinced the problems you're describing are really that much of a problem, if not just "tuesday". > The point is that these bozos have completely different ideas of what the heck the app is going to do and us coding around that isn't doing anybody any favors. In fact, we're hurting them. We're making a mess at the same time. This disagreement is a business one and they need to figure it out, not us. No amount of fancy coding is going to fix the fact that these guys are walking around with different mental models. I see that the wider-point was about how we should be handling mutually-exclusive customer-requirements (rather than that specific case you outlined (i.e. handling hetereogenous accounting methods, which isn't really mutually-exclusive, IME), but I'm not seeing how that carries you to your conclusion > Now, imagine that scenario with 50 symbols instead of just a few. We see logical inconsistencies as coders that would never appear in a conversation if we didn't bring it up. That's a precious gift that we've never had before, mainly because until 50 years or so ago we've never had hundreds of thousands of coders diving into tens of thousands of domains and finding these problems at this level of detail. > > As a programmer, maybe it's not important. Maybe it is. Not my call. Things I might think trivial are critically important and things I feel important may be trivial. I'm not the lawyer telling those guys something about the law. I'm a programmer. I make logically consistent stuff in great depth. I'm just a kind of mirror, a type of mirror that is completely new to our species. I really have no idea what you're trying to say here...

lowercased 3y ago
I've got an idea of what's being intended here, but it's sort of... 'obvious' in a way. OP, tell me if I'm way off. IT/dev folks sometimes have a unique high-level view of an organization that many others don't have. Personally, I've been in multiple orgs where I'm sitting in with various depts, and being asked/tasked with certain things. These things are in direct conflict with other depts' requests, but I'm the only one who knows that, because I'm the only one who is jumping between departments. I can raise these conflicts as issues that need resolving. Sometimes it's recognized and conflicts are ironed out. Sometimes not. That may be one example at one level of what OP was trying to get at(?) Even within a dept, and a single request, the more questions get asked for more clarity, we can often uncover logical states that aren't always blindingly obvious to others. Again, you can raise that and look for resolution (ideally, before you start), but you may not always get resolution. It sort of sucks sometimes because you can be seen as a know-it-all or "always trying to bring things down", but you/I/we are often the only ones who have to attempt to reconcile logical contradictions, or at least conflicting requirements that require political capital, not technical chops. "We have to send people their passwords via email". "We can never store or transmit plaintext passwords". I've had to have this mediation multiple times between parties. Request 1 is somewhat bad on its face, but trying to resolve these with multiple parties is sometimes really not fun, depending on the politics involved. And much of these issues come down to politics (and poor management, but poor management allows politics outsize influence in the first place).
- DanielBMarkham 3y ago
  Yes, exactly. The only thing I'd add is that raising those issues and trying to find resolution is probably even more important than the code. People can see whether the app is working or not. They can't see when these conflicts happen unless somebody helps them.

lowercased 3y ago

I've got an idea of what's being intended here, but it's sort of... 'obvious' in a way. OP, tell me if I'm way off. IT/dev folks sometimes have a unique high-level view of an organization that many others don't have. Personally, I've been in multiple orgs where I'm sitting in with various depts, and being asked/tasked with certain things. These things are in direct conflict with other depts' requests, but I'm the only one who knows that, because I'm the only one who is jumping between departments. I can raise these conflicts as issues that need resolving. Sometimes it's recognized and conflicts are ironed out. Sometimes not. That may be one example at one level of what OP was trying to get at(?) Even within a dept, and a single request, the more questions get asked for more clarity, we can often uncover logical states that aren't always blindingly obvious to others. Again, you can raise that and look for resolution (ideally, before you start), but you may not always get resolution. It sort of sucks sometimes because you can be seen as a know-it-all or "always trying to bring things down", but you/I/we are often the only ones who have to attempt to reconcile logical contradictions, or at least conflicting requirements that require political capital, not technical chops. "We have to send people their passwords via email". "We can never store or transmit plaintext passwords". I've had to have this mediation multiple times between parties. Request 1 is somewhat bad on its face, but trying to resolve these with multiple parties is sometimes really not fun, depending on the politics involved. And much of these issues come down to politics (and poor management, but poor management allows politics outsize influence in the first place).

DanielBMarkham 3y ago
Yes, exactly. The only thing I'd add is that raising those issues and trying to find resolution is probably even more important than the code. People can see whether the app is working or not. They can't see when these conflicts happen unless somebody helps them.