Statement sequence length for error/non-error paths

Derek Jones from The Shape of Code

One of the folk truisms of the compiler/source code analysis business is that error paths are short, i.e., when an error situation is detected (such as failing to open a file), few statements are executed before the functions returns.

Having repeated this truism for many decades, figure 2 from the paper APEx: Automated Inference of Error Specifications for C APIs jumped off the page at me; thanks to Yuan Kang, I now have a copy of the data.

The plots below (code+data) show two representations of the non-error/error path lengths (measured in statements within individual functions of libc; counting starts at a library call that could return an error value). The upper plot shows statement sequence lengths for error/non-error paths, and the lower is a kernel density plot of the error/non-error sequence lengths.

Statements contains in error and non-error paths

Another truism is that people tend to write positive tests, i.e., tests that do not involve error handling (some evidence).

Code coverage measurements (e.g., number of statements or branches that are executed by a test suite) often show the pattern seen in the plot below (code+data; thanks to the authors of the paper Code Coverage for Suite Evaluation by Developers for making the data available). The data was obtained by measuring the coverage of 1,043 Java programs executing their associated test suite (circles denote program size). Lines are fitted regression models for different sized programs.

Statement coverage against decision coverage

If people are preferentially writing positive tests, test suites with low coverage would be expected to execute a greater percentage of statements than branches (an if-statement has two branches, taken/not-taken), i.e., the behavior seen in the plot above (grey line shows equal statement/branch coverage). Once the low hanging fruit is tested (i.e., the longer, non-error, cases), tests have to be written for the shorter, more likely to be error handling, cases.

The plot would also be explained by typical execution paths favoring longer basic blocks, but I don’t have any data that could show this one way or another.

The new issue of the nor(DEV): magazine is out now, free to download!

Paul Grenyer from Paul Grenyer



This issue focuses on Business in Tech. Or Tech in Business, as it is almost impossible to have one without the other and they both have an equally important role to play in our region. Countless reports from business minds, governments and international organisations are all talking about how technology is going to play a bigger part in manufacturing, commerce and business in general.

So where does Norfolk fit in?

Luckily we’ve pulled together articles and interviews from some of the region’s leading names including Chris Sargisson and Tim Robinson, as well as celebrating all things Her with a gallery from the DevelopHER Awards. Speaking of women in tech, Hayley Johnson from Epos Now has been kind enough to close the issue with an inspirational call to action for all businesses.

We hope you enjoy this new issue and share the link with your friends and colleagues!

Download here.

Industry 4.0 – I Was There!

Paul Grenyer from Paul Grenyer

Last week we attended the Evolution: Journey into Industry 4.0 event and it was an illuminating experience! Not only did we get to hear from some of manufacturings leading lights in the region, we got to talk alongside them at Naame’s packed conference.

As well as having our exhibition stand, our Director Paul Grenyer spoke at the event, demonstrating the value of process automation within manufacturing and how it will support growth in the sector. No capital expenditure required! Paul was able to share the benefits our clients have already seen from automating processes, and have a little fun along the way too!

Other speakers included industry gurus from Loughborough University, the Department for International Trade, Knowledge Transfer Manager – KTN – Innovate UK, Cranfield University, Hethel Innovation and West Suffolk College. We were also fortunate enough to hear from companies already putting automation into practice to great effect, including Warren Services, asset intelligence group Pathfindr, telecoms giant Huawei UK and electric motors company MSF Technologies. We were also reassured that despite some reports claiming future tech would mean job losses, those at Industry 4.0 disagreed, saying job roles would simply evolve from manual tasks to monitoring and analysing. It was also interesting to discover that our region is leading the way in disruptive tech!

Henk Koopmans, chief executive of Huawei UK, encouraged business to ‘think big’ and focus on their market first, but the main takeaway message from the event was that engineering needed to play an important part of the New Anglia LEP economic strategy. The LEP is hoping for greater involvement from businesses to help define the skills needed in five years time so it can work with colleges to get those skills taught now in preparation.

For Naame’s part, it hopes to support manufacturers and introduce them to others who may be able to help with the challenges they face. They are also looking to create manufacturing groups in Suffolk – contact Naame if you are interested. The New Anglia Advanced Manufacturing and Engineering group are also looking to develop a strategic map and would like feedback on a consultation document being released onto their website this week.

The day proved to be a worthwhile investment, with genuinely interesting speakers and an intelligent audience keen to support and be involved in the next phase of industry in our region.

Interested in finding out what Naked Element can do to prepare your business for Industry 4.0? Get in touch for a cup of tea and a chat!

Originally published here.

Sprint Zero

Allan Kelly from Allan Kelly Associates

SprintZero-2018-02-25-11-21.jpg

Starting a new project? A new product? Have a team transitioning to “Agile” (aka Scrum) and wanting to get ready?

Why not try a Sprint Zero? – Why not indeed.

Sprint Zero is a way to get everything ready to start work, to buy the tools you need, set up your databases, perhaps do some architecture review, tell the rest of the organization about what you are doing, maybe write some requirements, get some additional training, etc. etc.

Sprint Zero doesn’t need to happen in a time box, you can take all the time you need, after all, you haven’t become “agile” yet, Sprint Zero will make you Agile.

Good idea?

Please don’t.

Sprint Zero is a get-out-of-jail-free card that pushes really change down the road a little bit further.

The truth is: there is work to do.

Just start “sprinting”. Schedule an iteration to start tomorrow and get going. Do what you plan for the next week, then review and plan again.

