Can’t you just…

Posted on 2016-11-19 by Graham

Continuing the thoughts on vexing problems, one difficulty when it comes to discussing software is talking about the size of software. I’m not really talking about productivity metrics – good or bad – like source lines of code or function points, rather the fact that the complexity of a problem looks different depending on who’s doing the looking.

Sometimes, a problem that’s very simple from a business perspective can be incredibly complex technically. One product I worked on could be summarised very quickly: let people interact with marketing campaigns by sending and receiving messages on their mobiles. The small amount of logic between send and receive – allowing the campaigns to operate as quizzes, votes, or auctions – could be detailed on an index card.

But that simplicity was backed by a huge amount of technical complexity to make it work. “Can you just send this message to everyone who got the quiz question correct?” Well, yes, but as it’s a picture message we need to work out how to make it look good on the recipient phone, change it to fit those criteria, and then send it. What makes it look good – and indeed how we can get the information to make that decision – depends on the device, but also which network it’s on, and maybe whether it’s on pre-pay or post-pay and whether they use HTTP, WAP or e-mail to send messages to that device (which might be different from how they send to other devices on the same network). And even after we’ve gathered that information, it may be wrong as some devices claim to support image formats that they can’t render, or image sizes that they’ll actually reject or fail to display.

On the other hand, sometimes the business problem is a lot more complex than the technical problem. If you’re a mobile app developer, any length of problem definition about exciting disruptive apps can be reduced to “so you want to display data from a web service in a table view”.

And then at other times, “can’t you just” gets stymied from left field. Why yes, we could simply do that, and it would be good for the business, but this regulation/patent/staff shortage means we need to do something else.

Posted in Business | Leave a comment

On the business case for (or against) software

Posted on 2016-11-16 by Graham

In the vexing problems, I dismissed the hard problems of computer science as being incidental to another problem: we can’t say what the value of our work is. That post contained plenty of questions, precisely because the subject is so unknown.

There are plenty of ways in which the “value” of something can be discussed, but let’s stick with economic value for the moment. Imagine you have the opportunity to write some software, but only if I pay you for it. And not even then, but only if you can make me reasonably confident that I will get some return; that having the work done is worth more than the cost of you doing the work.

A corner of the software industry just cowered and stuck its head in the sand. “#NoEstimates!”, they cry. This problem is hard, so why should we solve it?

That’s a really interesting perspective. You should come and talk about #NoEstimates at my conference. It’ll be on sometime, in a place, and there’ll be a flight that can get you there. Maybe. That’s enough information to be going on for it to be clear that you should commit to it, so I’ll see you there.

At the other end are the folks who would literally write whole books about the topic (and given that books are themselves literary, that “literally” is itself meant literally). I pulled a few likely titles off the shelf to see what they would tell me, and ended up with:

We have to wonder how some people can be certain that estimates are worthlessly inaccurate, while others such as Barry Boehm (the author of Software Engineering Economics and the COnstructive COst MOdel it describes) have built careers out of explaining how to do it well.

Here’s one hypothesis: Boehm is a charlatan, and the COCOMO doesn’t work at all. Let’s see whether there’s evidence for that.

A likely source is COCOMO evaluation and tailoring by Miyazaki and Mori from Fujitsu. The authors of that paper, applying the COCOMO (’81, not the later COCOMO II) model to a corpus of projects undertaken by Fujitsu, conclude:

The original COCOMO overestimates the effort required to develop software in our environment, but its tailoring methodology is applicable. […] The resulting model fits 68% of the projects with less than 20% relative error, after the deletion of two outliers.

That’s maybe short of brilliant – the median project effort in their paper seems to be over 10 person-years, so they’re saying “there’s around two chances in three that we can tell you what this project will cost to within twice a developer’s salary” – but it’s much more precise than “#NoEstimates!” and only quite a lot less accurate.

It might be interesting to track the application of COCOMO through time, and see whether a larger corpus of projects and refinement of the model has improved its accuracy and applicability. Unfortunately, that goal is in conflict with a general industry observation, noted in the introduction of the Fujitsu paper:

