Mutant algorithms

Fran from BuontempoConsulting

 The word "algorithm" has caused a storm in recent news in the UK. Due to COVID-19 school children were not able to sit their exams. This left 16 and 18 year olds waiting to see how they would be assessed, and had obvious implications for their academic or career futures.  As you may know, the grades were awarded based on an "algorithm", which our Prime Minister later described as mutant. According to the BBC news, he said "'Mutant algorithm' caused exam chaos." This begs the question, what does our PM think a mutant algorithm is?

The news in the UK has talked generally about the algorithm's inputs being course work and teacher's estimated grades. These are "mutated" (or adjusted) by the algorithm to take into account a school's performance over the last three years. This means schools whose pupils sometimes struggle are more likely to be down-graded. The precise details are buried in a 319 page report. Feel free to read it all and report back. TL;DR; Private and public schools tend to get higher grades than government run schools, so poorer pupils tended to get down-graded and richer pupils did not. Some form of mutation, or even perversion, perhaps of justice, but not in the algorithm. 

Now, some algorithms do use mutation. In fact genetic algorithms rely on mutation to seek out new solutions to problems. This is guided by a fitness function, to check the "mutant algorithm" is doing what's required. You can test such algorithms to see what they do, and keep an eye on them as they run to check they are heading the right way. You frequently spend a long time tuning parameters to get better results. This, on the face of it, has nothing whatsoever to do with the "mutant algorithm" our PM was talking about. 

There has also be a hint of slur on the programmers who wrote the algorithm, suggesting the idea was good and proper but the naughty programmers took it upon themselves to do something completely different that got out of hand, like a Marvel movie. Think Magneto (naughty programmers) versus Charles Francis Xavier (sensible people like, our PM? Go figure). I am sick of programmer bashing and the general misunderstanding of algorithms.

Where a genetic algorithm uses mutation, or a Monte Carlo simulation uses random numbers as input, it is still possible to test the algorithm is doing what you require. Programmers should never abdicate responsibility for what they have built. However, it is highly irresponsible of the news to allow propaganda and misrepresentations to flourish like this. 

A while ago, the Imperial College model for COVID-19 was open-sourced. At the time many people raised bug reports against it. One rumour suggested that running it twice with the same seed for the pseudo-random numbers would produce different results. Now, that might be described as a "mutant algorithm", but we'd usually describe this as buggy code. I don't believe our PM has the technical know-how to spot buggy code, but I'm willing to help him out if he wants. I'm also willing to be interviewed by the BBC to explain some of these technical issues in more detail, if they are interested. Or I could find other technical people who could equally well help out.

DM me.

https://twitter.com/fbuontempo


 



The aims of software engineering research

Derek Jones from The Shape of Code

Physics researchers aim to explain the workings of the universe (technically they build models whose behavior mimics that of the universe we can measure), biologists the workings of biological systems, and psychologists the working of the human mind.

What are researchers in software engineering aiming to do?

Talking to academics, the answer is that they aim to do research that can be published in a high impact journal.

What do those involved in commercial software development think software engineering researchers should be aiming to achieve?

Most of the commercial developers I have asked have never thought about the subject; hardly surprising, they have plenty of other issues to think about.

Those who pay for software, rather than create it, want it to be cheaper and delivered faster.

Vendors are under some pressure to reduce costs and deliver sooner. But since its inception, software has been a sellers market, which means the customer pressure does not have the impact it has in other industries.

The very large organizations who pay lots of money for software for their own use (e.g., the U.S. Department of Defence) recognise that research into software production may well save them lots of money, and at one time interesting things were being discovered, but then funding got rerouted to people with an aversion to actual software engineering, i.e., academics.

Cheaper and faster will always be of interest, and will start to become a hot topic in software engineering research once software starts to becoming a buyers market.

Maintaining existing systems continues its growth to dominating what nearly every software developer does. Dependencies on the rest of the software world (e.g., libraries and compilers) is starting to consume a large percentage of maintenance costs. Managers want to know which packages are likely to have a long and stable lifetime, and which are likely to be short-lived. An understanding of the evolution of software ecosystems is a pressing need. This is really cheaper and faster over the long term.

Cheaper and faster (short term for development, long term for maintenance) covers everything.

