15 Jan 2024
Go and enjoy Zarar Siddiqi’s excellent new-year piece, The size of your backlog is inversely proportional to how often you talk to customers.
His thesis holds true in more contexts than government folks like to admit. He also has orthodox (read: scathing) views on hifi design upfront, voiced but not heard by most government programs.
In a recent large gov program, fairly indicative of lots of them, I regularly saw backlogs triple handled. It used a nameless enterprise agile methodology, which made backlog management a serpentine but not impossible. The process shook out a few things, sure, but ended defined well enough into the future, very difficult to deliver against. Nevertheless, about half the program did a decent job speaking with customers. Translating those conversations into working software remained a challenge!
Upfront funding remains to blame, but as more than one public servant has expressed over the years – they either need this or they don’t. Overspends suck, and it is not super legal to commit funds that are not there, but it is such an accepted fact of life it falls into the realm of ‘effectively engaging with risk’. Much of the trouble arises when we look at spending categories.
Federal government can crank out the same things it has always done to an ‘unlimited’ (say, 2x budget) spend limit, in a specific category. It does this by translating the wants and desires of public servants – generally sustainment-funded, overburdened managers – into over-realised product visions, generally minimally validated. They only get one shot at this before the program leaves the station and moves on to the next well-meaning exec. Managers are impressive enough, usually experienced, though their relationship with their immediate senior exec will determine their ability to express things clearly enough to yield an initial estimation and a shot at change. Their engagement with software folks is generally characterised by mistrust; perhaps fairly, as IT have been hard to engage, they have potentially waited years for someone to even give them the time of day, and – this part is most tragic – many have history with systems built by people sitting next to them, since wrested away by IT under efficiency and centralisation initiatives that doubtless closed datacenters and saved millions, but also took with it any hope for systems agility or a genuinely digital workforce.
Returning to Siddiqi, who prescribes – as any good agilist – defering design almost entirely:
A product’s capacity to implement UI customer feedback is more important than a product’s initial UI
How true. Why is it so hard?
Technology is part of it, to be sure. Tech debt and brittle, bespoke, or overly clever architectural choices, certainly. Competency comes in too – the design-adjacency of frontend development often seems to exclude it from dev teams entirely. It’s hard to make UI changes when your org has scant UI skills; and more UX focused folks (which undoubtedly skew ‘BA’ in government land) will typically gravitate to the other side of the org chart. The best changes are snuck – The quantum of ‘it felt good to me at the time’ developer-written content, absent any awareness of ‘business areas’ is far greater than anyone admits. Sustainment funding is mythically bad: all good business cases are predicated on rainbows, unicorns and FTE reduction.
Process is another. The unduly IT centric nature of transformation initiatives skews the workforce to recognisable roles. In defence of big IT, they historically know how to get the money in a way that new policy proposals (in a genuine policy-oriented sense) only dream of. IT teams still often include design, as a quantified afterthought because the Digital Service Standard told them they should and there was a chance of a spend review that asks, ‘where are your designers?’. But the design function is still, often, viewed as an input to estimation. Designers often produce optional, undervalued backlog items that merely enable the ‘real work’ to be estimated (and perhaps delivered, if runway permits).
There is one more reason it is hard. Good design on government services is hard, and typically in ways that are beyond quarterly planning horizons. It is a rare federal government service that does not involve multiple parties. Don’t let me undersell the value of simple single identity – The renewed MyGov policy call is a good thing! – But plenty of duplication remains beyond this identity demarcation. Think multi-user, org management, audit trails, and, increasingly, API use without the past horrors of Auskey and friends. Yet in delivering ‘deep portals’ – web services that let you do more than a flat form in an authenticated context – you’re going to fight battles that don’t matter because the funding is attached to the wrong thing. You’re going to agitate around the wording on forms, because that is your inflection point. You’ll end up producing guidance materials in PDFs, because WalkMe would take you two quarters to business case, security assess, and you’d probably lose anyway and end up estimating three quarters to build a bad alternative. And you’ll probably have aspirations about ‘deep portal’ functionality that is so hard to prioritise because it is not sufficiently domain specific. These common, identity-adjacent needs, are the tip of the 80/20 iceberg, and to my knowledge and awareness there is no vendor coming to the rescue. The recently-axed Modernising Business Registers program included the closest federal government had come, at least introducing multi-user business authentication of a kind. Yet a review found the program was characterised by ‘significant underestimation’. Vale.
The best thing we can do is keep the ability to make changes high. This requires more sustainment than anyone would like to admit. Consensus on sustainment is really hard when significant program goals are (usually) nothing to do with the customer. It is common to have cost- and efficiency-based priorities behind programs, and give lip service to user experience to get them over the line. It’s easy to blame ‘big IT’ – but they are not an interesting target of wrath, being a fixed point of most IT transformations. Defer as much design as you can, while keeping people doing design close to the service, talking to users, and pushing legislative reform to genuinely simplify services.
09 Mar 2023
Hello, fictive reader. Blog’s been quiet for years.
Working in government has significant chilling effects on public speech, but suffice to say Canberra has been an (unexpected) blessing in terms of work. We’ve been here about seven years and it’s been a great journey in design, tech, climate – and consultancy scale-ups.
This year looks a bit different.
I finished up at Pragma and am taking the year to study ✨theology✨ (no, not astrology!). The Jesus kind.
Getting to the point of ‘quit your job and study the bible’ is a bit of a journey. More to be said than is said here, so do reach out if you would like to chat!
You’re studying what now?
I’ve enrolled full time at Ridley College, based in Melbourne, but studying online.
Theology is studying God and religious belief - in this case, consistent with Christian faith. Ridley are ‘reformed evangelical’ and (self-describedly) world class theological education. The academic rigour is real (more below). I’m just a few weeks in now and it has been wonderful learning from their staff. I know only a few people who have studied there, but it’s been widely recommended as the best distance option. (There are, of course, caveats on distance that are in some measure predictable in our COVID-weary world - ask and I’ll tell you!)
Too jargony? Parse ‘reformed/evangelical’ as ‘a focus on how God has spoken to us through the bible, and historical Jesus’ life, death and resurrection’.
Can’t you just read the bible?
(Or, my fav variant on this question: don’t you already know what is in the bible?)
One of the New Testament letter writers sets the frame for this: “the word of God is living and active, sharper than any two-edged sword, piercing to the division of soul and of spirit, of joints and of marrow, and discerning the thoughts and intentions of the heart.” (Heb 4:12)
There’s an imperative to read again, and again. But it’s a fair question. Full-time study isn’t the ‘real world’, and isn’t forever. In day-to-day Christian life, we read the words of God, and probably use a bit of what we’ve heard in faith settings as a lens to understand how they fit tighter.
This sentiment is pretty familiar: “…some people today believe the [writers of gospels] took divine dictation: they were merely stenographers, the secretaries of the Holy Spirit.”
Part of the humanities bag-of-tricks is considering context and form. Part of the rigour is piecing together what smart people, who wrestle with the mess/age of history, know about the academic reality of how we get these texts, and beliefs.
The reality is real people wrote the words of life, to particular people at a particular time.
What’s the driver?
A number of things, best told in person, got us to this decision point in late January.
This is a strange choice. But the bible describes a strange people. The main game is to understand God’s salvation without dull eyes, ears or heart, to persuade about Jesus in the Spirit’s power.
I am trusting God will graciously use this year for greater understanding and transformation. Now, ‘knowledge puffs up’. If you talk to God, please ask it doesn’t give selfish pride but the fruit of the Spirit - love, joy, peace, patience, kindness, goodness, faithfulness, gentleness and self-control.
People I’ve told this have, broadly, responded with “you do you, you’ve got to look after yourself” (self-actualisation, I suppose?) or perhaps presumed it is a bit of a nerding-out exercise, maybe lacking in rigour. Others still wonder if it is credentialling - accordingly, I will be bored.
To be honest, I am grappling with the firehose of content right now. Perhaps common to new endeavours, perhaps God already answering that prayer about pride.
While humanities study isn’t new, theological education, and full-time study, is. Transitioning from 4-day-a-week work to a full-time course load has also been genuinely difficult to keep up with. Kids of course doesn’t pause, started a new school this year, have their own full little lives, and the rest of life remains busy and (a little unpredictably) full.
But God is not far off, and so I pray in the Spirit for perseverance in studies this year!
12 Jul 2018
A while back I stumbled across a FootprintDNS host on a few Office 365 services, and wondered what it was up to. A few others were wondering the same. There didn’t seem to be an answer out there.
We’ve been looking into using Azure Traffic Manager for load balancing and in particular their Real User Monitoring feature. In the process of auditing how this works (noting it uses client-side JS), it became clear that it’s using the footprintdns.com for tracking.
https://www.atmrum.net/client/v1/atm/fpv2.min.js is worth a read. It uses
.clo.footprintdns.com subdomains for tracking.
Ostensibly the purpose is to learn about real user latency - which means that anecdotal reports of this service taking a while to load are sensible, and in line with its purpose!
For those wondering if this is blockable, it seemingly would have no impact on end-user experience, but of course in aggregate means your users aren’t going to have Traffic Manager balance requests toward lower latency endpoints. Probably not a big issue if you are security conscious.
If you would like to try something more targeted – on the off chance there are other, undocumented uses of this domain – you could instead block
atmrum.net (and subdomains) which hosts the loader script for Azure Traffic Manager’s Real User Monitoring.
27 Jan 2017
Finally got around to playing with LetsEncrypt this evening. I was naively copy-pastaing my way through a tutorial when I ran up against this error.
Failed authorization procedure. www.example.com (tls-sni-01): urn:acme:error:tls :: The server experienced a TLS error during domain verification :: Failed to connect to 126.96.36.199:443 for TLS-SNI-01 challenge, example.com (tls-sni-01): urn:acme:error:tls :: The server experienced a TLS error during domain verification :: Failed to connect to 188.8.131.52:443 for TLS-SNI-01 challenge
The IP in the error belongs to Cloudflare, which was already active and providing ‘flexible’ (i.e. illusory) SSL. 
One way to fix this is to make a DNS change to point directly at your origin server (your own IP), instead of the CDN, while you provision the cert. But half the point of LetsEncrypt is that you get readily automated and cycleable certificates, which big scary DNS changes would get in the way of. Not to mention that DNS changes are typically slow/multistage/relatively hard to script.
Thankfully, LetsEncrypt are smart folks and have another option.
sudo letsencrypt --apache -d example.com -d www.example.com --webroot --webroot-path=/var/www/html/ --renew-by-default --agree-tos
> Too many flags setting configurators/installers/authenticators 'apache' -> 'webroot'
Did I mention I was using Apache?
The copy-paste tutorial I was following used the
--apache switch as a way of, I guess, automagically configuring a virtualhost. I broadly trust that LetsEncrypt will have saner defaults than whatever other DigitalOcean tutorial I used to provision the box in the first place, so that seemed like a good idea. Only, of course, it wasn’t compatible with the
But, eventually, this did:
sudo letsencrypt --installer apache -d example.com -d www.example.com --webroot --webroot-path=/var/www/html/ --renew-by-default --agree-tos
--apache is shorthand for
--installer apache, which is somehow sufficiently differentiated from
--webroot to not throw errors. Don‘t know what I’m doing deeply enough to file a bug yet so throwing this blog up for a hopefully searchable solution in the meantime.
- This has been written up dozens of times, but to summarise the issue:
Browser talks to CDN talks to Server.
Browser to CDN is secure. CDN to Server is insecure.
So we’re trying to fix that last mile (which, of course, still leaves the “CloudFlare can MITM half the Internet” issue… but that’s a bit beyond my immediate threat model).
11 Jul 2016
Need to see what’s running?
I think Optimizely might’ve done something to make this tricker as an optional project setting, but it’s handy to be able to debug what’s running and possible splits.
item = optimizely.allExperiments[item];
if (!item.enabled) return;
return "\t" + item.variation_weights[v]/1000 + "%: " + optimizely.allVariations[v].name;
Paste in console.