We have the impression that software people prefer to start from scratch rather than improving upon the work of others, which seems to be slowing down the progress in this field.

And indeed much of what was written in the sources I’ve been talking about here is no longer applied. All three of the books I mentioned up top talk about Earned Value (EV) Analysis, recording the actual rate of delivering on a project against its Planned Value (PV). For example, Hughes and Cotterell recommend plotting earned value using the “0/100 technique”:

where a task is assigned a value of zero until such time as it is completed when it is given a value of 100% of the budgeted value

Agilistas will recognise the resulting plot: it’s a burn down chart, where a story is not delivered until it has been accepted according to the definition of done, at which point it is completely delivered.

Ultimately somebody in the Agile community must have noticed that they accidentally borrowed a software engineering concept, because the burn down chart is now unfashionable.

If the team starts with a very full, prioritized, and estimated backlog with the expectation they will burn down all tasks to zero — does this not sound like a Waterfall mentality?

Oh noes, the dreaded W word! Run away from this thought, for it is a thought that somebody in the past has already considered!

And that is why I consider these problems to be vexing: when potential solutions are proposed, they are by necessity existing ideas from the old school that must be rejected in favour of…whatever is not those solutions. As Craftsmanship is post-Agile is post-Software Engineering is post-Crisis thinking, surely it will soon be time for post-Craftsmanship thinking. And then post-whatever-comes-next thinking. And we still won’t know how to compare expected value to expected cost.

Posted in Business, economics | 2 Comments

The Vexing Problems in Programming

Posted on 2016-11-13 by Graham

I admit it, I’ve been on the internet for quite a while (I could tell you that my ICQ number is 95941970, but I haven’t logged in for years) and my habits haven’t changed. I still regularly get technology news from slashdot, and today was no exception. An interesting article was Here Be Dragons: The 7 most vexing problems in programming. Without wanting to spoil the article for you by giving away the punchline, there are indeed some frustratingly difficult problems mentioned: multithreading, security, encryption are among the list.

All of these problems are sideshows to what I see as one of the largest and most vexing issues in programming: the fundamental rule to business administration is that your income should be greater than your costs, but software makers still, by and large, don’t have a way to compare the expected value of their work to the expected cost of the work.

The problem in space

Different software teams – and individuals – do work in different contexts, and in different ways. The lone wolf micro-ISV is not the same as an individual contract developer. The in-house IT team does not have the same problems to solve as the shrinkwrapped software vendor, and those developing web services for public consumption have yet another context. The team with core hours all working in a single office is different from the distributed team inhabiting multiple time zones.

How much of this variety is essential, and how much is accidental? How much of it is relevant, when considering some intervention, process change, or technique? Consultants speaking at conferences (another context with its own similarities and differences from the others) don’t tend to talk about what researchers in fields such as psychology would recognise as “threats to validity” of their work, but given all of the ways in which software is made, we need to know whether some proposal applies to all of them, or to some of them, or whether it has been applied to some of them and might be applied to others, and what would assist or confound that application.

The problem in time

What are the accepted, tested and validated ways to identify who will be using and otherwise impacted by our software systems? To know whether they can use the system we propose, and whether it is the best system for their intended use? To ensure that our proposed software systems treat those people ethically? To understand the cost (to ourselves and to others) of constructing those systems? To deliver the systems to the people who will interact with them? To choose which people are or aren’t entitled to access? To build a representation of the problem to be solved, to validate that representation, to validate the solution against that representation?

Where an answer exists to those questions, what are the contexts in which it is valid and what are the threats to its validity? How has that answer been compared with other possibilities? How has it been confirmed? How has it been challenged? How can I find out about those confirmations and challenges? How can I find out about any alternatives? What techniques exist to weigh up those alternatives quantitively, rather than relying merely on the persuasiveness of the conference speakers promoting those solutions (and, by the way, the books/screencasts that describe the solutions)?

The lack of a problem