It’s tempting to list personnel selection, i.e., who is likely to make the best software developer. But why should the process of selecting software developers be any different from the processes used to select people to become doctors, lawyers and other professions? I’m sure that those involved in the various professions would like a magic wand that points to the appropriate people (for some definition of appropriate), this magic wand is no more likely to exist for software developers than any other profession.

What do you think the aims of software engineering research should be?

Digital Ocean’s PaaS Goes BETA

Paul Grenyer from Paul Grenyer

Make no mistake, I LOVE DigitalOcean! It’s simple to use and reasonably priced, especially compared to some of its better known competitors. They even respond quickly to queries on Twitter!

A couple of days ago I received an email from DigitalOcean inviting me to try out their new Beta 2 for App Platform (DigitalOcean’s PaaS product) which they described as follows:

“It handles common infrastructure-related tasks like provisioning and managing servers, databases, operating systems, application runtimes, and other dependencies. This means you can go from code to production in just minutes. We support Node.js, Python, Ruby, Go, PHP, and static sites right out of the box. If you have apps in other languages, simply create a Dockerfile and App Platform will do the rest. You can deploy apps directly from your Github repos and scale them (vertically and horizontally) if needed.….”

I’m also a fan of Heroku for its ease of application deployment and, with the exception of a few AWS services, Heroku is the only platform other than DigitalOcean which I regularly use for deploying my projects. I use Heroku because I don’t have to provision a Droplet (a Linux server on DigitalOcean) to run a simple web application. Now that DigitalOcean has a similar service there’s a good chance I won’t need Heroku.

The DigitalOcean App Platform (which I’ll refer to as ‘Apps’ from here on) doesn’t yet have as many features as Heroku, but the corresponding features which Apps does support are much simpler to work with. There are basically two types of applications you can run, a static website (static), a web application (service) or a worker. A worker is basically a service without any routing and can be used for background tasks. As with Heroku you can add databases as well.

Apps is currently in Beta which means it’s an initial release of a potential future product. Customers who participate in DigitalOceans beta programs have the opportunity to test, validate, and provide feedback on future functionality, which helps DigitalOcean to focus their efforts on what provides the most value to their customers.

  • Customer availability: Participation in beta releases is by invitation, and customers may choose not to participate. Beta invitations may be public or private. (How exciting, they picked me!).
  • Support: Beta releases are unsupported.
  • Production readiness: Beta releases may not be appropriate for production-level workloads.
  • Regions: Beta offerings may only be available in select regions.
  • Charges: Beta offerings may be charged or free. However, free use of beta offerings may be discontinued at any point in time.
  • Retirement: At the end of a beta release, DigitalOcean will determine whether to continue an offering through its lifecycle. We reserve the right to change the scope of or discontinue a Beta product or feature at any point in time without notice, as outlined in our terms of service.

I was (am!) very excited and decided to try a few things out on Apps. Below you’ll find what I tried, how I did it and some of what I learnt.

Static Asset App

The simplest type of ‘app’ which you can deploy to Apps is a static website and it really is straight forward. Remember the days when you would develop a website by creating files in a directory and opening them locally in a browser? Well, once you’ve done that you can just push them to GitHub and they’re on the web!

1. Create a new GitHub repository - it can be private or public.

2. Add a single index.html file, e.g:

<!doctype html>
<html lang="en">
  <head>
    <!-- Required meta tags -->
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
    <!-- Bootstrap CSS -->
    <link rel="stylesheet" ref="https://stackpath.bootstrapcdn.com/bootstrap/4.5.2/css/bootstrap.min.css" integrity="sha384-JcKb8q3iqJ61gNV9KGb8thSsNjpSL0n8PARn9HuZOnIxN0hoP+VmmDGMN5t9UJ0Z" crossorigin="anonymous">
    <title>Hello, App Platform!</title>
  </head>
  <body>
    <h1>Hello, App Platform!</h1>
    <!-- Optional JavaScript -->
    <!-- jQuery first, then Popper.js, then Bootstrap JS -->
    <script src="https://code.jquery.com/jquery-3.5.1.slim.min.js" integrity="sha384-DfXdz2htPH0lsSSs5nCTpuj/zy4C+OGpamoFVy38MVBnE+IbbVYUew+OrCXaRkfj" crossorigin="anonymous"></script>
    <script src="https://cdn.jsdelivr.net/npm/popper.js@1.16.1/dist/umd/popper.min.js" integrity="sha384-9/reFTGAW83EW2RDu2S0VKaIzap3H66lZH81PoYlFhbGU+6BZp6G7niu735Sk7lN" crossorigin="anonymous"></script>
    <script src="https://stackpath.bootstrapcdn.com/bootstrap/4.5.2/js/bootstrap.min.js" integrity="sha384-B4gt1jrGC7Jh4AgTPSdUtOBvfO8shuf57BaghqFfPlYxofvL8/KUEfYiJOMMV+rV" crossorigin="anonymous"></script>
  </body>
