Live data from Hacker News

The Making of Software Engineering Myths

modelviewculture.com

11–20 of 52 posts

Re: The Making of Software Engineering Myths

#11
Fucken retard-nigger. You want to fight God? Stupid fuck.

God says... birds poor I_made_it_that_way take_your_pick Percival now_that_I_think_about_it vermin yikes tree_hugger couldnt_possibly hurts_my_head services petty rich awesome hotel zoot if_anything_can_go_wrong ice_cream mine watch_it_buddy patience computers smile nasty Angel Oy I'm_gonna_smack_someone kick_back but_of_course hopefully na_na I'll_ask_nicely bastard begs_the_question depressing you're_no_fun what_would_Jesus_do endure awful Is_that_so caution

God says... C:\TAD\Text\PLATO.TXT

th him, and been present at his dally life and known him in his family relations, where he may be seen stripped of his tragedy attire, and again in the hour of public danger--he shall tell us about the happiness and misery of the tyrant when compared with other men?

That again, he said, is a very fair proposal.

Shall I assume that we ourselves are able and experienced judges and have before now met with such a person? We shall then have some one who will answer our enquiries.

By all means.

----

Kill the nigger.

God says... wife umm_the_other_answer Oh_really hotel it's_my_world as_a_matter_of_fact I'm_busy quite taxes charity lifes_like_chocolates

Re: The Making of Software Engineering Myths

#12
post #5
post #3

Earlier quoted context omitted.

"singling out some myths for critique rather than others gives a misleading impression" Article author here. Agree with your first para, so the above has me puzzled, a bit. Would you please expand: what impressions do you think the article gives, that are misleading? (And if possible: what do you see or hear that makes you think they are misleading?)

Edit: What I said there was rooted in earlier discussions and not the current article. Sorry; my confusion. But I'll leave the explanation of what I meant anyway. You place so much emphasis on dismantling the 10x claim (writing an entire book about it) rather than software research in general, that an observer might reasonably be left with the impression that there's something more "mythy" about that claim than other…

> dismantling the 10x claim (writing an entire book about it)

"Leprechauns" is by no means entirely about 10x developers.

In it I also tackle things like the "exponentially increasing cost of bugs" claim, the Cone of Uncertainty, the "software crisis", the successive mythical reconstructions of the Waterfall bogeyman, the limitations of the "empirically based software engineering" movement and specifically the problem of discipline envy.

If it had only been the 10x thing that turned out to be ill-supported I wouldn't have gotten my knickers all atwist. My beef is precisely that when you look closely most of software engineering looks awfully like pseudoscience.

This article is, in a way, Chapter 1 of the next book, in which I'd look beyond "academic" myths, and try to confront a broader picture of how the software community thinks about itself, and how that perpetuates some of the problems we've been bitching about for decades. (And some of these problems turned out to be non-existent; other very real ones barely rate a nod from academia. That is also part of the problem.)

Re: The Making of Software Engineering Myths

#13
post #2

Can anyone name a finding of software engineering research that isn't folklore? I've looked many times. The field is strikingly weak. It is typified by tiny sample sizes, subjective analysis, and zero replication. [Edit: deleted mistaken impression here.]

Try "Making Software: What really works and why we believe it". I'm about halfway thru reading it, some of the findings presented are that TDD studies either aren't very good or give inconclusive results; that a number of code complexity metrics don't predict bug rates any better than file size does; that bug rates are correlated with how well organizational structure matches code structure; and that competent PHP pr…

I have the book and have read several (though not all) of the papers. I didn't see anything worth exempting from what I wrote above. The state of the field is just very weak. Even the good researchers, like Lutz Prechelt, aren't producing anything that comes close to justifying changing one's mind based on evidence. (The PHP vs. Java article struck me as fluff; so many other variables come to mind so easily.) I'd be happy to be wrong. Counterexamples are welcome.

I did like the paper on code size very much. The principle that code size is the best measurement of complexity and a good predictor of error rates is probably the finding I'd name if I had to answer my own "name one that isn't folklore" question. At least that one has multiple studies behind it. Even so, most of them (that I've seen) aren't very good.

