3 ms·

Not so sure about this: "An example of a gentle environment is software development. Outcomes are clearly specified, frameworks are common and work well, and yo

Not so sure about this: "An example of a gentle environment is software development. Outcomes are clearly specified, frameworks are common and work well, and your actions receive instant and accurate feedback."

Hackbraten 5y ago
I agree with you. Software development is a highly people-driven environment. You can introduce something in your process (e. g. a new framework) but the feedback comes only a year later when it becomes evident that the framework hasn’t been a good fit or was introduced poorly (e. g. team members are quitting, productivity has plummeted, tech debt has piled up).
- danielmarkbruce 5y ago
  The writer almost certainly isn't a software engineer. It's one of those things where you don't know how something works so you imagine the process as much simpler/less messy/more well defined than it really is...
- wongarsu 5y ago
  A year is still blazingly fast. Most plumbers will wait years to try a new way of joining pipes, and it might take decades until it's clear if the new way is more reliable. In the time it takes most professions to consider trying a new framework or tool (beyond the early adopters), entire programming languages rise to popularity and fall back into obscurity.
krisoft 5y ago
I see what you say. Although I'm not the author I will try to speculate on what they might mean by "instant and accurate feedback": I heard the same sentiment from an architect friend. (The kind of architect who designs buildings) He said that in their business you put your best ideas on paper. Most plans then don't get built for reasons outside of your control. Projects fail, companies fold. Sometimes your designs can't pass review with the authorities because you misunderstood the regulations. Sometimes it can't pass review because the local government doesn't like your customer. Years down the road some of your plans are built. If there are problems with the design some problems might be obvious immediately, but most will only show up as the building ages. And if there are problems, are they there because you designed it wrong? Or the builders skimped on materials? Or is it maybe because the costumer meddled with your designs? You will never know. The feedback loop is both years long, and the execution is inaccurate. On the other hand besides being an architect he was also dabbling in hobby programming projects. There if he made a syntax error the computer pointed it out to him within seconds. And even when he found a bug after compilation he could be certain it wasn't because the compiler saved money by using 10% less screws than specified or something. That is to say the feedback was both fast and accurate. If you had bugs, most probably it was because you made a mistake.
inopinatus 5y ago
Indeed, the opposite of all three assertions is true in practically every project I ever worked on. Not sure if the author is joking, or simply has no software dev experience.
- ZephyrBlu 5y ago
  I think the author may be referencing programming moreso than the full software development process.
  - candeira 5y ago
    Yes, and I understood his point because, as a business-minded software engineer, I can map the edit-run-test-debug process to what he calls a tight loop (the Maths Test). I also recognise the fuzzier process of designing features with stakeholders, implementing them, deploying them and having them tested in the market as something between the Rocket Launch (for the technical process from ideation to deployment and subsequent maintenance) and Stock Picking (for the product/market fit). To finish populating the 2x2 matrix, the Novice Bowler approach is more similar to what many of the students used to do back when I was tutoring Algorithms and Data Structures at uni. They'd throw things at the IDE until it compiled, and call it a day.

Hackbraten 5y ago

I agree with you. Software development is a highly people-driven environment. You can introduce something in your process (e. g. a new framework) but the feedback comes only a year later when it becomes evident that the framework hasn’t been a good fit or was introduced poorly (e. g. team members are quitting, productivity has plummeted, tech debt has piled up).

danielmarkbruce 5y ago
The writer almost certainly isn't a software engineer. It's one of those things where you don't know how something works so you imagine the process as much simpler/less messy/more well defined than it really is...
wongarsu 5y ago
A year is still blazingly fast. Most plumbers will wait years to try a new way of joining pipes, and it might take decades until it's clear if the new way is more reliable. In the time it takes most professions to consider trying a new framework or tool (beyond the early adopters), entire programming languages rise to popularity and fall back into obscurity.

krisoft 5y ago

I see what you say. Although I'm not the author I will try to speculate on what they might mean by "instant and accurate feedback": I heard the same sentiment from an architect friend. (The kind of architect who designs buildings) He said that in their business you put your best ideas on paper. Most plans then don't get built for reasons outside of your control. Projects fail, companies fold. Sometimes your designs can't pass review with the authorities because you misunderstood the regulations. Sometimes it can't pass review because the local government doesn't like your customer. Years down the road some of your plans are built. If there are problems with the design some problems might be obvious immediately, but most will only show up as the building ages. And if there are problems, are they there because you designed it wrong? Or the builders skimped on materials? Or is it maybe because the costumer meddled with your designs? You will never know. The feedback loop is both years long, and the execution is inaccurate. On the other hand besides being an architect he was also dabbling in hobby programming projects. There if he made a syntax error the computer pointed it out to him within seconds. And even when he found a bug after compilation he could be certain it wasn't because the compiler saved money by using 10% less screws than specified or something. That is to say the feedback was both fast and accurate. If you had bugs, most probably it was because you made a mistake.

inopinatus 5y ago

Indeed, the opposite of all three assertions is true in practically every project I ever worked on. Not sure if the author is joking, or simply has no software dev experience.

ZephyrBlu 5y ago
I think the author may be referencing programming moreso than the full software development process.
- candeira 5y ago
  Yes, and I understood his point because, as a business-minded software engineer, I can map the edit-run-test-debug process to what he calls a tight loop (the Maths Test). I also recognise the fuzzier process of designing features with stakeholders, implementing them, deploying them and having them tested in the market as something between the Rocket Launch (for the technical process from ideation to deployment and subsequent maintenance) and Stock Picking (for the product/market fit). To finish populating the 2x2 matrix, the Novice Bowler approach is more similar to what many of the students used to do back when I was tutoring Algorithms and Data Structures at uni. They'd throw things at the IDE until it compiled, and call it a day.