Using tuned.conf to disable mongod startup warnings on RHEL/CentOS 7

Timo Geusch from The Lone C++ Coder's Blog

RHEL 7 – and CentOS 7, which I used for this test – use tuned.conf to set a lot of system settings. Several of the tuned settings affect MongoDB’s performance; some are important enough that mongod actually triggers startup warnings. The main setting is transparent huge pages, which is a setting that does not work […]

The post Using tuned.conf to disable mongod startup warnings on RHEL/CentOS 7 appeared first on The Lone C++ Coder's Blog.

McCabe’s cyclomatic complexity and accounting fraud

Derek Jones from The Shape of Code

The paper in which McCabe proposed what has become known as McCabe’s cyclomatic complexity did not contain any references to source code measurements, it was a pure ego and bluster paper.

Fast forward 10 years and cyclomatic complexity, complexity metric, McCabe’s complexity…permutations of the three words+metrics… has become one of the two major magical omens of code quality/safety/reliability (Halstead’s is the other).

It’s not hard to show that McCabe’s complexity is a rather weak measure of program complexity (it’s about as useful as counting lines of code).

Just as it is possible to reduce the number of lines of code in a function (by putting all the code on one line), it’s possible to restructure existing code to reduce the value of McCabe’s complexity (which is measured for individual functions).

The value of McCabe’s complexity for the following function is 16, i.e., there are 16 possible paths through the function:

int main(void)
{
if (U) a(); else b();
if (X) c(); else d();
if (Y) e(); else f();
if (Z) g(); else h();
}

each ifelse contains two paths and there are four in series, giving 2*2*2*2 paths.

Restructuring the code, as below, removes the multiplication of paths caused by the sequence of ifelse:

void a_b(void) {if (U) a(); else b();}

void c_d(void) {if (X) c(); else d();}

void e_f(void) {if (Y) e(); else f();}

void g_h(void) {if (Z) g(); else h();}

int main(void)
{
a_b();
c_d();
e_f();
g_h();
}

reducing main‘s McCabe complexity to 1 and the four new functions each have a McCabe complexity of two.

Where has the ‘missing’ complexity gone? It now ‘exists’ in the relationship between the functions, a relationship that is not included in the McCabe complexity calculation.

The number of paths that can be traversed, by a call to main, has not changed (but the McCabe method for counting them now produces a different answer)

Various recommended practice documents suggest McCabe’s complexity as one of the metrics to consider (but don’t suggest any upper limit), while others go as far as to claim that it’s bad practice for functions to have a McCabe’s complexity above some value (e.g., 10) or that “Cyclomatic complexity may be considered a broad measure of soundness and confidence for a program“.

Consultants in the code quality/safety/security business need something to complain about, that is not too hard or expensive for the client to fix.

If a consultant suggested that you reduced the number of lines in a function by joining existing lines, to bring the count under some recommended limit, would you take them seriously?

What about, if a consultant highlighted a function that had an allegedly high McCabe’s complexity? Should what they say be taken seriously, or are they essentially encouraging developers to commit the software equivalent of accounting fraud?

Visual Lint 6.5.1.294 has been released

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

Visual Lint 6.5.1.294 has just been released. This is a maintenance update for Visual Lint 6.5, and is compatible with all Visual Lint 6.0 and 6.5 licence keys. The following changes are included:
  • Built-in compiler preprocessor symbols are now automatically included in the analysis configuration for Atmel Studio projects using ARM toolchains where possible.
  • Fixed a bug which caused a "project changed" event to be erroneously sourced if an external project file located in the same folder as a loaded project was changed.
  • The PC-lint raw analysis results parser will now raise a fatal error if a PC-lint Plus License Error is detected.
  • Fixed a bug in the "Analysis Tool" Options page which affected browsing for an analysis tool installation folder.
  • Modified a handful of prompts to refer to "PC-lint or PC-lint Plus" rather than just "PC-lint".
Download Visual Lint 6.5.1.294

Top, must-read paper on software fault analysis

Derek Jones from The Shape of Code

What is the top, must read, paper on software fault analysis?

Software Reliability: Repetitive Run Experimentation and Modeling by Phyllis Nagel and James Skrivan is my choice (it’s actually a report, rather than a paper). Not only is this report full of interesting ideas and data, but it has multiple replications. Replication of experiments in software engineering is very rare; this work was replicated by the original authors, plus Scholz, and then replicated by Janet Dunham and John Pierce, and then again by Dunham and Lauterbach!

I suspect that most readers have never heard of this work, or of Phyllis Nagel or James Skrivan (I hadn’t until I read the report). Being published is rarely enough for work to become well-known, the authors need to proactively advertise the work. Nagel, Dunham & co worked in industry and so did not have any students to promote their work and did not spend time on the academic seminar circuit. Given enough effort it’s possible for even minor work to become widely known.