</html>

I’ve used the Bootstrap Hello, World! example as it brings in CSS and JavaScript, but any HTML example will do.

3. Log into DigitalOcean and select Apps from the left-hand menu.

4. If it’s your first App click ‘Launch App’. Otherwise click ‘Create App’.

5. Then click ‘GitHub’. If this is your first App, select ‘Configure your GitHub permissions’ and follow the instructions to link your GitHub account.

6. Back in Apps, select your new repository from the dropdown list and click Next.

On the next page you’ll be asked to choose a name for the app, select the branch to use from your repository and configure ‘Autodeploy on Push’.

7. Update the name of the app if you want to, leave the rest of the defaults as they are and click Next.

On the next page you have the option to add build and run commands. You don’t need any for a simple HTML app.

8. On the ‘Choose Build Configuration’ page click ‘Launch App’ to deploy the app and wait while Apps configures the app.

9. After receiving the ‘Deployed successfully!’ message, click the ‘Live App’ link to launch the app in a new tab.

That’s it! Your HTML page is now live on DigitalOcean’s App Platform. You can treat your repository just like the root directory of a website and add pages, images and JavaScript as you need. Just add them to the repository, commit, push and wait for them to be deployed.

Apps will generate a URL with a subdomain which is a combination of the name of your app and a unique sequence of characters, on the domain .ondigitalocean.app. You can configure a custom domain from the app’s settings tab and Apps provides a CNAME for redirection.


Node App

The next step up from a static asset app is a simple node webapp. Apps will install Node.js and your app’s dependencies for you and then fire up the app.

I was hoping to be able to deploy a very simple node webapp such as:

var http = require('http');

http.createServer(function (req, res) {

  res.write('Hello, App Platform!');

  res.end();

}).listen(process.env.PORT || '3000');

But this seemed to confuse Apps. It requires a package-lock.js file, which is generated by running npm install, to be checked into the repository and didn’t deploy successfully until I added the express package. 

1. Create a new directory for a simple node project and move into it.

2. Run npm init at the command line. Enter a name for the app and accept the other defaults.

3. Add a .gitignore file containing:

node_modules

so that dependencies are not checked into the repository.

4. Add the Express () package:

npm install express --save

This will also generate the package-lock.js which Apps needs and must be checked into the repository with the other files.

5. Create an index.js file at the root of the project:

const express = require('express')

const app = express()

const port = process.env.PORT || '3000';

app.get('/', (req, res) => {

  res.send('Hello World!')

})

app.listen(port, () => {

  console.log(`Example app listening at http://localhost:${port}`)

})

Apps injects the port the webapp should run on as an environment variable called, PORT. This is easily read by Node.js as shown.

6. Add a start command to the scripts section in package.json:

"scripts": {

    "start": "node index.js",

    "test": "echo \"Error: no test specified\" && exit 1"

  },

7. Create a new GitHub repository, it can be private or public, and check your node project into it.

Then follow from step 3 of the Static Asset app above. Note at step 8, Apps has automatically configured npm start as the run command, having detected a Node application and you can select the pricing plan on the same screen.

WARNING: Node applications are NOT free on DigitalOcean App Platform. Make sure you delete unwanted applications from the Settings tab.


Docker App

As well as Node.js, Apps appears to support Ruby, Go and Python nativity, as well as others. What about .Net or other languages and platforms? For those Apps supports Docker. Let’s see if we can get a simple dotnet core application running in Apps.

1. Create a new directory for a dotnet core project (e.g. dotnetcore) and move into it.

