4 ms·

That's true in a universal sense, but humans don't exist in a universally-logical world. Yes, all code/abstractions are broken, ie, all models are broken but s

That's true in a universal sense, but humans don't exist in a universally-logical world. Yes, all code/abstractions are broken, ie, all models are broken but some are more useful than others. That, however, is not the point. The point is that these models are inconsistent in an invisible way even to experienced practitioners in whatever domain the code is in. It's not the the code or abstraction is broken. As you say, that's a non-event. It's that the code can show where the people are broken in ways that they themselves do not understand. That's the new part. That's where the line about the code talking back to the people comes from in the essay. An abstraction is a person generalizing and codifying something. This is about code correcting abstractions, not abstractions being more or less useful than one another. I believe your directional arrow here is backward from the intent of the essay.

Michelangelo11 3y ago
> It's that the code can show where the people are broken in ways that they themselves do not understand. Sorry, but I really don't understand how that's the case. Can you give a concrete example? I know you gave an example in the essay, but you didn't go into the specifics and you explicitly said its details don't matter and the reader shouldn't look at them closely.
- DanielBMarkham 3y ago
  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? Because there's this whole school of thought that you can code around inconsistencies using various techniques, higher levels of abstraction, rule-based code, and so on. These things are all possible, so whatever example I give I'm completely sure that you'll be able to "solve" it in code. 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. I want to help you, but this is a business event, not a coding one, so it's dependent on depth-of-knowledge and general intelligence of your business partners. I'll give you something trivial, with the caveat that there's not a coding response to this that's appropriate. That's the point of the essay. 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. But that's not the point. 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. 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.
  - DaiPlusPlus 3y ago
    > 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...
- 2b3a51 3y ago
  Disclaimer: UK based teacher here not an IT specialist About 15 years or so ago there was a slogan in colleges in the UK about 'personalised learning'. People sat in meetings and agreed that learning should indeed be personalised. I used to ask questions like how do I personalise learning with 25 teenagers in a basic maths class at 2pm on Friday.... no answers. The phrase 'personalised learning' had no 'operational' definition. It meant anything the middle managers and inspectors wanted it to mean. A buzz word if you like. I think the point the OA was making was that writing software to deliver things forces precise operationalised meanings for things - you can't write code if you don't know what the output is supposed to be. Below is teaching stuff... Obviously at 2pm on Friday you present to the median in the room and then keep the more confident going with harder tasks during the individual work bit of the lesson and give the dazed and confused more structured skills based work, that is basic teaching practice. I always got the students to fill in a learning log (piece of paper) at the end of the lesson - a line on the log for date, 'what did I learn today'(1) and comments. Turned out that was fine! I was officially doing 'personalised learning'. Who knew? A well known elearning provider in the UK took the 'personalised learning' slogan more seriously than I did and produced the following... * Screen based MCQ diagnostic quizzes on Maths and English - carefully designed questions with good feedback on distractors - the quality of this stage is absolutely critical * Tests were adaptive so if a student got a lot of questions wrong on (say) percentages, they got easier ones, and if most answers correct they got harder ones * Results logged against micro-topics. After test completed, student got an 'individual learning plan' with links to screen based materials. The 'learning plan' could be printed out and had enough detail to allow a teacher to run coaching sessions for that student. The linked learning materials were an add-on product. The diagnostic component is widely used in colleges in the UK. The learning plan bit is an add-on not so widely used. I used it and had good results with the students who don't like sitting in classrooms. (1) one lad put 'I learned how to sleep with my eyes open'. He'll go far I think.
- yuiod 3y ago
  I am having trouble following the thread of your back and forth here, and I feel the article also flounders in its seemingly intended message, but I can give you an example that I thought the article was actually about when I saw the headline: NP-Completeness. I am unable to remember or find the source but I read a quote by a prominent researcher who quipped that complexity theory was developed to create a corpus of experts to point your manager at when they ask you to “just solve the traveling salesman problem by end of week”. https://en.m.wikipedia.org/wiki/Computational_complexity_theory https://en.m.wikipedia.org/wiki/Computational_complexity_the...
- gopher_space 3y ago
  > Can you give a concrete example? Spellcheck. You enable the service to learn from your mistakes and to keep you from looking like an idiot.
ssivark 3y ago
Since the whole discussion (post + comments here) is a little abstract, I wonder whether this short comic sketch might serve to exemplify through caricature what we’re trying to get at: “The expert” https://youtu.be/BKorP55Aqvg https://youtu.be/BKorP55Aqvg
- Verdex 3y ago
  Interestingly enough, someone made a response video: https://www.youtube.com/watch?v=B7MIJP90biM https://www.youtube.com/watch?v=B7MIJP90biM Although, to be sure, the response from management et al will almost definitely indicate that this isn't what they were looking for at all. [I know an electrical engineer who was part of a team that provided an engine control component to a customer and their response was that even though the component 100% meets all of the requirements they told them about it apparently didn't conform to the requirements that they were not told about (or perhaps that the customer was unaware of)]
  - hinkley 3y ago
    My name is Scott Williamson, and I don't know the definition of a line. And while it's possible (likely?) that management also doesn't know what the definition of 'line' is either, I'm pretty sure nobody agrees those green lines are red. A frequent problem in requirements communication is when the customer aggressively insists that they understand all of the definitions you are using ("I'm not an idiot."), they don't actually mean the same thing you mean by them.

