Analyse your Jira data? (for free)

Send me your data!

Think of this as a free offer, let me look at your data and I’ll tel you if I find anything interesting.

When I work with clients I often download the Jira data and crunch the data in Excel to see if I can find any patterns or any information in the mass of tickets and dates. I know there are tools out there which will do this but I’m never quite sure what these tools are telling me so I like to do it myself. Also its a bit of a “fishing trip” – I don’t know what I might find. Having done this a few time I’ve developed a bit of a pattern myself – nothing i can describe yet but who knows.

So, if you would like me to crunch your data please send it over. I say Jira but I’m happy to work with data from any other systems – I’ll learn something new

You will need to export all the issues as a CSV or Excel file. And I suggest you anonymise the data, just delete the columns with names and even delete the card description. The more you can send me the better, but the columns that interest me most have to do with dates (created and closed), ticket types (story, bug, task/sub-task, etc.), status and, if they are recorded, estimates and actual times.

I won’t share the data with anyone else – I’ll even delete it when I am finished if you wish. I would like to document some of my findings in a blog post but I can give you first sight if you like.

Apart from find patterns and perhaps learning something what interests me is what I might be able to tell about a team I know nothing about. It is an experiment. I’m allan AT allankelly.net – or use the contact page.

The post Analyse your Jira data? (for free) appeared first on Allan Kelly Associates.

TIL that org-mode has an exporter for ODR

I’m by no means an Emacs org-mode power user - in fact, anything but - but I do use org-mode a lot for note taking and also when I need an outliner to try and arrange ideas in a suitable manner. It excels at both, and usually does what I need including exporting to HTML. Exporting to HTML covers about 90% of my use cases. As much as I’d like to, LaTeX does not feature in my needs, but I needed to export an org-mode file for use with Microsoft Word.

Readability: a scientific approach

Readability, as applied to software development today, is a meaningless marketing term. Readability is promoted as a desirable attribute, and is commonly claimed for favored programming languages, particular styles of programming, or ways of laying out source code.

Whenever somebody I’m talking to, or listening to in a talk, makes a readability claim, I ask what they mean by readability, and how they measured it. The speaker invariably fumbles around for something to say, with some dodging and weaving before admitting that they have not measured readability. There have been a few studies that asked students to rate the readability of source code (no guidance was given about what readability might be).

If somebody wanted to investigate readability from a scientific perspective, how might they go about it?

The best way to make immediate progress is to build on what is already known. There has been over a century of research on eye movement during reading, and two model of eye movement now dominate, i.e., the E-Z Reader model and SWIFT model. Using eye-tracking to study developers is slowly starting to be adopted by researchers.

Our eyes don’t smoothly scan the world in front of us, rather they jump from point to point (these jumps are known as a saccade), remaining fixed long enough to acquire information and calculate where to jump next. The image below is an example from an eye tracking study, where subjects were asking to read a sentence (see figure 770.11). Each red dot appears below the center of each saccade, and the numbers show the fixation time (in milliseconds) for that point (code):

Saccade points in a sentence, and fixation times.

Models of reading are judged by the accuracy of their predictions of saccade landing points (within a given line of text), and fixation time between saccades. Simulators implementing the E-Z Reader and SWIFT models have found that these models have comparable performance, and the robustness of these models are compared by looking at the predictions they make about saccade behavior when reading what might be called unconventional material, e.g., mirrored or scarmbeld text.

What is the connection between the saccades made by readers and their understanding of what they are reading?

Studies have found that fixation duration increases with text difficulty (it is also affected by decreases with word frequency and word predictability).

It has been said that attention is the window through which we perceive the world, and our attention directs what we look at.

A recent study of the SWIFT model found that its predictions of saccade behavior, when reading mirrored or inverted text, agreed well with subject behavior.

I wonder what behavior SWIFT would predict for developers reading a line of code where the identifiers were written in camelCase or using underscores (sometimes known as snake_case)?

If the SWIFT predictions agreed with developer saccade behavior, a raft of further ‘readability’ tests spring to mind. If the SWIFT predictions did not agree with developer behavior, how might the model be updated to support the reading of lines of code?

Until recently, the few researchers using eye tracking to investigate software engineering behavior seemed to be having fun playing with their new toys. Things are starting to settle down, with some researchers starting to pay attention to existing models of reading.

What do I predict will be discovered?

Lots of studies have found that given enough practice, people can become proficient at handling some apparently incomprehensible text layouts. I predict that given enough practice, developers can become equally proficient at most of the code layout schemes that have been proposed.

The important question concerning text layout, is: which one enables an acceptable performance from a wide variety of developers who have had little exposure to it? I suspect the answer will be the one that is closest to the layout they have had the most experience,i.e., prose text.

Readability: a scientific approach

Readability, as applied to software development today, is a meaningless marketing term. Readability is promoted as a desirable attribute, and is commonly claimed for favored programming languages, particular styles of programming, or ways of laying out source code.

Whenever somebody I’m talking to, or listening to in a talk, makes a readability claim, I ask what they mean by readability, and how they measured it. The speaker invariably fumbles around for something to say, with some dodging and weaving before admitting that they have not measured readability. There have been a few studies that asked students to rate the readability of source code (no guidance was given about what readability might be).

If somebody wanted to investigate readability from a scientific perspective, how might they go about it?

The best way to make immediate progress is to build on what is already known. There has been over a century of research on eye movement during reading, and two model of eye movement now dominate, i.e., the E-Z Reader model and SWIFT model. Using eye-tracking to study developers is slowly starting to be adopted by researchers.

Our eyes don’t smoothly scan the world in front of us, rather they jump from point to point (these jumps are known as a saccade), remaining fixed long enough to acquire information and calculate where to jump next. The image below is an example from an eye tracking study, where subjects were asking to read a sentence (see figure 770.11). Each red dot appears below the center of each saccade, and the numbers show the fixation time (in milliseconds) for that point (code):

Saccade points in a sentence, and fixation times.

Models of reading are judged by the accuracy of their predictions of saccade landing points (within a given line of text), and fixation time between saccades. Simulators implementing the E-Z Reader and SWIFT models have found that these models have comparable performance, and the robustness of these models are compared by looking at the predictions they make about saccade behavior when reading what might be called unconventional material, e.g., mirrored or scarmbeld text.

What is the connection between the saccades made by readers and their understanding of what they are reading?

Studies have found that fixation duration increases with text difficulty (it is also affected by decreases with word frequency and word predictability).

It has been said that attention is the window through which we perceive the world, and our attention directs what we look at.

A recent study of the SWIFT model found that its predictions of saccade behavior, when reading mirrored or inverted text, agreed well with subject behavior.

I wonder what behavior SWIFT would predict for developers reading a line of code where the identifiers were written in camelCase or using underscores (sometimes known as snake_case)?

If the SWIFT predictions agreed with developer saccade behavior, a raft of further ‘readability’ tests spring to mind. If the SWIFT predictions did not agree with developer behavior, how might the model be updated to support the reading of lines of code?

Until recently, the few researchers using eye tracking to investigate software engineering behavior seemed to be having fun playing with their new toys. Things are starting to settle down, with some researchers starting to pay attention to existing models of reading.

What do I predict will be discovered?

Lots of studies have found that given enough practice, people can become proficient at handling some apparently incomprehensible text layouts. I predict that given enough practice, developers can become equally proficient at most of the code layout schemes that have been proposed.

The important question concerning text layout, is: which one enables an acceptable performance from a wide variety of developers who have had little exposure to it? I suspect the answer will be the one that is closest to the layout they have had the most experience,i.e., prose text.

Triumvirate – baron m.

Welcome Sir R-----! Pray join me for a draught of cider to refresh you on this close summer's eve!

Would you be in the mood for some sporting diversion?

It pleases me to hear so Sir! It pleases me greatly!

I challenge you to a game that reflects the somewhat unique political system adopted by the three sister-queens of Thornborough; Alnitak, Alnilam and Mintaka. Whilst ruling as a triumvirate their constitution requires all three to concur upon any decision, quite unlike any others in antiquity or modernity which, as I'm quite sure that you are aware, require but two.

Minimal example of a Maven pom for a mixed Kotlin and Java project

The Kotlin docs describe some things you need in your pom.xml to create a project that is a mix of Kotlin and Java code, but there is no complete example, so here is mine:

pom.xml:

<project>
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example.kj</groupId>
    <artifactId>kotlin-and-java</artifactId>
    <version>1.0.0-SNAPSHOT</version>

    <properties>
        <kotlin.version>1.5.21</kotlin.version>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    </properties>

    <build>
        <plugins>
            <plugin>
                <groupId>org.jetbrains.kotlin</groupId>
                <artifactId>kotlin-maven-plugin</artifactId>
                <version>${kotlin.version}</version>
                <executions>
                    <execution>
                        <id>compile</id>
                        <goals>
                            <goal>compile</goal>
                        </goals>
                        <configuration>
                            <sourceDirs>
                                <sourceDir>${project.basedir}/src/main/kotlin</sourceDir>
                                <sourceDir>${project.basedir}/src/main/java</sourceDir>
                            </sourceDirs>
                        </configuration>
                    </execution>
                    <execution>
                        <id>test-compile</id>
                        <goals> <goal>test-compile</goal> </goals>
                        <configuration>
                            <sourceDirs>
                                <sourceDir>${project.basedir}/src/test/kotlin</sourceDir>
                                <sourceDir>${project.basedir}/src/test/java</sourceDir>
                            </sourceDirs>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.5.1</version>
                <executions>
                    <!-- Replacing default-compile as it is treated specially by maven -->
                    <execution>
                        <id>default-compile</id>
                        <phase>none</phase>
                    </execution>
                    <!-- Replacing default-testCompile as it is treated specially by maven -->
                    <execution>
                        <id>default-testCompile</id>
                        <phase>none</phase>
                    </execution>
                    <execution>
                        <id>java-compile</id>
                        <phase>compile</phase>
                        <goals>
                            <goal>compile</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>java-test-compile</id>
                        <phase>test-compile</phase>
                        <goals>
                            <goal>testCompile</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
    <dependencies>
        <dependency>
            <groupId>org.jetbrains.kotlin</groupId>
            <artifactId>kotlin-stdlib</artifactId>
            <version>${kotlin.version}</version>
        </dependency>
    </dependencies>
</project>

src/main/java/MyJava.java:

public class MyJava {
    public static void main(String[] args) {
        MyKotlin k = new MyKotlin();  // Use Kotlin from Java
        System.out.println(k.message());
    }
}

src/main/kotlin/MyKotlin.kt:

class MyKotlin : MyJava() {  // Use Java from Kotlin
    fun message(): String {
        return "Hello from Kotlin!"
    }
}

src/test/java/MadeInJavaTest.java:

class MadeInJavaTest {
    public void testCanUseJava() {
        MyJava j = new MyJava();
    }

    public void testCanUseKotlin() {
        MyKotlin k = new MyKotlin();
        assertEquals(k.message(), "Hello from Kotlin!");
    }

    static void assertEquals(String left, String right) {
        if (!left.equals(right)) {
            throw new AssertionError(left + " != " + right);
        }
    }
}

src/test/kotlin/MadeInKotlinTest.kt:

class MadeInKotlinTest {
    fun testCanUseJava() {
        MyJava()
    }

    fun testCanUseKotlin() {
        val k = MyKotlin();
        assertEquals(k.message(), "Hello from Kotlin!");
    }
}

fun assertEquals(left: String, right: String) {
    if (left != right) {
        throw AssertionError("${left} != ${right}");
    }
}

Visual Lint 8.0.3.340 has been released

Visual Lint 8.0.3.340 has now been released. This a recommended maintenance update for Visual Lint 8.0, and includes the following changes:

  • Visual Studio 2022 now appears as a supported project type in VisualLintGui and VisualLintConsole.

  • Added a stub PC-lint Plus compiler indirect file for Visual Studio 2022 (co-rb-vs2022.lnt) to the installer. This will be replaced by an expanded implementation in due course.

  • Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-vs2019.lnt to support Visual Studio 2019 v16.10.4.

  • Fixed a bug in the Visual Lint Options Dialog which caused a "Visual Studio has encountered an unexpected error" message when the dialog was invoked while the Visual Studio plugin was loaded but turned off.

  • The Eclipse C/C++ project (.cproject) file reader now takes into account the value of buildPath attributes when parsing the <builder> elements which define the properties of makefile builds. If not specified, the value of buildPath is assumed to be ${ProjDirPath}.

  • Fixed a handful of typos in the helpfile.

    The Visual Lint plug-in included in this build is not compatible with Visual Studio 2022 Preview.

    Visual Lint beta builds with full support for Visual Studio 2022 Preview are however available. Please contact us if you would like to become a beta tester.

Download Visual Lint 8.0.3.340

Visual Lint 8.0.3.340 has been released

Visual Lint 8.0.3.340 has now been released. This a recommended maintenance update for Visual Lint 8.0, and includes the following changes:

  • Visual Studio 2022 now appears as a supported project type in VisualLintGui and VisualLintConsole.

  • Added a stub PC-lint Plus compiler indirect file for Visual Studio 2022 (co-rb-vs2022.lnt) to the installer. This will be replaced by an expanded implementation in due course.

  • Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-vs2019.lnt to support Visual Studio 2019 v16.10.4.

  • Fixed a bug in the Visual Lint Options Dialog which caused a "Visual Studio has encountered an unexpected error" message when the dialog was invoked while the Visual Studio plugin was loaded but turned off.

  • The Eclipse C/C++ project (.cproject) file reader now takes into account the value of buildPath attributes when parsing the <builder> elements which define the properties of makefile builds. If not specified, the value of buildPath is assumed to be ${ProjDirPath}.

  • Fixed a handful of typos in the helpfile.

    The Visual Lint plug-in included in this build is not compatible with Visual Studio 2022 Preview.

    Visual Lint beta builds with full support for Visual Studio 2022 Preview are however available. Please contact us if you would like to become a beta tester.

Download Visual Lint 8.0.3.340

Cognitive bias or not paying enough attention?

Assume you are responsible for two teams who independently work on projects, say Team A and Team B. The teams have different work completion rates, with Team A completing work at the rate of 70 widgets per week, while Team B completes 30 widgets per week. Both teams always work on projects that require the completion of the same number of widgets.

You have the resources to send just one of the teams on a course. It is predicted that sending Team A on the course would improve their performance to 110 widgets per week, while attending the course would improve the performance of Team B to 40 widgets per week.

Senior management have decreed that time to market is the metric by which project managers are judged.

You want to impress senior management by significantly improving time to market for your projects; which team do you send on the course (i.e., the one that is likely to experience the largest reduction in time to market)?

This question is a restatement of a one involving cars travelling at different speeds, that has grown into a niche research area. Studies have found that a large percentage of subjects give the wrong answer, and they are said to have a time-saving bias, or time-loss bias.

The inability to correctly process “inverse variables” has been given as the reason people tend to give the wrong answer. The term “inverse variables” comes from the formula for calculating completion time, where the velocity appears as the denominator. Another way of looking at this problem is that when going slowly, there is more scope for improvement, compared to when going much faster.

A speed increase from 30 to 40 is only 10, or a 33% improvement; while an increase from 70 to 110 is an increase of 40, or 57%. Based on these numbers, Team A should be sent on the course.

However, we are interested in time to market. Let’s assume that both teams have to complete a project requiring 100 widgets. Before attending the course, Team A completes 100 widgets in 100/70=1.4 weeks, and Team B completes 100 widgets in 100/30=3.3 weeks. After attending the course, Team A would complete 100 widgets in 100/110=0.91 weeks, and Team B would complete 100 widgets in 100/40=2.5 weeks. Time to market for Team A has been reduced by (1.4-0.9)=0.5 weeks, while the reduction for Team B is (3.3-2.5)=0.8 weeks. So sending Team B on the course makes you look better, on the time to market metric.

If somebody ran an experiment with project managers, would the subjects tend to incorrectly process “inverse variables”. Well, somebody has done the experiment, and yes, many subjects exhibited the time-saving bias (the experimental scenario described in the appendix is a lot easier to understand than the one in the main body of the paper, which is a mess; Magne Jørgensen continues to be the only person doing interesting experiments in software estimation).

It has become common practice that, when a large percentage of subjects in a psychology experiment respond in ways that are inconsistent with a mathematical approach, the behavior is labelled as being a bias. I think the use of this terminology makes the behavior sound more interesting than it actually is; what’s wrong with saying that people make mistakes. Perhaps labelling experimental responses as being a bias makes it easier to get papers published.

Whether people are biased, or don’t pay enough attention, when solving non-trivial equations, what might be done about it?

This is not about whether any particular metric is a useful one, rather it is about calculating the right answer for whatever metric happens to be chosen.

Would an awareness campaign highlighting the problems people have with “inverse variables” be worthwhile? I don’t think so. Many people have problems with equations, and I don’t see why this case is more worthy of being highlighted than any other.

Am I missing something?

Psychology researchers are interested in figuring out the functioning of the brain/mind, so they are looking for patterns in the responses subjects give. Once someone has published a few papers on a research topic, they become invested in it. If they continue to get funding, the papers keep on coming. Sometimes a niche topic acquires a major following, and the work contributes to a major change of thinking about the mind, e.g., the Wason selection task helped increase the evidence that culture has an impact on cognitive behavior.

I think that software engineering researchers need to carefully evaluate the likely importance of behaviors that psychology researchers have labelled as a bias.

Cognitive bias or not paying enough attention?

Assume you are responsible for two teams who independently work on projects, say Team A and Team B. The teams have different work completion rates, with Team A completing work at the rate of 70 widgets per week, while Team B completes 30 widgets per week. Both teams always work on projects that require the completion of the same number of widgets.

You have the resources to send just one of the teams on a course. It is predicted that sending Team A on the course would improve their performance to 110 widgets per week, while attending the course would improve the performance of Team B to 40 widgets per week.

Senior management have decreed that time to market is the metric by which project managers are judged.

You want to impress senior management by significantly improving time to market for your projects; which team do you send on the course (i.e., the one that is likely to experience the largest reduction in time to market)?

This question is a restatement of a one involving cars travelling at different speeds, that has grown into a niche research area. Studies have found that a large percentage of subjects give the wrong answer, and they are said to have a time-saving bias, or time-loss bias.

The inability to correctly process “inverse variables” has been given as the reason people tend to give the wrong answer. The term “inverse variables” comes from the formula for calculating completion time, where the velocity appears as the denominator. Another way of looking at this problem is that when going slowly, there is more scope for improvement, compared to when going much faster.

A speed increase from 30 to 40 is only 10, or a 33% improvement; while an increase from 70 to 110 is an increase of 40, or 57%. Based on these numbers, Team A should be sent on the course.

However, we are interested in time to market. Let’s assume that both teams have to complete a project requiring 100 widgets. Before attending the course, Team A completes 100 widgets in 100/70=1.4 weeks, and Team B completes 100 widgets in 100/30=3.3 weeks. After attending the course, Team A would complete 100 widgets in 100/110=0.91 weeks, and Team B would complete 100 widgets in 100/40=2.5 weeks. Time to market for Team A has been reduced by (1.4-0.9)=0.5 weeks, while the reduction for Team B is (3.3-2.5)=0.8 weeks. So sending Team B on the course makes you look better, on the time to market metric.

If somebody ran an experiment with project managers, would the subjects tend to incorrectly process “inverse variables”. Well, somebody has done the experiment, and yes, many subjects exhibited the time-saving bias (the experimental scenario described in the appendix is a lot easier to understand than the one in the main body of the paper, which is a mess; Magne Jørgensen continues to be the only person doing interesting experiments in software estimation).

It has become common practice that, when a large percentage of subjects in a psychology experiment respond in ways that are inconsistent with a mathematical approach, the behavior is labelled as being a bias. I think the use of this terminology makes the behavior sound more interesting than it actually is; what’s wrong with saying that people make mistakes. Perhaps labelling experimental responses as being a bias makes it easier to get papers published.

Whether people are biased, or don’t pay enough attention, when solving non-trivial equations, what might be done about it?

This is not about whether any particular metric is a useful one, rather it is about calculating the right answer for whatever metric happens to be chosen.

Would an awareness campaign highlighting the problems people have with “inverse variables” be worthwhile? I don’t think so. Many people have problems with equations, and I don’t see why this case is more worthy of being highlighted than any other.

Am I missing something?

Psychology researchers are interested in figuring out the functioning of the brain/mind, so they are looking for patterns in the responses subjects give. Once someone has published a few papers on a research topic, they become invested in it. If they continue to get funding, the papers keep on coming. Sometimes a niche topic acquires a major following, and the work contributes to a major change of thinking about the mind, e.g., the Wason selection task helped increase the evidence that culture has an impact on cognitive behavior.

I think that software engineering researchers need to carefully evaluate the likely importance of behaviors that psychology researchers have labelled as a bias.

Why on-ramps and off-ramps are more important than highways

It begins with a simple request: “we need to know when it will be done.” Or, when there is an agile-savvy manager, “our velocity needs to be higher.” But the more I look the more it appears the dev team aren’t really that bad, in fact they might actually be good. And, if you doubled team productivity overnight it wouldn’t make a big difference. The problem is elsewhere.

Sure the dev team could be better in many ways but simply coding faster isn’t going to solve the problem. The on-ramp and the off-ramp are in need of improvement: the work intake and the work delivery mechanism – entry ramp (getting stuff in processed) and exit ramp (getting it out the door) are often more imporant.

As they say: its déjà vu all over again. I see this again and again. In my mind’s eye turning requests into working software is a freeway, a motorway, an autobahn – a controlled-access highway to use a technical term. Each piece of work is a car.

Most of our attention goes on the cars/work speeding down the lanes, that is where we assume time is spent. That is where most of the team are working, that is where we direct people to look for problems. If all goes well the work/car moves rapidly from one place to another. Sure things go wrong on that journey, in coding, sometimes other pieces of work get in the way, sometimes something goes wrong and there is a pile up with work/cars queuing behind. And sometimes the best way of improving the overall flow is to limit work in progress or reduce speed limits.

But, the actual speeding down the highway part is but one of three essential elements. Frequently this is not where time is lost, and even though work can be unpredictable it is not the most unpredictable part of the work.

It is fairly common for work to spend most of its life waiting to enter the system – the on-ramp, how cars get on the highway and how work enters the development processes.

And there is the off-ramp – how does work leave the system and reach the customer? – after cars only join the highway when they are coming from one place and want to get to another.

Most people working in the system see their job as driving cars and ensuring that a particular payload is delivered to the destination. Who looks at the overall system? Who manages the highway? Who optimises the flow? This is where I see my work. It is not enough to ensure a piece of work is delivered, it is not enough to ensure the cars are going fast, one has to see the whole system. Usually the on-ramp and off-ramp require far more work than the actual highway itself.

In other words: it is not about ensuring any one car arrives once. It is about ensuring the system for delivering cars works effectively. While the highway journey gets the attention the on-ramp and off-ramp are often far more important.

Consider the off-ramp: it is very common to find that development teams are working pretty well, but when work is “done coding” it queues to get through testing, queues to get into a release and queues to be released. In fact, it is almost normal in teams that work spends longer “getting out the door” than it spends being done.

The continuous delivery movement has done a lot to improve this and the best teams have streamlined and automated this part but problems remain. I’ll just mention two.

One: I just said “the best teams.” The best teams are few and far between. Yes they get lots of attention but most teams are a long way from this. It is not uncommon to find that teams consider some continuous delivery processes madness. I floated the idea of branchless development to a team this year and they took it as a sign that I didn’t understand their work. The idea that you might not use source control branches appeared like a naive beginners mistake.

Two: where do you put testing? If testing is considered a special activity that must happen as part of a release process then it occurs on the off-ramp. That off-ramp has limited capacity and any problems have big knock on effects – it is very risky.

However, testing can be considered part of the main highway experience. Developers can work to a high standard an incorporate practices like TDD and BDD which lesson the need for testing. Formal testing – probably by professional testers- can be positioned before the off-ramp if you design the highway/workflow correctly.

