Hacker News Reader

Comment by k__ | Hacker News Reader

I talked with a few mechanical engineers, a much older profession than software engineering. They have higher standards and whatnot, but I'm seriously happy that I don't work in that industry. Many I talked to even switched to SE because it's easier money and people in SE are more relaxed.

View on HN

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

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

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

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.

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.

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

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

Operating systems/kernels as a whole largely deal with abstractions, and some are built to incredibly high, and in some cases mathematically proven, standards. seL4 is an example of a formally verified kernel.

So are you arguing that very well-defined and carefully thought-out requirements are, in practice, essential to the development of high-quality software?

That would be quite the no-brainer, wouldn't it be?

All the dancing around waterfall, agile or what ever turns around the problem that people usually don't know what their requirements are, are not able to formulate what their requirements are, but hopefully know when they see something it if something helps them or not. If we could just get people to define their requirements in all the detail needed we would take a great step forward, but looking around .. I don't see this happening in the near future.

I.e. Let's avoid the question of quality altogether by declaring it an unsolvable problem in the limit.

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.

In what way do you think this supports your claims? What argument are you making here?

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.

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.

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

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.

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.

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.

Reply on news.ycombinator.com