5 ms·

> They have higher standards and whatnot Note that "higher standards" in civil engineering usually boils down to a) having standards at all instead of fuzzy pr

by _pmf_ 9y ago

> They have higher standards and whatnot Note that "higher standards" in civil engineering usually boils down to a) having standards at all instead of fuzzy process management frameworks b) these standards often boil down to "do this task/product with this regulatory mandated large margin of error" and c) building according to specification (i.e. having a reliable specification in the first place), which is exactly how reliable software is built (SIL, ASIL, aerospace level redundancy). There is nothing magical about it, but it needs to be driven by business and is not something that us lowly developers can just chose to do on a whim (because it increases costs by a factor 10 - 100). Embracing agile (as his ThoughtWorks contract requires him to do) while lamenting quality and lack of professionalism, as Mr Martin does, is extremely dishonest.

sgift 9y ago
> Embracing agile (as his ThoughtWorks contract requires him to do) while lamenting quality and lack of professionalism, as Mr Martin does, is extremely dishonest. Why exactly? I fail to see the connection between lack of quality and embracing agile.
- LeifCarrotson 9y ago
  For the reasons explained in the previous project. A source of quality in mechanical and civil engineering is that they have rigid standards, legal regulations, and thorough specifications. These cost a lot of money, sacrifice a lot of flexibility, and add a lot of time, but they work. Agile development methods do create useful software quickly and cheaply, but are very dissimilar to this sort of strict framework. As an employee of ThoughtWorks, he can't suggest increased regulation and specification, because he's paid to suggest less of those things. It's disingenuous, then, to complain about a lack of the results of those processes when he's advocating a method that lacks those processes.
- mannykannot 9y ago
  In principle, 'agile' is so weakly defined that it is possible to follow a process that produces quality software and describe it as agile. In practice, insofar as agile stands for anything at all, one of its pillars is what might be called an 'active disinterest' in doing much thinking ahead, and in practice, it is very hard to produce quality software without doing some serious thinking ahead.
  - k__ 9y ago
    Is this really true? I have the feeling "producing software" is a highly volatile process. First, software can do almost everything. You have WhatsApp, DOOM, Photoshop, Ableton Live, Google, Linux etc. which are hugely different systems and it was just the stuff that came to my mind in 10 seconds. Second, the requirements change and change. One person thinking ahead and getting a brilliant idea may end up with producing complete garbage, because many things have changed since they had the idea. I think the reason for the fact, that it hasn't been formalized and regulated like, for example, building cars, is simply that it can't be. Software isn't a car or a house or a ship. Software is an abstraction layer above this. It's more like the accumulated orders needed to build these things.
    - mannykannot 9y ago
      > I think the reason for the fact, that it hasn't been formalized and regulated like, for example, building cars, is simply that it can't be. NASA writes highly reliable software, as do the organizations producing the software for fly-by-wire airplanes, so your assertion is empirically false. You are extrapolating too far from your personal level of knowledge and experience.
      - k__ 9y ago
        Sure they do, but how much is because of formalization? I mean, just look at SQLite, which is a highly reliable software. They bought this stability with a gigantic test suite.
        mannykannot 9y ago
        In what way do you think this supports your claims? What argument are you making here?
      - sgift 9y ago
        > NASA writes highly reliable software, as do the organizations producing the software for fly-by-wire airplanes, so your assertion is empirically false. What I find interesting is that both of your examples (and many others) are for software which controls physical systems, i.e. which is pretty well defined due to the nature of the machines it controls. Do you have comparable examples which aren't defined by the physical systems they interact with?
- throwawayReply 9y ago
  Civil engineers don't I suppose agree to build a bridge before they've surveyed the land and then begin construction before knowing the loads. Contrast that to software engineering, where beginning before you have requirements is seen as a requirement of being agile.
  - sgift 9y ago
    > Contrast that to software engineering, where beginning before you have requirements is seen as a requirement of being agile. Not that I agree with all the agile ideas, but if I remember correctly we had a process already which was supposed to start with "gather all requirements" and then the rest follows. It was called waterfall development and didn't work so great either, mostly due to the 'all' part in requirements being violated all the time in practice.
  - soru 9y ago
    This is kind of precisely backwards. A survey is like a test; it asks 'will this work'? A good civil engineer will do that as early as possible, rather than produce pages of engineering drawings blindly. A good civil engineer will calculate the stresses and load factors on a bridge as soon as possible, rather than assume things will work. A good architect will hand a sketch of a building to a client as early as possible, and ask 'do you like it'? All of those are tests, and the engineering processes in those domains are put in place to ensure that that testing happens as early as possible, before mistakes are too costly to undo.
    - throwawayReply 9y ago
      A test is only a test if it can fail. All the projects I've seen, even the ones where there are "minimum viable projects" have too much pressure from above (or have already been sold) so they aren't allowed to fail. So I agree testing should happen as early as possible, but too often they're not real tests because failure isn't allowed.
