4 ms·

> I’m glad that software is invisible, mostly But that also makes it somewhat intangible and the ability to analyze, test and observe a large software construc

> I’m glad that software is invisible, mostly But that also makes it somewhat intangible and the ability to analyze, test and observe a large software construct relies on the mental capacity to read and grasp units of code and its complex interactions. Once components start messaging with each other and cross-influence their state you quickly enter the realm of complexity theory and tight control of information flow is the only way to guarantee some degree of predictable outcomes. When I see these ship assembly videos, it's very tough engineering and often novel territory but you got something in your hands, you see the parts move and can measure their forces and evaluate interactions. Every nut has a checkbox, but code lines don't.

jiofih 7y ago
> Every nut has a checkbox, but code lines don't. That’s part of the problem. Usually the output and behavior of a program is well specified enough that we should have a checkbox (test?) for it. This is more about the process of development than the artifacts.
- icebraining 7y ago
  > Usually the output and behavior of a program is well specified enough that we should have a checkbox (test?) for it I've literally never worked in a project like this. It's always "here's some general idea of what we want, with a couple of hard constraints. Build it however it makes sense to you, and we'll change anything we don't like after we see it." The only exception I can think of is data import from a known file format or API.
  - viklove 7y ago
    It's very easy to explain to someone why blowing a hole in their bedroom wall to put an extension cord through it is a bad idea. On the other hand, try explaining to your product team that building a certain feature in 2 weeks will require doing the equivalent of that, and they won't see any issues with it. This is the problem with building software. It's intangible and non-developers have a very hard time understanding the tradeoff of doing something "hacky" vs doing it right.
- pjc50 7y ago
  > Usually the output and behavior of a program is well specified enough that we should have a checkbox (test?) for it. lolnope Or at least, if there is such a specification, it's never in a single organized form but scattered around the tickets, emails, postit notes and memories of the team members. And filled with assumptions on what's expected. Only the most complicated, expensive and safety-critical systems get that kind of treatment. At which point people start realising that the requirements engineering is actually one of the most difficult parts for business applications. Some projects have collapsed with millions spent before writing any code, simply trying to untangle the requirements.
  - exikyut 7y ago
    > ...requirements engineering is actually one of the most difficult parts for business applications. Some projects have collapsed with millions spent before writing any code, simply trying to untangle the requirements. This gives me a terrible idea: Put https://xkcd.com/1737/ https://xkcd.com/1737/ (Scale) and continuous integration into a blender. Stand up a whole new team to build out your Ultimate Last Widget, from first principles, every 5 years. Have maybe 5 teams running continuously. Each team operates asynchronously from all the others and there is no blocking. Maybe teams can freely exchange ideas, and maybe workers can switch teams at will. Hmm. This would unfortunately result in a Super-Team™ that knows how to create a new Widget X from scratch in (eventually) record time, but not necessarily maintain it. And there's the good question of whether squishy real-world influences would cause the last of the teams to succumb to second-system effect... Wow this is hard
    - pjc50 7y ago
      Some defence projects end up being run like that. Although it tends to operate in reverse: project A has been running to produce the Ultimate Fighter for 20 years, but that's taken too long, so a slightly scaled back project for Acceptable Fighter is launched. Ten years later, neither is finished, so project Desperate Stopgap fighter is launched. Another few years on and an actual war breaks out, so Obsolete Fighter With Guns Taped To It is used to do the actual fighting until the losses are unacceptable and all the preceding teams are galvanised into producing actual results. (e.g. https://en.wikipedia.org/wiki/The_Pentagon_Wars https://en.wikipedia.org/wiki/The_Pentagon_Wars , but also applied to a lot of early WW2 and things like the UK V-bombers)
- zelos 7y ago
  > and behavior of a program is well specified enough that we should have a checkbox (test?) for it. Thanks, I needed a good laugh ;-)
downvoted 7y ago
So if you are able to read and understand a single page of code, then you can almost definitely understand the overall design of a system and the flow of its operations. But if you are tasked with analyzing a system of hundreds of pages of code, you are likely to struggle with some of the aspects of code, such as its semantics, its design and its behavior.

jiofih 7y ago

> Every nut has a checkbox, but code lines don't. That’s part of the problem. Usually the output and behavior of a program is well specified enough that we should have a checkbox (test?) for it. This is more about the process of development than the artifacts.

icebraining 7y ago
> Usually the output and behavior of a program is well specified enough that we should have a checkbox (test?) for it I've literally never worked in a project like this. It's always "here's some general idea of what we want, with a couple of hard constraints. Build it however it makes sense to you, and we'll change anything we don't like after we see it." The only exception I can think of is data import from a known file format or API.
- viklove 7y ago
  It's very easy to explain to someone why blowing a hole in their bedroom wall to put an extension cord through it is a bad idea. On the other hand, try explaining to your product team that building a certain feature in 2 weeks will require doing the equivalent of that, and they won't see any issues with it. This is the problem with building software. It's intangible and non-developers have a very hard time understanding the tradeoff of doing something "hacky" vs doing it right.
pjc50 7y ago
> Usually the output and behavior of a program is well specified enough that we should have a checkbox (test?) for it. lolnope Or at least, if there is such a specification, it's never in a single organized form but scattered around the tickets, emails, postit notes and memories of the team members. And filled with assumptions on what's expected. Only the most complicated, expensive and safety-critical systems get that kind of treatment. At which point people start realising that the requirements engineering is actually one of the most difficult parts for business applications. Some projects have collapsed with millions spent before writing any code, simply trying to untangle the requirements.
- exikyut 7y ago
  > ...requirements engineering is actually one of the most difficult parts for business applications. Some projects have collapsed with millions spent before writing any code, simply trying to untangle the requirements. This gives me a terrible idea: Put https://xkcd.com/1737/ https://xkcd.com/1737/ (Scale) and continuous integration into a blender. Stand up a whole new team to build out your Ultimate Last Widget, from first principles, every 5 years. Have maybe 5 teams running continuously. Each team operates asynchronously from all the others and there is no blocking. Maybe teams can freely exchange ideas, and maybe workers can switch teams at will. Hmm. This would unfortunately result in a Super-Team™ that knows how to create a new Widget X from scratch in (eventually) record time, but not necessarily maintain it. And there's the good question of whether squishy real-world influences would cause the last of the teams to succumb to second-system effect... Wow this is hard
  - pjc50 7y ago
    Some defence projects end up being run like that. Although it tends to operate in reverse: project A has been running to produce the Ultimate Fighter for 20 years, but that's taken too long, so a slightly scaled back project for Acceptable Fighter is launched. Ten years later, neither is finished, so project Desperate Stopgap fighter is launched. Another few years on and an actual war breaks out, so Obsolete Fighter With Guns Taped To It is used to do the actual fighting until the losses are unacceptable and all the preceding teams are galvanised into producing actual results. (e.g. https://en.wikipedia.org/wiki/The_Pentagon_Wars https://en.wikipedia.org/wiki/The_Pentagon_Wars , but also applied to a lot of early WW2 and things like the UK V-bombers)
zelos 7y ago
> and behavior of a program is well specified enough that we should have a checkbox (test?) for it. Thanks, I needed a good laugh ;-)

downvoted 7y ago

So if you are able to read and understand a single page of code, then you can almost definitely understand the overall design of a system and the flow of its operations. But if you are tasked with analyzing a system of hundreds of pages of code, you are likely to struggle with some of the aspects of code, such as its semantics, its design and its behavior.