Morendil

(N.B. This is a blog post I wrote on Google+ in 2014, which had since disappeared from the Web.)

Can we bury the NIST study once and for all now?

The NIST study concluded that "the impact of inadequate software testing infrastructure on the US economy was between 22.2 and 59.5 billion dollars".

As usual, people mention this figure as if it was an undisputed fact (for instance, you can find it on a couple Wikipedia pages). It's a good bet that they haven't read the original document carefully and critically. If they had, they might have noticed some red flags in the "study" and would at the very least hedge by emphasizing that it is an estimate.

There are two important aspects to any estimate: precision and accuracy.

Morendil

This is an old piece I wrote a few years ago (late 2012), which I don't think I ever published. I couldn't be bothered to write up a conclusion, I think - it was pretty obvious anyway what to conclude.

Research in the age of sampling - dissecting the Frankenpaper

Around Halloween I came across a paper titled "Cost Effective Software Test Metrics", by Lazic et al. It appears to have been published in "WSEAS Transactions on Computers", in June 2008.

WSEAS is an organization whose academic standing is a little difficult to investigate; searching for its name will lead you to a number of blogs, for instance, that vigorously denounce other organizations for creating bogus conferences, sending spam, or defrauding researchers. The Shakespearean phrase "the lady doth protest too much" comes to mind.

Plagiarism in the Google age

Morendil

Note: this content is reposted from my old Google Plus blog, which disappeared when Google took Plus down. It was originally published on 2016-05-18. My views and the way I express them may have evolved in the meantime. If you like this gist, though, take a look at Leprechauns of Software Engineering. (I have edited minor parts of this post for accuracy after having a few mistakes pointed out in the comments.)

Degrees of intellectual dishonesty

In the previous post, I said something along the lines of wanting to crawl into a hole when I encounter bullshit masquerading as empirical support for a claim, such as "defects cost more to fix the later you fix them".

It's a fair question to wonder why I should feel shame for my profession. It's a fair question who I feel ashamed for. So let's drill a little deeper, and dig into cases.

Before we do that, a disclaimer: I am not in the habit of judging people. In what follows, I only mean to condemn behaviours. Also, I gath

Morendil

Note: this content is reposted from my old Google Plus blog, which disappeared when Google took Plus down. It was originally published on 2016-05-16. My views and the way I express them may have evolved in the meantime, and I have likely revisited this investigation in a somewhat more rigorous manner since.

This is just how embarrassed I am for my entire profession

So here I was idly looking at Twitter, when Scott Nickell innocently poked me, regarding one more instance of the old "cost of defects" chestnut:

"I can't tell if this "Systems Sciences Institute at IBM" thing is a new study, or just the same-old."

I was feeling lazy, so I encouraged Scott to apply the usual Leprechaun hunting process: "Here's how you could tell: Google exact phrase for a portion of the article citing it, then note the publication dates of hits." ([Try it](https://www.google.com/search?q=%22cost+to+fix+an+er

Morendil

OpenFisca et "métaprogrammation"

rfr = individu.foyer_fiscal('rfr', period.n_2)

L'appel ci-dessus est à peu près équivalent à

simulation = individu.simulation

Morendil

The citations game: Cone of Uncertainty

Rubric: Software Engineering : Factual Claims : Cone of Uncertainty : Empirical Validation

Context

The Wikipedia page on "Cone of Uncertainty" lists two "empirical validations" of Boehm's initial work. I didn't chase these down for Leprechauns. They are:

• "Later work by Boehm and his colleagues at USC applied data from a set of software projects from the U.S. Air Force and other sources to validate the model;"
• "The basic model was further validated based on work at NASA's Software Engineering Lab (NASA 1990 p. 3-2)."

Morendil

1. What do you want to do at Alan? How do you see your ideal role?

I'll be answering this in two parts - what I'd want to do anywhere quite generically, and what might make me feel happy at Alan, given what I know about the organization.

Perhaps the biggest thing I intend to do, in any professional role, is to "bring my whole self to work", and expect and encourage others around me to do the same. I've long felt that the software industry tends to get too hung up on narrowly defined "roles" - developer, tester, architect, data person, and so on. For me, each person fits the Whitman quote, "I am vast, I contain multitudes". We each have a variety of resources we can draw upon, developed from past professional experience or from personal life - as a parent, a spouse, a friend, a volunteer, and so on - or from how other people or even fictional characters have inspired us.

For instance, while I primarily think of myself as a developer, one of my facets consists of team "coaching" tools. One such tool that I

Morendil

The citations game: Wolverton Ratios

Rubric: Software Engineering : Factual Claims : Defect Cost Increase : Wolverton Ratios

Context

See previous note on the IBM Systems Sciences Institute

In absolute numbers, the Wolverton are as follows: 139:455:977:7136:14102, claimed dollar costs of fixing an "average" defect. (Itself an absurd claim, see Leprechauns, I should perhaps write more on that.)

Morendil

The citations game: Pressman Ratios

Rubric: Software Engineering : Factual Claims : Defect Cost Increase : Pressman Ratios

Context

See previous note on the IBM Systems Sciences Institute

Origins

Morendil

The IBM Systems Science Institute

Rubric: Software Engineering : Factual Claims : Defect Cost Increase : Pressman Ratios

Context

Background: I have been researching quantity and quality of empirical evidence underlying claims in software engineering. What do we know, and how well-established is that? See in particular https://leanpub.com/leprechauns which concludes that the answer is in (too) many cases "not much, and poor".

This applies in particular to the "Defect Cost Increase" claim, which is poorly supported by evidence. The claim states that the longer a defect stays undiscovered after being introduced in a software system's artefacts, the more expensive it is to correct.