Major players in evidence-based software engineering

Derek Jones from The Shape of Code

Who are the major players in evidence-based software engineering?

How might ‘majorness’ of players be calculated? For me, the amount of interesting software engineering data they have made publicly available is the crucial factor. Any data published in a book, paper or report is enough to be considered interesting. How interesting is data published on a web page? This is a tough question, let’s dodge the question to start with, and consider the decades before the start of 2000.

In the academic world performance is based on number of papers published, the impact factor of where they were published and number of citations of those papers. This skews the results in favor of those with lots of students (who tack their advisor’s name on the end of papers published) and those who are good at marketing.

Historians of computing have primarily focused on the evolution of hardware and are slowly moving to discuss software (perhaps because microcomputers have wiped out nearly every hardware vendor). So we will have to wait perhaps a decade or two for tentative/definitive historian answer.

The 1950s

Computers and Automation is a criminally underused resource (a couple of PhDs worth of primary data here). A lot of the data is hardware related, but software gets a lot more than a passing mention.

The US military published lots of hardware data, but software does not get mentioned much.

The 1960s

Computers and Automation are still publishing.

The US military still publishing data; again mostly hardware related.

Datamation, a weekly news magazine, published a lot of substantial material on the software and hardware ecosystems as they evolved.

Kenneth Knight’s analysis of computer performance is an example of the kind of data analysis that many people undertook for hardware, which was rarely done for software.

The 1970s

The US military are still leading the way; we are in the time of Rome. Air Force officers studying for a Master’s degree publish more software engineering data than all academics combined over this and the next two decades.

“Data processing technology and economics” by Montgomery Phister is 720 A4 pages packed with graphs and tables of numbers. Despite citing earlier sources, this has become the primary source for a lot of subsequent researchers; this is understandable in a pre-internet age. Now we have Bitsavers and the Internet Archive, and the cited primary source can be downloaded.

NASA is surprisingly low volume.

The 1980s

Rome falls (i.e., the work gets outsourced to a university) and the false prophets (i.e., academics doing non-evidence based work) multiply and prosper. There are hushed references to trouble makers performing unclean acts experiments in the wilderness.

A few people working in the wilderness, meaning that the quantity of data being produced drops by at least an order of magnitude.

The 1990s

Enough time has passed for people to be able to refer to the wisdom of the ancients.

There are still people in the wilderness howling at the moon, and performing unclean acts experiments.

The 2000s

Repositories of Open source and bug reports grow and prosper. Evidence-based software engineering research starts to become mainstream.

There are now groups of people doing software engineering research.

What about individuals as major players? A vaguely scientific way of rating individual impact, on evidence-based software engineering, is to count the number of papers they have published, that are cited by a book claiming to discuss all the important/interesting publicly available software engineering data (code+data).

The 1,521 papers cited, by such a book, had 3,716 authors, of which 3,095 were different. The authors who appeared most often are listed below (count on the right, and yes, at number 2 is a theoretician; I have cited myself nine times, but two of those are to web sites hosting data).

Magne Jorgensen 17
Anne Chao 11
Dag I. K. Sjoberg 10
Massimiliano Di Penta 10
Ahmed E. Hassan 8
Christian Bird 8
Stanislas Dehaene 8
Giuliano Antoniol 7
Thomas Zimmermann 7
Alexander Serebrenik 6
Dror G. Feitelson 6
Gregorio Robles 6
Krzysztof Czarnecki 6
Lutz Prechelt 6
Victor R. Basili 6

The number of authors/papers follows the usual pattern of many people writing one paper.

Number of evidence-based papers written by an author

Who might I have missed? The business school researchers don’t get a mention because their data is often covered by a confidentiality agreement. The machine learning crowd are just embarrassing.

Suggestions for major players welcome.

Direct access to SonarQube Postgresql Database

Tim Pizey from Tim Pizey

I want to change to change the name of a sonarqube project. This cannot be done without performing another analysis. You can just do it in SQL https://stackoverflow.com/questions/30511849/how-to-rename-a-project-in-sonarqube-5-1 but you have to be able to login to the database. Postgresql is very secure. A quick fix is to edit /var/lib//pgsql/pg_hba.conf change local connections from ident to trust:

# TYPE DATABASE USER CIDR-ADDRESS METHOD

# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust

Now you can edit:

psql -U sonarqube -W sonar
and finally:

UPDATE projects
SET name = 'NEW_PROJECT_NAME',
long_name = 'NEW_PROJECT_NAME'
WHERE kee = 'PROJECT_KEY'

My experience upgrading to Elm 0.19

Andy Balaam from Andy Balaam's Blog

