5 ms·

The explanation in the article didn't really click for me, and I still don't fully understand why, according to the author, programming is so special compared t

The explanation in the article didn't really click for me, and I still don't fully understand why, according to the author, programming is so special compared to law, medicine, etc. I do of course understand why a given request from the client might be impossible to satisfy, given the abstractions that are currently in the code, but at least in some cases you can feasibly tweak the abstractions or build new ones. OK, that's not always possible, but ... so what? So, as far as I can see, the only conclusion left to draw is "Abstractions of a given subject can be mutually exclusive." OK ... and? Surely that's Logic 101. After all, they're abstractions and by definition they remove some information that's present in the subject itself, which means that information that's present in some abstractions of the subject won't be present in different ones.

DanielBMarkham 3y ago
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.
- 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.
golergka 3y ago
> I do of course understand why a given request from the client might be impossible to satisfy, given the abstractions that are currently in the code Not quite. A request from the client might be impossible to satisfy given _the request_. May be not this particular request, but some previous requirement that this system has to uphold. I have a lot of times found myself in the situation where I explained to stakeholders that they essentially have bugs in their requirements, as they were logically inconsistent and self contradictory. That's what the article is about — it almost never happens in other professions.
- johncalvinyoung 3y ago
  Contradictory or inconsistent requirements? I've heard lots of anecdotes around that sort of thing in hardware engineering. It happens whenever abstractions meet implementation.
- DaiPlusPlus 3y ago
  > That's what the article is about I thought the article's subtext, or implication, was about how line-of-business software writers will soon be replaced by some LLM that attempts to follow the clients' requests as-best-as-possible when its generating its own software domain-model and simply refusing to ever push-back to the client: the ultimate obsequious SWE - which means that software-quality will go down the drain. ...which I think is a rather specific prediction of the future and doesn't consider whether automated program-synthesis (whether LLM-based or otherwise) would be able to interrogate proposed requirements, identify flaws and inconsistencies, and require the user to correct their input before generating the code that defines the system.
  - tl 3y ago
    We have this problem today. I've never worked on a team that didn't have at least one person whose coding ability largely stopped at what you could copy and paste. Pre-internet, they were assigned non-programming tasks or things that could be done via copy-paste-modify of existing code. Collegues on my current team of this caliber have Bard open. This is an observed phenomenon, and I'm not surprised they reach for the less capable but incumbent provided option. I don't have enough data to say this has negatively impacted code quality, but I can rule out most positive results. From the above example, at least one person wants to disable Typescript because it makes code [from them but of unknown origin] harder to execute. That is not promising.
0x445442 3y ago
There’s a big difference between a doctor or lawyer and programmers. Doctors and lawyers are licensed professionals who quite often have their own business. Most programmers are employees doing what they’re told by their bosses. A plumber is much closer to a Doctor or lawyer than a programmer. There are some programmers who are not on retainer but are consultants. These types typically tell clients what can and can’t be done and the clients typically respect their opinions, unlike butts in seats programmers.

DanielBMarkham 3y ago

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.
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.

golergka 3y ago

> I do of course understand why a given request from the client might be impossible to satisfy, given the abstractions that are currently in the code Not quite. A request from the client might be impossible to satisfy given _the request_. May be not this particular request, but some previous requirement that this system has to uphold. I have a lot of times found myself in the situation where I explained to stakeholders that they essentially have bugs in their requirements, as they were logically inconsistent and self contradictory. That's what the article is about — it almost never happens in other professions.

johncalvinyoung 3y ago
Contradictory or inconsistent requirements? I've heard lots of anecdotes around that sort of thing in hardware engineering. It happens whenever abstractions meet implementation.
DaiPlusPlus 3y ago
> That's what the article is about I thought the article's subtext, or implication, was about how line-of-business software writers will soon be replaced by some LLM that attempts to follow the clients' requests as-best-as-possible when its generating its own software domain-model and simply refusing to ever push-back to the client: the ultimate obsequious SWE - which means that software-quality will go down the drain. ...which I think is a rather specific prediction of the future and doesn't consider whether automated program-synthesis (whether LLM-based or otherwise) would be able to interrogate proposed requirements, identify flaws and inconsistencies, and require the user to correct their input before generating the code that defines the system.
- tl 3y ago
  We have this problem today. I've never worked on a team that didn't have at least one person whose coding ability largely stopped at what you could copy and paste. Pre-internet, they were assigned non-programming tasks or things that could be done via copy-paste-modify of existing code. Collegues on my current team of this caliber have Bard open. This is an observed phenomenon, and I'm not surprised they reach for the less capable but incumbent provided option. I don't have enough data to say this has negatively impacted code quality, but I can rule out most positive results. From the above example, at least one person wants to disable Typescript because it makes code [from them but of unknown origin] harder to execute. That is not promising.

0x445442 3y ago

There’s a big difference between a doctor or lawyer and programmers. Doctors and lawyers are licensed professionals who quite often have their own business. Most programmers are employees doing what they’re told by their bosses. A plumber is much closer to a Doctor or lawyer than a programmer. There are some programmers who are not on retainer but are consultants. These types typically tell clients what can and can’t be done and the clients typically respect their opinions, unlike butts in seats programmers.