Silhouette 9y ago
Embracing agile (as his ThoughtWorks contract requires him to do) while lamenting quality and lack of professionalism, as Mr Martin does, is extremely dishonest. "It is difficult to get a man to understand something when his salary depends upon his not understanding it." -- Upton Sinclair
lostboys67 9y ago
Civil Engineering still has its mishaps I had to reverse engineer a program to analyse soil density to prove that we (top 5 consulting engineers) where not responsible for abridge falling of its supports.

by _pmf_ 9y ago

sgift 9y ago

> Embracing agile (as his ThoughtWorks contract requires him to do) while lamenting quality and lack of professionalism, as Mr Martin does, is extremely dishonest. Why exactly? I fail to see the connection between lack of quality and embracing agile.

LeifCarrotson 9y ago
For the reasons explained in the previous project. A source of quality in mechanical and civil engineering is that they have rigid standards, legal regulations, and thorough specifications. These cost a lot of money, sacrifice a lot of flexibility, and add a lot of time, but they work. Agile development methods do create useful software quickly and cheaply, but are very dissimilar to this sort of strict framework. As an employee of ThoughtWorks, he can't suggest increased regulation and specification, because he's paid to suggest less of those things. It's disingenuous, then, to complain about a lack of the results of those processes when he's advocating a method that lacks those processes.
mannykannot 9y ago
In principle, 'agile' is so weakly defined that it is possible to follow a process that produces quality software and describe it as agile. In practice, insofar as agile stands for anything at all, one of its pillars is what might be called an 'active disinterest' in doing much thinking ahead, and in practice, it is very hard to produce quality software without doing some serious thinking ahead.
- k__ 9y ago
  Is this really true? I have the feeling "producing software" is a highly volatile process. First, software can do almost everything. You have WhatsApp, DOOM, Photoshop, Ableton Live, Google, Linux etc. which are hugely different systems and it was just the stuff that came to my mind in 10 seconds. Second, the requirements change and change. One person thinking ahead and getting a brilliant idea may end up with producing complete garbage, because many things have changed since they had the idea. I think the reason for the fact, that it hasn't been formalized and regulated like, for example, building cars, is simply that it can't be. Software isn't a car or a house or a ship. Software is an abstraction layer above this. It's more like the accumulated orders needed to build these things.
  - mannykannot 9y ago
    > I think the reason for the fact, that it hasn't been formalized and regulated like, for example, building cars, is simply that it can't be. NASA writes highly reliable software, as do the organizations producing the software for fly-by-wire airplanes, so your assertion is empirically false. You are extrapolating too far from your personal level of knowledge and experience.
    - k__ 9y ago
      Sure they do, but how much is because of formalization? I mean, just look at SQLite, which is a highly reliable software. They bought this stability with a gigantic test suite.
      - mannykannot 9y ago
        In what way do you think this supports your claims? What argument are you making here?
    - sgift 9y ago
      > NASA writes highly reliable software, as do the organizations producing the software for fly-by-wire airplanes, so your assertion is empirically false. What I find interesting is that both of your examples (and many others) are for software which controls physical systems, i.e. which is pretty well defined due to the nature of the machines it controls. Do you have comparable examples which aren't defined by the physical systems they interact with?
throwawayReply 9y ago
Civil engineers don't I suppose agree to build a bridge before they've surveyed the land and then begin construction before knowing the loads. Contrast that to software engineering, where beginning before you have requirements is seen as a requirement of being agile.
- sgift 9y ago
  > Contrast that to software engineering, where beginning before you have requirements is seen as a requirement of being agile. Not that I agree with all the agile ideas, but if I remember correctly we had a process already which was supposed to start with "gather all requirements" and then the rest follows. It was called waterfall development and didn't work so great either, mostly due to the 'all' part in requirements being violated all the time in practice.
- soru 9y ago
  This is kind of precisely backwards. A survey is like a test; it asks 'will this work'? A good civil engineer will do that as early as possible, rather than produce pages of engineering drawings blindly. A good civil engineer will calculate the stresses and load factors on a bridge as soon as possible, rather than assume things will work. A good architect will hand a sketch of a building to a client as early as possible, and ask 'do you like it'? All of those are tests, and the engineering processes in those domains are put in place to ensure that that testing happens as early as possible, before mistakes are too costly to undo.
  - throwawayReply 9y ago
    A test is only a test if it can fail. All the projects I've seen, even the ones where there are "minimum viable projects" have too much pressure from above (or have already been sold) so they aren't allowed to fail. So I agree testing should happen as early as possible, but too often they're not real tests because failure isn't allowed.

Silhouette 9y ago

Embracing agile (as his ThoughtWorks contract requires him to do) while lamenting quality and lack of professionalism, as Mr Martin does, is extremely dishonest. "It is difficult to get a man to understand something when his salary depends upon his not understanding it." -- Upton Sinclair

lostboys67 9y ago

Civil Engineering still has its mishaps I had to reverse engineer a program to analyse soil density to prove that we (top 5 consulting engineers) where not responsible for abridge falling of its supports.