Michelangelo11 3y ago

> It's that the code can show where the people are broken in ways that they themselves do not understand. Sorry, but I really don't understand how that's the case. Can you give a concrete example? I know you gave an example in the essay, but you didn't go into the specifics and you explicitly said its details don't matter and the reader shouldn't look at them closely.

DanielBMarkham 3y ago
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? Because there's this whole school of thought that you can code around inconsistencies using various techniques, higher levels of abstraction, rule-based code, and so on. These things are all possible, so whatever example I give I'm completely sure that you'll be able to "solve" it in code. 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. I want to help you, but this is a business event, not a coding one, so it's dependent on depth-of-knowledge and general intelligence of your business partners. I'll give you something trivial, with the caveat that there's not a coding response to this that's appropriate. That's the point of the essay. 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. But that's not the point. 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. 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.
- DaiPlusPlus 3y ago
  > 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...
2b3a51 3y ago
Disclaimer: UK based teacher here not an IT specialist About 15 years or so ago there was a slogan in colleges in the UK about 'personalised learning'. People sat in meetings and agreed that learning should indeed be personalised. I used to ask questions like how do I personalise learning with 25 teenagers in a basic maths class at 2pm on Friday.... no answers. The phrase 'personalised learning' had no 'operational' definition. It meant anything the middle managers and inspectors wanted it to mean. A buzz word if you like. I think the point the OA was making was that writing software to deliver things forces precise operationalised meanings for things - you can't write code if you don't know what the output is supposed to be. Below is teaching stuff... Obviously at 2pm on Friday you present to the median in the room and then keep the more confident going with harder tasks during the individual work bit of the lesson and give the dazed and confused more structured skills based work, that is basic teaching practice. I always got the students to fill in a learning log (piece of paper) at the end of the lesson - a line on the log for date, 'what did I learn today'(1) and comments. Turned out that was fine! I was officially doing 'personalised learning'. Who knew? A well known elearning provider in the UK took the 'personalised learning' slogan more seriously than I did and produced the following... * Screen based MCQ diagnostic quizzes on Maths and English - carefully designed questions with good feedback on distractors - the quality of this stage is absolutely critical * Tests were adaptive so if a student got a lot of questions wrong on (say) percentages, they got easier ones, and if most answers correct they got harder ones * Results logged against micro-topics. After test completed, student got an 'individual learning plan' with links to screen based materials. The 'learning plan' could be printed out and had enough detail to allow a teacher to run coaching sessions for that student. The linked learning materials were an add-on product. The diagnostic component is widely used in colleges in the UK. The learning plan bit is an add-on not so widely used. I used it and had good results with the students who don't like sitting in classrooms. (1) one lad put 'I learned how to sleep with my eyes open'. He'll go far I think.
yuiod 3y ago
I am having trouble following the thread of your back and forth here, and I feel the article also flounders in its seemingly intended message, but I can give you an example that I thought the article was actually about when I saw the headline: NP-Completeness. I am unable to remember or find the source but I read a quote by a prominent researcher who quipped that complexity theory was developed to create a corpus of experts to point your manager at when they ask you to “just solve the traveling salesman problem by end of week”. https://en.m.wikipedia.org/wiki/Computational_complexity_theory https://en.m.wikipedia.org/wiki/Computational_complexity_the...
gopher_space 3y ago
> Can you give a concrete example? Spellcheck. You enable the service to learn from your mistakes and to keep you from looking like an idiot.

ssivark 3y ago

Since the whole discussion (post + comments here) is a little abstract, I wonder whether this short comic sketch might serve to exemplify through caricature what we’re trying to get at: “The expert” https://youtu.be/BKorP55Aqvg https://youtu.be/BKorP55Aqvg

Verdex 3y ago
Interestingly enough, someone made a response video: https://www.youtube.com/watch?v=B7MIJP90biM https://www.youtube.com/watch?v=B7MIJP90biM Although, to be sure, the response from management et al will almost definitely indicate that this isn't what they were looking for at all. [I know an electrical engineer who was part of a team that provided an engine control component to a customer and their response was that even though the component 100% meets all of the requirements they told them about it apparently didn't conform to the requirements that they were not told about (or perhaps that the customer was unaware of)]
- hinkley 3y ago
  My name is Scott Williamson, and I don't know the definition of a line. And while it's possible (likely?) that management also doesn't know what the definition of 'line' is either, I'm pretty sure nobody agrees those green lines are red. A frequent problem in requirements communication is when the customer aggressively insists that they understand all of the definitions you are using ("I'm not an idiot."), they don't actually mean the same thing you mean by them.