Elm is unstable, so upgrading to the next version can be painful. Here’s what I needed to do to upgrade from 0.18 to 0.19.

  • Replace elm-package.json and tests/elm-package.json with elm.json – e06f5a1728
  • Switch to the new elm-testb964b7c7a
  • Re-arrange Main, and how we call it from JavaScript – 0c118c49f
  • Stop using eeue56/elm-all-dict (since it’s not ported to 0.19 and porting it looked hard due to a lack of Debug.crash) – fe100f256
  • Replace toString with String.fromX or Debug.toString – 9e78163d0a3
  • Stop “shadowing” names by making new variables with the same name as another in the scope – 9688a621de
  • Adapt to the changed Html.style function – b991ab4f
  • Stop using Debug.crash – f98a70ad1
  • Adapt to the changes in the Regex module – 856762a4
  • Stop using tuples with more than 3 parts – 472c0bb7

The lack of Debug.crash is really, really painful, especially for a library like eeue56/elm-all-dict that has lots of invariants that are hard or impossible to enforce via the type system. On the other hand, if Elm can give a hard guarantee that there will be no runtime errors, this seems pretty cool. The problem is that some code may well have to return the wrong answer silently, instead of crashing, which could be much worse than crashing in some use-cases.

I was annoyed by the lack of more-than-3-part tuples, but even as I did the work to change my code, I saw it get better, so it’s hard to argue with.

The hardest part to work out was how to run the tests. Fortunately the tests themselves needed almost no changes. I just needed to do this:

rm -r tests/elm-stuff
rm tests/elm-package.json
sudo npm install -g elm-test@0.19.0-beta8
elm-test install
elm-test

My next job is to check out the –optimize compiler flag, and the advice on making the code smaller and faster.

Visual Lint 6.5.4.298 has been released

Products, the Universe and Everything from Products, the Universe and Everything

This is a recommended maintenance update for Visual Lint 6.5. The following changes are included:

  • If a "Lint" folder without the hidden attribute exists in a solution/workspace folder Visual Lint will no longer attempt to use it to store analysis results and will create a new ".visuallint" folder instead. This prevents Visual Lint from assuming that a user-created "Lint" folder is one which was created by an earlier (pre-v5.0) version of Visual Lint.
  • Fixed a crash which could occur when files were saved in the Eclipse plug-in. The crash seemed to particularly affect plug-in installations running within Texas Instruments Code Composer Studio and configured for per-project analysis with the "Re-analyse saved files using the preferred method" option set.
  • The project variables $(CEVER), $(ARCHFAM) and $(_ARCHFAM_) are now automatically defined when analysing Visual Studio 2008 projects for the NetDCU9 (ARMV4I) platform.
  • Corrected the "Supported development environments" help topic to reflect the fact that Atmel AVR Studio 5 and Atmel Studio 6.x/7.x are now supported via a dedicated plug-in.
  • Updated the PC-lint Plus message database to reflect changes in PC-lint Plus 1.2. Note that the definitions for Clang errors 5905, 5916 and 5922 have been omitted as the PC-lint Plus -dump_messages directive does not reveal either their titles or descriptions.

Download Visual Lint 6.5.4.298

Visual Lint 6.5.4.298 has been released

Products, the Universe and Everything from Products, the Universe and Everything

This is a recommended maintenance update for Visual Lint 6.5. The following changes are included:

  • If a "Lint" folder without the hidden attribute exists in a solution/workspace folder Visual Lint will no longer attempt to use it to store analysis results and will create a new ".visuallint" folder instead. This prevents Visual Lint from assuming that a user-created "Lint" folder is one which was created by an earlier (pre-v5.0) version of Visual Lint.
  • Fixed a crash which could occur when files were saved in the Eclipse plug-in. The crash seemed to particularly affect plug-in installations running within Texas Instruments Code Composer Studio and configured for per-project analysis with the "Re-analyse saved files using the preferred method" option set.
  • The project variables $(CEVER), $(ARCHFAM) and $(_ARCHFAM_) are now automatically defined when analysing Visual Studio 2008 projects for the NetDCU9 (ARMV4I) platform.
  • Corrected the "Supported development environments" help topic to reflect the fact that Atmel AVR Studio 5 and Atmel Studio 6.x/7.x are now supported via a dedicated plug-in.
  • Updated the PC-lint Plus message database to reflect changes in PC-lint Plus 1.2. Note that the definitions for Clang errors 5905, 5916 and 5922 have been omitted as the PC-lint Plus -dump_messages directive does not reveal either their titles or descriptions.

Download Visual Lint 6.5.4.298

Visual Lint 6.5.4.298 has been released

Products, the Universe and Everything from Products, the Universe and Everything