2. Create a dotnet core web application:

dotnet new webapp

3. Add a Dockerfile to the project:

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build-env

WORKDIR /app

# Copy everything else and build

COPY . ./

RUN dotnet publish dockercore.csproj -c Release -o out

# Build runtime image

FROM mcr.microsoft.com/dotnet/core/sdk:3.1

WORKDIR /app

COPY --from=build-env /app/out .

EXPOSE $PORT

ENTRYPOINT [ "dotnet", "dockercore.dll" ]

Apps injects the port the webapp should run on as an environment variable called, PORT. Make sure the Docker image will expose it as shown.

4. To make sure the application runs on the port injected add the following UseUrls method call in program.cs:

public static IHostBuilder CreateHostBuilder(string[] args)

{

    var port = Environment.GetEnvironmentVariable("PORT") ;

    return Host.CreateDefaultBuilder(args)

        .ConfigureWebHostDefaults(webBuilder =>

        {

            webBuilder.UseStartup<Startup>().UseUrls($"http://+:{port}");

        });

}

5. To prevent the application trying to redirect to a non-existent ssl port, remove or comment out the following line from startup.cs

// app.UseHttpsRedirection();

6. Building a dotnet core application generates a lot of intermediate files that you don’t want to check in, so add an appropriate .gitignore file to the root of the project.

7. Create a new GitHub repository, it can be private or public, and check your dotnet core project into it.

Then follow from step 3 of the Static Asset app above. Note at step 8, Apps has detected the Dockerfile and is not giving the option for build commands. You don’t need to specify any run commands and you can select the pricing plan on the same screen.

WARNING: Docker based  applications are NOT free on DigitalOcean App Platform. Make sure you delete unwanted applications from the Settings tab.


Finally