Why should I care? There’s enough money in software at the moment to mean that I don’t need to be any good at knowing what works or doesn’t work, I just need to get out there and sell some software. In the rare situation that I don’t make my money back, that’s just the market forces at work, and I can go and get a high-paying job somewhere while I lick my wounds, and pick another programming language/framework/platform/whatever it is that’s going to make my next attempt definitely succeed.

Clearly, this bottomless pit of money that arises from society’s unwavering faith in software and its ability to cure all ills is never going to run out. There’s no need to worry ever about whether we’re doing it right, because there’ll always be someone out there willing to pay for us to do it wrong. Life as a programmer is like some kind of socialist utopia where whether we’re making a valuable contribution or not, the rest of society is looking out for us.

That’s going to last forever, right?

Posted in Business, economics, Responsibility | 2 Comments

Withholding the Four Freedoms

Posted on 2016-10-31 by Graham

Having downsized my rather over-enthusiastic computer collection (thanks, eBay!), I was down to one computer. Unfortunately, as a rather long in the tooth MacBook Air, it’s no longer suited to my needs and neither is it upgradeable. I got all of the files I care about off of its disk and set out to look for a replacement, meanwhile setting the MacBook aside to one day wipe its e4fs storage and re-install Mac OS X/OS X/macOS/whatever we call it this week.

I chose the sort of spec computer I wanted, then carefully researched various vendors to see what components they used and whether there was reported driver support in the Linux kernel. Eventually, dude, I got a Dell. The Alienware 15 R3 is made of bits that are supported in Linux, with the most complex piece being that the network adapter requires binary firmware. The manufacturer includes links to the firmware blobs on their website though, so this can’t be hard…can it?

I fell straight to running the Debian Jessie installer, put the firmware blobs in place, and…the wi-fi isn’t detected. Oh well, it’s quite an old kernel, maybe I could switch to Testing? No, that doesn’t boot at all: some error about not getting valid cache information from the SSD. Neither does the Ubuntu 16.10 kernel boot, for the same reason. 16.04 boots just fine, and it detects the wireless and connects to the network…and then the installer crashes.

One thing I’m not looking forward to is the onslaught of replies to this post from people who want to help, but ultimately won’t help. “You should try Arch Linux, I expect that works,” or “maybe you’ll have better luck with Fedora.” Why do you expect that? What specific knowledge about my problem makes you think that your specific choice of distribution will work better? And why can’t I just take that knowledge and apply it to Debian, or Ubuntu? They’re just distributions, they’re all made of the same bits.

I admit, I’m frustrated. I want to be a proud advocate for Free Software and for totally free computing environments, but being unable to even run some of the flagship software makes me reticent to recommend it to others. I was having these problems back in 2001, and I’m having these problems now. And it’s not like I’m incompetent when it comes to *nix administration or to Linux driver configuration, and nor did I just buy the prettiest computer I could find and hope that it would work, I _did my research_. I spent hours making sure that there were drivers for the various components in this system, reading reviews, QA forum posts, and kernel mailing list messages. Unfortunately my willingness to screw about with configuring my computer just so that I can use it has waned over the last couple of decades, faster than the necessity to screw about with it has decreased.

For the moment, I’m running Windows 10 as a hardware abstraction layer, and have a full-screen VirtualBox VM to do my work in. It works, it makes me die a little inside but it works. But I’m worried that for all the crowing that open source is eating the world, it’s still too hard to jump in, even for a diligent and experienced user. Until we can give someone a computer that they turn on and start working in, and that runs free software, this will all remain the preserve of professionals and committed hobbyists. The Four Freedoms will effectively be restricted to those in the know and with time to dedicate to obtaining them: all users are equal, but some are more equal than others.

Posted in freesoftware, GNU, UI | Leave a comment

I didn’t study computer science at school or university, and still manage to work as a programmer.

That is not to say that I don’t need to know some things that are taught on computer science courses. Just this week I’ve had to build a couple of different data structures and understand their running time: very CS.

I’ve also needed to know things that aren’t on a CS degree, too. The acceptance criteria for one of my projects are written in French, and none of the CS courses I’ve seen in UK universities include that in the syllabus.