This is a recommended maintenance update for Visual Lint 6.5. The following changes are included:
  • If a "Lint" folder without the hidden attribute exists in a solution/workspace folder Visual Lint will no longer attempt to use it to store analysis results and will create a new ".visuallint" folder instead. This prevents Visual Lint from assuming that a user-created "Lint" folder is one which was created by an earlier (pre-v5.0) version of Visual Lint.
  • Fixed a crash which could occur when files were saved in the Eclipse plug-in. The crash seemed to particularly affect plug-in installations running within Texas Instruments Code Composer Studio and configured for per-project analysis with the "Re-analyse saved files using the preferred method" option set.
  • The project variables $(CEVER), $(ARCHFAM) and $(_ARCHFAM_) are now automatically defined when analysing Visual Studio 2008 projects for the NetDCU9 (ARMV4I) platform.
  • Corrected the "Supported development environments" help topic to reflect the fact that Atmel AVR Studio 5 and Atmel Studio 6.x/7.x are now supported via a dedicated plug-in.
  • Updated the PC-lint Plus message database to reflect changes in PC-lint Plus 1.2. Note that the definitions for Clang errors 5905, 5916 and 5922 have been omitted as the PC-lint Plus -dump_messages directive does not reveal either their titles or descriptions.
Download Visual Lint 6.5.4.298

Business school research in software engineering is some of the best

Derek Jones from The Shape of Code

There is a group of software engineering researchers that don’t feature as often as I would like in my evidence-based software engineering book; academics working in business schools.

Business school academics have written some of the best papers I have read on software engineering; the catch is that the data they use is confidential. For somebody writing a book that only discusses a topic if there is data publicly available, this is a problem.

These business school researchers show that it is possible for academics to obtain ‘interesting’ software engineering data from industry. My experience with talking to researchers in computing departments is that most are too involved in their own algorithmic bubble to want to talk to anybody else.

One big difference between the data analysis papers written by academics in computing departments and business schools, is statistical sophistication. Computing papers are still using stone-age pre-computer age techniques, the business papers use a wide range of sophisticated techniques (sometimes cutting edge).

There is one aspect of software engineering papers written by business school researchers that grates with me, many of the authors obviously don’t understand software engineering from a developer’s perspective; well, obviously, they are business oriented people.

The person who has done the largest amount of interesting software engineering research, whose work I don’t (yet; I will find a way) discuss, is Chris Kemerer; a researcher who has a long list of empirical papers going back to the early 1990s, and rarely gets cited by papers by people in computing departments (I am the only person I know, who limits themself to papers where the data is publicly available).

#NoProjects: Project Myopia is published

Allan Kelly from Allan Kelly Associates

ProjectMyopiaNew-2018-09-10-11-17.jpg

Project Myopia – the original case for #NoProjects – has been a long time in the works but it is now done. Published. For sale on Amazon.

Projects fail. Some say 40% of all IT projects fail, some say 70%. And it has been that way for years. Each project fails for its own reasons but they all share one thing in common: the Project Model. Could it be the project model itself which creates failure?

Projects end. Successful software continues. Twenty-first century digital businesses want to continue and grow.

Project Myopia is available to buy on Amazon today – the physical version should joined the eBook in a few days.

Project Myopia gives the case against projects – the hard core #NoProjects arguments. A second book, Continuous Digital will join Project Myopia in a few weeks on Amazon. Right now copyediting isn’t finished on Continuous Digital, plus the physical copy needs to be worked out. In the meantime late drafts of Continuous Digital are available on LeanPub.

The post #NoProjects: Project Myopia is published appeared first on Allan Kelly Associates.

#NoProjects: Project Myopia is published

Allan Kelly from Allan Kelly Associates

ProjectMyopiaNew-2018-09-10-11-17-1.jpg

Project Myopia – the original case for #NoProjects – has been a long time in the works but it is now done. Published. For sale on Amazon.

Projects fail. Some say 40% of all IT projects fail, some say 70%. And it has been that way for years. Each project fails for its own reasons but they all share one thing in common: the Project Model. Could it be the project model itself which creates failure?

Projects end. Successful software continues. Twenty-first century digital businesses want to continue and grow.

Project Myopia is available to buy on Amazon today – the physical version should joined the eBook in a few days.

Project Myopia gives the case against projects – the hard core #NoProjects arguments. A second book, Continuous Digital will join Project Myopia in a few weeks on Amazon. Right now copyediting isn’t finished on Continuous Digital, plus the physical copy needs to be worked out. In the meantime late drafts of Continuous Digital are available on LeanPub.

The post #NoProjects: Project Myopia is published appeared first on Allan Kelly Associates.