Re: The Making of Software Engineering Myths

#14
post #5

Earlier quoted context omitted.

Edit: What I said there was rooted in earlier discussions and not the current article. Sorry; my confusion. But I'll leave the explanation of what I meant anyway. You place so much emphasis on dismantling the 10x claim (writing an entire book about it) rather than software research in general, that an observer might reasonably be left with the impression that there's something more "mythy" about that claim than other…

> dismantling the 10x claim (writing an entire book about it) "Leprechauns" is by no means entirely about 10x developers. In it I also tackle things like the "exponentially increasing cost of bugs" claim, the Cone of Uncertainty, the "software crisis", the successive mythical reconstructions of the Waterfall bogeyman, the limitations of the "empirically based software engineering" movement and specifically the proble…

Thanks for the clarification. It seems we disagree less than I thought, and I've deleted my mistaken impression from the root comment.

I may have asked you this before, but do you know of any finding in the research literature that you don't consider pseudoscience? The only one I know of that might come close is research on code size. I've heard that the literature on code inspections is good, but that may just be another myth.

Re: The Making of Software Engineering Myths

#15
The 10x engineer exist but not because he or she is so great but because they wrote the shitty code in the first place so it takes a new person 10x longer than the author to do anything.

the exponential cost thing is probably somewhat true. If the people who come up with the software actually knew what the fuck they wanted they would save the software from having to guess wrong and redo the code. Unless the software runs on a million dollar jet or something finding a bug during testing should not be 100x more then finding it during code. Infact I can make a decent argument that it is cheaper to pay a tester to find bugs then to waste an engineers time looking for them.

the software crises story about defence i think is real: http://www.reuters.com/investigates/pentagon/#article/part1

Re: The Making of Software Engineering Myths

#16
post #9

"The trope of 'software as a highly abstract, intellectually demanding, nearly mathematical activity' contributes to a myth of software development as a profession 'naturally' dominated by males: math is the subject of its own interlocking system of tropes, myths and stereotypes that paint it as a manly pursuit." That logic seems to be all backwards to me. Of course developing software is a highly abstract, intellect…

> Of course developing software is a highly abstract, intellectually demanding activity

I don't mean to sound harsh, but "of course" and "it's absurd" aren't much of an argument.

My advice is to dig into this a bit deeper. What do you think makes software "a highly abstract, intellectually demanding activity"? What would the world look like if that were NOT the case, what would it look like if it WERE the case?

How does this claim coexist with that, which has been bandied about for decades, that software programming is on the brink of being automated away?

How does this claim square with sites like the Daily WTF, which provide evidence that many gainfully employed programmers do not, in fact, use their brains very much? With the more or less weekly announcements of "security breaches" caused by people ignoring basic best practice, for instance storing passwords in plain text?

How much mathematical(ish) ability is actually needed to put together a Web page, a bunch of CRUD fields, and some backend database template?

Why is it so easy to get a job writing software even if you have no formal credentials at all? How is it that some people can get these jobs even if all they can do is write a Web page, and that badly?

It's possible that our experiences differ: that for you software has been abstract and demanding. (I can see people who write kernels for a living getting the "of course" reaction.) Whereas I've often rubbed shoulders with the world of "IT programming", with self-taught games programmers and Web programmers and people who turned a half-baked idea and their gift for the gab into multimillion dollar businesses.

Whenever I did my homework and dug into the facts, I found that things that "of course" held true weren't all that obvious. I'm trying to encourage people in the profession to get into that habit.

> as absurd as claiming women are somehow incapable of doing exactly that

Yes, I too see that as a false claim. Do you deny that there are people out there who are in fact making that claim?

Re: The Making of Software Engineering Myths

#17
post #9

"The trope of 'software as a highly abstract, intellectually demanding, nearly mathematical activity' contributes to a myth of software development as a profession 'naturally' dominated by males: math is the subject of its own interlocking system of tropes, myths and stereotypes that paint it as a manly pursuit." That logic seems to be all backwards to me. Of course developing software is a highly abstract, intellect…