I’m neither arguing for nor against the validity of a CS background in professional software development. I’m arguing against taking either side. You need to know some CS things to write software, you need to know some other things, multiple backgrounds are appropriate and welcome.

Posted on 2016-10-26 by Graham | Leave a comment

Something old, something new

Posted on 2016-09-26 by Graham

Sometimes, what you want out of a software system is something
unexciting. Something proven to work, that’s well-understood, and has
had all of the kinks smoothed out over years (or even decades) of
refinement.

Of course, what you get when that’s what you want is something like
Unix. Where the thing it was designed for…well, let’s not pretend
that
Unix was ever designed. The
thing it was used for – hosting the runoff typesetting system that is
only applied these days to formatting its own manual – is so far from
its current application as a
bootloader sitting between your other bootloader and the thing you’re using your computer for
that you can’t understand why someone would think the same thing would
be used for both purposes.

And you find that the kinks have not been ironed out so much as, well,
baked in. The limitation that processes communicate via an untyped
character stream with unspecified eight-bit encoding is not a
limitation, it’s
a design philosophy.

So what you really want to do is to throw away all of that cruft,
all of the mistakes of the past, and go somewhere new. Somewhere
exciting. Somewhere…like node.js? Well no,
JavaScript is of course far from new and exciting, even
the jokes about it are
years old now.

OK, so bad example, but maybe you have your own counter-example. The
one true environment that will be used for all future software. Well,
at least for the next nine months, before its killer comes along.

Of course, what you get when that’s what you want is another rewrite
of all of the things that were working anyway. Your new environment
probably comes with a package manager written from scratch in the new
language, when there was really nothing much wrong with CPAN.

Keeping on the programming theme, because that’s what we tend to make
computering out of, most languages that have any traction these days
almost certainly have C language bindings. So it’s no surprise that
the most popular open source projects are all written in C…

…OK, now that you’ve stopped laughing and got your breath back, you
can appreciate that actually the lingua franca of modern (ahem)
operating systems is not used to cut through the babel of other
programming languages, but just to write their runtimes. Because
that’s what C is good at: secure, bounds-checked execution
environments.

And you can also appreciate that all of the novelty of the new shiny
is used to rewrite the things that already existed and already worked,
replacing them with new implementations that work in surprising ways
(and don’t work in surprising ways, too).

There’s good in the old. There’s bad in the new. There’s bad in the
old, and good in the new, too. There are plenty of social, political,
economic, and – maybe – technical factors in whether the old survives,
or the new thrives. Arguments for the old or the new for their own
sake are facile and misguided.

Posted in Uncategorized | Leave a comment

Dogmatic paradigmatism

Posted on 2016-07-28 by Graham

First, you put all of your faith in structured programming, and you got burned. You found it hard to associate the operations in your software with the data upon which they act, and to make sure that the expectations made on the data in one place are satisfied when that data has been modified in that other place, or over there in yet another place. Clearly structured programming is broken.

Then, you put all of your faith in object-oriented programming, and you got burned. You found it hard to follow the flow of a program when it jumps in and out of different classes, and to see which parts were coupled to what. Clearly object-oriented programming is broken.

Then, you put all of your faith in functional programming, and you got burned. You found it hard to represent real business processes in terms of immutable data structures and pure functions, and to express changes to the operating environment without using side effects. Clearly functional programming is broken.

Or maybe it’s you. Maybe, rather than relying on faith to make these conceptual thought frameworks do what you need from them, you could have thought about the concepts.

Posted in advancement of the self, FP, OOP, philosophy after a fashion, software-engineering | 1 Comment

Apple’s Best Programming Language

Posted on 2016-04-28 by Graham

My talk at App Builders 2016 was on Apple’s best programming language. Spoiler alert: it’s Dylan. Or is it?

I chose a few properties one might wish to find in programming languages, then demonstrated how these were all present in the Dylan language. I also took a dig at certain other languages, which do things in ways that could be seen as less good than Dylan’s. For example, did you know that there’s a programming language out there which distinguishes constant from variable values with the words let and var, rather than using the arguably more readable constant keyword?