Now consider the on-ramp: the intake process, the requirements process, the work-before coding, work that is normally done by Product Owners/Product Managers or Business Analysts. This can cause even bigger hold-ups than the off-ramp.

I’ve written before about the fear many organizations have of actually coding. As a result work is held in perpetual review, estimation and planning before it is allowed anywhere near a coder.

Another cause of delay is the product backlog: in many places this is a bottomless pit of work to do. Every few weeks the Product Owner shifts through the backlog selecting a few pieces of work to get done. Most work doesn’t get done and falls to the bottom. It is unlikely to be done but gets in the way and distorts metrics. As a result most work spends most of its life cycle waiting to be done, waiting to get onto the highway.

There is a natural (and good) tendency to focus on the work in hand, to think “if I can only get this piece of work done…” Like Orwell’s Boxer pledging “I will work harder” to any problem. (There are plenty of none team members prepared to stand on the sidelines saying “If only they did work harder.”)

It is not enough for any one person to work harder. It is a system: the an on-ramp, a highway and and off-ramp all need to work together. Only looking at the whole do these things become clear. Improving this flow requires a different set of skills to those of writing code and testing – of course there is overlap in skills and of course people can learn; but again, if one simply pledges to “work harder” and write better code the improvement will be marginal.

Seeing the highway – the work flow – is something I would expect a development manager to do, and if not a development manager than the person I call and Agile Guide and most of the rest of the industry calls an Agile Coach.


Subscribe to my blog newsletter and download Continuous Digital for free – normal price $9.99/£9.95/€9.95

The post Why on-ramps and off-ramps are more important than highways appeared first on Allan Kelly Associates.

ResOrg 2.0.9.29 has been released

ResOrg 2.0.9.29 has now been released. This a recommended maintenance update for ResOrg 2.0, and includes the following changes:

  • When installing/uninstalling the Visual Studio 2017/2019 extension (ResOrgPackage.vsix) the installer now invokes VSIXInstaller.exe silently rather than interactively, writing a logfile to %TEMP%.

  • Fixed a bug in the installer which could prevent the Visual Studio plug-in from being correctly installed to Visual Studio 2019.

  • Fixed a bug in the installer which could prevent the Visual Studio plug-in from being correctly uninstalled from Visual Studio 2017 or 2019.

  • Replaced the "invalid key entered" balloon tip in the Registration Key Dialog with an inline text field.

    The ResOrg plug-in included in this build is not compatible with Visual Studio 2022 Preview.

    Support for Visual Studio 2022 Preview is currently being worked on in the ResOrg development branch, and should become available in due course, but in the meantime ResOrgApp can edit VS2022 resource symbol files.

Download ResOrg 2.0.9.29

ResOrg 2.0.9.29 has been released

ResOrg 2.0.9.29 has now been released. This a recommended maintenance update for ResOrg 2.0, and includes the following changes:

  • When installing/uninstalling the Visual Studio 2017/2019 extension (ResOrgPackage.vsix) the installer now invokes VSIXInstaller.exe silently rather than interactively, writing a logfile to %TEMP%.

  • Fixed a bug in the installer which could prevent the Visual Studio plug-in from being correctly installed to Visual Studio 2019.

  • Fixed a bug in the installer which could prevent the Visual Studio plug-in from being correctly uninstalled from Visual Studio 2017 or 2019.

  • Replaced the "invalid key entered" balloon tip in the Registration Key Dialog with an inline text field.

    The ResOrg plug-in included in this build is not compatible with Visual Studio 2022 Preview.

    Support for Visual Studio 2022 Preview is currently being worked on in the ResOrg development branch, and should become available in due course, but in the meantime ResOrgApp can edit VS2022 resource symbol files.

Download ResOrg 2.0.9.29

Actual implementation times are often round numbers

To what extent do developers consciously influence the time taken to actually complete a task?

If the time estimated to complete a task is rather generous, a developer has the opportunity to follow Parkinson’s law (i.e., “work expands so as to fill the time available for its completion”), or if the time is slightly less than appears to be required, they might work harder to finish within the estimated time (like some marathon runners have a target time)?

The use of round numbers are a prominent pattern seen in task estimation times.

If round numbers appeared more often in the actual task completion time than would be expected by chance, it would suggest that developers are sometimes working to a target time. The following plot shows the number of tasks taking a given amount of actual time to complete, for project 615 in the CESAW dataset (similar patterns are present in the actual times of other projects; code+data):

Number of tasks taking a given amount of time to complete, for project 615.

The red lines are a fitted bi-exponential distribution to the ‘spike’ (i.e., round numbers, circled in grey) and non-spike points (spikes automatically selected, see code for details), green and purple lines are the two components of the non-spike fit.

Tasks are not always started and completed in one continuous work session, work may be spread over multiple work sessions; the CESAW data includes the start/end time of every work session associated with each task (85% of tasks involve more than one work session, for project 615). The following plots are based on work sessions, rather than tasks, for tasks worked on over two (left) and three (right) sessions; colored lines denote session ordering within a task (code+data):

Number of sessions taking a given amount of time to complete, for project 615.

Shorter sessions dominate for the last session of task implementation, and spikes in the counts indicate the use of round numbers in all session positions (e.g., 180 minutes, which may be half a day).

Perhaps round number work session times are a consequence of developers using round number wall-clock times to start and end work sessions. The plot below shows (left) the number of work sessions starting at a given number of minutes past the hour, and (right) the number of work sessions ending at a given number of minutes past the hour; both for project 615 (code+data):

Rose diagrams for minutes past the hour of work session wall clock start (left) and end (right).

The arrow (green) shows the direction of the mean, and the almost invisible interior line shows that the length of the mean is almost zero. The five-minute points have slightly more session starts/ends than the surrounding minute values, but are more like bumps than spikes. The start of the hour, and 30-minutes, have prominent spikes, which might be caused by the start/end of the working day, and start/end of the lunch break.

Five-minutes is a convenient small rounding interval to either expand implementation time, or to target as a completion time. The following plot shows, for each of the 47 individuals working on project 615, the number of actual session times and the number exactly divisible by five. The green line shows the case where every actual is divisible by five, the purple line where 20% are divisible by five (expected for unbiased timing), the dashed purple lines show one standard deviation, the blue/green line is a fitted regression model (0.4*Actual^{0.94 pm 0.04}) (code+data):

Number of sessions against number of sessions whose actual time is divisible by five, for 47 people working on project 615.

It appears that on average, five-minute session times occur twice as often as expected by chance; two individuals round all their actual session times (ok, it’s not that unlikely for the person with just two sessions).

Does it matter that some developers have a preference for using round numbers when recording time worked?

The use of round numbers in the recording of actual work sessions will inflate the total actual time for most tasks (because most tasks involve more than one session, and assuming that most rounding is not caused by developers striving to meet a target). The amount of error introduced is probably a lot less than the time variability caused by other implementation factors (I have yet to do the calculation).

I see the use of round numbers as a means of unpicking developer work habits.

Given the difficulty of getting developers to record anything, requiring them to record to minute-level accuracy appears at best optimistic. Would you work for a manager that required this level of effort detail (I know there is existing practice in other kinds of jobs)?

Actual implementation times are often round numbers

To what extent do developers consciously influence the time taken to actually complete a task?

If the time estimated to complete a task is rather generous, a developer has the opportunity to follow Parkinson’s law (i.e., “work expands so as to fill the time available for its completion”), or if the time is slightly less than appears to be required, they might work harder to finish within the estimated time (like some marathon runners have a target time)?

The use of round numbers are a prominent pattern seen in task estimation times.

If round numbers appeared more often in the actual task completion time than would be expected by chance, it would suggest that developers are sometimes working to a target time. The following plot shows the number of tasks taking a given amount of actual time to complete, for project 615 in the CESAW dataset (similar patterns are present in the actual times of other projects; code+data):

Number of tasks taking a given amount of time to complete, for project 615.

The red lines are a fitted bi-exponential distribution to the ‘spike’ (i.e., round numbers, circled in grey) and non-spike points (spikes automatically selected, see code for details), green and purple lines are the two components of the non-spike fit.

Tasks are not always started and completed in one continuous work session, work may be spread over multiple work sessions; the CESAW data includes the start/end time of every work session associated with each task (85% of tasks involve more than one work session, for project 615). The following plots are based on work sessions, rather than tasks, for tasks worked on over two (left) and three (right) sessions; colored lines denote session ordering within a task (code+data):

Number of sessions taking a given amount of time to complete, for project 615.

Shorter sessions dominate for the last session of task implementation, and spikes in the counts indicate the use of round numbers in all session positions (e.g., 180 minutes, which may be half a day).

Perhaps round number work session times are a consequence of developers using round number wall-clock times to start and end work sessions. The plot below shows (left) the number of work sessions starting at a given number of minutes past the hour, and (right) the number of work sessions ending at a given number of minutes past the hour; both for project 615 (code+data):

Rose diagrams for minutes past the hour of work session wall clock start (left) and end (right).

The arrow (green) shows the direction of the mean, and the almost invisible interior line shows that the length of the mean is almost zero. The five-minute points have slightly more session starts/ends than the surrounding minute values, but are more like bumps than spikes. The start of the hour, and 30-minutes, have prominent spikes, which might be caused by the start/end of the working day, and start/end of the lunch break.

Five-minutes is a convenient small rounding interval to either expand implementation time, or to target as a completion time. The following plot shows, for each of the 47 individuals working on project 615, the number of actual session times and the number exactly divisible by five. The green line shows the case where every actual is divisible by five, the purple line where 20% are divisible by five (expected for unbiased timing), the dashed purple lines show one standard deviation, the blue/green line is a fitted regression model (0.4*Actual^{0.94 pm 0.04}) (code+data):

Number of sessions against number of sessions whose actual time is divisible by five, for 47 people working on project 615.

It appears that on average, five-minute session times occur twice as often as expected by chance; two individuals round all their actual session times (ok, it’s not that unlikely for the person with just two sessions).

Does it matter that some developers have a preference for using round numbers when recording time worked?

The use of round numbers in the recording of actual work sessions will inflate the total actual time for most tasks (because most tasks involve more than one session, and assuming that most rounding is not caused by developers striving to meet a target). The amount of error introduced is probably a lot less than the time variability caused by other implementation factors (I have yet to do the calculation).

I see the use of round numbers as a means of unpicking developer work habits.

Given the difficulty of getting developers to record anything, requiring them to record to minute-level accuracy appears at best optimistic. Would you work for a manager that required this level of effort detail (I know there is existing practice in other kinds of jobs)?

Will They Blend? – a.k.

Last time we saw how we can create new random variables from sets of random variables with given probabilities of observation. To make an observation of such a random variable we randomly select one of its components, according to their probabilities, and make an observation of it. Furthermore, their associated probability density functions, or PDFs, cumulative distribution functions, or CDFs, and characteristic functions, or CFs, are simply sums of the component functions weighted by their probabilities of observation.
Now there is nothing about such distributions, known as mixture distributions, that requires that the components are univariate. Given that copulas are simply multivariate distributions with standard uniformly distributed marginals, being the distributions of each element considered independently of the others, we can use the same technique to create new copulas too.

Importing/migrating from one peertube server to another

My Peertube server is shutting down, so I need to move my videos to another one. The official scripts don’t seem to cover this case very well, so here is what I did.

My script fetches videos and their details and uploads them to the new server via the Peertube API.

Contributions welcome: I was not able to copy video descriptions across, and I was too lazy so I hard-coded the number of tags. Also, I didn’t make a git repo for all this because I felt it needs more thought, but feel free to start one and I will happily contribute this.

This script copies all videos in a single Peertube channel to a different server. You must find the numeric ID of the channel on the new server to copy into, which I did by looking at the responses in the Network tab of Firefox’s developer tools when I clicked on its name in the web interface. It requires bash, curl, youtube-dl and jq.

Here’s peertube-migrate-channel.bash:

#!/bin/bash

set -u
set -e

# Modify these for your setup
OLD_SERVER="INSERT OLD SERVER e.g. https://peertube.social"
OLD_CHANNEL="INSERT CHANNEL URL-NAME e.g. trials_fusion"
NEW_SERVER="INSERT NEW SERVER e.g. https://video.hardlimit.com"
NEW_CHANNEL="INSERT NEW CHANNEL ID e.g. 4103"
USERNAME="INSERT_USERNAME for new server e.g. trials"
PASSWORD="INSERT PASSWORD for new server"
TAG1="INSERT_A_TAG e.g trials"
TAG2="INSERT_A_TAG e.g. gaming"
TAG3="INSERT_A_TAG e.g. gameing"

DIR=$(mktemp -d)
API_PATH="${NEW_SERVER}/api/v1"

# Find out how many videos are in the channel
curl -s \
    "${OLD_SERVER}/api/v1/video-channels/${OLD_CHANNEL}/videos/?count=1" \
    > "${DIR}/videos-total.json"

TOTAL=$(jq .total < "${DIR}/videos-total.json")
CURRENT=0
PAGE_SIZE=10

# Get a list of URLS for all the videos

echo -n "" > "${DIR}/urls.txt"

while (( CURRENT < TOTAL )); do
    FILE="${DIR}/videos-page-${CURRENT}.json"

    curl -s \
        "${OLD_SERVER}/api/v1/video-channels/${OLD_CHANNEL}/videos/?start=${CURRENT}&count=${PAGE_SIZE}&skipCount=true" \
        > "${FILE}"

    jq ".data | map(.uuid) | .[]" -r < "${FILE}" >> "${DIR}/urls.txt"

    CURRENT=$((CURRENT + PAGE_SIZE))
done

# Log in to the new server

client_id=$(curl -s "${API_PATH}/oauth-clients/local" | jq -r ".client_id")
client_secret=$(curl -s "${API_PATH}/oauth-clients/local" | jq -r ".client_secret")
token=$(curl -s "${API_PATH}/users/token" \
  --data client_id="${client_id}" \
  --data client_secret="${client_secret}" \
  --data grant_type=password \
  --data response_type=code \
  --data username="${USERNAME}" \
  --data password="${PASSWORD}" \
  | jq -r ".access_token")

# Download and upload each video

tac "${DIR}/urls.txt" \
    | while read ID; do
        URL="${OLD_SERVER}/api/v1/videos/${ID}"
        curl -s "${URL}" > "${DIR}/info-${ID}.json"
        NAME=$(jq -r .name < "${DIR}/info-${ID}.json")
        CATEGORY=$(jq -r .category.id < "${DIR}/info-${ID}.json")
        LICENCE=$(jq -r .licence.id < "${DIR}/info-${ID}.json")
        LANGUAGE=$(jq -r .language.id < "${DIR}/info-${ID}.json")
        PRIVACY=$(jq -r .privacy.id < "${DIR}/info-${ID}.json")

        OLD_VIDEO="https://peertube.social/videos/watch/${ID}"
	mkdir "${DIR}/dl-${ID}"
	youtube-dl "${OLD_VIDEO}" --output="${DIR}/dl-${ID}/dl.mp4"

        echo "Uploading ${OLD_VIDEO}"
        curl "${API_PATH}/videos/upload" \
	  --silent \
          -H "Authorization: Bearer ${token}" \
          --output "${DIR}/curl-out-${ID}.txt" \
          --max-time 6000 \
	  --form name="${NAME}" \
	  --form videofile=@"${DIR}/dl-${ID}/dl.mp4" \
          --form channelId=${NEW_CHANNEL} \
          --form category=${CATEGORY} \
          --form licence=${LICENCE} \
          --form description="TODO VIDEO DESCRIPTION" \
          --form language=${LANGUAGE} \
          --form privacy=${PRIVACY} \
          --form tags="${TAG1}" \
          --form tags="${TAG2}" \
          --form tags="${TAG3}"
    done

Have Google made a $billion skateboard mistake?

How do you design a car? – It is one of the most famous diagrams in the agile world drawn by Henrik Kniberg.

I’m guessing many readers know this already: one approach (top of the diagram) is to iteratively design and build all the pieces, put them together and you have a car. This is one interpretation of iterative but until you put the pieces together there is no feedback and no value.

After all, who wants half a car? We know what we want from a car, right? Who needs feedback? Who wants a car with three wheels? – Why waste time experimenting?

The alternative, advocated by minimally viable product people everywhere is to redefine the problem; we don’t want a car so much as transportation, we could start with a very simple – and quick to deliver – transportation system (the skateboard). Because it is delivered sooner we get feedback sooner. We see how people use it, and evolve it over a series of iterations into a motorised car.

Since I know this, you know this and it is on the back of every agile cereal packet one can rest assured that Larry Page, Tim Cook and Jeff Bezos know this, right?

Well no, not according to the Financial Times recently. The FT carried a piece about the development of autonomous cars – “Robotaxis: have Google and Amazon backed the wrong technology?” – paywalled. Since we already have the sort taxi someone drives the development effort goes into advancement.

For the last few years Google/Waymo, Apple and others have sunk billions of dollar – yes billions – into developing self-driving cars. And of course, we all know what we want from a car, even a self-driving car so this is an engineering problem.

These cars now work but there are a number of challenges before the achieve world dominance. Most of the challenges now are less to do with the technology and more to do with the market: customer acceptance, insurance, pricing, etc. Still, billions more are needed before any return can be achieved. In other words: Google etc. took the first approach, build the pieces.

What is less well know, and what the FT writes about, is that another group of companies has take the other approach. Component suppliers like Bosch and Magna, and tech companies like Mobileye (Intel) have been developing desecrate technologies that can be incorporated into existing cars which evolve towards self-driving dream. Not only is this cheaper but it is easier to market and clear regulatory hurdles because humans are assisted in driving not replaced. (Tesla is also in this camp as they add more and more capabilities to their auto-pilot features and have been getting feedback from real customers for years.)

Now it seems evolutionary approach may win-out against the big clean sheet of paper. The race is not over yet but the evolutionary suppliers are making money while the new designer are still burning cash. The evolutionary suppliers are integrating their tech into cars and getting regulatory approach while the new designers have to navigate many regulators.

Engineers often object to the evolutionary model because: “we need to see the big picture”, “you need an architecture”, “you can’t evolve a skateboard into a car”. And indeed, one of the Google engineers, quoted in the FT saying:

“Conventional wisdom would say that we’ll just take driver assistance systems and we’ll kind of push them and … over time, they’ll turn into self-driving cars … well that’s like saying that if I work really hard at jumping, one day I’ll be able to fly.”

Chris Urmson, 2015

When you consider the problem purely in engineering terms this rings true, but while one needs to respect engineering it is not the only frame of reference. One need to consider the commercial and marketing aspects, as well as customer acceptance and other factors. To give any single line of thought a privileged position is to expose yourself to risks from the others.

At the end of the day, as I have argued repeatedly: engineering is about creating solutions within a context, within constraints. To any given problem there are many potential solutions – many ways to slice the onion. The “best” solution is the solution which best fits those constraints.

The evolutionary approach allows you get feedback sooner which allows you to uncover those constrains sooner, that allows for course corrections and it also means less time and money has been spent on solutions which don’t meet the constraints.


Subscribe to my blog newsletter and download Continuous Digital for free – normal price $9.99/£9.95/€9.95

The post Have Google made a $billion skateboard mistake? appeared first on Allan Kelly Associates.

What can be learned from studying long gone development practices?

Current ideas about the best way of building a software system are heavily influenced by the ideas that captured the attention of previous generations of developers. Can anything of practical use be learned from studying long gone techniques for building software systems?

During the writing of my software engineering book, I was spending a lot of time researching the development techniques used during the twentieth century, and one day I suddenly realised that this was a waste of time. While early software developers tend to be eulogized today, the reality is that they were mostly people who had little idea what they were doing, who through personal competence of being in the right place at the right time managed to produce something good enough. On the whole, twentieth century software development techniques are only of historical interest. Yes, some timeless development principles were discovered, and these can be integrated into today’s techniques (which may also turn out to be of their-time).

My experience of software development in the late 1970s and 1980s is that there was rarely any connection between what management told the world about the development process, and how those reporting to the manager actually did the development.

If you are a manager in a world where software development is still very new, and you are given the job of managing the development of a software system, how do you go about it? A common approach is to apply the techniques that are already being used to run the manager’s organization. On a regular basis, managers came up with the idea of applying techniques from the science of industrial production (which is still happening today).

In the 1970s and 1980s there were usually very visible job hierarchies, and sharply defined roles. Organizations tended to use their existing job hierarchies and roles to create the structure for their software development employees. For years after I started work as a graduate, managers and secretaries were surprised to see me typing; secretaries typed, men did not type, and women developers fumed when they were treated like secretaries (because they had been seen typing).

The manual workers performed data entry, operated the computer (e.g., mounted tapes, and looked after the printer). The junior staff often started with the job title programmer, or perhaps junior programmer and there might be senior programmers; on paper these people wrote the code to implement the functionality specified by a systems analyst (or just analyst, or business analyst, perhaps with added junior or senior). Analysts did not to write code and programmers only coded what the specification they were given, at least according to management.

Pay level was set by the position in the job hierarchy, with those higher up earning more than those below them, and job titles/roles were also mapped to positions in the hierarchy. This created, in theory, a direct correspondence between pay and job title/role. In practice, organizations wanted to keep their productive employees, and so were flexible about the correspondence between pay and title, e.g., during their annual review some people were more interested in the status provided by a job title, while others wanted more money and did not care about job titles. Add into this mix the fact that pay/title levels rarely matched up between organizations, it soon became obvious to all that software job titles were a charade.

How should the people at the sharp end go about building a software system?

Structured programming was the widely cited technique in the 1970s. Consultants promoted their own variants, with Jackson structured programming being widely known in the UK, with regular courses and consultants offering to train staff. Today, structured programming appears remarkably simplistic, great for writing tiny programs (it has an academic pedigree), but not for anything larger than a thousand lines. Part of its appeal may have been this simplicity, many programs were small (because computer memory was measured in kilobytes) and management often thought that problems were simple (a recurring problem). There were a few adaptations that tried to address larger scale issues, e.g., Warnier/Orr structured programming.

The military were major employers of software developers in the 1960s and 1970s. In the US Work Breakdown Structure was mandated by the DOD for project development (for all projects, not just software), and in the UK we had MASCOT. These mandated development methodologies were created by committees, and have not been experimentally tested to be better/worse than any other approach.

I think the best management technique for successfully developing a software system in the 1970s and 1980s (and perhaps in the following decades), is based on being lucky enough to have a few very capable people, and then providing them with what is needed to get the job done while maintaining the fiction to upper management that the agreed bureaucratic plan is being followed.

There is one technique for producing a software system that rarely gets mentioned: keep paying for development until something good enough is delivered. Given the life-or-death need an organization might have for some software systems, paying what it takes may well have been a prevalent methodology during the early days of major software development.

To answer the question posed at the start of this post. What might be learned from a study of early software development techniques is the need for management to have lots of luck and to be flexible; funding is easier to obtain when managing a life-or-death project.

What can be learned from studying long gone development practices?

Current ideas about the best way of building a software system are heavily influenced by the ideas that captured the attention of previous generations of developers. Can anything of practical use be learned from studying long gone techniques for building software systems?

During the writing of my software engineering book, I was spending a lot of time researching the development techniques used during the twentieth century, and one day I suddenly realised that this was a waste of time. While early software developers tend to be eulogized today, the reality is that they were mostly people who had little idea what they were doing, who through personal competence of being in the right place at the right time managed to produce something good enough. On the whole, twentieth century software development techniques are only of historical interest. Yes, some timeless development principles were discovered, and these can be integrated into today’s techniques (which may also turn out to be of their-time).

My experience of software development in the late 1970s and 1980s is that there was rarely any connection between what management told the world about the development process, and how those reporting to the manager actually did the development.

If you are a manager in a world where software development is still very new, and you are given the job of managing the development of a software system, how do you go about it? A common approach is to apply the techniques that are already being used to run the manager’s organization. On a regular basis, managers came up with the idea of applying techniques from the science of industrial production (which is still happening today).