> Of course developing software is a highly abstract, intellectually demanding activity I don't mean to sound harsh, but "of course" and "it's absurd" aren't much of an argument. My advice is to dig into this a bit deeper. What do you think makes software "a highly abstract, intellectually demanding activity"? What would the world look like if that were NOT the case, what would it look like if it WERE the case? How d…

>How does this claim square with sites like the Daily WTF, which provide evidence that many gainfully employed programmers do not, in fact, use their brains very much? With the more or less weekly announcements of "security breaches" caused by people ignoring basic best practice, for instance storing passwords in plain text?

I take many people being bad at programming as evidence that programming is hard, not that it's easy. Maybe it's evidence that getting a programing job is easy, but that's not the same thing.

Re: The Making of Software Engineering Myths

#18
Tons of 10x hate in here already. Is there a reason this is such a stumbling block for people? Is there a reason that isn't tinged by sour grapes? I'm like 99% convinced that I've worked with such people and seen what they can do. I'd be willing to buy that it isn't simply the individual, but the individual plus the right circumstances. But I absolutely can't say that I've never seen a single developer write a surprisingly large amount of good code in a surprisingly short amount of time, because I have seen it.

Re: The Making of Software Engineering Myths

#19
post #17

Earlier quoted context omitted.

> Of course developing software is a highly abstract, intellectually demanding activity I don't mean to sound harsh, but "of course" and "it's absurd" aren't much of an argument. My advice is to dig into this a bit deeper. What do you think makes software "a highly abstract, intellectually demanding activity"? What would the world look like if that were NOT the case, what would it look like if it WERE the case? How d…

>How does this claim square with sites like the Daily WTF, which provide evidence that many gainfully employed programmers do not, in fact, use their brains very much? With the more or less weekly announcements of "security breaches" caused by people ignoring basic best practice, for instance storing passwords in plain text? I take many people being bad at programming as evidence that programming is hard, not that it…

> I take many people being bad at programming as evidence that programming is hard, not that it's easy.

We are in violent agreement. Note that "hard" is not the same as "abstract and intellectually demanding". Running a marathon is hard. Becoming a US Marine is hard. Many things are hard that do not primarily require quasi-mathematical skills.

For that matter, finding gravitational waves is hard but may be just as much about investing enough money (think space-based laser interferometry) or just plain luck.

The ways in which people suck at programming are much more diverse than just a failure of abstraction, otherwise we would all be writing Haskell.

These ways include failure to ask what the user or sponsor wants, failure to make sure we've understood what the user or sponsor said, failure to communicate with other members of the team, failure to question the things we learned in school and always took for granted. All of these are common failure modes in the biz, none of them are a failure of abstraction.

In fact excessive or premature abstraction is a widely recognized failure mode of software engineers, and the myth is responsible in good part for that.

Re: The Making of Software Engineering Myths

#20

The 10x engineer exist but not because he or she is so great but because they wrote the shitty code in the first place so it takes a new person 10x longer than the author to do anything. the exponential cost thing is probably somewhat true. If the people who come up with the software actually knew what the fuck they wanted they would save the software from having to guess wrong and redo the code. Unless the software…

I don't know why anyone down voted this because there's definitely at least some truth here. A lot of times the stereotypical 10x rock stars in an organization are really smart and productive people who ship features and move on to the next feature, leaving maintenance to the people who are left behind. They get the glory, but in many cases (totally anecdotal of course) they did it by taking all sorts of shortcuts and kludging things together in ways that aren't scalable or maintainable.

In this case, the 10x productivity boost comes from incurring technical debt that they personally will never have to deal with. Many organizations need these people in order to actually ship stuff, but their productivity comes at a cost that's paid for later, by other people. Maybe they're 10x up front, but it ends up being more like 1-2x when these costs are taken into account.

I'm more worried about the much more tangible 0.1x (or the feared but very real -1x) engineers, who exist in many organizations.

Post reply on HN