Now here’s a thing: of course there are many things iOS app programmers could have been using if we didn’t want to use Objective-C, without the addition of Swift. Indeed, a few months before Swift was introduced I enumerated some of these alternatives on this very blog. However, many of us chose to use Objective-C rather than any of the alternatives, and then chose Swift when that alternative was presented.

Similarly, Apple could have pursued any of those alternatives, and indeed did pursue quite a few of them. What would the world look like if Apple had invested in MacRuby? It would have Swift in it, we know that because they did and it does.

At the end of my talk, I invited the conference to discuss what it was particularly about Swift that led to its brisk success, when it can be considered equivalent to many existing alternatives in numerous ways. Here are some of the suggestions (none of them from me, all from the audience):

  • marketing
  • evangelism
  • LLVM
  • Apple now isn’t the same as Apple in Dylan’s time
  • “Halo effect” from iOS
  • people only want to use first-party tools
  • Objective-C pain provided the opportunity
  • big enough community to reach critical mass

That leads me to wonder how closely related the conditions for “better” and the conditions for “accepted” are, whether there are “better” things out there for programmers that haven’t been adopted, whether those things truly are better, and how aware we all are of the distinction between being better and being popular when we make engineering choices.

Posted in code-level, Uncategorized | 1 Comment

On immutable data structures…?

Posted on 2016-03-24 by Graham

If you write a scholarly publication and cite another one, what you say about it depends on its mutability. An article or a book can be cited by saying “this publication I’m identifying here says this”. Maybe you have to version your claim: “the second edition of this publication says this”. They’re immutable. Even if the third edition doesn’t say the thing you relied on in constructing your argument, the second edition still did. Someone who can get access to that second edition can look at it and see how you built your synthesis.

You can’t do that with a website. Websites change. Instead, you have to say that “this website identified by this URL, on the date that I read it, said this”. Someone who comes along later has to sort-of trust that, because if the website no longer says that, it might not be possible to tell whether it ever did say that, or whether you’re telling porky pies about your research.

Dependencies in software systems are usually given as if they work like book citations:

gem 'rack', '1.0'

…looks like it says “the thesis that’s constructed by my software is a synthesis in which version 1.0 of rack is axiomatic”, but it doesn’t. It’s really saying “at the time that I want you to think that I actually tested this stuff, it was true that the thing identified by being version 1.0 of rack was…”. It’s really a poorly-constructed website citation.

It’s fun to think, particularly in light of the npm shenanigans, just how long that dependency you didn’t bother downloading will still be around. You can presumably forget about relying on commercial software, as the licence agreement is the legal equivalent of Vader saying “I have altered the deal. Pray I do not alter it any further.” And indeed you can forget most open sores licences, which don’t put any requirements on your supplier. But what about the GPL? Version 3 (retrieved from this URL on 24th March 2016) says that anybody who distributes licensed software as object code may, as one possible way to provide access to the corresponding source code, provide that object:

accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge

What if the person you got the object code from dies within that three year period, do you have the right to ask the executor of their estate for the source code?

Posted in academia, architecture of sorts | Leave a comment

In which I interview so you don’t have to

Posted on 2016-03-15 by Graham

Describing job interviews for technical roles in the software industry to people who have left or have always been outside the software industry requires two things: patience on the part of the one doing the describing, and the ability for the listener to take a joke. Over the last twelve years I have taken countless job interviews so that you don’t have to. Here’s what I’ve found: presented as a guide to running the average software developer interview. As with all descriptions of mediocrity, you should treat this as best practice.

[Be clear on this: not all interviews are like this. But this is an expectable baseline, derived from experience.]

Person Specification

The ideal candidate will be rich. We’re going to put them through hours – maybe even days – of tests, interviews, meetings, and “informal chats” that they’d better be on best behaviour for anyway. They need to be able to afford taking that time away from work, friends, other opportunities, so they’d better be rich.