In the 1970s and 1980s there were usually very visible job hierarchies, and sharply defined roles. Organizations tended to use their existing job hierarchies and roles to create the structure for their software development employees. For years after I started work as a graduate, managers and secretaries were surprised to see me typing; secretaries typed, men did not type, and women developers fumed when they were treated like secretaries (because they had been seen typing).

The manual workers performed data entry, operated the computer (e.g., mounted tapes, and looked after the printer). The junior staff often started with the job title programmer, or perhaps junior programmer and there might be senior programmers; on paper these people wrote the code to implement the functionality specified by a systems analyst (or just analyst, or business analyst, perhaps with added junior or senior). Analysts did not to write code and programmers only coded what the specification they were given, at least according to management.

Pay level was set by the position in the job hierarchy, with those higher up earning more than those below them, and job titles/roles were also mapped to positions in the hierarchy. This created, in theory, a direct correspondence between pay and job title/role. In practice, organizations wanted to keep their productive employees, and so were flexible about the correspondence between pay and title, e.g., during their annual review some people were more interested in the status provided by a job title, while others wanted more money and did not care about job titles. Add into this mix the fact that pay/title levels rarely matched up between organizations, it soon became obvious to all that software job titles were a charade.

How should the people at the sharp end go about building a software system?

Structured programming was the widely cited technique in the 1970s. Consultants promoted their own variants, with Jackson structured programming being widely known in the UK, with regular courses and consultants offering to train staff. Today, structured programming appears remarkably simplistic, great for writing tiny programs (it has an academic pedigree), but not for anything larger than a thousand lines. Part of its appeal may have been this simplicity, many programs were small (because computer memory was measured in kilobytes) and management often thought that problems were simple (a recurring problem). There were a few adaptations that tried to address larger scale issues, e.g., Warnier/Orr structured programming.

The military were major employers of software developers in the 1960s and 1970s. In the US Work Breakdown Structure was mandated by the DOD for project development (for all projects, not just software), and in the UK we had MASCOT. These mandated development methodologies were created by committees, and have not been experimentally tested to be better/worse than any other approach.

I think the best management technique for successfully developing a software system in the 1970s and 1980s (and perhaps in the following decades), is based on being lucky enough to have a few very capable people, and then providing them with what is needed to get the job done while maintaining the fiction to upper management that the agreed bureaucratic plan is being followed.

There is one technique for producing a software system that rarely gets mentioned: keep paying for development until something good enough is delivered. Given the life-or-death need an organization might have for some software systems, paying what it takes may well have been a prevalent methodology during the early days of major software development.

To answer the question posed at the start of this post. What might be learned from a study of early software development techniques is the need for management to have lots of luck and to be flexible; funding is easier to obtain when managing a life-or-death project.

2021 in the programming language standards’ world

Last Tuesday I was on a Webex call (the British Standards Institute’s use of Webex for conference calls predates COVID 19) for a meeting of IST/5, the committee responsible for programming language standards in the UK.

There have been two developments whose effect, I think, will be to hasten the decline of the relevance of ISO standards in the programming language world (to the point that they are ignored by compiler vendors).

  • People have been talking about switching to online meetings for years, and every now and again someone has dialed-in to the conference call phone system provided by conference organizers. COVID has made online meetings the norm (language working groups have replaced face-to-face meetings with online meetings). People are looking forward to having face-to-face meetings again, but there is talk of online attendance playing a much larger role in the future.

    The cost of attending a meeting in person is the perennial reason given for people not playing an active role in language standards (and I imagine other standards). Online attendance significantly reduces the cost, and an increase in the number of people ‘attending’ meetings is to be expected if committees agree to significant online attendance.

    While many people think that making it possible for more people to be involved, by reducing the cost, is a good idea, I think it is a bad idea. The rationale for the creation of standards is economic; customer costs are reduced by reducing diversity incompatibilities across the same kind of product., e.g., all standard conforming compilers are consistent in their handling of the same construct (undefined behavior may be consistently different). When attending meetings is costly, those with a significant economic interest tend to form the bulk of those attending meetings. Every now and again somebody turns up for a drive-by-shooting, i.e., they turn up for a day to present a paper on their pet issue and are never seen again.

    Lowering the barrier to entry (i.e., cost) is going to increase the number of drive-by shootings. The cost of this spray of pet-issue papers falls on the regular attendees, who will have to spend time dealing with enthusiastic, single issue, newbies,

  • The International Organization for Standardization (ISO is the abbreviation of the French title) has embraced the use of inclusive terminology. The ISO directives specifying the Principles and rules for the structure and drafting of ISO and IEC documents, have been updated by the addition of a new clause: 8.6 Inclusive terminology, which says:

    “Whenever possible, inclusive terminology shall be used to describe technical capabilities and relationships. Insensitive, archaic and non-inclusive terms shall be avoided. For the purposes of this principle, “inclusive terminology” means terminology perceived or likely to be perceived as welcoming by everyone, regardless of their sex, gender, race, colour, religion, etc.

    New documents shall be developed using inclusive terminology. As feasible, existing and legacy documents shall be updated to identify and replace non-inclusive terms with alternatives that are more descriptive and tailored to the technical capability or relationship.”

    The US Standards body, has released the document INCITS inclusive terminology guidelines. Section 5 covers identifying negative terms, and Section 6 deals with “Migration from terms with negative connotations”. Annex A provides examples of terms with negative connotations, preceded by text in bright red “CONTENT WARNING: The following list contains material that may be harmful or
    traumatizing to some audiences.”

    “Error” sounds like a very negative word to me, but it’s not in the annex. One of the words listed in the annex is “dummy”. One member pointed out that ‘dummy’ appears 794 times in the current Fortran standard, (586 times in ‘dummy argument’).

    Replacing words with negative connotations leads to frustration and distorted perceptions of what is being communicated.

    I think there will be zero real world impact from the use of inclusive terminology in ISO standards, for the simple reason that terminology in ISO standards usually has zero real world impact (based on my experience of the use of terminology in ISO language standards). But the use of inclusive terminology does provide a new opportunity for virtue signalling by members of standards’ committees.

    While use of inclusive terminology in ISO standards is unlikely to have any real world impact, the need to deal with suggested changes of terminology, and new terminology, will consume committee time. Most committee members tend to a rather pragmatic, but it only takes one or two people to keep a discussion going and going.

Over time, compiler vendors are going to become disenchanted with the increased workload, and the endless discussions relating to pet-issues and inclusive terminology. Given that there are so few industrial strength compilers for any language, the world no longer needs formally agreed language standards; the behavior that implementations have to support is controlled by the huge volume of existing code. Eventually, compiler vendors will sever the cord to the ISO standards process, and outside of the SC22 bubble nobody will notice.

2021 in the programming language standards’ world

Last Tuesday I was on a Webex call (the British Standards Institute’s use of Webex for conference calls predates COVID 19) for a meeting of IST/5, the committee responsible for programming language standards in the UK.

There have been two developments whose effect, I think, will be to hasten the decline of the relevance of ISO standards in the programming language world (to the point that they are ignored by compiler vendors).

  • People have been talking about switching to online meetings for years, and every now and again someone has dialed-in to the conference call phone system provided by conference organizers. COVID has made online meetings the norm (language working groups have replaced face-to-face meetings with online meetings). People are looking forward to having face-to-face meetings again, but there is talk of online attendance playing a much larger role in the future.

    The cost of attending a meeting in person is the perennial reason given for people not playing an active role in language standards (and I imagine other standards). Online attendance significantly reduces the cost, and an increase in the number of people ‘attending’ meetings is to be expected if committees agree to significant online attendance.

    While many people think that making it possible for more people to be involved, by reducing the cost, is a good idea, I think it is a bad idea. The rationale for the creation of standards is economic; customer costs are reduced by reducing diversity incompatibilities across the same kind of product., e.g., all standard conforming compilers are consistent in their handling of the same construct (undefined behavior may be consistently different). When attending meetings is costly, those with a significant economic interest tend to form the bulk of those attending meetings. Every now and again somebody turns up for a drive-by-shooting, i.e., they turn up for a day to present a paper on their pet issue and are never seen again.

    Lowering the barrier to entry (i.e., cost) is going to increase the number of drive-by shootings. The cost of this spray of pet-issue papers falls on the regular attendees, who will have to spend time dealing with enthusiastic, single issue, newbies,

  • The International Organization for Standardization (ISO is the abbreviation of the French title) has embraced the use of inclusive terminology. The ISO directives specifying the Principles and rules for the structure and drafting of ISO and IEC documents, have been updated by the addition of a new clause: 8.6 Inclusive terminology, which says:

    “Whenever possible, inclusive terminology shall be used to describe technical capabilities and relationships. Insensitive, archaic and non-inclusive terms shall be avoided. For the purposes of this principle, “inclusive terminology” means terminology perceived or likely to be perceived as welcoming by everyone, regardless of their sex, gender, race, colour, religion, etc.

    New documents shall be developed using inclusive terminology. As feasible, existing and legacy documents shall be updated to identify and replace non-inclusive terms with alternatives that are more descriptive and tailored to the technical capability or relationship.”

    The US Standards body, has released the document INCITS inclusive terminology guidelines. Section 5 covers identifying negative terms, and Section 6 deals with “Migration from terms with negative connotations”. Annex A provides examples of terms with negative connotations, preceded by text in bright red “CONTENT WARNING: The following list contains material that may be harmful or
    traumatizing to some audiences.”

    “Error” sounds like a very negative word to me, but it’s not in the annex. One of the words listed in the annex is “dummy”. One member pointed out that ‘dummy’ appears 794 times in the current Fortran standard, (586 times in ‘dummy argument’).

    Replacing words with negative connotations leads to frustration and distorted perceptions of what is being communicated.

    I think there will be zero real world impact from the use of inclusive terminology in ISO standards, for the simple reason that terminology in ISO standards usually has zero real world impact (based on my experience of the use of terminology in ISO language standards). But the use of inclusive terminology does provide a new opportunity for virtue signalling by members of standards’ committees.

    While use of inclusive terminology in ISO standards is unlikely to have any real world impact, the need to deal with suggested changes of terminology, and new terminology, will consume committee time. Most committee members tend to a rather pragmatic, but it only takes one or two people to keep a discussion going and going.

Over time, compiler vendors are going to become disenchanted with the increased workload, and the endless discussions relating to pet-issues and inclusive terminology. Given that there are so few industrial strength compilers for any language, the world no longer needs formally agreed language standards; the behavior that implementations have to support is controlled by the huge volume of existing code. Eventually, compiler vendors will sever the cord to the ISO standards process, and outside of the SC22 bubble nobody will notice.

Visual Studio 2022 Preview 2 and the v143 platform toolset

Visual Studio 2022 Preview 2 was released by Microsoft last week.

One of the changes included in Preview 2 is the addition of the Visual Studio 2022 specific v143 platform toolset (Preview 1 used the v142 platform toolset from Visual Studio 2019). Support for the v143 toolset has already been added to Visual Lint 8.0 and will soon become available within both VisualLintConsole and VisualLintGui in Visual Lint 8.0.3.

As part of that change, 8.0.3 will include a PC-lint Plus indirect file for Visual Studio 2022, and the Configuration Wizard and Options Dialog will both offer Visual Studio 2022 projects as an option:

Configuration Wizard with co-rb-vs2022.lntThe PC-lint Plus indirect file co-rb-vs2022.lnt has been added to to support Visual Studio 2022.

Furthermore, since Preview 1 was released last month we have been gradually plugging away (no pun intended!) in the Visual Lint development branch, adding support for the VS2022 VSSDK COM interfaces along with new x64 build configurations where needed.

It's worth noting that although named identically, the Visual Studio 2022 interfaces differ somewhat from their 32 bit predecessors so a lot of boilerplate changes have been required. However as we (fortunately, it turns out) use an in-house Visual Studio interfacing library to wrap the Visual Studio COM interfaces we use those changes have been largely localised to the support library itself - and that's made things a lot easier than it might otherwise have been.

Once that was done we turned our attention to the Visual Studio plugin project itself, by adding x64 build configurations to it and then gradually working through the code fixing the inevitable compilation and linker errors (mostly by conditionally compiling out 32 bit specific code, such as that relying on the add-in interfaces used with Visual Studio versions prior to Visual Studio 2015).

We finally got a clean build on a dev machine this morning, and then turned our attention to adding a VS2022 VSIX package project, which is necessary to deploy a plugin (or "extension", in Microsoft terminology) to Visual Studio 2022.

A few tweaks, some headscratching and more tweaks later, and just after lunch today Visual Lint not only successfully loaded under debug in a Visual Studio 2022 experimental instance for the first time but also analysed its first project under that environment:

screenshotA development build of Visual Lint running within Visual Studio 2022 Preview 2. screenshotA development build of Visual Lint running within Visual Studio 2022 Preview 2.

Of course getting the plugin running under debug is just the first step - there is still much to do before we can release a public build with a Visual Studio 2022 compatible version of the Visual Studio plugin.

That said, getting to this point is hugely encouraging, so today has definitely been a good day.

Visual Studio 2022 Preview 2

Visual Studio 2022 Preview 2 was released by Microsoft last week.

One of the changes included in Preview 2 is the addition of the Visual Studio 2022 specific v143 platform toolset (Preview 1 used the v142 platform toolset from Visual Studio 2019). Support for the v143 toolset has already been added to Visual Lint 8.0 and will soon become available within both VisualLintConsole and VisualLintGui in Visual Lint 8.0.3.

As part of that change, 8.0.3 will include a PC-lint Plus indirect file for Visual Studio 2022, and the Configuration Wizard and Options Dialog will both offer Visual Studio 2022 projects as an option:

Configuration Wizard with co-rb-vs2022.lntThe PC-lint Plus indirect file co-rb-vs2022.lnt has been added to to support Visual Studio 2022.

Furthermore, since Preview 1 was released last month we have been gradually plugging away (no pun intended!) in the Visual Lint development branch, adding support for the VS2022 VSSDK COM interfaces along with new x64 build configurations where needed.

It's worth noting that although named identically, the VS2022 interfaces differ somewhat from their 32 bit predecessors so a lot of boilerplate changes have been required. However as we (fortunately, it turns out) use an in-house Visual Studio interfacing library to wrap the Visual Studio COM interfaces we use those changes have been largely localised to the support library itself - and that's made things a lot easier than it might otherwise have been.

Once that was done we turned our attention to the Visual Studio plugin project itself, by adding x64 build configurations to it and then gradually working through the code fixing the inevitable compilation and linker errors (mostly by conditionally compiling out 32 bit specific code, such as that relying on the add-in interfaces used with Visual Studio versions prior to VS2015).

We finally got a clean build on a dev machine this morning, and then turned our attention to adding a VS2022 VSIX package project, which is necessary to deploy a plugin (or "extension", in Microsoft terminology) to VS2022.

A few tweaks, some headscratching and more tweaks later, and just after lunch today Visual Lint not only successfully loaded under debug in a Visual Studio 2022 experimental instance for the first time but also analysed its first project under that environment:

screenshotA development build of Visual Lint running within Visual Studio 2022 Preview 2. screenshotA development build of Visual Lint running within Visual Studio 2022 Preview 2.

Of course getting the plugin running under debug is just the first step - there is still much to do before we can release a public build with a VS2022 version of the Visual Studio plugin.

That said, getting to this point is hugely encouraging, so today has definitely been a good day.

Visual Studio 2022 Preview 2

Visual Studio 2022 Preview 2 was released by Microsoft last week.

One of the changes included in Preview 2 is the addition of the Visual Studio 2022 specific v143 platform toolset (Preview 1 used the v142 platform toolset from Visual Studio 2019). Support for the v143 toolset has already been added to Visual Lint 8.0 and will soon become available within both VisualLintConsole and VisualLintGui in Visual Lint 8.0.3.

As part of that change, 8.0.3 will include a PC-lint Plus indirect file for Visual Studio 2022, and the Configuration Wizard and Options Dialog will both offer Visual Studio 2022 projects as an option:

Configuration Wizard with co-rb-vs2022.lntThe PC-lint Plus indirect file co-rb-vs2022.lnt has been added to to support Visual Studio 2022.

Furthermore, since Preview 1 was released last month we have been gradually plugging away (no pun intended!) in the Visual Lint development branch, adding support for the VS2022 VSSDK COM interfaces along with new x64 build configurations where needed.

It's worth noting that although named identically, the VS2022 interfaces differ somewhat from their 32 bit predecessors so a lot of boilerplate changes have been required. However as we (fortunately, it turns out) use an in-house Visual Studio interfacing library to wrap the Visual Studio COM interfaces we use those changes have been largely localised to the support library itself - and that's made things a lot easier than it might otherwise have been.

Once that was done we turned our attention to the Visual Studio plugin project itself, by adding x64 build configurations to it and then gradually working through the code fixing the inevitable compilation and linker errors (mostly by conditionally compiling out 32 bit specific code, such as that relying on the add-in interfaces used with Visual Studio versions prior to VS2015).

We finally got a clean build on a dev machine this morning, and then turned our attention to adding a VS2022 VSIX package project, which is necessary to deploy a plugin (or "extension", in Microsoft terminology) to VS2022.

A few tweaks, some headscratching and more tweaks later, and just after lunch today Visual Lint not only successfully loaded under debug in a Visual Studio 2022 experimental instance for the first time but also analysed its first project under that environment:

screenshotA development build of Visual Lint running within Visual Studio 2022 Preview 2. screenshotA development build of Visual Lint running within Visual Studio 2022 Preview 2.

Of course getting the plugin running under debug is just the first step - there is still much to do before we can release a public build with a VS2022 version of the Visual Studio plugin.

That said, getting to this point is hugely encouraging, so today has definitely been a good day.

Documentation, another case of rapidly diminishing returns

No body writes documentation in startups.

Writing documents is a luxury only established companies can afford. One might ask: are companies successful because they write documents or do they write documents because they are successful? But I’d be hard pushed to find anyone to argue the latter.

Back in 1996 I worked on the ill-fated UK rail privatisation. I was part of the team writing a new computer system to create a new rail timetable – one that would allow competition in train services. In the average week I spent half my time coding and half my time documenting.

For every program there was a program specification – what the program had to do. And a functional specification – saying what the program did. I had to update both. And these had to align with the system architecture, which was a multi-volume beast I wasn’t allowed to touch.

Additionally I had to create a unit test plan for each program or set of changes. Unit tests were manual and the test plan was made up of two Word documents. One was a big table and the other had one test per page. As I conducted the test I had to update the plan with success or fail – and fail of course mean rework so we alwys made sure it worked before hand.

When my program was ready to check-in I had to fill in a source code control form so my team leader knew which files to check in. If I added a new code file to the system I needed to complete an additional form to explain what the file was. On one occasion I got fed up of a 2,000 line C++ file and refactored it as 4 smaller files. Being C++ his meant 4 pairs of .h and .cpp files, so 8 new files each with a form. My team leader was quite clear: I was never to do this again, it made too much work for her.

Did it help? – I find it hard to imagine it did. In fact I started my own hidden documentation, the “Rough Guide to …” which told me (and other devs) things we actually needed to know.

There are two types of companies: those that don’t write documents – and where many many people are asking for documentation. Documentation is seen as a solution to (almost) any problem. And yet people don’t write documents, then they feel guilty about not writing them.

The second type of company is overrun with documentation. There seem to be armies of people writing documentation: architects and business analysts seem particularly keen to write documents. These are often prose, they are about as readable as your average Shakespeare play is to a 15 year old and read about as often. Project managers are also prone to documentation but they don’t write prose; instead, project plans and progress presentations are documents in another medium.

In the first type of company nobody reads documents because there are none. In the second type of company its debatable how many of those documents are read. Many of them are so utterly boring that it is hard to stay awake reading them. As I’m often heard to say:

The bigger a document is, the less likely it is to be read.

And if it is read, the bigger a document is the less the reader will remember.

In one eye-and-out-the-other.

It’s probably just as well because documentation rapidly becomes out of date unless copious amounts of time are invested in keeping it up to date. Actually, it is good that documentation is seldom read because reading it is almost as expensive as writing it and, in theory at least, it should be read far more often.

True, “documentation” covers a very wide range of things. From project plans to release notes, from user guides to architecture diagrams. Some has more readers more than others – user guides compared to functional specifications. But then, who has read their iPhone manual? Does such a document even exist? Arguably the best products don’t need documentation.

In both types of companies I hear complaints about the lack of communication – actually, I don’t think I’ve ever visited a client were people didn’t complain about the lack of communication. But only in the first type of company do people think that documentation will cure the problem.

In such companies documentation is seen as the solution to almost every problem. Programmers complain they haven’t been given written requirements and specifications, they complain the user designers aren’t giving them documents of is expected, and most of all they complain the developers who came before them did not document what they did. Equally testers demand the same requirements and specification but also want programmers to provide written descriptions of what the program does. Project managers want written reports of what was done and so on.

Nobody ever got fired for asking for more documentation, but I’m not so sure about writing it.

While I have sympathy that these people want information I don’t believe documentation will solve the problems – perhaps because I’ve never seen a development effort with “Goldilocks documentation” – not too much and not too little. One thing I do know is that if everyone wrote the documentation they thought was needed, and what others wanted from them, then little would get done.

What I fear is a descent into documentation as everyone sets about communicating through documentation and not talking.

Because documentation takes time and money to create, it takes time and money to read, it takes time and money to update and keep current. And all the time and money spent on documentation is time and money not being spent on developing products and testing products in the market.

Worst still documentation becomes a hinderance to change. On multiple occasions I have met companies that do not want to change their products or processes because the cost of updating the documentation is too great.

I’ve nothing against documentation itself, I simply lament the time and money that could be better spent elsewhere, I regret the missed opportunities for real communication and belief that something has been communicated; and I fear the limitations that documentation brings once in place.

To answer my own question above. I don’t believe companies that write documents are successful, documentation does not determine success – if it did many many projects would have succeeded instead of failing. That documentation is so often lacking but products are successful actually goes to prove that is not essential.

Nor do I really believe companies write documents because they are successful. They write documents because they are successful enough to be able to afford to write documents but those same documents inhibit future success.

Before I close, I can almost hear people rushing to their keyboards to tell me of occasions were a system document saved their life,

“If Sam hadn’t left behind a document that told me the function was connected to the reactor core…”

While I’m sure such cases exists I’m not convinced the they justify the vast amounts of cost of writing a document against doing something else. If Sam hadn’t written that document what might Sam have done with the time instead? Possibly something even more valuable.

As with planning documentation exhibits rapidly diminishing returns on investment.

Photo by Glenn Carstens-Peters on Unsplash


Subscribe to my blog newsletter and download Continuous Digital for free – normal price $9.99 / £9.95 / €9.95

The post Documentation, another case of rapidly diminishing returns appeared first on Allan Kelly Associates.

User Stories by Example part 3 (Refactoring)

The latest instalment of my online User Stories tutorial is now available online, User Stories by Example: Refactoring.

It takes as its starting point some existing stories and reworks them to convey their message more clearly. In the process I discuss:

The use of time-boxed spikes.

The naming of team members in user stories, e.g. “As a developer I want …” – and why this isn’t a good idea.

Rewriting user stories and breaking them down into more smaller stories. (More on this in the next tutorial.)

Why more smaller stories is better than a fewer larger stories.

How acceptance criteria can be used to split stories into smaller pieces.

and a brief look at dealing with dependencies.

Videos are intersperced with exercises and quizzes. My guess is this tutorial will take two to three hours to complete – which can be all in one go or split over days or weeks to suit yourself. As with the earlier tutorials I work through real life user stories to illustrate and draw lessons.

This is the third tutorial, it joins User Stories by Example part 1 Starting with Stories and part 2 Acceptance Criteria. The next module will look at splitting stories in more detail.

The tutorial this carries the introductory price of $49. In time this price will probably rise and I’ll introduce a combined option to buy all the courses in one go.

Please e-mail me with your comments and suggestions.

The post User Stories by Example part 3 (Refactoring) appeared first on Allan Kelly Associates.

Succeeding with OKRs in Agile, Podcast with Agile Uprising

