5 ms·

"I see construction workers wasting time putting on hard hats when I haven't once seen something fall on their heads. When will they grow up?" "I see electric

"I see construction workers wasting time putting on hard hats when I haven't once seen something fall on their heads. When will they grow up?" "I see electricians making sure they're properly grounded before working on high voltage electrical equipment rather than just making sure they don't touch the dangerous parts while they're working. When will they grow up?" "I see pilots going through the same checklist they went through the last time they flew the plane even though they never find anything wrong. When will they grow up?" "I see lifeguards wearing buoys on their feet rather than just swimming right to begin with. When will they grow up?" Programming suffers from a lack of attention to quality not a lack of awareness that we "solve business problems".

majormajor 5y ago
Most of the architectural wankery that happens in the real world does nothing to improve security or reliability of a project, though. People love to spend time discussing how to organize the code for potential future maintenance that then becomes irrelevant when requirements change, and didn't prevent someone from missing security vulnerabilities in an outdated version of a third party library anyway. So it's hard to compare that to pilots following a checklist or workers wearing helmets. Imagine if pilots spent an hour debating which sequence to push a particular set of buttons that would be needed after takeoff - where either of several ways would work - to the point that the plane took off hours too late.
- digbybk 5y ago
  I wouldn't expect the pilots to spend an hour debating before every takeoff, but rather to have had that debate ahead of time and have a solid set of patterns that they follow so they don't have to reinvent the wheel each time. The fact that attention to code doesn't prevent all problems doesn't mean that it doesn't prevent some problems.
- mtdewcmu 5y ago
  The pilots aren't inventing anything on each flight. If they fly the airplane exactly the same way every time, that's a good thing. Writing new programs is not like that.
  - phkahler 5y ago
    >> The pilots aren't inventing anything on each flight. If they fly the airplane exactly the same way every time, that's a good thing. Writing new programs is not like that. I have an intern writing and app for internal use. He's using Python, tkinter, and one pip-install package for talking on modbus. Deployment to our hand full of users is easy. Low number of dependencies. It's going really well. A few days ago he said "I really would have liked to use ZZYXX-web-whatever for the GUI instead of tkinter". I said "you users don't give a fuck about that but keeping dependencies easy to manage is important". Users don't actually care about dependencies either, but they do care when it negatively affects getting the thing up and running (or slows development or...). His main gripe with tkinter was actually a lack of familiarity. I said "dude, a large part of your job is going to be learning. Get used to it." Many architectural decisions in software are completely arbitrary and don't matter nearly as much as some people think. That's not to say all such decisions, but really a lot are not a big deal. In those cases KISS trumps most preferences and big ideas. IMHO of course.
    - mcguire 5y ago
      Just when I'd lost all hope for the future... Thank you!
- Jtsummers 5y ago
  > Imagine if pilots spent an hour debating which sequence to push a particular set of buttons that would be needed after takeoff - where either of several ways would work - to the point that the plane took off hours too late. Thanks for this, this prompted me to submit an article I read yesterday. Pilots don't need the debate because the work is (for the most part) well-known. There is no debate because the aircraft has a method of working that is well-understood so long as you aren't in the field of flight testing new aircraft, which is to say: the vast majority of pilots. As a consequence, there is zero need for discussion because there is "one way" to do things, and where there are choices (actions that can be done in any order) there are often conventions (such as going left-to-right across a panel to reduce the risk of missing a step). Software is different. Software is design, which pushes it towards the need to communicate more often and work in a collaborative fashion. In fact, a lack of communication seems to be the problem in the org of the article and not the desire for high quality software. The programmers weren't talking with each other or their customer and instead acted more like the pilot situation, but without sufficient insight to actually make decisions or take the actions they were taking.
deleted 5y ago
[deleted]
egor2820 5y ago
Electricity, building houses is based on hard science, code quality is base on opinion
- tehjoker 5y ago
  Those guys had to have unions to fight for safety practices. It's to protect the workers. This code quality stuff is about various competing business objectives and now annoying stuff is. I've never seen a programmer be dismembered from a missing test though I'm sure such things happen in embedded systems and robotics. Tesla Autopilot or the Uber self-driving accident in Arizona are great examples of programming leading to deaths. I guess if your Uber app doesn't work in the rain that is bad. It's when people are making safety critical decisions that this stuff matters more.
- Bancakes 5y ago
  RAM and CPU usage is not an opinion.
  - Brian_K_White 5y ago
    Of course it is. You can prioritize cpu or ram or disk or network or developer or user resoures for the sake of the others in countless mixes and for countless mixes of reasons.
- jk20 5y ago
  Rubbish, coding is hard science, business is snake oil salesmanship.
