Structure and Interpretation of Computer Programmers

I make it easier and faster for you to write high-quality software.

Wednesday, July 25, 2018

On study-only licences

In my previous post, I mused on the value of Freedom Zero and of a non-free licence that allows for study but not for use:

I think it would have to be a licence that enabled studying, sharing and modification of the software, but that explicitly forbade any use for any purpose that isn’t studying, modifying or sharing. With a “contact me or my agent, tell us what you’re doing, and we’ll decide whether to grant you an additional licence for use” suffix. This is more open than closed proprietary software, but no more available for deployment to bad actors.

Waking up this morning I remembered that I have a copy of Numerical Recipes. This is a book, that contains code, and as such you can read the code. But not much else:

Without an additional license to use the contained software, this book is intended as a text and reference book, for reading and study purposes only. However, a restricted, limited free license for use of the software by the individual owner of a copy of this book who personally keyboards one or more routines into a single computer is granted under terms described on p.xix.

Page xix expands:

If you personally keyboard no more than 10 routines from this book into your computer, then we authorize you (and only you) to use those routines (and only those routines) on that single computer.

If you want to study, or to try things, knock yourself out. If you want to distribute things, or use things, get in touch and we’ll choose whether to sell you a licence.

This is not unexplored territory.

posted by Graham at 09:49  

Tuesday, July 24, 2018

Is Freedom Zero such a hot idea?

I’ve been thinking lately that if we don’t want to work on the databases that extremist governments use to detain immigrants they have separated from their children, or on the operating systems that well-equipped militaries used to rain autonomous death from above, or the image processing tools used by mass surveillance networks, then we need to stop dishing out the freedom to run the program as you wish, for any purpose.

That also means discriminating against fields of endeavour, so such software would not only not be Free Software but not even Open Source. I’m OK with that, if it also means that it’s not used for purposes I don’t want to support. I still think Free Software is better than closed proprietary software, but have come to believe that Free Software is the amoral option where what our field needs is morality.

I don’t know what this would look like. I do not believe it would look like The JSON Licence, which is open to misinterpretation (intentional or otherwise). I think it would have to be a licence that enabled studying, sharing and modification of the software, but that explicitly forbade any use for any purpose that isn’t studying, modifying or sharing. With a “contact me or my agent, tell us what you’re doing, and we’ll decide whether to grant you an additional licence for use” suffix. This is more open than closed proprietary software, but no more available for deployment to bad actors.

Yes, that can be abused, but that doesn’t mean it’s not worth trying.

posted by Graham at 19:14  

Tuesday, July 17, 2018

Story points: there’s no right way to do it

Story points as described represent an attempt to abstract estimation away from “amount of stuff done per unit time”, because we’re bad at doing that and people were traditionally using that to make us look bad. So we introduce an intermediate value, flip a ratio, and get the story point: the [meaningless value] per amount of stuff. Then we also get the velocity, which is the [meaningless value] per unit time, and…

…and we’re back where we started. Except we’re not, we’re slower than we were before, because it used to be that people asked “how much do you think you can get done over the next couple of weeks”, and we’d tell them, and we’d be wrong. But now they ask “how big is this stuff”, then they ask “how much capacity for stuff is there over the next couple of weeks”, and we tell them both of those things, and we get both wrong, so we still have a wrong answer to the original question but answered two distinct questions incorrectly to get there.

There’s no real way out of that. The idea that velocity will converge over time is flawed, both because the team, the context, and the problem are all changing at once, and because the problem with estimation is not that we’re Gaussian bad at it, but that we’re optimistic bad at it. Consistently, monotonically, “oh I think this will just mean editing some config, call it a one-pointer”-ingly, we fail to see complexity way more than we fail to see simplicity. The idea that even if velocity did converge over time, we would then have reliable tools for planning and estimation is flawed, because what people want is not convergence but growth.

Give people 40 points per sprint for 20 sprints and you’ll be asked not how you became so great at estimation, but why your people aren’t getting any better. Give them about 40 points per sprint for 20 sprints, and they’ll applaud the 44s and frown at the 36s.

The assumption that goes into agile, lean, kanban, lean startup, and similar ideas is that you’re already doing well enough that you only need to worry about local optima, so you may as well take out a load of planning overhead and chase those optima without working out your three-sprint rolling average local optimisation rate.

posted by Graham at 17:26  

Wednesday, July 11, 2018

OOP the Easy Way

It’s still very much a work in progress, but OOP the Easy Way is now available to purchase from Leanpub (a free sample is also available from the book’s Leanpub page). Following the theme of my conference talks and blog posts over the last few years, OOP the Easy Way starts with an Antithesis, examining the accidental complexity that has been accumulating under the banner of Object-Oriented Programming for nearly four decades. This will be followed by a Thesis, constructing a model of software objects from the essential core, then a Synthesis, investigating problems that remain unsolved and directions that remain unexplored.

At this early stage, your feedback on the book is very much welcome and will help yourself and fellow readers to get more from the book. You will automatically get updates for free as they are published through Leanpub.

I hope you enjoy OOP the Easy Way!

posted by Graham at 14:30  

Powered by WordPress