Agile Uprising has just published a new podcast they recorded with my a few weeks ago about, well OKRs and my book Succeeding with OKRs in Agile.

Succeeding with OKRs in Agile podcast is available for download now – for free


Subscribe to my blog newsletter and download Continuous Digital for free – normal price $9.99/£9.95/€9.95

The post Succeeding with OKRs in Agile, Podcast with Agile Uprising appeared first on Allan Kelly Associates.

Estimating using a granular sequence of values

When asked for an estimate of the time needed to complete a task, should developers be free to choose any numeric value, or should they be restricted to selecting from a predefined set of values (e.g, the Fibonacci numbers, or T-shirt sizes)?

Allowing any value to be chosen would appear to provide the greatest flexibility to make an accurate estimate. However, estimating is an intrinsically uncertain process (i.e., the future is unknown), and it is done by people with varying degrees of experience (which might be used to help guide their prediction about the future).

Restricting the selection process to one of the values in a granular sequence of numbers has several benefits, including:

  • being able to adjust the gaps between permitted values to match the likely level of uncertainty in the task effort, or the best accuracy resolution believed possible,
  • reducing the psychological stress of making an estimate, by explicitly giving permission to ignore the smaller issues (because they are believed to require a total effort that is less than the sequence granularity),
  • helping to maintain developer self-esteem, by providing a justification when an estimate turning out to be inaccurate, e.g., the granularity prevented a more accurate estimate being made.

Is there an optimal sequence of granular values to use when making task estimates for a project?

The answer to this question depends on what is attempting to be optimized.

Given how hard it is to get people to produce estimates, the first criterion for an optimal sequence has to be that people are willing to use it.

I have always been struck by the ritualistic way in which the Fibonacci sequence is described by those who use it to make estimates. Rituals are an effective technique used by groups to help maintain members’ adherence to group norms (one of which might be producing estimates).

A possible reason for the tendency to use round numbers might estimate-values is that this usage is common in other social interactions involving numeric values, e.g., when replying to a request for the time of day.

The use of round numbers, when developers have the option of selecting from a continuous range of values, is a developer imposed granular sequence. What form do these round number sequences take?

The plot below shows the values of each of the six most common round number estimates present in the BrightSquid, SiP, and CESAW (project 615) effort estimation data sets, plus the first six Fibonacci numbers (code+data):

The six most common round number estimates present in various software task estimation datasets, plus the Fibonacci sequence, and fitted regression lines.

The lines are fitted regression models having the form: permittedValue approx e^{0.5 Order} (there is a small variation in the value of the constant; the smallest value for project 615 was probably calculated rather than being human selected).

This plot shows a consistent pattern of use across multiple projects (I know of several projects that use Fibonacci numbers, but don’t have any publicly available data). Nothing is said about this pattern being (near) optimal in any sense.

The time unit of estimation for this data was minutes or hours. Would the equation have the same form if the time unit was days, would the constant still be around 0.5. I await the data needed to answer this question.

This brief analysis looked at granular sequences from the perspective of the distribution of estimates made. Perhaps it makes more sense to base a granular estimation sequence on the distribution of actual task effort. A topic for another post.

Estimating using a granular sequence of values

When asked for an estimate of the time needed to complete a task, should developers be free to choose any numeric value, or should they be restricted to selecting from a predefined set of values (e.g, the Fibonacci numbers, or T-shirt sizes)?

Allowing any value to be chosen would appear to provide the greatest flexibility to make an accurate estimate. However, estimating is an intrinsically uncertain process (i.e., the future is unknown), and it is done by people with varying degrees of experience (which might be used to help guide their prediction about the future).

Restricting the selection process to one of the values in a granular sequence of numbers has several benefits, including:

  • being able to adjust the gaps between permitted values to match the likely level of uncertainty in the task effort, or the best accuracy resolution believed possible,
  • reducing the psychological stress of making an estimate, by explicitly giving permission to ignore the smaller issues (because they are believed to require a total effort that is less than the sequence granularity),
  • helping to maintain developer self-esteem, by providing a justification when an estimate turning out to be inaccurate, e.g., the granularity prevented a more accurate estimate being made.

Is there an optimal sequence of granular values to use when making task estimates for a project?

The answer to this question depends on what is attempting to be optimized.

Given how hard it is to get people to produce estimates, the first criterion for an optimal sequence has to be that people are willing to use it.

I have always been struck by the ritualistic way in which the Fibonacci sequence is described by those who use it to make estimates. Rituals are an effective technique used by groups to help maintain members’ adherence to group norms (one of which might be producing estimates).

A possible reason for the tendency to use round numbers might estimate-values is that this usage is common in other social interactions involving numeric values, e.g., when replying to a request for the time of day.

The use of round numbers, when developers have the option of selecting from a continuous range of values, is a developer imposed granular sequence. What form do these round number sequences take?

The plot below shows the values of each of the six most common round number estimates present in the BrightSquid, SiP, and CESAW (project 615) effort estimation data sets, plus the first six Fibonacci numbers (code+data):

The six most common round number estimates present in various software task estimation datasets, plus the Fibonacci sequence, and fitted regression lines.

The lines are fitted regression models having the form: permittedValue approx e^{0.5 Order} (there is a small variation in the value of the constant; the smallest value for project 615 was probably calculated rather than being human selected).

This plot shows a consistent pattern of use across multiple projects (I know of several projects that use Fibonacci numbers, but don’t have any publicly available data). Nothing is said about this pattern being (near) optimal in any sense.

The time unit of estimation for this data was minutes or hours. Would the equation have the same form if the time unit was days, would the constant still be around 0.5. I await the data needed to answer this question.

This brief analysis looked at granular sequences from the perspective of the distribution of estimates made. Perhaps it makes more sense to base a granular estimation sequence on the distribution of actual task effort. A topic for another post.

What is known about software effort estimation in 2021

What do we know about software effort estimation, based on evidence?

The few publicly available datasets (e.g., SiP, CESAW, and Renzo) involve (mostly) individuals estimating short duration tasks (i.e., rarely more than a few hours). There are other tiny datasets, which are mostly used to do fake research. The patterns found across these datasets include:

  • developers often use round-numbers,
  • the equation: Actual approx K*Estimate^{0.9pm 0.05}, where K is a constant that varies between projects, often explains around 50% of the variance present in the data. This equation shows that developers under-estimate short tasks and over-estimate long tasks. The exponent, 0.9pm 0.05, applies across most projects in the data,
  • individuals tend to either consistently over or under estimate,
  • developer estimation accuracy does not change with practice. Possible reasons for this include: variability in the world prevents more accurate estimates, developers choose to spend their learning resources on other topics.

Does social loafing have an impact on actual effort? The data needed to answer this question is currently not available (the available data mostly involves people working on their own).

When working on a task, do developers follow Parkinson’s law or do they strive to meet targets?

The following plot suggests that one or the other, or both are true (data):

left: Number of tasks taking a given amount of actual time, when they were estimated to take 30, 60 or 120 minutes; right: Number of tasks estimated to take a given amount of time, when they actually took 30, 60 or 120 minutes

On the left: Each colored lines shows the number of tasks having a given actual implementation time, when they were estimated to take 30, 60 or 120 minutes (the right plot reverses the role of estimate/actual). Many of the spikes in the task counts are at round numbers, suggesting that the developer has fixated on a time to finish and is either taking it easy or striving to hit it. The problem is distinguishing them mathematically; suggestions welcome.

None of these patterns of behavior appear to be software specific. They all look like generic human behaviors. I have started emailing researchers working on project analytics in other domains, asking for data (no luck so far).

Other patterns may be present for many projects in the existing data, we have to wait for somebody to ask the right question (if one exists).

It is also possible that the existing data has some unusual characteristics that don’t apply to most projects. We won’t know until data on many more projects becomes available.

Turning this particular server into a bit less of a pet

I’m in the middle of a server redo - right now, I’m setting up a replacement server for my trusty Dell T30, plus it was time to give this web server a new home. When I started the migration from my old WordPress site to the new static site, the static site was running on a small 1 core / 1GB RAM cloud server at Vultr. That had enough oomph for testing and for the last couple of months.

Software is not a lump or work to do (and the laws which prove it)

Workers digging hole

Building software is not like digging a hole in the ground: your target changes as you dig, the people and machines you use change the outcome as much as any original idea, and you never really know when to stop digging.

Years ago I was hired by Reuters to build an interface connector between the Liffe trading exchange and their data systems. Another developer started a few weeks after me. In the end we produced about half a dozen modules that worked together to make the connection. But we only produced that many because we were over staffed. In reality the one module I wrote handled 90% of the work required, the other modules were largely superfluous. And certainly the extra time which would have been required to make my module do 100% of the work was less than the time I spent to make sure it worked with the other.

Regular readers have probably already recognised Kelly’s Second Law of software: Inside every large development effort there is a small one struggling to get out

This itself is an example of Parkinson’s Law: work expands so as to fill the time available for its completion.

Actually you might restate my second law as Parkinson’s Law in reverse: constraining the capacity to do work reduces the amount of work to do. If you think about it this is a result of Conway’s Law: system designs copy the communication channels in the organization which creates the system.

Economists see a related phenomenon as the Lump of Work fallacy: people assume there is a fixed lump of work to do. If there are more people to do the work (say from immigration) then there will be unemployment – or possibly wages will be forced down and same work is distributed between more people. However it doesn’t national economies work like that, more people demand more food, houses, healthcare, schools and so on. What is true in the small is not true in the large. The net effect can be positive for countries but exactly how and by how much is hotly debated.

Software development has its own lump of work fallacy. There isn’t a fixed amount of work to do. Rather than saying “How many people will it take and how long will it take?” It is better to say “If we have five people working on this for three months what progress can we make?”

Writing software is not like digging a hole in the ground: the work to do is neither really known in advance nor is it fixed. Adding people actually increases the amount of work to do – Brooks’s Law.

At the start nobody really knows what it required, they may get lucky but more often that not once the thing is put in front of clients and (potential) customers the ask changes. I’ve heard this called Humphrey’s Law (after Watts Humphrey) although that name is not in common usage and there is another Humphrey’s Law from the world of psychology – which is connected with time estimation discussions for different reasons.

When you put Parkinson’s Law together with this “don’t know until I see it” law you get Hofstadter’s law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Assume for the moment that one can know what is wanted in advance there is another problem: there are multiple ways to achieve the same result. There is no one true way in software development, there are always multiple ways to achieve the same end result.

Even if one was to fix the big questions – the OS, the delivery platform, the programming language and the database and so on – then you can still create very different implementations for the same thing. Or as I usually put it “there are many ways to dice the onion” – my Crown Jewels post describes how I can get wildly different time and money estimates for what is basically the same piece of work.

Of course the big consequence of these is estimation – how can anyone estimate in these circumstances? Let me go further and suggest that the process of estimating the work to do is more likely than not to increase the amount of work to do. Not only does estimation take time to do itself, but there when estimating there is a tendency to “play safe” and favour larger estimates even when these estimates are themselves underestimates (see Vierordt’s law.)

Sometimes it feels like quantum physics: when one parameter is measured another changes, we can know the speed but not the direction, or the direction but not the speed.

I’m not sure I have a complete answer but I have some of the pieces.

Start new work with a Minimally Viable Team: task the team to start immediately and in parallel work to understand what is needed and create potential solutions.

Keep teams stable: This contains a lot of variables and provides some past performance data to include in calculations. It will at times be necessary for the teams to call in more help – pull more skills and resources as needed.

By working with existing and minimally viable teams the problems are partially constrained: the technologies available are mostly the technologies the team knows already, the number of people available to work on the work is the number of people on the team. In time you may change both these parameters but initially they are constraints to work within.

Use active portfolio management and governance to kill work which is under performing or escalating beyond expectations.

The next time someone says “Building software should be like building a house” please remind them you aren’t building a house. What software engineers do is massively more variable and complex than building another example of the same thing.

Back at Reuters, the bright side was that the over engineered system we built wasn’t just used for Liffe, it was used to connect 2 or 3 other exchanges too so maybe over staffing was worth it. Except I don’t believe it really made economic sense, it would have been better to get the one exchange working and only add the minimum to the system when the second and third exchanges came along – diseconomies of scale again.


Subscribe to my blog and download Continuous Digital for free – normal price $9.99/£9.95/€9.95

The post Software is not a lump or work to do (and the laws which prove it) appeared first on Allan Kelly Associates.

Visual Studio 2022 Preview 1 is now available

Ever since news broke in April of Microsoft's plans for Visual Studio 2022 we have been waiting to get our hands on a preview build of the new version.

The first public preview was finally released on 17th June, so naturally we have spent the past few days taking a look to see what we need to do - both to analyse codebases using it and to update our existing Visual Lint and ResOrg plugins to integrate within it.


From what I can see, Visual Studio 2022 Preview 1 seems to use Visual Studio 2019 project files (the platform toolset is still v142, and _MSC_VER is still 1929). I've no doubt that will change in subsequent preview versions.

However, unlike its predecessor Visual Studio 2019, Visual Studio 2022 is a fully 64 bit development environment (although VS2019 and its predecessors can compile and debug 64 bit projects, the IDEs themselves are firmly 32 bit).

As such it follows that plugins for Visual Studio 2022 must also be compiled as 64 bit. Although the plug-in architecture is not changing in VS2022 (see The Future of Visual Studio Extensions), the move to 64 bit is a very significant change in itself.

For our Visual Studio plugin to run within Visual Studio 2022, what we have to do is basically:

  • Recompile the existing plugins to target the x64 platform, using the new (VS2022 specific) 64 bit Visual Studio COM interfaces and the new (and also VS2022 specific) version of the Visual Studio SDK.

  • Add Visual Studio 2022 specific VSIX packages to deploy the x64 version of the plugins.

  • Update the installers to recognise Visual Studio 2022 and install the new x64 version of the plugin.

  • Try really, really hard not to break support for earlier Visual Studio versions in the process (those cannot load 64 bit plugins, so the existing 32 bit versions still have to be maintained).

The full details of all of the changes involved are somewhat beyond the scope of this blogpost, but suffice it to say we have already started preparing to port the code to Visual Studio 2022 and expect that to keep us busy over the summer.