Doing anything else delays the change and potentially reduces motivation.

If you want to call your first iteration Zero then fine; you can call it Zero, or One, or Two, or 57 or even -1 if you want, I don’t care. Give it a number and make sure the next iteration adds one to that number.

All those things I just listed – and more – that you need to do to “get started” are themselves work that needs doing. Why not write them on a card and schedule them like you would any other piece of work in an iteration?

If you haven’t worked out what those things are then No problem, try and schedule some real work. When you find you don’t have something (a database instance for example) simply write out a card, schedule it, do it. The things you need to do to “get ready” are actually things you need to do to build something you do want.

My big worry with Sprint Zero (apart from it injecting unnecessary delay and loss of change momentum) is that it makes work. You may think you need to do something in advance and you might be right. But, then again, you might be wrong. You might do something – like install a database – when you could quite easily postpone that work for a few weeks or even skip it entirely.

Similarly some say “How can we start work until we know what we need to do? – we need to gather requirements, write some stories….”

But again: determining what needs doing, requirements gathering, is itself work to be done.

If it is not clear what needs to be done on day-1 then the first thing to do is to do some work to find out what needs to be done. The initial work may well be requirements discover and story writing with only a little bit of product building.

Speculative, early, requirements gathering, may actually increase the amount of work to do because you capture all the things people think you need to do. Once you start to put the product together you may not need those things but once they are listed as part of the work to do – and especially if they have been promised to someone – then not doing them can be problematic.

Anyway, having written this blog I now wonder if I should have bothered. Now I look about a lot of other people have made similar points already. As I have been writing this post I thought I should find a definition of Sprint Zero, so I did a search. Interestingly, most of the articles that came up on page 1 of Google are also critical of Sprint Zero for similar reasons to myself. So maybe Sprint Zero is an idea whose time has already come and gone.

The post Sprint Zero appeared first on Allan Kelly Associates.

Mathematical proofs contain faults, just like software

Derek Jones from The Shape of Code

The idea of proving programs correct, like mathematical proofs, is appealing, but is based on an incorrect assumption often made by non-mathematicians, e.g., mathematical proofs are fault free. In practice, mathematicians make mistakes and create proofs that contain serious errors; those of us who are taught mathematical techniques, but are not mathematicians, only get to see the good stuff that has been checked over many years.

An appreciation that published proofs contain mistakes is starting to grow, but Magnificent mistakes in mathematics is an odd choice for a book title on the topic. Quotes from De Millo’s article on “Social Processes and Proofs of Theorems and Programs” now appear regularly; On proof and progress in mathematics is worth a read.

Are there patterns to the faults that appear in claimed mathematical proofs?

A surprisingly common approach, used by mathematicians to avoid faults in their proofs, is to state theorems without giving a formal proof (giving an informal one is given instead). There are plenty of mathematicians who don’t think proofs are a big part of mathematics (various papers from the linked-to book are available as pdfs).

Next time you encounter an advocate of proving programs correct using mathematics, ask them what they think about the uncertainty about claimed mathematical proofs and all the mistakes that have been found in published proofs.

Quaker’s Dozen – baron m.

baron m. from thus spake a.k.

Sir R-----, my fine friend! The coming of spring always puts one in excellent spirits, do you not find? Speaking of which, come join me in a glass of this particularly peaty whiskey with which we might toast her imminent arrival!

Might I tempt you with a little sport to quicken the blood still further?

It lifts my soul to hear it Sir!

I have in mind a game that I learned when in passage to the new world with a company of twelve Quakers. I was not especially relishing the prospect of yet another monotonous transatlantic crossing and so you can imagine my relief when I spied the boisterous party embarking, dressed in the finest silks and satins and singing a bawdy tavern ballad as they took turns at a bottle of what looked like a very fine brandy indeed!

Fixing Slack emojis in HexChat

Andy Balaam from Andy Balaam's Blog

If, like me, you are this person:

(Source: xkcd.com/1782)

You may want to fix the stupid :slightly_smiling_face: messages you receive from Slack via the IRC gateway. Obviously, I’d prefer they went away entirely, but it’s still better to see a character than being spammed with colon abominations all over the place.

You’ll need the Python emoji package, and a HexChat plugin like this:

# Replace all the horrible :slightly_smiling_face: rubbish that Slack inserts
# into horrible Unicode emoji symbols.
# Author: Andy Balaam
# License: CC0 https://creativecommons.org/publicdomain/zero/1.0/

# Requires https://pypi.python.org/pypi/emoji - I used 0.4.5
# I manually copied the emoji dir into:
# /home/andrebal/.local/lib/python2.7/site-packages
import emoji
import hexchat

__module_name__ = "slack-emojis"
__module_version__ = "1.0"
__module_description__ = "Translate emojis from Slack with colons into emojis"

print "Loading slack-emojis"
chmsg = "Channel Message"
prmsg = "Private Message to Dialog"

def preprint(words, word_eol, userdata):
    txt = word_eol[1]
    replaced = emoji.emojize(txt, use_aliases=True)
    if replaced != txt:
        hexchat.emit_print(
            userdata["msgtype"],
            words[0],
            replaced.encode('utf-8'),
        )
        return hexchat.EAT_HEXCHAT
    else:
        return hexchat.EAT_NONE

hexchat.hook_print(chmsg, preprint, {"msgtype": chmsg})
hexchat.hook_print(prmsg, preprint, {"msgtype": prmsg})

According to the page linked above, Slack are retiring the IRC gateway, which will make me very unhappy.

Update: added support for private messages too.