The study run by Nagel and Skrivan first had three experienced developers independently implement the same specification. Each of these three implementations was then tested, multiple times. The iteration sequence was: 1) run program until fault experienced, 2) fix fault, 3) if less than five faults experienced, goto step (1). The measurements recorded were fault identity and the number of inputs processed before the fault was experienced.

This process was repeated 50 times, always starting with the original (uncorrected) implementation; the replications varied this, along with the number of inputs used.

For a fault to be experienced, there has to be a mistake in the code and the ‘right’ input values have to be processed.

How many input values need to be processed, on average, before a particular fault is experienced? Does the average number of inputs values needed for a fault experience vary between faults, and if so by how much?

The plot below (code+data) shows the numbers of inputs processed, by one of the implementations, before individual faults were experienced, over 50 runs (sorted by number of inputs):

Number of inputs processed before particular fault experienced

Different faults have different probabilities of being experienced, with fault a being experienced on almost any input and fault e occurring much less frequently (a pattern seen in the replications). There is an order of magnitude variation in the number of inputs processed before particular faults are experienced (this pattern is seen in the replications).

Faults were fixed as soon as they were experienced, so the technique for estimating the total number of distinct faults, discussed in a previous post, cannot be used.

A plot of number of faults found against number of inputs processed is another possibility. More on that another time.

Suggestions for top, must read, paper on software faults, welcome (be warned, I think that most published fault research is a waste of time).

Digg Reader shuts down, and thoughts on organising my blog reading

Timo Geusch from The Lone C++ Coder's Blog

Farewell, Digg Reader Unfortunately,  Digg announced that Digg Reader is shutting down tomorrow. While I never used Digg Reader as my main RSS feed reader – I’ve got a paid subscription to Feedly – I was very happy to use it as a backup reader for those feeds that weren’t always that great at adhering […]

The post Digg Reader shuts down, and thoughts on organising my blog reading appeared first on The Lone C++ Coder's Blog.

Product Owner or Backlog Administrator?

Allan Kelly from Allan Kelly Associates

3337233_thumbnail-2018-03-20-18-08.jpg

In the official guides all Product Owners are equal. One size fits all.

In the world I live in some Product Owners are more equal than others and one size does not fit all.

The key variable here is the amount of Authority a Product Owner has. In my last post I said that Authority is one of the four things every product owner needs – the others being legitimacy, skills and time. However there is a class of Product Owner who largely lack authority and who I have taken to calling Backlog Administrators.

About the only thing a Backlog Administrator owns is their Jira login. They are at the beck and call of one or more people who tell them what should be in the backlog. Prioritisation is little more than an exercise in decibel management – he who shouts loudest gets what they want.

A Backlog Administrator rarely throws anything out of the backlog, they don’t feel they have the authority to do so. As a result their backlogs are constipated – lots of stories, many of little value. Fortunately Jira knows no limits, it is a bottomless pit – just don’t draw a CfD or Burn-Up chart!

If the team are lucky the Backlog Administrator can operate as a Tester, they can review work which is in progress or possibly “done.” They may be able to add acceptance criteria. If the team are unlucky the Backlog Administrator doesn’t know enough about the domain to do testing.

I would be the first to say that the Product Owner role can be vary a great deal: different individuals working with different teams in different domains for different type of company mean there that apart from backlog administration there is inherently a lot of variability in the role.

The Product Owner role should be capable of deciding what to build and/or change.

So Product Owners need to know what the most valuable thing to do it. Part of the job means finding out what is valuable. While Backlog Administration is part of the job the question one should ask is:

How does the Product Owner know what they need to know to do that?

Backlog Administrators are little more than gophers for more senior people.

True Product Owners take after full Product Managers and Senior Business Analysts – or a special version of Business Analysts sometimes called Business Partners.

Product Owners should be out meeting customers and observing users. They should be talking about technology options with the technical team and interface design options with UXD.

Product Owners should understand commercial pressures, how the product makes (or saves) money for the company. Product Owners are responsible for Product Strategy so they should both understand company strategy and input into company strategy. Product Strategy both supports company strategy and feeds into company strategy.

Product Owners may need to observe the competitor landscape and keep an eye on competitors and understand relevant technology trends. That probably means attend trade shows and even supporting sales people if asked.

Frequently Product Owners will require knowledge of the domain, i.e. the field in which your product is used. Sometimes – like in telecoms or surveying that may require actual hands on experience.

And apart from backlog administration there is a lot of work to do to deliver the things they want delivered: they need to work with the technical team to explain stories, to have the conversations behind the story, write acceptance criteria, attend planning meetings, perhaps help with interviewing new staff and sharing all the things they learn from meeting customers, analysing competitors, debating strategy, attending shows, etc. etc.

I sure there are many who would rush to call the Backlog Administrator an “anti-pattern” but since I don’t believe in anti-patterns I don’t. I just think Product Owners should be more than a Backlog Administrator.

The post Product Owner or Backlog Administrator? appeared first on Allan Kelly Associates.