throwawayboise 5y ago
Most programming tasks don't involve the life safety issues you are using as examples. It is certainly true that overdesign up front can be fatal to the finances of a project. There is even a term for people who engage in this, "architecture astronauts" The point is to know what you are working on, and what the customer needs. If they need one or two simple data stores and a couple of web pages, you don't need to spend weeks talking about it.
marcosdumay 5y ago
It's funny because the article starts with a series of factors that the author claims to reduce code quality, and then goes to conclude that the project suffers from excess of quality. And then ends it claiming that quality is something that slows down development...

majormajor 5y ago

Most of the architectural wankery that happens in the real world does nothing to improve security or reliability of a project, though. People love to spend time discussing how to organize the code for potential future maintenance that then becomes irrelevant when requirements change, and didn't prevent someone from missing security vulnerabilities in an outdated version of a third party library anyway. So it's hard to compare that to pilots following a checklist or workers wearing helmets. Imagine if pilots spent an hour debating which sequence to push a particular set of buttons that would be needed after takeoff - where either of several ways would work - to the point that the plane took off hours too late.

digbybk 5y ago
I wouldn't expect the pilots to spend an hour debating before every takeoff, but rather to have had that debate ahead of time and have a solid set of patterns that they follow so they don't have to reinvent the wheel each time. The fact that attention to code doesn't prevent all problems doesn't mean that it doesn't prevent some problems.
mtdewcmu 5y ago
The pilots aren't inventing anything on each flight. If they fly the airplane exactly the same way every time, that's a good thing. Writing new programs is not like that.
- phkahler 5y ago
  >> The pilots aren't inventing anything on each flight. If they fly the airplane exactly the same way every time, that's a good thing. Writing new programs is not like that. I have an intern writing and app for internal use. He's using Python, tkinter, and one pip-install package for talking on modbus. Deployment to our hand full of users is easy. Low number of dependencies. It's going really well. A few days ago he said "I really would have liked to use ZZYXX-web-whatever for the GUI instead of tkinter". I said "you users don't give a fuck about that but keeping dependencies easy to manage is important". Users don't actually care about dependencies either, but they do care when it negatively affects getting the thing up and running (or slows development or...). His main gripe with tkinter was actually a lack of familiarity. I said "dude, a large part of your job is going to be learning. Get used to it." Many architectural decisions in software are completely arbitrary and don't matter nearly as much as some people think. That's not to say all such decisions, but really a lot are not a big deal. In those cases KISS trumps most preferences and big ideas. IMHO of course.
  - mcguire 5y ago
    Just when I'd lost all hope for the future... Thank you!
Jtsummers 5y ago
> Imagine if pilots spent an hour debating which sequence to push a particular set of buttons that would be needed after takeoff - where either of several ways would work - to the point that the plane took off hours too late. Thanks for this, this prompted me to submit an article I read yesterday. Pilots don't need the debate because the work is (for the most part) well-known. There is no debate because the aircraft has a method of working that is well-understood so long as you aren't in the field of flight testing new aircraft, which is to say: the vast majority of pilots. As a consequence, there is zero need for discussion because there is "one way" to do things, and where there are choices (actions that can be done in any order) there are often conventions (such as going left-to-right across a panel to reduce the risk of missing a step). Software is different. Software is design, which pushes it towards the need to communicate more often and work in a collaborative fashion. In fact, a lack of communication seems to be the problem in the org of the article and not the desire for high quality software. The programmers weren't talking with each other or their customer and instead acted more like the pilot situation, but without sufficient insight to actually make decisions or take the actions they were taking.

deleted 5y ago

[deleted]

egor2820 5y ago

Electricity, building houses is based on hard science, code quality is base on opinion

tehjoker 5y ago
Those guys had to have unions to fight for safety practices. It's to protect the workers. This code quality stuff is about various competing business objectives and now annoying stuff is. I've never seen a programmer be dismembered from a missing test though I'm sure such things happen in embedded systems and robotics. Tesla Autopilot or the Uber self-driving accident in Arizona are great examples of programming leading to deaths. I guess if your Uber app doesn't work in the rain that is bad. It's when people are making safety critical decisions that this stuff matters more.
Bancakes 5y ago
RAM and CPU usage is not an opinion.
- Brian_K_White 5y ago
  Of course it is. You can prioritize cpu or ram or disk or network or developer or user resoures for the sake of the others in countless mixes and for countless mixes of reasons.
jk20 5y ago
Rubbish, coding is hard science, business is snake oil salesmanship.

throwawayboise 5y ago

Most programming tasks don't involve the life safety issues you are using as examples. It is certainly true that overdesign up front can be fatal to the finances of a project. There is even a term for people who engage in this, "architecture astronauts" The point is to know what you are working on, and what the customer needs. If they need one or two simple data stores and a couple of web pages, you don't need to spend weeks talking about it.

marcosdumay 5y ago

It's funny because the article starts with a series of factors that the author claims to reduce code quality, and then goes to conclude that the project suffers from excess of quality. And then ends it claiming that quality is something that slows down development...