(well, it's not as if anyone can really go on holiday right now, is it?)

The screenshots below show Visual Studio 2022 Preview 1 with an AppWizard generated C++ VSIX extension project loaded and running. Note that I had to make a couple of minor corrections to the generated project and property files to get it to compile and link.

VS2022 IDE screenshotAn AppWizard generated VS2022 extension project loaded inside Visual Studio 2022 Preview 1. VS2022 plug-in project runningAn AppWizard generated VS2022 extension project running inside an experimental instance of Visual Studio 2022 Preview 1.

Visual Studio 2022 Preview 1

Ever since news broke in April of Microsoft's plans for Visual Studio 2022 we have been waiting to get our hands on a preview build of the new version.

The first public preview was finally released on 17th June, so naturally we have spent the past few days taking a look to see what we need to do - both to analyse codebases using it and to update our existing Visual Lint and ResOrg plugins to integrate within it.


From what I can see, Visual Studio 2022 Preview 1 seems to use Visual Studio 2019 project files (the platform toolset is still v142, and _MSC_VER is still 1929). I've no doubt that will change in subsequent preview versions.

However, unlike its predecessor Visual Studio 2019, Visual Studio 2022 is a fully 64 bit development environment (although VS2019 and its predecessors can compile and debug 64 bit projects, the IDEs themselves are firmly 32 bit).

As such it follows that plugins for Visual Studio 2022 must also be compiled as 64 bit. Although the plug-in architecture is not changing in VS2022 (see The Future of Visual Studio Extensions), the move to 64 bit is a very significant change in itself.

For our Visual Studio plugin to run within VS2022, what we have to do is basically:

  • Recompile the existing plugins to target the x64 platform, using the new (VS2022 specific) 64 bit Visual Studio COM interfaces and the new (and also VS2022 specific) version of the Visual Studio SDK.

  • Add Visual Studio 2022 specific VSIX packages to deploy the x64 version of the plugins.

  • Update the installers to recognise VS2022 and install the new x64 version of the plugin.

  • Try not to break support for earlier Visual Studio versions in the process (those cannot load 64 bit plugins, so the existing 32 bit versions will still have to be maintained).

The full details of all of the changes involved are somewhat beyond the scope of this blogpost, but suffice it to say we have already started preparing to port the code to VS2022 and expect that to keep us busy over the summer.

(well, it's not as if anyone can really go on holiday right now, is it?)

The screenshots below show VS2022 Preview 1 with an AppWizard generated C++ VSIX extension project loaded and running. Note that I had to make a couple of minor corrections to the generated project and property files to get it to compile and link.

VS2022 IDE screenshotAn AppWizard generated VS2022 extension project loaded inside Visual Studio 2022 Preview 1. VS2022 plug-in project runningAn AppWizard generated VS2022 extension project running inside an experimental instance of Visual Studio 2022 Preview 1.

Visual Studio 2022 Preview 1

Ever since news broke in April of Microsoft's plans for Visual Studio 2022 we have been waiting to get our hands on a preview build of the new version.

The first public preview was finally released on 17th June, so naturally we have spent the past few days taking a look to see what we need to do - both to analyse codebases using it and to update our existing Visual Lint and ResOrg plugins to integrate within it.


From what I can see, Visual Studio 2022 Preview 1 seems to use Visual Studio 2019 project files (the platform toolset is still v142, and _MSC_VER is still 1929). I've no doubt that will change in subsequent preview versions.

However, unlike its predecessor Visual Studio 2019, Visual Studio 2022 is a fully 64 bit development environment (although VS2019 and its predecessors can compile and debug 64 bit projects, the IDEs themselves are firmly 32 bit).

As such it follows that plugins for Visual Studio 2022 must also be compiled as 64 bit. Although the plug-in architecture is not changing in VS2022 (see The Future of Visual Studio Extensions), the move to 64 bit is a very significant change in itself.

For our Visual Studio plugin to run within VS2022, what we have to do is basically:

  • Recompile the existing plugins to target the x64 platform, using the new (VS2022 specific) 64 bit Visual Studio COM interfaces and the new (and also VS2022 specific) version of the Visual Studio SDK.

  • Add Visual Studio 2022 specific VSIX packages to deploy the x64 version of the plugins.

  • Update the installers to recognise VS2022 and install the new x64 version of the plugin.

  • Try not to break support for earlier Visual Studio versions in the process (those cannot load 64 bit plugins, so the existing 32 bit versions will still have to be maintained).

The full details of all of the changes involved are somewhat beyond the scope of this blogpost, but suffice it to say we have already started preparing to port the code to VS2022 and expect that to keep us busy over the summer.

(well, it's not as if anyone can really go on holiday right now, is it?)

The screenshots below show VS2022 Preview 1 with an AppWizard generated C++ VSIX extension project loaded and running. Note that I had to make a couple of minor corrections to the generated project and property files to get it to compile and link.

VS2022 IDE screenshotAn AppWizard generated VS2022 extension project loaded inside Visual Studio 2022 Preview 1 VS2022 plug-in project runningAn AppWizard generated VS2022 extension project running inside an experimental instance of Visual Studio 2022 Preview 1

Production of software may continue to be craft based

Andrew Carnegie made his fortune in the steel industry, and his autobiography is a fascinating insight into the scientific vs. craft/folklore approach to smelting iron ore. Carnegie measured the processes involved in smelting; he tracked the input and outputs involved in the smelting process, and applied the newly available scientific knowledge (e.g., chemistry) to minimize the resources needed to extract iron from ore. Other companies continued to treat Iron smelting as a suck-it-and-see activity, driven by personal opinion and the application of techniques that had worked in the past.

The technique of using what-worked-last-time can be a successful strategy when the variability of the inputs is low. In the case of smelting Iron there was a lot of variability in the Iron ore, Limestone and Coke fed into the furnaces. The smelting companies in Carnegie’s day ‘solved’ this input variability problem by restricting their purchase of raw materials to mines that delivered material that worked last time.

Hiring an experienced chemist (the only smelting company to do so), Carnegie found out that the quality of ore (i.e., percentage Iron content) in some mines with a high reputation was much lower than the ore quality of some mines with a low reputation; Carnegie was able to obtain a low price for high quality ore because other companies did not appreciate its characteristics (and shunned using it). Other companies were unable to extract Iron from high quality ore because they stuck to using a process that worked for lower quality ore (the amount of Limestone and Coke added to the smelting process has to be adjusted based on the Iron content of the ore, otherwise the process may deliver poor results, or even fail to produce Iron; see chapter 13).

When Carnegie’s application of scientific knowledge, and his competitors’ opinion driven production, is combined with being a good businessman, it’s no surprise that Carnegie made a fortune from his Iron smelting business.

What are the parallels between iron smelting in Carnegie’s day and the software industry?

An obvious parallel is the industry dominance of opinion driven processes. But then, the lack of any scientific basis for the processes involved in building software systems would seem to make drawing parallels a pointless exercise.

Let’s assume that there was a scientific basis for some of the major processes involved in software engineering. Would any of these science-based processes be adopted?

The reason for using science based knowledge and mechanization is to reduce costs, which may lead to increased profits or just staying in business (in a Red Queen’s race).

Agriculture is an example of a business where science and mechanization dominate, and building construction is a domain where this has not happened. Perhaps building construction will become more mechanized when unknown missing components become available (mechanization was available for agricultural processes in the 1700s, but they did not spread for a century or two, e.g., threshing machines).

It’s possible to find parallels between software engineering and the smelting process, agriculture, and building construction. In fact, it parallels can probably be found between software engineering and any other major business domain.

Drawing parallels between software engineering and other major business domains creates a sense of familiarity. In practice, software is unlike most existing business domains in that software products are one-off creations of an intangible good, which has (virtually) zero cost of reproduction, while the economics of creating tangible goods (e.g., by smelting, sowing and reaping, or building houses) is all about reducing the far from zero cost of reproduction.

Perhaps the main take-away from the history of the production of tangible goods is that the scientific method has not always supplanted the craft approach to production.

Mixing It Up – a.k.

Last year we took a look at basis function interpolation which fits a weighted sum of n independent functions, known as basis functions, through observations of an arbitrary function's values at a set of n points in order to approximate it at unobserved points. In particular, we saw that symmetric probability density functions, or PDFs, make reasonable basis functions for approximating both univariate and multivariate functions.
It is quite tempting, therefore, to use weighted sums of PDFs to construct new PDFs and in this post we shall see how we can use a simple probabilistic argument to do so.

Why write an entire game (including Graphics) in a single, hand-coded JavaScript file?

My new game, Rightwaves, is out now! It’s a tribute to the great classic R-Type.

A pixel-art spaceship battles aliens

The entire implementation, including all the graphics, is contained within a single ~5000-line JavaScript file. Why?

This is a terrible idea

Let me start by saying I do not recommend writing code this way. It’s a terrible idea, and some aspects of the development process have been severely hampered by doing this.

A pixellated spaceship dodges bullets and heads for a narrow passageway

Complexity

One of my goals for Smolpxl is to strip coding back to the simplest possible thing it can be.

Over the last 40 years, programming has changed a huge amount: the number and variety of the tools we have to work with has increased beyond what I can take in, and almost all of these things are utterly brilliant.

I can’t imagine writing a game like Eat Apples Quick using the line-orientated editor I used on the ZX Spectrum. I thoroughly enjoyed the Rust code completion and documentation I get from running rust-language-server inside NeoVim. (I’ve even heard there are editors that work inside a windowed environment, but I am not brave enough to try one.)

A pacman-like game

I can’t imagine writing the simple physics engine for Spring in assembly language, or trying to concentrate on that while I had to unravel complex graphics rendering conventions and timings. Instead, I was able to write code that looked a bit like the maths it represented, and allow the browser to handle the graphics card.

A spring with a cheery face bounces off a platform

But, along with all these powerful tools like high-level programming languages, fully cross-platform user interface components, and libraries that make writing a game loop simple, comes a new problem: complexity.

We must choose which tools, libraries and paradigms we’re going to use, and to make that choice we need to understand them.

The Smolpxl library makes some of these choices for you, by enforcing an Elm-style model/update/view split, providing a pixellated canvas of known size, and handling a game loop with fixed framerate. This is particularly suited to writing little retro-style games, similar to what I used to write in AMOS Basic on my Amiga.

I want to make everything simple, but I want our game to work on people’s computers. The only platform we can realistically choose is the browser: the exact same code works almost everywhere.

None of this explains why I would write a game inside a single file of source code, but hopefully it begins to demonstrate where I am coming from.

Simplicity

Another goal for Smolpxl is to teach programming, and a huge barrier I see to getting started is the build process.

No build

You can write Smolpxl games in Rust and compile them to WASM (which is how Eat Apples Quick is done), and you could also package the JavaScript with webpack or similar, but I want the first-class way of using Smolpxl to involve no build at all: I want you to be able to copy in a standard index.html and smolpxl.js and then write your code in game.js and have it just work when you double-click on index.html.

A goal for Rightwaves is to demonstrate that you can write a full game in Smolpxl, without stepping outside that simple story: just double-click on index.html.

It’s all inside game.js

So, Rightwaves is a single* JavaScript file containing the code, the level descriptions, and, probably most unusually, the graphics.

* Note: I cheated – the “action-replay” data is in a separate file – it was much bigger than the source code, and would have made it too hard to deal with. If I wanted to stay pure, I would have had to remove the default action replay from the game, but I just liked it too much.

Level design

Many times while I was writing Rightwaves, I wished I had written a level editor. In fact, I am often quoted as saying

“A game without a level editor is only half a game.”
— Andy Balaam, quite often

But instead, the level design is code like this:

const LEVELS = [
    {
        scenery: [
            { x:   0, y: 80, image: "machinery-20x16-01"},
            { x:  20, y: 88, image: "machinery-20x08-01"},
// ... etc.
        ],
        width: 1526,
        aliens: [
            newRedFlat(130, 20),
            newRedFlat(145, 25),
// ... etc.

The full code is at gitlab.com/smolpxl/rightwaves/-/blob/main/public/game.js#L3478.

It’s not a lot of fun to edit, but on the other hand, every time you make a change a simple refresh in the browser lets you see what it really looks like. No build process; no waiting.

Graphics

I drew the graphics for Rightwaves using GIMP, exported the images as PNG files, and converted them to text using a little Rust utility I wrote.

When I wanted to change an image, it was a nightmare, and I would recommend this approach to no-one whatsoever.

The reason why Smolpxl supports creating images in the source code is so you can hand-craft them right there, using an ASCII-art style.

Here’s the spaceship: An ASCII-art spaceship

and here is the code for it:

const IMAGES = {
    "ship": {
        pixels: [
            "..www.......",
            "dddddww.bbb.",
            "rllldddcccwb",
            "dddhlllccccb",
            "rddddddaccb.",
            "..aaa......."
        ],
        key: {
            "w": [255, 255, 255],
            "d": [88, 88, 88],
            "b": [77, 111, 249],
            "r": [141, 0, 0],
            "l": [126, 125, 125],
            "h": [192, 192, 192],
            "c": [3, 157, 157],
            "a": [42, 42, 42]
        }
    },
// ... lots, and I do mean lots, more here for the other graphics ...

The full code is at gitlab.com/smolpxl/rightwaves/-/blob/main/public/game.js#L41.

Note that I painstakingly coloured that code in for you, for this blog post. In the code there is no such luxury!

Openness

All the Smolpxl games are Free/Open Source software, of course. By avoiding a build, anyone can see the source code, just as I wrote, it in their browser. Anyone (including me) can debug problems without any extra steps. Putting everything in one file makes it easier to find the code (but probably makes it harder to understand).

Optimisation

Rightwaves loads really fast. On my machine, the first time you visit the page, it is playing within 1.4 seconds, after downloading 5 files at a total of 149kB (gzipped). If we exclude the included action replay, it is much smaller.

All of this, with no build process.

Maybe it wasn’t such a bad idea after all.

This is a bad idea

Don’t try this.

For fun

Except, of course, if you like fun. I tried this because it was fun. I would heartily recommend trying things because they might be fun.

Also, if you like fun, try playing the games on Smolpxl games, or write your own!

A puzzle game, a cross-the-road game, a tunnel game, a snake game, a Heli game, and a game-of-life thingy

New online tutorial: User Stories

This blog and my email updates have been quiet lately because I’ve been working on some online tutorial (in addition to working with clients!).

These tutorials differ from my earlier work in that they are autonomous, self-paced, async – I’m not there! – truly online.

Just my voice, my slides, my exercises and my wisdom.

At the moment there are two tutorial, “User Stories by Example” part 1 – an introduction and part 2 which looks specifically at acceptance criteria. Both use actual user stories I’ve collected over the years and both are derived from the online interactive workshops I ran during lockdown last year. Those workshops were themselves based on a physical workshop I’ve been running for several years, which in turn is based on my Little Book of Requirements and User Stories book.

I have plans for more tutorials covering user story refactoring stories (i.e. improving existing stories), story lifecycle and workflow, splitting stories and appreciating value. First I’ll wait for more feedback on these first two.

I’ve set introductory pricing at $59 and $49 (USD) but I expect those prices to rise as I add more modules. Part includes both the e-book and audio book version of Little Book.

Blog readers can get another 20% off with the coupon code “blogdiscount” until the end of July.

I’d love to get your feedback on these course so if you try one please complete the survey at the end and e-mail me if you have other comments. And if these courses are not for you, well, please e-mail me anyway and tell me what you would like to see me produce next.

The post New online tutorial: User Stories appeared first on Allan Kelly Associates.

Visual Lint 8.0.2.338 has been released

Visual Lint 8.0.2.338 has now been released. This a recommended maintenance update for Visual Lint 8.0, and includes the following changes:

  • Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file `co-rb-vs2019.lnt to support Visual Studio 2019 v16.10.0.

  • Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-vs2017.lnt to support Visual Studio 2017 v15.9.36.

  • Project (e.g. $(ConfigName) or ${ConfigName}) and environment (e.g. %COMPUTERNAME%) variables can now be used in the values of the "Analysis configuration" [PC-lint/PC-lint Plus], "Warning policy" [PC-lint/PC-lint Plus] and "Generate reports in..." properties of a solution/project specific analysis configuration. [Visual Lint Professional and Enterprise Editions]

  • Project (e.g. $(ConfigName) or ${ConfigName}) and environment (e.g. %COMPUTERNAME%) variables can now be used in the values of the "Analysis tool installation folder", "Analysis tool executable", "When solution analysis completes..." and "Post-process PC-lint indirect (project.lnt) files after generation..." properties of a solution/project specific analysis configuration. [Visual Lint Enterprise Edition]

  • Fixed a bug in the implementation of the Solution/Project Analysis Configuration Dialog "Analysis tool executable" property. [Visual Lint Enterprise Edition]

  • Fixed a bug in the implementation of the Solution/Project Analysis Configuration Dialog "Warning policy" property. [PC-lint/PC-lint Plus] [Visual Lint Professional and Enterprise Editions]

  • Modified the Visual Studio plug-in to prevent duplicated entries for projects from appearing in the Analysis Status Display (this could be caused by the IDE sourcing duplicated "ProjectAdded" events, and these are now filtered out).

  • The Configuration Wizard "Analysis Tools" page no longer allows multiple analysis tools to be selected.

Download Visual Lint 8.0.2.338

Visual Lint 8.0.2.338 has been released

Visual Lint 8.0.2.338 has now been released. This a recommended maintenance update for Visual Lint 8.0, and includes the following changes:

  • Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file `co-rb-vs2019.lnt to support Visual Studio 2019 v16.10.0.

  • Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-vs2017.lnt to support Visual Studio 2017 v15.9.36.

  • Project (e.g. $(ConfigName) or ${ConfigName}) and environment (e.g. %COMPUTERNAME%) variables can now be used in the values of the "Analysis configuration" [PC-lint/PC-lint Plus], "Warning policy" [PC-lint/PC-lint Plus] and "Generate reports in..." properties of a solution/project specific analysis configuration. [Visual Lint Professional and Enterprise Editions]

  • Project (e.g. $(ConfigName) or ${ConfigName}) and environment (e.g. %COMPUTERNAME%) variables can now be used in the values of the "Analysis tool installation folder", "Analysis tool executable", "When solution analysis completes..." and "Post-process PC-lint indirect (project.lnt) files after generation..." properties of a solution/project specific analysis configuration. [Visual Lint Enterprise Edition]

  • Fixed a bug in the implementation of the Solution/Project Analysis Configuration Dialog "Analysis tool executable" property. [Visual Lint Enterprise Edition]

  • Fixed a bug in the implementation of the Solution/Project Analysis Configuration Dialog "Warning policy" property. [PC-lint/PC-lint Plus] [Visual Lint Professional and Enterprise Editions]

  • Modified the Visual Studio plug-in to prevent duplicated entries for projects from appearing in the Analysis Status Display (this could be caused by the IDE sourcing duplicated "ProjectAdded" events, and these are now filtered out).

  • The Configuration Wizard "Analysis Tools" page no longer allows multiple analysis tools to be selected.

Download Visual Lint 8.0.2.338

Increase in defect fixing costs with distance from original mistake

During software development, when a mistake has been made it may be corrected soon after it is made, much later during development, by the customer in a shipped product, or never corrected.

If a mistake is corrected, the cost of correction increases as the ‘distance’ between its creation and detection increases. In a phased development model, the distance might be the number of phases between creation and detection; in a throw it at the wall and see if it sticks development model, the distance might be the number of dependencies on the ‘mistake’ code.

There are people who claim that detecting mistakes earlier will save money. This claim overlooks the cost of detecting mistakes, and in some cases earlier detection is likely to be more expensive (or the distribution of people across phases may rate limit what can be done in any phase). For instance, people might not be willing to read requirements documents, but be willing to try running software; some coding mistakes are only going to be encountered later during integration test, etc.

Folklore claims of orders of magnitude increases in fixing cost, as ‘distance’ increases, have been shown to be hand waving.

I know of two datasets on ‘distance’ between mistake creation and detection. A tiny dataset in Implementation of Fault Slip Through in Design Phase of the Project (containing only counts information; also see figure 6.41), and the CESAW dataset.

The plot below shows the time taken to fix 7,000 reported defects by distance between phases, for CESAW project 615 (code+data). The red lines are fitted regression models of the form fixTime approx sqrt{phaseDistance}, for minimum fix times of 1, 5 and 10 minutes:

Time taken to fix reported defect by distance between inserted/detected phases.

The above plot makes various simplifying assumptions, including: ‘sub-phases’ being associated with a ‘parent’ phase selected by your author, and the distance between all pairs of adjacent phase is the same (in terms of their impact on fix time).

A more sophisticated data model might change the functional form of the fitted regression model, but is unlikely to remove the general upward trend.

There are lots of fix times taking less than five minutes. Project 615 developed safety critical software, and so every detected mistake was recorded; on other projects, small mistakes would probably been fixed without an associated formal record.

I think that, if it were not for the, now discredited, folklore claiming outsized relative costs for fixing reported defects at greater ‘distances’ from the introduction of a mistake, this issue would be a niche topic.

Evidence-based book: six months of downloads

When my C book was first made available as a freely downloadable pdf, in 2005, there were between 19k to 37k downloads in the first week. The monthly download rate remained stable at around 1k for several years, and now floats around 100 per month.

I was hoping to have many more downloads for my Evidence-based software engineering book. The pdf became available last year on November 8th, and there were around 10k downloads in the first week. Then a link to my blog post announcing the availability of the book was posted to news.ycombinator. That generated quarter million downloads of the pdf, with an end-of-month figure of 275,309 plus 16,135 for the mobile friendly version.

The initial release did not include a mobile friendly version. After a half-a-dozen or so requests in various forums, I quickly worked up a mobile friendly pdf (i.e., the line length was reduced to be visually readable on a mobile phone, or at least on my 7-year-old phone which is smaller than most).

In May a link to the book’s webpage was posted on news.ycombinator. This generated 125k+ downloads, and the top-rated comment was that this was effectively a duplicate of the November post.

The plot below shows the number of pdf downloads for A4 and mobile formats, along with the number of kilo-bytes downloaded, for the 6-months since the initial release (code+data):

Downloads of A4 and mobile pdf over 6-months.

On average, there are five A4 downloads per mobile download (excluding November because of the later arrival of a mobile friendly version).

A download is rarely a complete copy (which is 23Mbyte), with the 6-month average being 1.7M for A4 and 2.5M for mobile. I have no idea of the reason for this difference.

The bytes per download is lower in the months when the ycombinator activity occurred. Is this because the ycombinator crowd tend to skim content (based on some of the comments, I suspect that many comments never read further than the cover)?

Copies of the pdf were made available on other sites, but based on the data I have seen, the downloads were not more than a few thousand.

I have not had any traffic spikes caused by non-English language interest. The C book experienced a ‘China’ spike, and I emailed the author of the blog post that caused it, to notify him of the Evidence-based book; he kindly posted an article on the book, but this did not generate a noticeable spike.

I’m confident that eventually a person in China/Russia/India/etc, with tens of thousands of followers, will post a link and there will be a noticeable download spike from that region.

What was the impact of content delivery networks and ISP caching? I have no idea. Pointers to write-ups on the topic welcome.

Further On A Clockwork Contagion – student

When last we spoke, I told you of my fellow students' and my first attempt at employing Professor B------'s wondrous computational engine to investigate the statistical properties of the spread of disease; a subject that we had become most curious about whilst confined to our quarters during the epidemic earlier this year. You will no doubt recall that our model assumed that once someone became infected their infectiousness would persist indefinitely, which is quite contrary to the nature of the outbreak. We have since added incubation, recovery and immunity and it is upon these refinements that I shall now report.

The CESAW dataset: a brief introduction

I have found that the secret for discovering data treasure troves is persistently following any leads that appear. For instance, if a researcher publishes a data driven paper, then check all their other papers. The paper: Composing Effective Software Security Assurance Workflows contains a lot of graphs and tables, but no links to data, however, one of the authors (William R. Nichols) published The Cost and Benefits of Static Analysis During Development which links to an amazing treasure trove of project data.

My first encounter with this data was this time last year, as I was focusing on completing my Evidence-based software engineering book. Apart from a few brief exchanges with Bill Nichols the technical lead member of the team who obtained and originally analysed the data, I did not have time for any detailed analysis. Bill was also busy, and we agreed to wait until the end of the year. Bill’s and my paper: The CESAW dataset: a conversation is now out, and focuses on an analysis of the 61,817 task and 203,621 time facts recorded for the 45 projects in the CESAW dataset.

Our paper is really an introduction to the CESAW dataset; I’m sure there is a lot more to be discovered. Some of the interesting characteristics of the CESAW dataset include:

  • it is the largest publicly available project dataset currently available, with six times as many tasks as the next largest, the SiP dataset. The CESAW dataset involves the kind of data that is usually encountered, i.e., one off project data. The SiP dataset involves the long term evolution of one company’s 20 projects over 10-years,
  • it includes a lot of information I have not seen elsewhere, such as: task interruption time and task stop/start {date/time}s (e.g., waiting on some dependency to become available)
  • four of the largest projects involve safety critical software, for a total of 28,899 tasks (this probably more than two orders of magnitude more than what currently exists). Given all the claims made about the development about safety critical software being different from other kinds of development, here is a resource for checking some of the claims,
  • the tasks to be done, to implement a project, are organized using a work-breakdown structure. WBS is not software specific, and the US Department of Defense require it to be used across all projects; see MIL-STD-881. I will probably annoy those in software management by suggesting the one line definition of WBS as: Agile+structure (WBS supports iteration). This was my first time analyzing WBS project data, and never having used it myself, I was not really sure how to approach the analysis. Hopefully somebody familiar with WBS will extract useful patterns from the data,
  • while software inspections are frequently talked about, public data involving them is rarely available. The WBS process has inspections coming out of its ears, and for some projects inspections of one kind or another represent the majority of tasks,
  • data on the kinds of tasks that are rarely seen in public data, e.g., testing, documentation, and design,
  • the 1,324 defect-facts include information on: the phase where the mistake was made, the phase where it was discovered, and the time taken to fix.

As you can see, there is lots of interesting project data, and I look forward to reading about what people do with it.

Once you have downloaded the data, there are two other sources of information about its structure and contents: the code+data used to produce the plots in the paper (plus my fishing expedition code), and a CESAW channel on the Evidence-based software engineering Slack channel (no guarantees about response time).

Online Concurrency Workshop at C++ on Sea 2021

The restrictions brought upon us by COVID-19 are not over yet, and C++ on Sea is the latest conference that will be running as an online-only conference.

I will be running my More Concurrent Thinking class as an online workshop for C++ on Sea on 30th June and 1st July 2021.

The workshop will run from 09:30 UTC to 18:15 UTC each day. For attendees from North and South America, this is likely quite an early morning, and may be a late night for attendees from the far East, so please check the times in your local timezone.

Tickets include the full day of "normal" conference presentations on 2nd July 2021. Get yours from the C++ On Sea tickets page.

I hope to see you there!

Posted by Anthony Williams
[/ news /] permanent link
Tags: , , ,
Stumble It! stumbleupon logo | Submit to Reddit reddit logo | Submit to DZone dzone logo

Comment on this post

Follow me on Twitter

Impact of native language on variable naming

When creating a variable name, to what extent are developers influenced by their native human language?

There is lots of evidence that variable names are either English words, abbreviations of English words, or some combination of these two. Source code containing a large percentage of identifiers using words from other languages does exist, but it requires effort to find; there is a widely expressed view that source should be English based (based on my experience of talking to non-native English speakers, and even the odd paper discussing the issue, e.g., Language matters).

Given that variable names can prove information that reduces the effort needed to understand code, and that most code is only ever read by the person who wrote it, developers should make the most of their expertise in using their native language.

To what extent do non-native English-speaking developers make use of their non-English native language?

I have found it very difficult to even have a discussion around this question. When I broach the subject with non-native English speakers, the response is often along the lines of “our develo0pers speak good English.” I am careful to set the scene by telling them of my interest in naming, and that I think there are benefits for developers to make use of their native language. The use of non-English languages in software development is not yet a subject that is open for discussion.

I knew that sooner or later somebody would run an experiment…

How Developers Choose Names is another interesting experiment involving Dror Feitelson (the paper rather confusingly refers to it as a survey, a post on an earlier experiment).

What makes this experiment interesting is that bilingual subjects (English and Hebrew) were used, and the questions were in English or Hebrew. The 230 subjects (some professional, some student) were given a short description and asked to provide an appropriate variable/function/data-structure name; English was used for 26 of the question, and Hebrew for the other 21 questions, and subjects answered a random subset.

What patterns of Hebrew usage are present in the variable names?

Out of 2017 answers, 14 contained Hebrew characters, i.e., not enough for statistical analysis. This does not mean that all the other variable names were only derived from English words, in some cases Hebrew words appeared via transcription using the 26 English letters. For instance, using “pinuk” for the Hebrew word that means “benefit” in English. Some variables were created from a mixture of Hebrew and English words, e.g., deservedPinuks and pinuksUsed.

Analysing this data requires someone who is fluent in Hebrew and English. I am not a fluent, or even non-fluent, Hebrew speaker. My role in this debate is encouraging others, and at last I have some interesting data to show people.

The paper spends time showing how for personal preferences result in a wide selection of names being chosen by different people for the same quantity. I cannot think of any software engineering papers that have addressed this issue for variable names, but there is lots of evidence from other fields; also see figure 7.33.

Those interested in searching source code for the impact of native-language might like to look at the names of variables appearing as operands of the bitwise and logical operators. Some English words occur much more frequently in the names of these variable, compared to variables that are operands of arithmetic operators, e.g., flag, status, and signal. I predict that non-native English-speaking developers will make use of corresponding non-English words.

A PR Exercise – a.k.

In the last few posts we've been looking at the BFGS quasi-Newton algorithm for minimising multivariate functions. This uses iteratively updated approximations of the Hessian matrix of second partial derivatives in order to choose directions in which to search for univariate minima, saving the expense of calculating it explicitly. A particularly useful property of the algorithm is that if the line search satisfies the Wolfe conditions then the positive definiteness of the Hessian is preserved, meaning that the implied locally quadratic approximation of the function must have a minimum.
Unfortunately for large numbers of dimension the calculation of the approximation will still be relatively expensive and will require a significant amount of memory to store and so in this post we shall take a look at an algorithm that only uses the vector of first partial derivatives.

Pomodoros worked during a day: an analysis of Alex’s data

Regular readers know that I am always on the lookout for software engineering data. One search technique is to feed a ‘magic’ phrase into a search engine, this can locate data hiding in plain sight. This week the magic phrase: “record of pomodoros” returned pages discussing two collections of daily Pomodoros worked, each over a year, plus several possible collections, i.e., not explicitly stated. My email requests for data have so far returned one of the collections, kindly made available by Alex Altair, and this post discusses Alex’s data (I have not discussed the data with Alex, who I’m hoping won’t laugh too loud at the conclusions I have reached).

Before analyzing data I always make predictions about what I expect to see. I know from the email containing the data that it consisted of two columns: date and Pomodoro’s worked, i.e., no record of task names. The first two predictions for this data were the two most common patterns seen in estimation data, i.e., use of round numbers, and a weekend-effect (most people don’t work during the weekend and the autocorrelation of the daily counts contain peaks at lags of 6 and 7). The third prediction was that over time the daily total Pomodoro counts would refine into counts for each of the daily tasks (I had looked at the first few lines of the data and seen totals for the daily Pomodoros worked.

The Renzo Pomodoro dataset is my only previous experience analysing Pomodoro data. Renzo created a list of tasks for the day, estimated the number of Pomodoros for each task would take, and recorded how many it actually took. For comparison, the SiP effort estimation dataset estimates software engineering tasks in hours.

Alex uses Pomodoros as a means of focusing his attention on the work to be done, and the recorded data is a measure of daily Pomodoro work done.

I quickly discovered that all my predictions were wrong, i.e., no obvious peaks showing use of round numbers, no weekend effect, and always daily totals. Ho-hum.

The round number effect is very prominent in estimates, but is not always visible in actuals; unless people are aiming to meet targets or following Parkinson’s law.

How many days had one Pomodoro worked, how many two Pomodoro, etc? The plot below shows the number of days for which a given number of Pomodoros were worked (the number of days with zero Pomodoros is not shown); note the axis are log scaled. The blue points are for all days in 2020, and the green points are all days in 2020+178 days of 2021. The red lines are two sets of two fitted power laws (code+data):

Number of days on which a given number of Pomodoros were worked, with fitted power laws.

Why the sudden change of behavior after seven Pomodoro? Given a Pomodoro of 25-minutes (Alex says he often used this), seven of them is just under 3-hours, say half a day. Perhaps Alex works half a day, for every day of the week.

Why the change of behavior since the end of 2020 (i.e., exponent of left line changes from 0.3 to -0.1, exponent of right line is -3.0 in both cases)? Perhaps Alex is trying out another technique. The initial upward trend is consistent with the Renzo Pomodoro dataset.

The daily average Pomodoros worked is unchanged at around 5.6. The following plot shows daily Pomodoros worked over the 543 days, red line is a fitted loess model.

Daily Pomodoros worked over 543 days.

The weekend effect might not be present, but there is a strong correlation between adjacent days (code+data). The best fitting ARIMA model gives the equation: P_t=0.37+0.93*P_{t-1}+w_t-0.74*w_{t-1}, where: P_t is the Pomodoros worked on day t, P_{t-1} Pomodoros worked on the previous day, w_t is white noise (e.g., a Normal distribution) with a zero mean and a standard deviation of 4 (in this case) on day t, and w_{t-1} the previous day’s noise (see section 11.10 of my book for technical time series details).

This model is saying that the number of Pomodoros worked today is strongly influenced by yesterday’s Pomodoro worked, modulated by a large random component that could be large enough to wipe out the previous days influence. Is this likely to be news to Alex, or to anybody looking at the plot of Pomodoros over time? Probably not.

For me, the purpose of data analysis is to find patterns of behavior that are of use to those involved in the processes that generated the data (for many academics, at least in software engineering, the purpose appears to be to find patterns that can be used to publish papers, and given enough searching, it is always possible to find patterns in data). What patterns of behavior might Alex be interested in?

Does more Pomodoro work get done at the start of the week, compared to the end of the week? The following heatmap is based on the number of week days on which a given number of Pomodoros were worked. The redder the region, the more likely that value is likely to occur (code+data):

Heatmap of number of days on which a given number of Pomodoros were worked on a given day of the week.

There are certainly more days near the end of the week having little or no Pomodoro work, and the high Pomodoro work days appear to be nearer the start of the week. I need to find a statistical technique that quantifies these observations.

I think that the middle plot is the most generally useful, it illustrates how variable the work done during a day can be.

Is Alex’s Pomodoro work typical or unusual? We will have to wait for a lot more data before that question can be addressed.

If you are a Pomodoro user, and have ideas for possible patterns in the data, please let me know.

As always, pointers to more data, Pomodoro or otherwise, most welcome.

Matrix is the only (chat) game in town

On my phone and computer I use WhatsApp, Signal, Slack, Keybase, Discord, IRC, XMPP/Jabber and Element/Matrix. In addition, I occasionally use the messaging features of Mastodon, Twitter and even LinkedIn. I’ve never used Telegram, Line, WeChat, Session, Wire or Status chat, but they exist too, along with many others.

It would be better if I could chat with people using the app I prefer, rather than the one I am forced to use.

Of course, the only useful chat app is the one your friends and family are on, so it’s pointless to debate the finer points in each service’s favour, but here I go anyway.

Only Matrix is:

The importance of decentralisation has been re-emphasised for me this week after the freenode IRC debacle. A single controlling entity, even when it is currently benign (as some people believe Signal is) is not a guarantee that things will stay this way. Thank goodness you can connect your usual IRC network to libera.chat: imagine what would happen to Signal users if they realised someone unscrupulous had acquired control.

Matrix does not solve all our problems. Notably:

  • Its security is probably not good enough for people threatened by powerful interests – at the moment it’s quite easy to see who’s talking to whom, and when.
  • Not all clients support end-to-end encryption, and not all turn it on by default (but the most-used ones do).

Despite these limitations, Matrix is the only chat network that is even attempting to provide what users need, and it seems to be doing a pretty good job of it.

I think we should work together to address its weaknesses, and adopt it wherever we can.

So, I recommend Matrix (specifically element.io) for group and individual chat.

Cascading OKRs and White Space OKRs

A couple of weeks ago I blogged about the top-down or bottom-up question – “OKRs top-down? bottom-up? or ripples on a pond?”

The idea of top-down OKRs keeps cropping up: it needs a name. So please let me introduce Cascading OKRs, or C-OKRs for short.

I only just invented the term so I don’t use it in Succeeding with OKRs in Agile – although I do warn against the idea. The meme is in books and blogs I’ve read, in podcasts I’ve heard and it comes up again and again in Q&A sessions when I do presentations.

The Cascading OKRs idea goes like this: the people at the top of the organisation set OKRs. These are shared with people and teams “below” them. Those teams then write OKRs to support the delivery of the those above them. Their OKRs are in turn shared with “lower” individuals and teams who repeat the processes.

I’ve even heard it suggested that teams take the OKRs from above and use the key results as their objective(s). The key results they create around these objectives can then be used by “lower” teams as their objectives. Hence OKRs cascade down the organisation. (And we all know what Cascades look like don’t we?)

Undoubtedly this interpretation has its own logic – both in the top setting the master OKRs and the lower levels implementing them. It is after all functional decomposition. And I must believe from what I hear that some companies do it this way even if I have never seen it myself. One hopes that it works for these companies, I think it can be better.

C-OKRs are incompatible with the agile mindset because it deprives teams of autonomy. Each team must implement the objectives given to them regardless of what the team believes, regardless of what the team’s customers are asking for, irrespective of the research the product owner/manager has done.

In reducing, even eliminating, autonomy motivation is going to fall too, teams are no longer their own masters.

Nor will this way increase agility because each team must move in lockstep – or perhaps one step behind – the team above them. The cascading hierarchy injects delay.

Cascading OKRs may be easy to grasp, they may be easy to sell, they may follow the logic of hierarchy and management-by-objective but that also means they represent a lost opportunity to integrate OKRs and agile.

Having named Cascading OKRs I need to name the alternative: broadly the approach I advocate in Succeeding with OKRs.

I name this approach White Space OKRs, WS-OKRs.

Organisational leaders should set the vision, the big-hairy-audacious-goal, the ultimate objective, the massively transformative purpose. They should name the mission, they should set the culture and talk about the purpose of the organisation.

And they should leave copious amounts of white space – space for teams to fill.

Those visions should be light on how; they should be light on orders, instructions and mandates. That may seem odd but only by leaving these things out – by leaving white space – can individuals and teams, at all levels, decide how best they can support that mission, goal, purpose or whatever you call it. Planning is disabling.

Because teams decide how to support those goals – while supporting existing customers, legacy business and technology, plus other (potentially completing) demands – team retain autonomy, and autonomy creates motivation and flexibility.

There is one more assumption underlying this which deserves mentioning.

White Space OKRs assume that the teams already exist. With WS-OKRs leaders don’t need to create new teams to deliver their goals because those teams already exist. In other words, the organisation is operating a post-projects model, e.g. product teams, continuous digital, Spotify, or maybe SAFe. That raises an issue of gaps and I’ll return to this another day.


Subscribe to my blog newsletter and download Continuous Digital for free – normal price $9.99/£9.95/€9.95


White space photo from Katie Doherty on Unsplash.

The post Cascading OKRs and White Space OKRs appeared first on Allan Kelly Associates.

Sorry about the OKRs

Quick word of appoogy to regular readers who may not be interested in OKRs: sorry for all the posts about OKRs.

Its probably a natural effect of pubishing a book on the subject and then doing a bunch of presentations, webinars, workshops and Q&A sessions. Give me a few weeks and this will pass. Normal service will be resumed, with thoughts on agile, technology and such – I just don’t know when!

The post Sorry about the OKRs appeared first on Allan Kelly Associates.

Where are the industrial strength R compilers?

Why don’t compiler projects for the R language make it into production use? The few that have been written have remained individual experimental products, e.g., RLLVMCompile.

Most popular languages attract many compiler implementations. I’m not saying that any of these implementations have more than a handful of users, that they implement the full language (a full implementation is not common), or that they fulfil any need other than their implementers desire to build something.

A commonly heard reason for the lack of production R compilers is that it is not worth the time and effort, because most of an R program’s time is spent in the library code which is written in a compiled language (e.g., C or Fortran). The fact that it is probably not worth the time and effort has not stopped people writing compilers for other languages, but then I think that the kind of people who use R tend not to be the kind of people who want to spend their time writing compilers. On the whole, they are the kind of people who are into statistics and data analysis.

Is it true that that most R programs spend most of their time executing library code? It’s certainly true for me. But I have noticed that a lot of the library functions executed by my code are written in R. Also, if somebody uses R for all their programming needs (it might be the only language they know), then their code might not be heavily library dependent.

I was surprised to read about Tierney’s byte code compiler, because his implementation is how I thought the R-core’s existing implementation worked (it does now). The internals of R is based on 1980s textbook functional techniques, and like many book implementations of the day, performance is dependent on the escape hatch of compiled code. R’s implementers wisely spent their time addressing user concerns, which revolved around statistics and visual presentation, i.e., not internal implementation technicalities.

Building an R compiler is easy, the much harder and time-consuming part is the runtime system.

Threaded code is a quick and simple approach to compiler implementation. R source gets mapped to a sequence of C function calls, with these functions proving a wrapper to library functions implementing the appropriate basic functionality, e.g., add two vectors. This approach has been the subject of at least one Master’s thesis. Thesis implementations rarely reach production use because those involved significantly underestimate the work that remains to be done, which is usually a lot more than the original implementation.

A simple threaded code approach provides a base for subsequent optimization, with the base having a similar performance to an interpreter. Optimizing requires figuring out details of the operations performed and replacing generic function calls with ones designed to be fast for specific cases, or even better replacing calls with inline code, e.g., adding short vectors of integers. There is a lot of existing work for scripting languages and a few PhD thesis researching R (e.g., Wang). The key technique is static analysis of R source.

Jan Vitek is running what appears to be the most active R compiler research group, at the moment e.g., the Ř project. Research can be good for uncovering language usage and trying out different techniques, but it is not intended to produce industry strength code. Lots of the fancy optimizations in early versions of the gcc C compiler started life as a PhD thesis, with the respective individual sometimes going on to spend a few years creating a production quality version for the released compiler.

The essential ingredient for building a production compiler is persistence. There are an awful lot of details that need to be sorted out (this is why research project code does not directly translate to production code, they ignore ‘minor’ details in order to concentrate on the ‘interesting’ research problem). Is there a small group of people currently beavering away on a production quality compiler for R? If there is, I can understand being discrete, on long-term projects it can be very annoying to have people regularly asking when the software is going to be released.

To have a life, once released, a production compiler needs to attract users, who are often loyal to their current compiler (because they know that their code works for this compiler); there needs to be a substantial benefit to entice people to switch. The benefit of compiling R to machine code, rather than interpreting, is performance. What performance improvement is needed to attract a viable community of users (there is always a tiny subset of users who will pay lots for even small performance improvements)?

My R code is rarely cpu bound, so I am not in the target audience, no matter what the speed-up. I don’t have any insight in the performance problems experienced by the R community, and have no idea whether a factor of two, five, ten or more would be enough.

PG Webhooks Tool (beta) – I want your feedback!


PG Webhooks Tool

https://pg-webhooks.herokuapp.com/

PG Webhooks is a tool designed to help with the testing of webhooks. It allows you to receive and view messages from a webhook until you're ready to setup the server which will receive the real webhooks for your application.

Register the URL uniquely generated for you by PG Webhooks with your webhook. Fire the webhook and see the messages appear. Select each message to see the details, including the body and header.

PG Webhooks sits on a free Heroku instance so may take a few moments to start the first time you use it. It is backed by a non-persistent Redis database, so your messages are only stored temporarily.

PG Webhooks beta is very much a prototype and has plenty of rough edges. I would appreciate any feedback in the comments below. 



The Fours Reawakens – baron m.

Hail Sir R-----! Come join me for a tankard of this rather exceptional spring ale!

Might you also join me in a little sport?

You are, my friend, a most dependable fellow!

I suggest a game that puts me in mind of my second tenure as the Russian military attaché to Coruscant. Some years after I helped the Emperor-Mage Palpatine crush the uprising led by the blasphemous warrior-priests known as Jedi, news reached the Russian court that they were now waging a guerilla campaign against the duly anointed tyrant's armed forces and I was dispatched post haste to lend support once more.

New Profile: Written for a talk on ‘Entrepreneurship’

Husband, father, software engineer, metaller, Paul has been writing software for over 35 years and professionally for more than 20. In that time he has worked for and in all sorts of companies from two man startups to world famous investment banks and insurance companies. He has built and run three limited companies, none of which made him a millionaire and two of which threatened his sanity on more than one occasion.

Paul was a founding member of both SyncNorwich and Norfolk Developers, two of the most successful tech and startup based community groups in the East. He created and chaired the hugely successful Norfolk Developers Conference (nor(DEV):con) for seven years bringing in speakers and delegates in the sphere of software engineering from around the globe.

Paul is currently a Senior Platform Engineer at the Fintech startup Snoop and the founder of the tea finding app, Find My Tea. He loathes the word Entrepreneur, not least because he struggles to spell it and it reminds him of Del Boy from the 80s sitcom Only Fools and Horses. He sees Entrepreneurship as a side effect of the creative process of problem solving, rather than a career path in its own right.

Despite having dealt with the world of business from directors of the board down, Paul has kept both feet firmly on the ground even when his head has been in the clouds with healthy doses of Heavy Metal, Science Fiction and Formula One and long hair until it started falling out in 2013.

Oh, and he loves good tea too!

The NZXT H1 saga, continued

Not much to update since the last post on this topic, I’m still waiting for the updated PCIe riser. Although I do have to admit that based on the latest video from Gamers Nexus on this saga, I’m not holding my breath. With the current shipping issues I’ll give it another month or so and see if I get any PCIe riser before making a decision if I write off this case and rebuild the machine in a different SFF case.

Delphi and group estimation

A software estimate is a prediction about the future. Software developers were not the first people to formalize processes for making predictions about the future. Starting in the last 1940s, the RAND Corporation’s Delphi project created what became known as the Delphi method, e.g., An Experiment in Estimation, and Construction of Group Preference Relations by Iteration.

In its original form experts were anonymous; there was a “… deliberate attempt to avoid the disadvantages associated with more conventional uses of experts, such as round-table discussions or other milder forms of confrontation with opposing views.”, and no rules were given for the number of iterations. The questions involved issues whose answers involved long term planning, e.g., how many nuclear weapons did the Soviet Union possess (this study asked five questions, which required five estimates). Experts could provide multiple answers, and had to give a probability for each being true.

One of those involved in the Delphi project (Helmer-Hirschberg) co-founded the Institute for the Future, which published reports about the future based on answers obtained using the Delphi method, e.g., a 1970 prediction of the state-of-the-art of computer development by the year 2000 (Dalkey, a productive member of the project, stayed at RAND).

The first application of Delphi to software estimation was by Farquhar in 1970 (no pdf available), and Boehm is said to have modified the Delphi process to have the ‘experts’ meet together, rather than be anonymous, (I don’t have a copy of Farquhar, and my copy of Boehm’s book is in a box I cannot easily get to); this meeting together form of Delphi is known as Wideband Delphi.

Planning poker is a variant of Wideband Delphi.

An assessment of Delphi by Sackman (of Grant-Sackman fame) found that: “Much of the popularity and acceptance of Delphi rests on the claim of the superiority of group over individual opinions, and the preferability of private opinion over face-to-face confrontation.” The Oracle at Delphi was one person, have we learned something new since that time?

Group dynamics is covered in section 3.4 of my Evidence-based software engineering book; resource estimation is covered in section 5.3.

The likelihood that a group will outperform an individual has been found to depend on the kind of problem. Is software estimation the kind of problem where a group is likely to outperform an individual? Obviously it will depend on the expertise of those in the group, relative to what is being estimated.

What does the evidence have to say about the accuracy of the Delphi method and its spinoffs?

When asked to come up with a list of issues associated with solving a problem, groups generate longer lists of issues than individuals. The average number of issues per person is smaller, but efficient use of people is not the topic here. Having a more complete list of issues ought to be good for accurate estimating (the validity of the issues is dependent on the expertise of those involved).

There are patterns of consistent variability in the estimates made by individuals; some people tend to consistently over-estimate, while others consistently under-estimate. A group will probably contain a mixture of people who tend to over/under estimate, and an iterative estimation process that leads to convergence is likely to produce a middling result.

By how much do some people under/over estimate?

The multiplicative factor values (y-axis) appearing in the plot below are from a regression model fitted to estimate/actual implementation time for a project involving 13,669 tasks and 47 developers (data from a study Nichols, McHale, Sweeney, Snavely and Volkmann). Each vertical line, or single red plus, is one person (at least four estimates needed to be made for a red plus to occur); the red pluses are the regression model’s multiplicative factor for that person’s estimates of a particular kind of creation task, e.g., design, coding, or testing. Points below the grey line are overestimation, and above the grey line the underestimation (code+data):

3n+1 programs containing various lines of code.

What is the probability of a Delphi estimate being more accurate than an individual’s estimate?

If we assume that a middling answer is more likely to be correct, then we need to calculate the probability that the mix of people in a Delphi group produces a middling estimate while the individual produces a more extreme estimate.

I don’t have any Wideband Delphi estimation data (or rather, I only have tiny amounts); pointers to such data are most welcome.

Our brains want more but less is more

Less is more – I say it so often but it is still a lesson I still have to relearn regularly. Go small. You could say that my most famous blog post is saying just the same thing in fancy language – Software has diseconomies of scale – not economies of scale.

So a couple of weeks ago I was fascinated to see an article in The Economist entitled “Why people forget that less is often more” (paywall) reporting on research published in Nature “People systematically overlook subtractive changes” (another paywall) – being Nature one knows this is serious science.

The researched showed that less is more applies mentally as well as physically. That is, people are far more likely to solve problems by adding elements than by subtracting them – even when subtraction is both viable and costs less (some of the experiments introduced the idea of cost.) The researches even go as far as to suggest this isn’t just a case of believing the additive (more) solution is better than the subtractive, it appears our brains are less likely to consider the a solution which subtracts elements to create a solution.

Last year when I was struggling to complete “Succeeding with OKRs in Agile” I found a solution in removing some chapters. Some were little more than notes, some were in draft and a couple were fully written (and edited). Removing those chapters made the book less, but it made my work load less too – which had an immediate benefit.

It also meant I could finish the book sooner. It meant the copy editing process was quicker and cheaper, and it meant that the book could be published on Amazon and start earning for sooner. But I also believe people like shorter books, I really believe that I’m selling more books because it has less than 200 pages than I would if it had over 200, let alone 300.

This has a bearing on the way companies organise themselves and their processes too. When I first started talking about #NoProjects (which became Project Myopia) I really saw this as a “just remove the project model” – keep doing all the other stuff but just drop projects. Part of me still believes that and while I recognise that some places need more structure I also believe that adding projects is simply overhead for many small companies.

I see it too in the “fear of coding” that many companies have – don’t let people code! Plan it, write it down, estimate it, find the cheapest supplier, argue about it – when simply doing it would be cheaper.

I see it too in the way “agile methods” have grown. Scrum, and XP, are barely viable development models. Compared to RUP they are miniscule. But they worked. Before agile we called them “lightweight”.

Now we have SAFe and other frameworks which bring big thinking back. Nobody would call SAFe lightweight – not with its 10 principles, four configurations and five versions. Perhaps we should have stuck with “lightweight development methods.”

I think it was Alistair Cockburn who once said “Traditional methods are tailored by removing elements, agile methods are tailored by adding.” If the research above is right it was only a matter of time before someone created an “agile method” as big as SAFe.

Finally, another example of less is more: I could write more in this blog but less is more.


Subscribe to my blog newsletter and download Continuous Digital for free – normal price $9.99/£9.95/€9.95

The post Our brains want more but less is more appeared first on Allan Kelly Associates.

Estimate variability for the same task

If 100 people estimate the time needed to implement a feature, in software, what is the expected variability in the estimates?

Studies of multiple implementations of the same specification suggest that standard deviation of the mean number of lines across implementations is 25% of the mean (based on data from 10 sets of multiple implementations, of various sizes).

The plot below shows lines of code against the number of programs (implementing the 3n+1 problem) containing that many lines (red line is a Normal distribution fitted by eye, code and data):

3n+1 programs containing various lines of code.

Might any variability in the estimates for task implementation be the result of individuals estimating their own performance (which is variable)?

To the extent that an estimate is based on a person’s implementation experience, a developer’s past performance will have some impact on their estimate. However, studies have found a great deal of variability between individual estimates and their corresponding performance.

One study asked 14 companies to bid on implementing a system (four were eventually chosen to implement it; see figure 5.2 in my book). The estimated elapsed time varied by a factor of ten. Until the last week this was the only study of this question for which the data was available (and may have been the only such study).

A study by Alhamed and Storer investigated crowd-sourcing of effort estimates, structured by use of planning poker. The crowd were workers on Amazon’s Mechanical Turk, and the tasks estimated came from the issue trackers of JBoss, Apache and Spring Integration (using issues that had been annotated with an estimate and actual time, along with what was considered sufficient detail to make an estimate). An initial set of 419 issues were whittled down to 30, which were made available, one at a time, as a Mechanical Turk task (i.e., only one issue was available to be estimated at any time).

Worker estimates were given using a time-based category (i.e., the values 1, 4, 8, 20, 40, 80), with each value representing a unit of actual time (i.e., one hour, half-day, day, half-week, week and two weeks, respectively).

Analysis of the results from a pilot study were used to build a model that detected estimates considered to be low quality, e.g., providing a poor justification for the estimate. These were excluded from any subsequent iterations.

Of the 506 estimates made, 321 passed the quality check.

Planning poker is an iterative process, with those making estimates in later rounds seeing estimates made in earlier rounds. So estimates made in later rounds are expected to have some correlation with earlier estimates.

Of the 321 quality check passing estimates, 153 were made in the first-round. Most of the 30 issues have 5 first-round estimates each, one has 4 and two have 6.

Workers have to pick one of five possible value as their estimate, with these values being roughly linear on a logarithmic scale, i.e., it is not possible to select an estimate from many possible large values, small values, or intermediate values. Unless most workers pick the same value, the standard deviation is likely to be large. Taking the logarithm of the estimate maps it to a linear scale, and the plot below shows the mean and standard deviation of the log of the estimates for each issue made during the first-round (code+data):

Mean against standard deviation for log of estimates of each issue.

The wide spread in the standard deviations across a spread of mean values may be due to small sample size, or it may be real. The only way to find out is to rerun with larger sample sizes per issue.

Now it has been done once, this study needs to be run lots of times to measure the factors involved in the variability of developer estimates. What would be the impact of asking workers to make hourly estimates (they would not be anchored by experimenter specified values), or shifting the numeric values used for the categories (which probably have an anchoring effect)? Asking for an estimate to fix an issue in a large software system introduces the unknown of all kinds of dependencies, would estimates provided by workers who are already familiar with a project be consistently shifted up/down (compared to estimates made by those not familiar with the project)? The problem of unknown dependencies could be reduced by giving workers self-contained problems to estimate, e.g., the 3n+1 problem.

The crowdsourcing idea is interesting, but I don’t think it will scale, and I don’t see many companies making task specifications publicly available.

To mimic actual usage, research on planning poker (which appears to have non-trivial usage) needs to ensure that the people making the estimates are involved during all iterations. What is needed is a dataset of lots of planning poker estimates. Please let me know if you know of one.

A Review of Absolution Gap: Ignore the naysayers. Read this book. Love this book.

Alastair Reynolds ISBN-13 : 978-0575083165

I re-read Absolution Gap a decade or more after the first time in anticipation of the next part coming out in July of this year (2021). It was always the weakest of the trilogy, but not nearly as bad as I remember. In fact this time I devoured it in a relatively, for me, short period of time.

It’s true, as some other reviewers have said, that the story here could have been told in far fewer words, but then much of the texture of the story telling would have been lost and I think this is what makes this such a great book!


The characters and themes are believable in this universe. I think the story could have been very different if certain characters had not been killed off so early or at all. It’s always a shame when a lot of the main thrust of a previous book (Redemption Ark) is undone, but this is often how things play out in the real world.


I achieved what I wanted by re-reading Absolution Gap, I’m up to speed ready for the next instalment. The problem is that there is so much in the Revelation Space universe I now feel the need to go back and read it all again.


Ignore the naysayers. Read this book. Love this book.


Bring Out The Big Flipping GunS – a.k.

Last month we took a look at quasi-Newton multivariate function minimisation algorithms which use approximations of the Hessian matrix of second partial derivatives to choose line search directions. We demonstrated that the BFGS rule for updating the Hessian after each line search maintains its positive definiteness if they conform to the Wolfe conditions, ensuring that the locally quadratic approximation of the function defined by its value, the vector of first partial derivatives and the Hessian has a minimum.
Now that we've got the theoretical details out of the way it's time to get on with the implementation.

Suspending the computer using Kupfer

I have recently started using Kupfer again as my application launcher in Ubuntu MATE, and I found it lacked the ability to suspend the computer.

Here is the plugin I wrote to support this.

To install it, quit Kupfer, create a directory in your home dir called .local/share/kupfer/plugins, and create this file suspend.py inside:

__kupfer_name__ = _("Power management")
__kupfer_sources__ = ("PowerManagementItemsSource", )
__description__ = _("Actions to suspend the computer")
__version__ = "2021-05-05"
__author__ = "Andy Balaam "


from kupfer.plugin import session_support as support


class Suspend (support.CommandLeaf):
    def __init__(self, commands):
        support.CommandLeaf.__init__(self, commands, "Suspend")
    def get_description(self):
        return _("Suspend the computer")
    def get_icon_name(self):
        return "system-suspend"


class PowerManagementItemsSource (support.CommonSource):
	def __init__(self):
		support.CommonSource.__init__(self, _("Power management"))
	def get_items(self):
		return (Suspend((["systemctl", "suspend"],)),)

# Copyright 2021 Andy Balaam, released under the MIT license.

Now restart Kupfer, go to Preferences, Plugins, and tick “Power management”.

You should now see a “Suspend” item if you search for it in the Kupfer interface.

Inspired by: Mate Session Management – Kupfer Plugin.

Reference docs: Kupfer Plugin API

OKRs top-down? bottom-up? or ripples in a pond?

One of the great things about writing a book is that you get a greater understanding of the subject. So it was with “Succeeding with OKRs in Agile”. In particular writing the book forced me to think about how OKRs fitted with agile and hierarchal structures. I get the impression that many people are interested in using OKRs to align teams but not everyone has worked out all the nuances.

On the face of it OKRs are hierarchal: it seems “obvious” that someone, somewhere, is going to set a big goal, that goal will cascade down and every team will end up with their own mini version of the goal. As I said, this seems obvious, how else could it be? Especially in a large organization?

After all, is that how the not so distant ancestors of OKRs, Management-By-Objectives (MBOs), worked.

This also fits the engineer’s mind: the product team have a goal, and all the supporting teams – whether contributing components or services – make their goals subservient to the one goal. The classic inverted tree with each team doing what the node above asks.

But, top-down conflicts directly with reality and with agile. Teams don’t have one goal, they don’t answer to but one leader but to multiple leaders, multiple customers, multiple stakeholders and these don’t always agree. Agile folk have long railed against command-and-control from above while advocating self-managing or self-organising teams. Surely OKRs go against this philosophy?

So, if we are to use OKRs in an agile environment these positions need to be reconciled. In Succeeding with OKRs I described the process as more bottom-up than top-down. Thus, rather than a big boss saying what should happen and that being cascaded down the origanization to provide goals at every level, I describer the big boss setting out a vision, a goal, an objective but not describing details. Then they say to the teams: “Help, how can you help more us towards that goal?”

Now, only a few months after I wrote that my thinking has moved on. I don’t disagree with myself but I see the need for a more nuanced explanation and a revised model.

First off, I’m guilty of using the language of hierarchy: top-down and bottom-up. In so doing I’m supporting the view that hierarchies are the natural state of things and creating a, possibly false dichotomy: one thing or another. For years I’ve been thinking of organisations both as federal entities and as solar systems. While the leadership team may be central to decisions they are not all powerful . Teams have their own paths, leadership and leadership teams are the sun and teams/divisions orbit them. (If I recall correctly I picked this idea up in the Henry Mintzberg book Simply Managing.)

Bear in mind, as I say in everyone of my books: team are autonomous. We stive for independent teams with devolved authority. Each team exists to deliver a product or service and each team has multiple stakeholders – of whom the big boss is but one. Each team therefore has to decide how best to deliver benefit to (potentially competing) stakeholders. Sometimes that means co-ordinating with other teams and even other companies.

Put that together: teams are creating OKRs but they are not doing it in isolation, they are listening to the big bosses at the centre but also the teams they need to work with.

Recently I’ve started to think of these concentric circles less as planetary orbits and more as waves, or ripples to be precise. The big boss at the centre makes big ripples that carry out to the edges.

But leaders are not the only ripple makers. Teams, customers and other stakeholders also have an effect – like rain falling on water. Sometimes these waves some together and magnify each other, other times they cancel each other out, more often than-not they are out of sync and disrupt each other in ways too complex to predictable.

We think of leaders as single water droplets but inreality there are lots of drops making lots of ripples

OKRs are the messaging system that allows teams to signal what ripples they are creating and which they are reacting to. Teams are iterating – OKRs reset every 13 weeks – which means every quarter teams get a chance to react to other ripples and rest their own.

Thought of like this you also get a scaling model. Not so much a model of “how to do this to scale” but a mental model which describes how to think about scaling.


I have some upcoming presentations and webinars about OKRs if you would like to know more

Or, buy the book “Succeeding with OKRs in Agile”


Subscribe to my blog newsletter and download Continuous Digital for free – normal price $9.99/£9.95/€9.95

The post OKRs top-down? bottom-up? or ripples in a pond? appeared first on Allan Kelly Associates.

Presentation & speaking engagements

Agile on the beach

The attention Succeeding with OKRs in Agile has got means I’ve had a lot of invites to speak about, well, Agile and OKRs. So I am at a number of meetup groups and conferences, and odd conversation, over the next few weeks, most of which are free to attend online.

An up to date list of public speaking engagements can always be found on my website. In addition to public speaking I regularly deliver private presentations too. So please get in touch and book a date your team or company.


Reawakening Agile with OKRs

When: 6 May, 5.30pm Sydney, 8.30am London

Online presentation

Organized by SAFe Sydney, free, booking required


Reawakening Agile with OKRs

When: 11 May 2021, online presentation

Organized by BCS Change Management group – booking required (free to attend)


Succeeding with OKRs

An online conversation with Adrian Reed, 20 May 2021.

Organiser and booking with BlackMetric


Reawakening Agile with OKRs

When: 27 May, online presentation

Organized by Cambridge Agile Exchange, free, booking required


Reawakening Agile with OKRs

When: 30 June 2021, online presentation

Organized by Future of Work in Scotland, booking required


Allan Kelly at Agile on the Beach
Allan Kelly at Agile on the Beach

Reawakening Agile with OKRs at Agile on the Beach conference

First live, in person, event since March 2020 – with beach party!

Sept 2, 2021, tickets on sale now

The post Presentation & speaking engagements appeared first on Allan Kelly Associates.

Claiming that software is AI based is about to become expensive

The European Commission is updating the EU Machinery Directive, which covers the sale of machinery products within the EU. The updates include wording to deal with intelligent robots, and what the commission calls AI software (contained in machinery products).

The purpose of the initiative is to: “… (i) ensuring a high level of safety and protection for users of machinery and other people exposed to it; and (ii) establishing a high level of trust in digital innovative technologies for consumers and users, …”

What is AI software, and how is it different from non-AI software?

Answering these questions requires knowing what is, and is not, AI. The EU defines Artificial Intelligence as:

  • ‘AI system’ means a system that is either software-based or embedded in hardware devices, and that displays behaviour simulating intelligence by, inter alia, collecting and processing data, analysing and interpreting its environment, and by taking action, with some degree of autonomy, to achieve specific goals;
  • ‘autonomous’ means an AI system that operates by interpreting certain input, and by using a set of predetermined instructions, without being limited to such instructions, despite the system’s behaviour being constrained by and targeted at fulfilling the goal it was given and other relevant design choices made by its developer;

‘Simulating intelligence’ sounds reasonable, but actually just moves the problem on, to defining what is, or is not, intelligence. If intelligence is judged on an activity by activity bases, will self-driving cars be required to have the avoidance skills of a fly, while other activities might have to be on par with those of birds? There is a commission working document that defines: “Autonomous AI, or artificial super intelligence (ASI), is where AI surpasses human intelligence across all fields.”

The ‘autonomous’ component of the definition is so broad that it covers a wide range of programs that are not currently considered to be AI based.

The impact of the proposed update is that machinery products containing AI software are going to incur expensive conformance costs, which products containing non-AI software won’t have to pay.

Today it does not cost companies to claim that their systems are AI based. This will obviously change when a significant cost is involved. There is a parallel here with companies that used to claim that their beauty products provided medical benefits; the Federal Food and Drug Administration started requiring companies making such claims to submit their products to the new drug approval process (which is hideously expensive), companies switched to claiming their products provided “… the appearance of …”.

How are vendors likely to respond to the much higher costs involved in selling products that are considered to contain ‘AI software’?

Those involved in the development of products labelled as ‘safety critical’ try to prevent costs escalating by minimizing the amount of software treated as ‘safety critical’. Some of the arguments made for why some software is/is not considered safety critical can appear contrived (at least to me). It will be entertaining watching vendors, who once shouted “our products are AI based”, switching to arguing that only a tiny proportion of the code is actually AI based.

A mega-corp interested in having their ‘AI software’ adopted as an industry standard could fund the work necessary for the library/tool to be compliant with the EU directives. The cost of initial compliance might be within reach of smaller companies, but the cost of maintaining compliance as the product evolves is something that only a large company is likely to be able to afford.

The EU’s updating of its machinery directive is the first step towards formalising a legal definition of intelligence. Many years from now there will be a legal case that creates what later generation will consider to be the first legally accepted definition.

My experience with the NZXT H1 recall so far

First, I’m very much a “very occasional” gamer so I’m usually not the target audience for most gaming related accessories and parts. I did however want to rebuild my rather large grey box Linux/Windows workstation into something more compact with a watercooler for the CPU. The NZXT H1 seemed at that point to be a really good match for my requirements and had received good reviews. One was duly ordered, together with a Mini-ITX motherboard and somehow, a better graphics card also snuck on the shopping list.

Uploading to PeerTube from the command line

PeerTube’s API documentation gives an example of how to upload a video, but it is missing a couple of important aspects, most notably how to provide multiple tags use form-encoded input, so my more complete script is below. Use it like this:

# First, make sure jq is installed
echo "myusername" > username
echo "mypassword" > password
./upload "video_file.mp4"

Downsides:

  1. Your username and password are visible via ps to users on the same machine (tips to avoid this are welcome)
  2. I can’t work out how to include newlines in the video description (again, tips welcome)

You will need to edit the script to provide your own PeerTube server URL, channel ID (a number), video description, tags etc. Output and errors from the script will be placed in curl-out.txt. Read the API docs to see what numbers you need to use for category, license etc.

Here is upload:

#!/bin/bash

set -e
set -u

USERNAME="$(cat username)"
PASSWORD="$(cat password)"
FILE_PATH="$1"
CHANNEL_ID=MY_CHANNEL_ID_EG_1234
NAME="${FILE_PATH%.*}"
NAME="${NAME#*/}"

API_PATH="https://MY_PEERTUBE_SERVER_URL/api/v1"
## AUTH
client_id=$(curl -s "${API_PATH}/oauth-clients/local" | jq -r ".client_id")
client_secret=$(curl -s "${API_PATH}/oauth-clients/local" | jq -r ".client_secret")
token=$(curl -s "${API_PATH}/users/token" \
  --data client_id="${client_id}" \
  --data client_secret="${client_secret}" \
  --data grant_type=password \
  --data response_type=code \
  --data username="${USERNAME}" \
  --data password="${PASSWORD}" \
  | jq -r ".access_token")

echo "Uploading ${FILE_PATH}"
curl "${API_PATH}/videos/upload" \
  -H "Authorization: Bearer ${token}" \
  --output curl-out.txt \
  --max-time 6000 \
  --form videofile=@"${FILE_PATH}" \
  --form channelId=${CHANNEL_ID} \
  --form name="$NAME" \
  --form category=15 \
  --form licence=7 \
  --form description="MY_VIDEO_DESCRIPTION" \
  --form language=en \
  --form privacy=1 \
  --form tags="TAG1" \
  --form tags="TAG2" \
  --form tags="TAG3" \
  --form tags="TAG4"

Developer becoming a product owner/product manager?

Product Owner choosing postits

A few weeks back I had an e-mail exchange with a blog reader about the product owner role which I think other readers might be interested in, it is a question that comes up regularly with clients. In this context the product owner is a product manager (regular readers know I consider product manager to be a subset of product owner).

Reader: This makes me think that the [product owner/manager] role is indeed super hard. Do you have a view on hiring versus training internally?

I’ve had great success with moving people from development into product owner/manager roles – I did it myself once upon a time. And I remember one developer who’s face lit up when I asked if he would like to move to a product role. A few years later – and several companies on – I got an e-mail from him to say how his career had flourished.

When to many the move looks obvious it is actually far harder than it looks and there are pitfalls.

The key thing is: the individual needs to leave their past life behind. Changing from developer to product owner/manager is changing your identity, it is hard.

The mistake that I see again and again is that the individuals – sometimes encouraged by those around them – continue to wear a developer hat. This means they don’t step into their new identity. They spread themselves thinly between two roles and their opinion divided. They seem themselves as capable of everything rather than specialist in one so don’t devote the time to both learn their new role and mentally change their perspective.

Imagine a hybrid developer/product manager comes back from lunch and has three or four hours spare – of course this never happens but just run with this thought experiment. Are they best: (a) pulling the highest priority item from the backlog and getting it done, or, (b) reviewing the latest customer interviews, site metrics, and perhaps picking up the phone and calling an existing customer?

Coding up a story clearly adds value, it reduces the backlog and enhances the product directly. Picking up the phone and analysing data may not have an immediate effect or enhance the product today, the payoff will come over weeks and months as better decisions are made and customers served better.

Product owners/managers need to empathise with customers and potential customers, they need to feel the pain of the business and see the opportunities in the market. Skilled coders feel the code, they hear it asking to be refactored; they dream about enhancing it in place; they worry about weaknesses, the places were coupling is too high and tests too few. In short, coders empathise with the code.

It is good that product people empathise with customers and coders with the code. But what happens when those things come into conflict? The code is crying out for a refactoring and customers demanding a feature? Ultimately it will be a judgement call – although both side may believe the answer is obvious.

If the code is represented by one person and the customer by another then they can have a discussion, balance priorities and options. If you ask on person to fill both roles then they need to have an argument with themselves, this is not good for their mental health or the final decision.

These problems are especially acute when the developer in question is either very experienced or very good – or both. They come to represent the product and champion it. But that makes the balancing act even more difficult. It also means that those understand when a No is a no because there is no business justification and when No is no because the code is a mess.

Hence I want the roles of developer and product specialist kept separate.

In a small company, say, less than 10 people, it can be hard to avoid this situation. And when the product is new technology or and API it is often difficult to disentangle “what the customer will pay for” from “what the technology can do” but those traps make it more important that a company addresses this when it grows.

So my advice is simple: the key thing is that the individual changing roles needs to put coding behind them – and step away from the keyboard. I know that seems hard but to fill the product owner/manager role properly one has to live it.

I usually recommend the person in question away for training. And I do mean away (lets hope we can travel again soon!). The person changing roles needs to immerse themselves in their new life. Sitting in a classroom with others helps make the psychological switch.

When I did it – with Pragmatic Marketing (now Pragmatic Institute) – the training was difficult to get in Europe so I went to the USA which added to the experience. Product manager culture is more developed in the USA than elsewhere – and even more developed on the West Coast simply because it has been there longer.

Going somewhere different and immersing yourself in a new culture and new ideas is a great way of breaking with your past and creating a new identity for yourself.


Subscribe to my blog newsletter and download Continuous Digital for free – normal price $9.99/£9.95/€9.95

The post Developer becoming a product owner/product manager? appeared first on Allan Kelly Associates.

Software engineering experiments: sell the idea, not the results

A new paper investigates “… the feasibility of stealthily introducing vulnerabilities in OSS via hypocrite commits (i.e., seemingly beneficial commits that in fact introduce other critical issues).” Their chosen Open source project was the Linux kernel, and they submitted three patches to the kernel review process.

This interesting idea blew up in their faces, when the kernel developers deduced that they were being experimented on (they obviously don’t have a friend on the inside). The authors have come out dodging and weaving.

What can be learned by reading the paper?

Firstly, three ‘hypocrite commits’ is not enough submissions to do any meaningful statistical analysis. I suspect it’s a convenience sample, a common occurrence in software engineering research. The authors sell three as a proof-of-concept.

How many of the submitted patches passed the kernel review process?

The paper does not say. The first eight pages provide an introduction to the Open source development model, the threat model for introducing vulnerabilities, and the characteristics of vulnerabilities that have been introduced (presumably by accident). This is followed by 2.5 pages of background and setup of the experiment (labelled as a proof-of-concept).

The paper then switches (section VII) to discussing a different, but related, topic: the lifetime of (unintended) vulnerabilities in patches that had been accepted (which I think should have been the topic of the paper. This interesting discussion is 1.5 pages; also see The life and death of statically detected vulnerabilities: An empirical study, covered in figure 6.9 in my book.

The last two pages discuss mitigation, related work, and conclusion (“…a proof-of-concept to safely demonstrate the practicality of hypocrite commits, and measured and quantified the risks.”; three submissions is not hard to measure and quantify, but the results are not to be found in the paper).

Having the paper provide the results (i.e., all three commits spotted, and a very negative response by those being experimented on) would have increased the chances of negative reviewer comments.

Over the past few years I have started noticing this kind of structure in software engineering papers, i.e., extended discussion of an interesting idea, setup of experiment, and cursory or no discussion of results. Many researchers are willing to spend lots of time discussing their ideas, but are unwilling to invest much time in the practicalities of testing them. Some reviewers (who decide whether a paper is accepted to publication) don’t see anything wrong with this approach, e.g., they accept these kinds of papers.

Software engineering research remains a culture of interesting ideas, with evidence being an optional add-on.

Republishing Bartosz Milewski’s Category Theory lectures

Category Theory is an incredibly exciting and challenging area of Maths, that (among other things) can really help us understand what programming is on a fundamental level, and make us better programmers.

By far the best explanation of Category Theory that I have ever seen is a series of videos by Bartosz Milewski.

The videos on YouTube have quite a bit of background noise, and they were not available on PeerTube, so I asked for permission to edit and repost them, and Bartosz generously agreed! The conversation was in the comments section of Category Theory 1.1: Motivation and Philosophy and I reproduce it below.

So, I present these awesome videos, with background noise removed using Audacity, for your enjoyment:

Category Theory by Bartosz Milewski

Permission details:

Andy Balaam: Utterly brilliant lecture series.  Is it available under a free license?  I'd like to try and clean up audio and repost it to PeerTube, if that is permitted. Bartosz Milewski: You have my permission. I consider my lectures public domain.

Andy Balaam: Utterly brilliant lecture series. Is it available under a free license? I’d like to try and clean up audio and repost it to PeerTube, if that is permitted.
Bartosz Milewski: You have my permission. I consider my lectures public domain.

Visual Lint 8.0.1.337 has been released

Visual Lint 8.0.1.337 is a recommended maintenance update for Visual Lint 8.0. The following changes are included:

  • If the Visual Studio plugin is selected for installation and the Visual Studio Debug Console (VsDebugConsole.exe) is running, the installer will now ask you to close it before installation can proceed.

  • Updated the interface with IncrediBuild to support IncrediBuild 9.5.x. [also in Visual Lint 7.0.12.336]

  • IncrediBuild analysis tasks can now be colour coded in the IncrediBuild Build Monitor from within the Visual Studio, Atmel Studio and Eclipse plug-ins. [also in Visual Lint 7.0.12.336]

  • Fixed a bug which could cause duplicate IncrediBuild analysis tasks to be queued. [also in Visual Lint 7.0.12.336]

  • Updated the prompt displayed if an IncrediBuild installation was not found when IncrediBuild analysis was enabled. [also in Visual Lint 7.0.12.336]

  • Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-vs2019.lnt to support Visual Studio 2019 v16.4.4.

  • Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-vs2017.lnt to support Visual Studio 2017 v15.9.35.

  • Various corrections and updates to help topics.

Download Visual Lint 8.0.1.337

Visual Lint 7.0.12.336 has been released

Visual Lint 7.0.12.336 is a recommended maintenance update for Visual Lint 7.0. The following changes are included:

  • Updated the interface with IncrediBuild to support IncrediBuild 9.5.x.

  • IncrediBuild analysis tasks can now be colour coded in the IncrediBuild Build Monitor from within the Visual Studio, Atmel Studio and Eclipse plug-ins.

  • Fixed a bug which could cause duplicate IncrediBuild analysis tasks to be queued.

  • Updated the prompt displayed if an IncrediBuild installation was not found when IncrediBuild analysis was enabled.

  • Various corrections and updates to help topics.

Download Visual Lint 7.0.12.336

Visual Lint 7.0.12.336 has been released

Visual Lint 7.0.12.336 is a recommended maintenance update for Visual Lint 7.0. The following changes are included:

  • Updated the interface with IncrediBuild to support IncrediBuild 9.5.x.

  • IncrediBuild analysis tasks can now be colour coded in the IncrediBuild Build Monitor from within the Visual Studio, Atmel Studio and Eclipse plug-ins.

  • Fixed a bug which could cause duplicate IncrediBuild analysis tasks to be queued.

  • Updated the prompt displayed if an IncrediBuild installation was not found when IncrediBuild analysis was enabled.

  • Various corrections and updates to help topics.

Download Visual Lint 7.0.12.336

Visual Lint 8.0.1.337 has been released

Visual Lint 8.0.1.337 is a recommended maintenance update for Visual Lint 8.0. The following changes are included:

  • If the Visual Studio plugin is selected for installation and the Visual Studio Debug Console (VsDebugConsole.exe) is running, the installer will now ask you to close it before installation can proceed.

  • Updated the interface with IncrediBuild to support IncrediBuild 9.5.x. [also in Visual Lint 7.0.12.336]

  • IncrediBuild analysis tasks can now be colour coded in the IncrediBuild Build Monitor from within the Visual Studio, Atmel Studio and Eclipse plug-ins. [also in Visual Lint 7.0.12.336]

  • Fixed a bug which could cause duplicate IncrediBuild analysis tasks to be queued. [also in Visual Lint 7.0.12.336]

  • Updated the prompt displayed if an IncrediBuild installation was not found when IncrediBuild analysis was enabled. [also in Visual Lint 7.0.12.336]

  • Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-vs2019.lnt to support Visual Studio 2019 v16.4.4.

  • Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-vs2017.lnt to support Visual Studio 2017 v15.9.35.

  • Various corrections and updates to help topics.

Download Visual Lint 8.0.1.337

Python virtual environments with pyenv on Apple Silicon

Apple's recent transition to the new architecture for its Mac computers has caused rather predictable problems for developers whose workflow depends on certain versions of pre-compiled libraries for x86 architecture. While the latest releases of Python come with a universal installer that allows to build universal binaries for M1 systems, those who prefer to manage Python environments with pyenv, may find it difficult to choose the correct version for installation.

This problem can be solved by installing both x86 and arm64 Python executables. To do that, we need to be able to run pyenv in x86 mode and make sure that all system dependencies are met for both architectures. In other words, we'll need both x86 and arm64 Homebrew packages that we'll keep separate using two installations of Homebrew.

First of all, to be able to run x86 executables, we'll need to install Rosetta:

$ softwareupdate —install-rosetta

Now we can install the x86 Homebrew:

$ arch -x86_64 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

It will be installed in the /usr/local/bin/ directory. For convenience, you can create an alias by adding the following line in your shell configuration file:

alias brew86="arch -x86_64 /usr/local/bin/brew"

Now we can invoke the x86 Homebrew as brew86 and install packages required by pyenv:

$ brew install openssl readline sqlite3 xz zlib

$ brew86 install openssl readline sqlite3 xz zlib

You can check whether the installation was successful and you have packages for both architectures using the file command, for example:

$ file /opt/homebrew/Cellar/openssl@1.1/1.1.1k/bin/openssl
/opt/homebrew/Cellar/openssl@1.1/1.1.1k/bin/openssl: Mach-O 64-bit executable arm64

$ file /usr/local/Cellar/openssl@1.1/1.1.1k/bin/openssl
/usr/local/Cellar/openssl@1.1/1.1.1k/bin/openssl: Mach-O 64-bit executable x86_64

To install x86 Python, you'll need to call pyenv with the arch -x86_64 prefix. For convenience, let's create an alias for this command by adding the following line in the shell config file:

alias pyenv86="arch -x86_64 pyenv"

Now you can install x86 Python binaries by calling:

$ pyenv86 install <PYTHON_VERSION>

By default, pyenv doesn't allow you to specify custom names for the installed Python versions, but you can use the pyenv-alias plugin to give your installations appropriate names:

$ VERSION_ALIAS="3.x.x_x86" pyenv86 install 3.x.x

Note that with aliases for your pyenv and Homebrew installations, you’ll have to specify them in all commands and locations, for example:

$ CFLAGS="-I$(brew86 --prefix openssl)/include" \
LDFLAGS="-L$(brew86 --prefix openssl)/lib" \
VERSION_ALIAS="3.x.x_x86" \
pyenv86 install -v 3.x.x

Using atomics for thread synchronization in C++

In my previous blog post I wrote about spin locks, and how compilers must not move the locking loop above a prior unlock.

After thinking about this done more, I realised that is not something specific to locks — the same issue arises with any two step synchronization between threads.

Consider the following code

std::atomic<bool> ready1{false};
std::atomic<bool> ready2{false};

void thread1(){
  ready1.store(true, std::memory_order_release);
  while(!ready2.load(std::memory_order_acquire)){}
}

void thread2() {
  while(!ready1.load(std::memory_order_acquire)) {}
  ready2.store(true, std::memory_order_release);
}

thread1 sets ready1 to true, then waits for thread2 to set ready2 to true. Meanwhile, thread2 waits for ready1 to be true, then sets ready2 to true.

This is almost identical to the unlock/lock case from the previous blog post, except the waiting thread is just using plain load rather than exchange.

If the compiler moves the wait loop in thread1 above the store then both threads will hang forever. However it cannot do this for the same reason the spinlocks can't deadlock in the previous post: the store has to be visible to the other thread in a finite period if time, so must be issued before the wait loop. https://eel.is/c++draft/intro.multithread#intro.progress-18

An implementation should ensure that the last value (in modification order) assigned by an atomic or synchronization operation will become visible to all other threads in a finite period of time.

If the optimizer moved the store across the loop in thread1, then it could not guarantee that the value became visible to the other thread in a finite period of time. Therefore such an optimization is forbidden.

Posted by Anthony Williams
[/ cplusplus /] permanent link
Tags: , , ,
Stumble It! stumbleupon logo | Submit to Reddit reddit logo | Submit to DZone dzone logo

Comment on this post

Follow me on Twitter

Another nail for the coffin of past effort estimation research

Programs are built from lines of code written by programmers. Lines of code played a starring role in many early effort estimation techniques (section 5.3.1 of my book). Why would anybody think that it was even possible to accurately estimate the number of lines of code needed to implement a library/program, let alone use it for estimating effort?

Until recently, say up to the early 1990s, there were lots of different computer systems, some with multiple (incompatible’ish) operating systems, almost non-existent selection of non-vendor supplied libraries/packages, and programs providing more-or-less the same functionality were written more-or-less from scratch by different people/teams. People knew people who had done it before, or even done it before themselves, so information on lines of code was available.

The numeric values for the parameters appearing in models were obtained by fitting data on recorded effort and lines needed to implement various programs (63 sets of values, one for each of the 63 programs in the case of COCOMO).

How accurate is estimated lines of code likely to be (this estimate will be plugged into a model fitted using actual lines of code)?

I’m not asking about the accuracy of effort estimates calculated using techniques based on lines of code; studies repeatedly show very poor accuracy.

There is data showing that different people implement the same functionality with programs containing a wide range of number of lines of code, e.g., the 3n+1 problem.

I recently discovered, tucked away in a dataset I had previously analyzed, developer estimates of the number of lines of code they expected to add/modify/delete to implement some functionality, along with the actuals.

The following plot shows estimated added+modified lines of code against actual, for 2,692 tasks. The fitted regression line, in red, is: Actual = 5.9Estimated^{0.72} (the standard error on the exponent is pm 0.02), the green line shows Actual==Estimated (code+data):

Estimated and actual lines of code added+modified to implement a task.

The fitted red line, for lines of code, shows the pattern commonly seen with effort estimation, i.e., underestimating small values and over estimating large values; but there is a much wider spread of actuals, and the cross-over point is much further up (if estimates below 50-lines are excluded, the exponent increases to 0.92, and the intercept decreases to 2, and the line shifts a bit.). The vertical river of actuals either side of the 10-LOC estimate looks very odd (estimating such small values happen when people estimate everything).

My article pointing out that software effort estimation is mostly fake research has been widely read (it appears in the first three results returned by a Google search on software fake research). The early researchers did some real research to build these models, but later researchers have been blindly following the early ‘prophets’ (i.e., later research is fake).

Lines of code probably does have an impact on effort, but estimating lines of code is a fool’s errand, and plugging estimates into models built from actuals is just crazy.

On Twenty-Niner – student

The Baron's most recent wager set Sir R----- the task of placing tokens upon spaces numbered from zero to nine according to the outcome of a twenty sided die upon which was inscribed two of each of those numbers. At a cost of one coin per roll of the die, Sir R-----'s goal was to place a token upon every space for which he should receive twenty nine coins and twenty nine cents from the Baron.

Can non-overlapping spinlocks deadlock in C++?

There has been discussion on Twitter recently about whether or not the C++ memory model allows spinlocks to deadlock if they just use memory_order_acquire in lock and memory_order_release in unlock, due to compiler optimizations. The case in question is where a thread locks one mutex, unlocks it, and locks a second: can the compiler reorder the second lock above the first unlock? If it does, and another thread does the same in the reverse order, with the same optimization, then sequential locks could deadlock.

Here is the code in question, with all the lock/unlock code inlined.

std::atomic<bool> mutex1{false};
std::atomic<bool> mutex2{false};

int x=0;
int y=0;

void thread1(){
  while(mutex1.exchange(true,std::memory_order_acquire)){}  // #1
  x=1;
  mutex1.store(false,std::memory_order_release); // #2

  while(mutex2.exchange(true,std::memory_order_acquire)){} // #3
  y=1;
  mutex2.store(false,std::memory_order_release); // #4
}

void thread2(){
  while(mutex2.exchange(true,std::memory_order_acquire)){} // #5
  x=2;
  mutex2.store(false,std::memory_order_release); // #6

  while(mutex1.exchange(true,std::memory_order_acquire)){} // #7
  y=2;
  mutex1.store(false,std::memory_order_release); // #8
}

For there to even be the possibility of deadlock, thread1 must successfully execute line #1 before thread2 successfully executes line #7, and thread2 must successfully execute line #5 before thread1 successfully executes line #3. Because these are RMW operations, the threads must agree on the ordering.

The modification order of mutex1 must thus be #1(success), #2, #7(success), #8. Similarly, the modification order of mutex2 must be #5(success), #6, #3(success), #4.

All threads must agree on these modification orders. https://eel.is/c++draft/intro.multithread#intro.races-4

From the point of view of thread1, everything must run in program order: compilers can only optimize things as long as they run "as if" in program order.

The store to mutex1 at #2 is guaranteed to be visible to thread2 in "a finite period of time". https://eel.is/c++draft/intro.multithread#intro.progress-18

Consequently, thread2 must eventually see that store at line #7, even if it executes line #7 a large number of times first.

Therefore, the compiler cannot move line #3 completely above line #2, since doing so would not guarantee the visibility of #2 to other threads in a finite period of time. It can move an arbitrary number of executions of line #3 above line #2 (all of which will see that mutex2 is still true), but not all the executions of line #3.

Given that thread2 eventually sees the store from #2 at line #7, the exchange at line #7 will eventually succeed, and thread2 will eventually complete.

Likewise, the store at #6 must become visible to thread1 in a finite period of time. Therefore the exchange at line #3 will eventually see the value stored by

6, the exchange will succeed, and thread1 will complete, and the compiler is

not allowed to move all the executions of line #7 above #6.

No amount of compiler optimization is allowed to break this, so no: spinlocks cannot deadlock if they don't overlap.

Posted by Anthony Williams
[/ cplusplus /] permanent link
Tags: , , ,
Stumble It! stumbleupon logo | Submit to Reddit reddit logo | Submit to DZone dzone logo

Comment on this post

Follow me on Twitter

Pricing by quantity of source code

Software tool vendors have traditionally licensed their software on a per-seat basis, e.g., the cost increases with the number of concurrent users. Per-seat licensing works well when there is substantial user interaction, because the usage time is long enough for concurrent usage to build up. When a tool can be run non-interactively in the cloud, its use is effectively instantaneous. For instance, a tool that checks source code for suspicious constructs. Charging by lines of code processed is a pricing model used by some tool vendors.

Charging by lines of code processed creates an incentive to reduce the number of lines. This incentive was once very common, when screens supporting 24 lines of 80 characters were considered a luxury, or the BASIC interpreter limited programs to 1023 lines, or a hobby computer used a TV for its screen (a ‘tiny’ CRT screen, not a big flat one).

It’s easy enough to splice adjacent lines together, and halve the cost. Well, ease of splicing depends on programming language; various edge cases have to be handled (somebody is bound to write a tool that does a good job).

How does the tool vendor respond to a (potential) halving of their revenue?

Blindly splicing pairs of lines creates some easily detectable patterns in the generated source. In fact, some of these patterns are likely to be flagged as suspicious, e.g., if (x) a=1;b=2; (did the developer forget to bracket the two statements with { }).

The plot below shows the number of lines in gcc 2.95 containing a given number of characters (left, including indentation), and the same count after even-numbered lines (with leading whitespace removed) have been appended to odd-numbered lines (code+data, this version of gcc was using in my C book):

North Star Horizon with cover removed.

The obvious change is the introduction of a third straight’ish line segment (the increase in the offset of the sharp decline might be explained away as a consequence of developers using wider windows). By only slicing the ‘right’ pairs of lines together, the obvious patterns won’t be present.

Using lines of codes for pricing has the advantage of being easy to explain to management, the people who sign off the expense, who might not know much about source code. There are other metrics that are much harder for developers to game. Counting tokens is the obvious one, but has developer perception issues: Brackets, both round and curly. In the grand scheme of things, the use/non-use of brackets where they are optional has a minor impact on the token count, but brackets have an oversized presence in developer’s psyche.

Counting identifiers avoids the brackets issue, along with other developer perceptions associated with punctuation tokens, e.g., a null statement in an else arm.

If the amount charged is low enough, social pressure comes into play. Would you want to work for a company that penny pinches to save such a small amount of money?

As a former tool vendor, I’m strongly in favour of tool vendors making a healthy profit.

Creating an effective static analysis requires paying lots of attention to lots of details, which is very time-consuming. There are lots of not particularly good Open source tools out there; the implementers did all the interesting stuff, and then moved on. I know of several groups who got together to build tools for Java when it started to take-off in the mid-90s. When they went to market, they quickly found out that Java developers expected their tools to be free, and would not pay for claimed better versions. By making good enough Java tools freely available, Sun killed the commercial market for sales of Java tools (some companies used their own tools as a unique component of their consulting or service offerings).

Could vendors charge by the number of problems found in the code? This would create an incentive for them to report trivial issues, or be overly pessimistic about flagging issues that could occur (rather than will occur).

Why try selling a tool, why not offer a service selling issues found in code?

Back in the day a living could be made by offering a go-faster service, i.e., turn up at a company and reduce the usage cost of a company’s applications, or reducing the turn-around time (e.g., getting the daily management numbers to appear in less than 24-hours). This was back when mainframes ruled the computing world, and usage costs could be eye-watering.

Some companies offer bug-bounties to the first person reporting a serious vulnerability. These public offers are only viable when the source is publicly available.

There are companies who offer a code review service. Having people review code is very expensive; tools are good at finding certain kinds of problem, and investing in tools makes sense for companies looking to reduce review turn-around time, along with checking for more issues.

OKRs in Agile infrographic

I am indebted to Yoan Thirion for created this infographic to illustrate Succeeding with OKRs in Agile. He’s done a brilliant job on both the graphics and the summary – undoubtedly better graphics than I could have done and probably a better summary than I would too, sometimes one can be too close to a thing.


Subscribe to my blog newsletter and download Continuous Digital for free – normal price $9.99/£9.95/€9.95

The post OKRs in Agile infrographic appeared first on Allan Kelly Associates.

Reading ‘Let over Lambda’ – thoughts on fundamentals and why I keep reading classic CS texts

Another one for my computer science reading list for this year. I do try to work my way through at least one classic computer science book annually and picked up Let Over Lambda a few weeks ago. Colour one of the cats not impressed, but then again she’s got more free time than I do and probably already read it. Not massively impressed by yet another old book

The first computer I owned

The first computer I owned was a North Star Horizon. I bought it in kit form, which meant bags of capacitors, resistors, transistors, chips, printed circuit boards, etc, along with the circuit diagrams for each board. These all had to be soldered in the right holes, the chips socketed (no surface mount soldering for such a low volume system), and wires connected. I was amazed when the system booted the first time I powered it up; debugging with the very basic equipment I had would have been a nightmare. The only missing component was the power supply transformer, and a trip to the London-based supplier sorted that out. I saved a months’ salary by building the kit (which cost me 4-months salary, and I was one of the highest paid people in my circle).

North Star Horizon with cover removed.

The few individuals who bought a computer in the late 1970s bought either a Horizon or a Commodore Pet (which was more expensive, but came with an integrated monitor and keyboard). Computer ownership really started to take off when the BBC micro came along at the end of 1981, and could be bought for less than a months’ salary (at least for a white-collar worker).

My Horizon contained a Z80A clocking at 4MHz, 32K of RAM, and two 5 1/4-inch floppy drives (each holding 360K; the Wikipedia article says the drives held 90K, mine {according to the labels on the floppies, MD 525-10} are 40-track, 10-sector, double density). I later bought another 32K of memory; the system ROM was at 56K, and contained 4K of code, various tricks allowed the 4K above 60K to be used (the consistent quality of the soldering on one of the boards below identifies the non-hand built board).

North Star Horizon underside of boards.

The OS that came with the system was CP/M, renamed to CP/M-80 when the Intel 8086 came along, and will be familiar to anybody used to working with early versions of MS-DOS.

As a fan of Pascal, my development environment of choice was UCSD Pascal. The C compiler of choice was BDS C.

Horizon owners are total computer people :-) An emulator, running under Linux and capable of running Horizon disk images, is available for those wanting a taste of being a Horizon owner. I didn’t see any mention of audio emulation in the documentation; clicks and whirls from the floppy drive were a good way of monitoring compile progress without needing to look at the screen (not content with using our Horizon’s at home, another Horizon owner and I implemented a Horizon emulator in Fortran, running on the University’s Prime computers). I wonder how many Nobel-prize winners did their calculations on a Horizon?

The Horizon spec needs to be appreciated in the context of its time. When I worked in application support at the University of Surrey, users had a default file allocation of around 100K’ish (memory is foggy). So being able to store stuff on a 360K floppy, which could be purchased in boxes of 10, was a big deal. The mainframe/minicomputers of the day were available with single-digit megabytes, but many previous generation systems had under 100K of RAM. There were lots of programs out there still running in 64K. In terms of cpu power, nearly all existing systems were multi-user, and a less powerful, single-user, cpu beats sharing a more powerful cpu with 10-100 people.

In terms of sheer weight, visual appearance and electrical clout, the Horizon power supply far exceeds those seen in today’s computers, which look tame by comparison (two of those capacitors are 4-inches tall):

North Star Horizon power supply.

My Horizon has been sitting in the garage for 32-years, and tucked away in unused rooms for years before that. The main problem with finding out whether it still works is finding a device to connect to the 25-pin serial port. I have an old PC with a 9-pin serial port, but I have spent enough of my life fiddling around with serial-port cables and Kermit to be content trying a simpler approach. I connect the power supply and switched it on. There was a loud crack and a flash on the disk-controller board; probably a tantalum capacitor giving up the ghost (easy enough to replace). The primary floppy drive did spin up and shutdown after some seconds (as expected), but the internal floppy engagement arm (probably not its real name) does not swing free when I open the bay door (so I cannot insert a floppy).

I am hoping to find a home for it in a computer museum, and have emailed the two closest museums. If these museums are not interested, the first person to knock on my door can take it away, along with manuals and floppies.

Big Friendly GiantS – a.k.

In the previous post we saw how we could perform a univariate line search for a point that satisfies the Wolfe conditions meaning that it is reasonably close to a minimum and takes a lot less work to find than the minimum itself. Line searches are used in a class of multivariate minimisation algorithms which iteratively choose directions in which to proceed, in particular those that use approximations of the Hessian matrix of second partial derivatives of a function to do so, similarly to how the Levenberg-Marquardt multivariate inversion algorithm uses a diagonal matrix in place of the sum of the products of its Hessian matrices for each element and the error in that element's current value, and in this post we shall take a look at one of them.

What is it with Business Agility?

Top of my Slack channels is the Business Agility Institute, just below that is the old #NoProjects slack that sometimes comes to life. Recently someone on #NoProjects asked:

Q: What do you guys think about Business Agility?

My reply: Business Agility, bit like apple pie, how can one not be in favour?

Of course, what flavour of business agility is another question. Lots of people seem to use the words “business agility” but I’m not sure there is a consensus on exactly what it is. I am a member, and supporter, of the Business Agility Institute which was founded by Evan Leybourn who also published a NoProjects book.

Evan and I were in regular communication while we were writing our books, we both saw the flaws in the project model and both arrived at the conclusion that as the business world digitalises business is never done therefore technology is never done. In essence that is the genesis of Continous Digital. While I wrote a book on the subject Evan founded the Business Agility Institute.

Q: So whats your take or how you think business agility is different from no-projects? is people just rebranding stuff to BA now?

My reply: Business Agility is good, it makes sense to go “up” from software to the business. Now look at the things you might want from Business Agility:

▪ Quick to market

▪ Fast to deliver

▪ Responsive to customers

▪ Reactive to trends and changes

▪ Efficient/effective

▪ … add your own here…

Isn’t that what any business wants? Whether you call it Business Agility or not? – these are apple pie things, hard to argue against and if you read (almost) any management textbook in the last 30 years they say the same things.

These aren’t #NoProjects, that is a very specific critique of the project model. Some people may have believed that projects facilitated those things, however what #NoProjects says is: the model is flawed, if you want those things you need to find another way. For me that other way is Continous Digital, which is why my presentations talk of #NoProjects evolution: it is not enough to say “projects don’t work”, one needs to suggest an alternative.

So how is Business Agility different?

First off: even if the things Business Agility offers aren’t new the rise of Business Agility is a new opportunity to push an agenda which is good, sometimes things need to be “rebranded” as new to get attention. Should’t be but there you are.

Second, the methods have changed: two forces at work here, Digital and “Millennials”

Digital tools – driven by Moore’s Law and the falling price of CPU power – have changed the way business works, it means that the things executives often want to avoid, software development, is now the power house of your business.

Hence, “the business is the technology and the technology is the business.” Think Uber: how do you separate Uber’s technology from Uber the taxi company?

This is why I have take to saying “IT is dead, IT’s Digital”. Information technology in business is no longer a cost centre, it is no longer “just” and enabler for business services, Digital means it is the business, it is were innovation happens and it is a driver of revenue and profitability.

That also means “Agile Methods” (a la software engineering) come into focus because a) you need to create software and b) as digital tools permeate every aspect of business life agile becomes more applicable.

Agile methods are the processes that maximised the benefits of digital tools. Agile started with software engineers (and friends) because they had early access to digital tools (email, IM, VOIP, web, wiki, etc.) and are able to create “missing” tools

Millennials: those born about 2000 are said to want more meaning, purpose and autonomy in their work. Personally I’ve always wanted these things and I think everyone does. Whether I am right or not this is a trend which has been running for a while, millennials exhibit this most clearly. (Plus the pandemic adds to this)

This too fits with agile because agile methods recognise the people aspect, people in agile are not plug compatible (although we do encourage a more team based approach.). Agile considers motivation and recognise those doing the work as experts in their own right – are better at addressing that need.

Hence, and a point I’m making in my “Reawakening Agile with OKRs” presentation which I’m delivering this year, we need to think more about purpose driven development – PDD. Our software needs purpose so our people have purpose.

Ultimately, while business agility might not be anything new there is a greater need for it.


Subscribe to my blog newsletter and download Continuous Digital for free – normal price $9.99/£9.95/€9.95

The post What is it with Business Agility? appeared first on Allan Kelly Associates.

Announcing I-DUNNO 1.0 and web-i-dunno

It’s hard to believe it’s already a year since the release of RFC 8771 (The Internationalized Deliberately Unreadable Network NOtation), which for me at least made me think about IP addresses in a whole new way.

So, it seems fitting for the anniversary to be able to release proper support for this standard in the Rust universe, with Rust I-DUNNO version 1.0 released. You can find it on Rust’s crates.io at crates.io/crates/i-dunno and the API documentation is at docs.rs/i-dunno.

Also, because for a standard like this to receive the wide adoption it deserves, it’s important that young people have a chance to interact with it, playing with encodings to get a real feel for what it’s like to use in practice, I’m proud to announce the I-DUNNO Creator. On that page you can enter an IP address (IPv4 or IPv6) and see it transformed immediately into a candidate I-DUNNO, with live information about the Confusion Level of the I-DUNNO, as specified in the standard. You can find the source code for the I-DUNNO Creator in the web-i-dunno repo.

The I-DUNNO Creator is built on the Rust package, making use of Rust’s highly-developed WASM support to compile the code into a form that works naturally in a web browser.

I hope that by offering both systems programmers and the young people of today and their new-fangled web sites the opportunity to create I-DUNNOs, I can contribute a little to spreading the word about deliberately unreadable notations to new audiences.

Note: the current implementation is limited to generate only I-DUNNOs with no padding bits. As specified in the standard, I-DUNNOs may end with arbitrary padding, and adding this functionality to rust-i-dunno is left as an exercise for the reader: merge requests welcome!

Linux has a sleeper agent working as a core developer

The latest news from Wikileaks, that GCHQ, the UK’s signal intelligence agency, has a sleeper agent working as a trusted member on the Linux kernel core development team should not come as a surprise to anybody.

The Linux kernel is embedded as a core component inside many critical systems; the kind of systems that intelligence agencies and other organizations would like full access.

The open nature of Linux kernel development makes it very difficult to surreptitiously introduce a hidden vulnerability. A friendly gatekeeper on the core developer team is needed.

In the Open source world, trust is built up through years of dedicated work. Funding the right developer to spend many years doing solid work on the Linux kernel is a worthwhile investment. Such a person eventually reaches a position where the updates they claim to have scrutinized are accepted into the codebase without a second look.

The need for the agent to maintain plausible deniability requires an arm’s length approach, and the GCHQ team made a wise choice in targeting device drivers as cost-effective propagators of hidden weaknesses.

Writing a device driver requires the kinds of specific know-how that is not widely available. A device driver written by somebody new to the kernel world is not suspicious. The sleeper agent has deniability in that they did not write the code, they simply ‘failed’ to spot a well hidden vulnerability.

Lack of know-how means that the software for a new device is often created by cutting-and-pasting code from an existing driver for a similar chip set, i.e., once a vulnerability has been inserted it is likely to propagate.

Perhaps it’s my lack of knowledge of clandestine control of third-party computers, but the leak reveals the GCHQ team having an obsession with state machines controlled by pseudo random inputs.

With their background in code breaking I appreciate that GCHQ have lots of expertise to throw at doing clever things with pseudo random numbers (other than introducing subtle flaws in public key encryption).

What about the possibility of introducing non-random patterns in randomised storage layout algorithms (he says waving his clueless arms around)?

Which of the core developers is most likely to be the sleeper agent? His codename, Basil Brush, suggests somebody from the boomer generation, or perhaps reflects some personal characteristic; it might also be intended to distract.

What steps need to be taken to prevent more sleeper agents joining the Linux kernel development team?

Requiring developers to provide a record of their financial history (say, 10-years worth), before being accepted as a core developer, will rule out many capable people. Also, this approach does not filter out ideologically motivated developers.

The world may have to accept that intelligence agencies are the future of major funding for widely used Open source projects.