That multiple-hour interview process means that they’d better be desperate for a job too. As you’ll find out in the section on our process, we pride ourselves on not giving away too much. We’re not selling our company to you, because we know we’re offering the chance to do what you’ve always wanted: sit in our open plan office space next to our own particular loud crisp-eater muttering at Eclipse.

The ability to go without food is desirable too. Even if a stage of the interview is planned to take so long that it would go over lunch, and even though we might put a break for lunch in, we might also forget to do any catering. Computers don’t need food and programmers are sort of like computers, we heard. We actually occasionally do feed our staff, and advertise this as a perk.

Our Process

The first thing we want to check is whether you can solve logical problems. We don’t actually need you to solve logical problems, after all, that’s what the computers are for. But we’ll give you an aptitude/basic reasoning test anyway [yes, although it’s no longer the 1960s and we aren’t IBM, this is still common if not universal].

The reasoning test is there to weed out people who didn’t have the same education as us, or were raised speaking a different language, or in a different culture. Empathy is hard, and to avoid unduly stressing our staff we want to make sure that their colleagues are as similar to them as possible. Additionally the hour you’ll take going through this test is an hour we don’t have to make eye contact or conversation with you: empathy is hard.

To be honest we have no idea what this test means or how to interpret its results. Everybody before you went through this test, and they’d raise merry hell if we “lowered the bar” by removing it now. As a holacracy/meritocracy/hypocrisy/this week’s organisational behaviour buzzword, we empower our employees to not see any changes that might raise a small amount of discomfort.

So after that test, depending on the seniority of the position and the candidate’s experience, we’ll…no, not really. We did nearly keep a straight face through that sentence though. In fact we didn’t read your CV except to find out whether the keywords that describe the problems we have right now and the solutions we have chosen last week appear. We didn’t read your GitHub/Lanyrd/Bitbucket profiles either, except to check that you have them so we know how much free work to expect out of you in addition to the paid stuff. Our project management system works on the Pareto Principle: 80 hours a week on our stuff, 20 hours a week on open source stuff that we can co-opt.

The next stage in the process is actually the same for everybody: a basic programming test to find out whether you even know what a computer is. We don’t care that you’re [glances at CV] Grace Hopper, we still don’t believe that you can reverse a linked list. None of our employees has ever had to reverse a linked list on the job, and we’d fire them if they did reverse a linked list on the job because there are libraries for that.

Now we’ll come onto the technical interview: a cross-examination by a panel of between one and twelve [not joking] people who have, or have had, a word like “engineer” in their job description at some point. These people are tasked with finding out whether you’ve solved the same problems in your career as they have in theirs. If you haven’t, you might not be clever enough. If you have, then what new experiences are you bringing to the table?

By the way, our flexibility on your technical skills will go down as you become more experienced. We appreciate that new grads might not have used our tools/frameworks/technology and are willing to train them, but if you have more than six months’ experience with Java we’re going to call you a Java developer and only consider you for Java roles.

After all of that, it’s still possible that you might have somehow snuck through the system despite not going to the same university or belonging to the same society as the founder. We can’t really quantify the idea of “culture fit” but that’s what we’re examining in the next part of the process and we’ll know it when we don’t see it.

The Offer

You’ll get a phone call from us while you’re in the bath. We’ll outline the position, pay and (unless this is an American company and there isn’t any) holiday provision. You then have two seconds in which to reply, with either “Yes” or whatever the other one is. You may have other irons in the fire but of course you’ll want to drop all of those when we tell you about the parking space we’ve already allocated for you [This has happened. I don’t have a car.].

The Job

You will be working with a team of people who all went through that same interview and decided they wanted to work in our environment. We will leave it to you to decide what that means.

The Alternative

There are some less…scientific…approaches to hiring that involve using the candidate’s stated and visible experience to have a conversation about what they’ve done, how they do and don’t like to work, how they’ve responded to success and failure, and whether the challenges they would like to see in their career match up with the environment we’re able to provide. While that sounds like quite a pleasant experience for everybody involved we fail to see how it could possibly translate into discovering whether we want to work with you or vice versa.

Posted in advancement of the self, Business | 1 Comment