There was one big disadvantage for me and that’s the lack of a free tier for anything more advanced than a static web application. The cost isn’t extortionate (https://www.digitalocean.com/docs/app-platform/#plans-and-pricing), but quite a bit for hobby programmers. If you want to use a database on top there’s a further cost, whereas this is free to begin with in Heroku.

Apps currently only supports GitHub. You can use private repositories, which is great, but I’d like to see BitBucket support as well. Heroku has its own git repositories as well as supporting external repositories. 

I’d also like there to be Terraform support for Apps as there is for the rest of the DigitalOcean services. However, given that Apps in Beta, I can see why it isn’t supported yet.

Overall Apps was very easy to use and had a much shallower learning curve and was generally easier to use than Heroku.  DigitalOcean, do you think we could have AWS style Lambdas next, please?


User Story or Epic?

Allan Kelly from Allan Kelly Associates

GoldenRules-2020-08-26-19-57.jpeg

I have two golden rules for user stories:

  1. The story should deliver business value: it should be meaningful to some customer, user, stakeholder. In some way the story should make their lives better.
  2. The story should be small enough to be delivered soon: some people say “within 2 days” but I’d generous, after all I used to be a C++ programmer, I’m happy as long as the story can be delivered within 2-weeks, i.e. the standard size of a sprint.

Now these two rules are in conflict, the need for value – and preferably more value! – pushes stories to be bigger while the second rule demands they are small. That is just the way things are, there is no magic solution, that is the tension we must manage.

Those two rules also help us differentiate between stories and epics – and tasks if you are using them:

  • Epics honour rule #1, epics are very valuable but they are not small, by definition they are large this epics are unlikely to be delivered soon
  • Tasks honour rule #2, they are small, very small, say a day of work. But they do not deliver value to stakeholders – or if they do it is not a big deal

EpicsStoriesTasks-2020-08-26-19-57.jpeg

Tasks are the things you do to build stories. And stories are the things you do to deliver epics. If you find you can complete a story without doing one of the planned tasks then great, and similarly not all stories need to be completed for an epic to be considered done.

In an ideal world you would not need tasks, every story would be small enough to stand alone. Nor would you need epics because stories would justify themselves. We can work towards that world but until then most teams of my experience use two of these three levels – stories and tasks or epics and stories. A few even use all three levels.

Using more than three is an administration problem. There is always a fourth level above these, the project or product that is the reason they exist in the first place. But really, three levels is more than enough to model just about anything: really small, small, and damn big.

And every story is a potential epic until proven guilty.

More about epics, stories and tasks in Little Book of Requirements and User Stories and in my User Stories Masterclass next month (use Blog15 for 15% discount).


September micro-workshops – spaced limited

User Stories Masterclass, Agile Estimation & Forecasting, Maximising value delivered

Early bird discounts & free tickets for unemployed/furloughed

Book with code Blog15 for 15% discount or get more details


The post User Story or Epic? appeared first on Allan Kelly Associates.

User Story or Epic?

Allan Kelly from Allan Kelly Associates

GoldenRules-2020-08-26-19-57.jpeg

I have two golden rules for user stories:

  1. The story should deliver business value: it should be meaningful to some customer, user, stakeholder. In some way the story should make their lives better.
  2. The story should be small enough to be delivered soon: some people say “within 2 days” but I’d generous, after all I used to be a C++ programmer, I’m happy as long as the story can be delivered within 2-weeks, i.e. the standard size of a sprint.

Now these two rules are in conflict, the need for value – and preferably more value! – pushes stories to be bigger while the second rule demands they are small. That is just the way things are, there is no magic solution, that is the tension we must manage.

Those two rules also help us differentiate between stories and epics – and tasks if you are using them:

  • Epics honour rule #1, epics are very valuable but they are not small, by definition they are large this epics are unlikely to be delivered soon
  • Tasks honour rule #2, they are small, very small, say a day of work. But they do not deliver value to stakeholders – or if they do it is not a big deal

EpicsStoriesTasks-2020-08-26-19-57.jpeg

Tasks are the things you do to build stories. And stories are the things you do to deliver epics. If you find you can complete a story without doing one of the planned tasks then great, and similarly not all stories need to be completed for an epic to be considered done.

In an ideal world you would not need tasks, every story would be small enough to stand alone. Nor would you need epics because stories would justify themselves. We can work towards that world but until then most teams of my experience use two of these three levels – stories and tasks or epics and stories. A few even use all three levels.

Using more than three is an administration problem. There is always a fourth level above these, the project or product that is the reason they exist in the first place. But really, three levels is more than enough to model just about anything: really small, small, and damn big.

And every story is a potential epic until proven guilty.

More about epics, stories and tasks in Little Book of Requirements and User Stories and in my User Stories Masterclass next month (use Blog15 for 15% discount).


September micro-workshops – spaced limited

User Stories Masterclass, Agile Estimation & Forecasting, Maximising value delivered

Early bird discounts & free tickets for unemployed/furloughed

Book with code Blog15 for 15% discount or get more details


The post User Story or Epic? appeared first on Allan Kelly Associates.

Agile Guide podcast with Wood Zuill and Tom Cagley

Allan Kelly from Allan Kelly Associates

I’m on a mission to popularise the term Agile Guide. A few weeks ago Wood Zuill (farther of Mob Programming and force behind #NoEstimates) and I recorded a podcast with Tom Cagley – another in his SpamCast series – on the Agile Guide role.

You can download the Agile Guide podcast from libsyn or you can download it from Apple, Sitcher, Google or Spotify.

The post Agile Guide podcast with Wood Zuill and Tom Cagley appeared first on Allan Kelly Associates.

All books bundle summer discoiunt

Allan Kelly from Allan Kelly Associates

PastedGraphic-2020-08-26-18-48.png
Now seems the time to add Agile & OKRs to my all books bundle on LeanPub. This bundle allows you to buy all six of my LeanPub books in one go at a discount – $27 instead of $68. While the addition doesn’t apply retrospectively anyone buying the bundle from now on will get Agile OKRs in addition to the other six books.

And for the week the bundle is discounted to $19.99 using the code Summer33 on the LeanPub site.

(Unfortunately I can’t include The Art of Agile Product Ownership, Business Patterns or Changing Software Development in this bundle because the copyright is now owned by the publishers.)


Subscribe to my blog newsletter and download Project Myopia for Free

The post All books bundle summer discoiunt appeared first on Allan Kelly Associates.

Time-to-fix when mistake discovered in a later project phase

Derek Jones from The Shape of Code

Traditionally the management of software development projects divides them into phases, e.g., requirements, design, coding and testing. A mistake introduced in one phase may not be detected until a later phase. There is long-standing folklore that earlier mistakes detected in later phases are much much more costly to fix persists, despite the original source of this folklore being resoundingly debunked. Fixing a mistake later is likely to a bit more costly, but how much more costly? A lack of data prevents reliable analysis; this question also suffers from different projects having different cost-to-fix profiles.

This post addresses the time-to-fix question (cost involves all the resources needed to perform the fix). Does it take longer to correct mistakes when they are detected in phases that come after the one in which they were made?

The data comes from the paper: Composing Effective Software Security Assurance Workflows. The 35,367 (yes, thirty-five thousand) logged fixes, from 39 projects drawn from three organizations, contains information on: phases in which the mistake was made and fixed, time taken, person ID, project ID, date/time, plus other stuff :-)

Every project has its own characteristics that affect time-to-fix. Project 615, avionics software developed by organization A, has the most fixes (7,503) and is analysed here.

Avionics software is safety critical, and each major phase included its own review and inspection. The major phases include: requirements gathering, requirements analysis, high level design, design, coding, and testing. When counting the number of phases between introduction/fix, should review and inspection each count as a phase?

The primary reason for doing a review and inspection is to check the correctness (i.e., lack of mistakes) in the corresponding phase. If there is a time-to-fix penalty for mistakes found in these symbiotic-phases, I suspect it will be different from the time-to-fix penalty between major phases (which for simplicity, I’m assuming is major-phase independent).

The time-to-fix has a resolution of 1-minute, and some fix times are listed as taking a minute; 72% of fixes are recorded as taking less than 10-minutes. What kind of mistakes require less than 10-minutes to fix? Typos and other minutiae.

The plot below shows time-to-fix for mistakes having a given ‘distance’ between introduction/fix phase, for fixes taking at least 1, 5 and 10-minutes (code+data):

Time-to-fix for mistakes having a given number of phases between introduction and fix.

There is a huge variation in time-to-fix, and the regression lines (which have the form: fixTime approx e^{sqrt{phaseSep}}) explains just 6% of the variance in the data, i.e., there is a small increase with phase separation, but it is almost down in the noise.

All but one of the 38 people who worked on the project made multiple fixes (30 made more than 20 fixes), and may have got faster with practice. Adding the number of previous fixes by people making more than 20 fixes to the model gives: fixTime approx e^{sqrt{phaseSep}}/fixNum^{0.03}, and improves the model by less than 1-percent.

Fixing mistakes is a human activity, and individual performance often has a big impact on fitted models. Adding person ID to the model as a multiplication factor: i.e., fixTime approx personID*{e^{sqrt{phaseSep}}/fixNum^{0.03}}, improves the variance explained to 14% (better than a poke in the eye, just). The fitted value of personID varies between 0.66 and 1.4 (factor of two, human variation).

The answer to the time-to-fix question posed earlier (for project 615), is that it does take slightly longer to fix a mistake detected in phases occurring after the one in which the mistake was introduced. The phase difference is tiny, with differences in human performance having a bigger impact.

We Three Kings – baron m.

baron m. from thus spake a.k.

Sir R----- my fine friend! Will you take a glass of perry with me to cool yourself from this summer heat?

Good man!

Might I also presume that you are in the mood for a wager?

Stout fellow!

I suggest a game that ever puts me in mind of that time in my youth when I squired for the warrior king Balthazar during his pilgrimage with kings Melchior and Caspar to the little town of Bethlehem.

Online Concurrency Classes

Anthony Williams from Just Software Solutions Blog

With all the restrictions brought upon us by COVID-19, many C++ conferences are moving online.

This includes Cppcon and NDC Tech Town, both of which are being run as 100% virtual conferences this year.

I will be running my More Concurrent Thinking class as an online class for both conferences.

The class at NDC Tech Town will be a 2-day class running on 31st August 2020 and 1st September 2020, 9am - 5pm CEST, which is 0700 - 1500 UTC.

The class at Cppcon will be a 3-day class running on 9th September 2020 to 11th September 2020, 11am - 5pm EDT, which is 1500 - 2100 UTC.

The content is the same in both cases, though the timings are clearly different. Hopefully one or other fits in with your local timezone.

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