• eyeo wins landmark copyright court decision; protects digital rights and sets important legal precedent for who ‘owns’ HTML – Media org Axel Springer (German gutter press, not the science publisher) lost its court case against Eyeo (Adblock Plus). They were sad at its sites’ ads being blocked, and claimed that the HTML of their sites is copyright, so blocking or changing any of it is copyright infringement. Herr Judge said “Keine Chance, du kolossaler Schweinehund. Verpiss dich.”
• Defensive CSS – “a collection of snippets that can help you in writing CSS that is protected. In other words, you will have fewer issues in the future” by Ahmad Shadeed
• Add a Service Worker to Your Site by Chris Ferdinandi
• A Complete Guide To Accessible Front-End Components by Vitaly Friedman
• Which accessibility settings do the Dutch really use on their phone? – Survey of 1 million people: “43% use one or more accessibility settings on their phone. 14% uses 2 or more accessibility settings”
• Chromium has started experimental implementation of <selectmenu> – it’s like select but you can style all the constituent parts, instead of twatting about with billions of divs and wiring up keyboard and ARIA yourself (or hoping a framework will)
• Boolean attributes in HTML and ARIA: what’s the difference? asks Hidde de Vries. And then, as a bonus, tells you the answer.
• A New Container Query Polyfill That Just Works by Coy Chrisier
• Full accessibility tree in Chrome DevTools
• Accessibility monitoring of public sector websites and mobile apps 2020-2021 – gov.uk
• Emojis and Accessibility: The Dos and Don’ts of Including Emojis in Texts and Emails – “A friend sent me a text the other day … I never got to the part where I was supposed to give them a call. The emojis got in the way.”
• RFC 3339 vs ISO 8601 – a handy venn diagram and table
• CEOs are hugely expensive – why not automate them? – “If a single role is as expensive as thousands of workers, it is surely the prime candidate for robot-induced redundancy.”
• Web3 is going just great

There’s a trope in the Apple-using technologist world that when an Apple innovation doesn’t immediately succeed, they abandon it. It’s not entirely true, let’s see what actually happens.

The quote in the above-linked item that supports the claim: “Apple has a tendency to either hit home runs out of the box (iPod, iPhone, AirPods) or come out with a dud and just sweep it under the rug, like iMessage apps and stickers.” iMessage apps and stickers are new features in iMessage. These are incremental additions to an existing technology. Granted, neither of them have revolutionised the way that everybody uses iMessage, and neither of them have received much (or any) further (user-facing) development, but both are themselves attempts to improve an actual product that Apple actually has and has not swept under the rug.

We can make a similar argument about the TouchBar. The TouchBar is the touchscreen strip on some models of MacBook Pro laptop that replaces the function key row on the keyboard with an adaptive UI. It appeared, it…stayed around a bit, then it seems to have now disappeared. Perhaps importantly, it never got replicated on their other keyboards, like the one that comes with the iMac or the one you can buy separately. We could say that the TouchBar was a dud that got swept under the rug, or we could say that it was an incremental change to the MacBook Pro and that Apple have since tried other changes to this long-running product, like the M1 architecture.

There are two other categories of non-home-run developments to take into account. The first is the duds that do get incremental development. iTV/Apple TV was such a bad business for the first many years of its history that execs would refer to it as a hobby, right up until it made them a billion dollars and was no longer a hobby.

Mac OS X’s first release was a lightly sparkling OpenStep, incompatible with any Mac software (it came with a virtual machine to run actual MacOS) and incompatible with most Unix software too. It was sold as a server-only product, which given the long wait involved when doing something as simple as opening the text editor (a Java application) was a sensible move. Yet, here we are, 23 years later, and macOS/iOS/iPadOS/tvOS/watchOS/bridgeOS is the same technology, incrementally improved.

Then the next category is things that go away, get rethought, and brought back. The thing we see might look like a dud but it’s actually an idea that Apple stick with. Again, two examples: remember dashboard widgets in Tiger? There was an overlay view that let you organise a screen of little javascript widgets to do world time, stocks, weather, and other things including those supplied by third-party developers. It was there, it looked the same for a bit (as long as you don’t mention the DashCode tool introduced along the way), then it wasn’t there. But later, control center came along, and we got a new version of the same idea.

In between that fizzy NeXT version of Mac OS X Server and the first public release of Mac OS X 10.0 (which was also a dud, many users sticking with MacOS 9 and Apple even giving away 10.1 for free to ensure as many people as possible got the fixes), the Aqua interface was born. Significantly more “lickable” than its modern look, it was nonetheless recognisable to a Monterey user, with its familiar traffic-light window controls: red for close, yellow for minimise, green for zoom, and purple for…wait, purple? Yes, purple. This activated single-window mode, in which only the active window was shown and all others minimised to the dock. Switch window, and the previous one disappeared. This wasn’t in the public release, but now we have Mission Control and fullscreen mode, so did it truly go away?

We wrote a custom Omniauth strategy to integrate with an an SSO provider. My problem arose when it came to making sure some changes to the strategy were sufficiently covered by unit tests. The Omniauth documentation seems to focus on integration testing using a simple Rails app as a test harness, but having an entire Rails application as a test dependency feels a little excessive.

So my starting point was to go through the list of omniauth strategies to see if any of them have an approach I can use. There’s a lot of good examples, but one problem. They all seem to be written using RSpec. Not a problem, but the test suite I’ve inherited is written in minitest. Not a big problem, but it is making me use my brain a bit.

Anyway, with a bit of digging, I managed to find enough examples to show me how to cobble together my extra test cases. I mainly wanted to write this as a sign post so if you stumble across this post after googling “custom omniauth strategy unit testing” you might wander over towards the list of existing strategies and take a look at how they did it.

New Scientist is reporting the Strongest evidence yet that Multiple Sclerosis is caused by Epstein-Barr virus:

A huge study of US military personnel suggests almost all cases of multiple sclerosis are triggered by the common Epstein-Barr virus, meaning a vaccine could largely eradicate the condition

Good news! I looked up Epstein-Barr virus on Wikipedia and found out that

Infection with EBV occurs by the oral transfer of saliva and genital secretions.

This makes sense. As a black belt (5th dan) in snogging and cunnilingus, I’m a victim of my own giving nature.

Another recent issue in the world of “centralised open source dependency repositories were a bad idea” initiated by the central contradiction of free software. People want to both give everything away without limitation on who uses it or how, and they want “Big Program” to pay for the work to be done.

While the license is the only tool used by free software authors, there is no way that this is going to be resolved in the favour of the Robin Hood model. There’s nothing of value on offer to Big Program in the software. They want the right to use the software for their nefarious purposes, and for free they can get the right to use the software for any purpose. Why would they pay more?

They wouldn’t. And no amount of whataboutism is going to change that. Whatabout if nobody can afford to work on free software any more, and they lose access to updates? Doesn’t happen. The current set of incentives – part financial, mostly reputational, and part itch-scratching – actually observably cause an increasing amount of free software to be created over time.

That gap needs to be resolved in other ways. There are things that companies will pay for even when they have the freedom to use the software for any purpose, at no charge. They will pay for support, bug bounties, indemnification, training, documentation, consultancy, integration, operations…

If the free software community hadn’t completely withdrawn from the patents discussion, they might pay to license the patent whether or not they take the (free) copyright licence. But that has yet to happen.

Plenty of organisations understand this: Red Hat became a forty-odd-billion dollar company giving away the software for free and selling other things. Canonical, Cygnus, ActiveState, O’Reilly, Mozilla, Musescore, Nextcloud…all of them make software, none of them is a software company. All make money in the free software world, none is a free software company.

Please continue giving us all the freedom to use the software for any purpose. Also the other freedoms, to study, improve, and share the software. But remember that freedom is not for sale.

The reason that the Star Wars character Jar Jar Binks is so reviled is that “binks” are things that are actually links, but styled to look like buttons and so don’t respond as expected for keyboard users. (Buttons are actionable with the space bar, links are not.)

And “jar” is some Java shit.

When I wrote I have some small idea of what I’m doing, it was on the basis that DHH was engaging in some exaggeration. Surely software engineers, whose job depends on what they know and what they can learn, would not really revel in their lack of knowledge?

Then it happened. A technology forum I’m a member of had a discussion in which participants expressed that they did not understand the topic, that they did not intend to understand that topic, and they still wished to dunk on the people in a video about said topic.

The topic, by the way, is cryptocurrency. It happens that I don’t have a lot of time for cryptocurrency and I think most other blockchain applications are not particularly beneficial, but this comes after taking a course on blockchain, reading a textbook, talking to some startups about their products, generally engaging with the topic. I haven’t flipped the bozo bit, but I have decided that I do not currently see any use for that technology and see a lot of downside to its application. If you’d asked me before all of that study, and people did, I would have told you that I don’t know anything about the topic.

I feel a bit bad for, and about, that technology forum. It contains people I respect, and I’ve had valuable conversations there, so I don’t want to disengage completely. I would then be flipping bozo bits at scale, which is exactly the problem we have with many current attempts to converse. I also don’t want it to degenerate into a bubble for the one approved mindset, and I particularly don’t want the software engineering mindset to be one where making your mind up before learning about a topic, and valorising that decision to engage before learning, is the preferred form of contribution.

Suggestions welcome.

(Last Updated on 25 January 2022)

I’d rather have a tiger come to tea
Than read more crap about Web 3.
Better have a walrus jizz in the butter
than meet another crypto nutter.
I’d sooner Melania Trump haunt my dreams
Than hear more batshit blockchain Ponzi schemes.

Not much happened in 2021, for obvious reasons. One surprising event was that I took a permanent job for the first time since Opera went tits-up in 2016. I had been contracting for Babylon Health for 6 months, helping them on their mission to make “high-quality healthcare accessible and affordable for everyone on Earth” and I liked them (even more surprisingly, they liked me) so when they offered me fripperies like paid time off and sick leave during a pandemic, I said yes.

Conferences didn’t really happen. I came to dislike speaking at Zoomferences, but did manage to harangue people in person at Front Conference Zurich, which was brilliantly organised by volunteers. Hopefully I can shout at people in real-life after Spring 2022 (and stay tuned for an exciting announcement about this).

Instead of conferences, I put my rabble-rousing urges into ending the Apple browser Ban, twice invited to brief the UK Competition and Marketing Authority about their investigation into Apple’s iOS browser monopoly and Progressive Web Apps. The final report will come out in June.

In personal news, I gained a few kilos due to an even more sedentary pandemic lifestyle, and didn’t smoke all year. And I managed to sell an Evil demonic spirit, captured in a box. Genuine ghost. Do NOT open the box! on eBay.

However, by the end of the year, I was feeling burned out and depressed, so decided to spend Christmas in Thailand, where I have a little rural holiday home. I felt a bit irresponsible travelling during Covid (and had to pay through the nose –pun intended– on 4 PCR tests for each family member), but it was absolutely worth it. It was such a tonic to get some sun, speak another language, eat different food and just see different surroundings after 2 years of the pandemic.

On return, however, I’m not feeling optimistic for the winter. In Thailand, everyone –and I mean, everyone– wears a mask outside their home, even in 30+ centigrade heat. No whining about “muzzles” or “liberty”, just social responsibility and a sense of shared endeavour. Yesterday, after my Day 2 PCR test came back negative, I could go to the supermarket to restock after my holiday. I reckon 50% of shoppers wore masks. Today my son returns to college. Given multiple sclerosis is my own immune system attacking my nervous system, I’m fully expecting to get sick. Hopefully, my vaccinations and booster will save me from serious illness.

Let’s hope 2022 brings better times for all.

(Last Updated on 24 January 2022)

You might remember that I was part of a small group of 3 UK web developers invited to brief the UK Competition and Markets Authority (i.e., our monopoly regulator) about Apple’s iOS browser monopoly and Progressive Web Apps. Yesterday, the very large interim report was published.

The CMA tweeted

Our provisional findings suggest Apple and Google’s substantial market power across mobile operating systems, apps stores and browsers could be negatively affecting consumers. People aren’t seeing the full benefit of innovative new products and services such as cloud gaming and web apps. Our provisional findings also suggest customers could be facing higher prices than they would in a more competitive market. Apple and Google take many decisions on behalf of their users to protect their security and privacy online – in some cases this has an impact on a user’s ability to make their own choices.

The report is gargantuan, and I haven’t read it all yet. It also deals with App/Play Store approval processes, and advertising, but these are aspects of the industry that concern me less than Progressive Web Apps. On PWAs, it’s pretty damning. Here are some choice quotes; emphasis is CMA’s.

Page 226-7:

Apple therefore benefits from higher usage of native apps on iOS. By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple’s App Store revenues.

we have not identified compelling evidence to date that suggests that, for dedicated browser apps, the potential impacts on competition and users from Apple’s WebKit restriction is justified on security grounds

We further consider that the limitation on the feature support that browsers on iOS can offer is likely to be significant. This appears to be particularly the case with respect to supporting web apps.

In addition to potentially harming the functionality of competing browsers within Apple’s ecosystem, we consider that the WebKit restriction may also serve to support Apple’s highly profitable position in the distribution of native apps through its App Store, and in parallel the market power of its operating system… web apps could in principle also serve to undermine the indirect network effects of native app distribution

Page 378-9:

We concluded in Chapter 5 that a significant contributing factor to the market power of Apple and Google in relation to mobile browsers is the restrictions that they – and in particular Apple – are able to place on rival browsers. We have therefore identified a number of potential interventions aimed at removing these restrictions. These interventions are summarised below:

• Apple does not permit the use of third-party browser engines within its mobile ecosystem – all browsers are required to use its browser engine, WebKit. We have not identified compelling evidence to date that suggests that, for dedicated browser apps, the potential impacts on competition or consumers from Apple’s WebKit restriction are justified on security grounds. We are therefore seeking to assess the merits of a requirement for Apple to allow alternative browser engines on iOS, at least for dedicated browser apps. This could be implemented by requiring Apple to permit third-party browser engines to interoperate with its iOS operating system, subject to those browser engines meeting conditions that would address any risks that might arise from a greater choice of browser engines (for example, complying with appropriate quality and security standards).
• Restrictions on the functionality of all browsers on iOS: as a possible alternative to requiring Apple to allow alternative browser engines, Apple could be required to enable access to specific features for browsers using WebKit on iOS, including supporting web app functionality. This could bring benefits from web apps providing a stronger competitive constraint on the App Store and the Play Store, while also reducing barriers to entry in the supply of new operating systems. We agree that, without appropriate safeguards, there are potential security and privacy risks associated with greater third-party interoperability with the iOS ecosystem.612 We are initially of the view that the costs and security risks associated with requiring access to core functions on the phone, such as push notifications, screen rotation and full screen capability should not be disproportionate.
• API access for rival browsers: we also have concerns regarding the differences in APIs that are available to Safari and Chrome by comparison with third-party browsers. This could be rectified by a requirement for Apple and Google to ensure that all browsers within a particular mobile ecosystem have access to directly comparable features and functionality through APIs. To the extent that some of the APIs and other functionality may be proprietary or increase costs for Apple and Google, such an intervention would also need to mandate the terms of such interoperability in a way that provides for access on fair and reasonable terms, potentially with guidance about how this would work in practice.

In its responses to our questions, Apple raised a number of concerns that introducing third-party browser engines, or increasing the interoperability of WebKit, could introduce privacy and security risks. Apple submitted that Webkit offers the best level of security, and has cautioned that ‘mandating use of third-party rendering engines on iOS would break the integrated privacy, security, and performance model of iOS devices’. Apple considers that by requiring apps to use WebKit, it is able to address security and privacy issues across all browsers on the iPhone for all iPhone users, quickly and effectively, and that ‘this is especially true when it comes to security vulnerabilities that have to be fixed as soon as possible in order to mitigate potential exploits by bad actors’.

7.73 However, as discussed in Chapter 5, the evidence that we have seen to date does not suggest that there are material differences in the security performance of WebKit and alternative browser engines. Further, and as discussed in Chapter 5, other parties have suggested that the impact of a browser engine on overall device security can, to a certain extent be limited.

Digital Markets Unit

The CMA is going to set up a permanent regulatory body called the Digital Markets Unit (DMU). This will have broad powers to enforce a code of conduct and apply interventions on activities by firms that have been given Strategic Market Status (SMS) in relation to activities in the scope of the CMAs Market Study. The DMU is currently operating on a non-statutory basis but it is intended that the government will introduce legislation to put the regime on a statutory basis when legislative time permits.

It is expected that while the DMU can only apply these regulations in the UK that they will cooperate with other regulators and the impacts will be global. Manchester has been picked as the head office of the DMU and they expect to hire 200 full time employees.

Strategic Market Status

In order to be regulated by the DMU a firm must be designated Strategic Market Status (SMS) in at least one digital activity. The test for SMS has three components:

• The activity must be at its core digital
• The firm must have substantial and entrenched Market Power arising from this activity that is unlikely to be removed by competition in the short or medium term
• Must have a strategic position meaning the use of this market power will be particularly widespread or significant

Both iOS and iOS Safari are recommended by the CMA as being designated strategic market status.

What’s next?

If you have opinions or comments, you’re invited to send them by 7 Feb. And, as I’ve seen, they will be listened to. Mine were, and I’m no cleverer than you. The final report is due to be published in June 2022.

Afterword

I just wanted to point out that I’m not an evil shill for Google, Soros or even the Illuminati. I just bought a new Macbook Pro, I greatly respect the Apple WebKit engineers and standards experts I’ve met over the years, and think Apple’s accessibility team is second to none. I just want Apple’s management to set Safari free.

Other news reports and opinions

• Benedict Evans’ twitter thread
• UK calls out Google and Apple for limiting competition, asks for better ways to move between iOS & Android, more
• UK’s antitrust watchdog is very angry and has written a letter telling Apple and Google how angry it is with them
• Apple’s cloud gaming restrictions may be biggest news in CMA interim report

• Responsive Layouts, Fewer Media Queries
• Accessible Toggles by @MicheBarks
• taba11y – Chromium extension calculates the tab order of all elements and displays it visually
• Consultation on modified commitments in respect of Google’s ‘Privacy Sandbox’ browser changes “CMA is inviting observations and evidence on modified commitments offered by Google in relation to the CMA’s investigation into Google’s proposals to remove third party cookies and other functionalities from its Chrome browser.” Deadline: 5pm, 17 Dec.
• The UI fund – Announcing the UI fund from Chrome, designed to provide grants for people who work on design tools, CSS, and HTML.
• Exploiting CSP in Webkit to Break Authentication & Authorization – “there was a vulnerability that we reported to Safari that Apple didn’t consider severe enough to fix quickly… after waiting for almost a year, we decided to explore the potential of vulnerability by targeting bug bounty programs”. And, of course, because of the Apple browser ban, all iOS browsers were vulnerable/
• Improving The Performance Of Wix Websites (Case Study) – my chum @DanShappir, the Panjandrum of Performance at @WixEng, on improving the speed of millions of sites hosted at Wix.
• Windows 11 blocks Edge browser competitors from opening links
• :has pseudo class prototyping status – your friends a Eeyo (Adblock Plus) are funding your friends at Igalia to implement the long wished-for :has pseudoclass (aka ‘parent selector’). Implementor Byungwoo Lee discusses problems of it, prototyping progress, current status and steps forward at BlinkOn 15 (captioned YouTube video, 25 mins)
• ‘Buy the Constitution’ Aftermath: Everyone Very Mad, Confused, Losing Lots of Money, Fighting, Crying, Etc – “ConstitutionDAO tried to buy the Constitution. Now it has a $40 million mess on its hands and entire refunds are being wiped out by high fees. Once cryptobro is quoted as saying “We have educated an entire cohort of people about the possibilities of web3”. Indeed.
• Thinking of uses for BlockChains – sagacious Uncle Tel does some thoughts
• Why are hyperlinks blue? and should they be underlined still?

A couple of weeks ago, Manuel Matuzović wrote

UI component libraries are using the term “accessible” too freely. Adding focus styles and copy-pasting some ARIA roles doesn’t make your library accessible, neither does adding an “accessibility” page where you claim to conform to WCAG just because you ran a Lighthouse test.

Mallory replied

I think right now today they could *all* switch to simply listing what they did and tested, without claims starting with “a”. Followed by a link to their gh tickets w the “accessibility” label. More useful tbh

By coincidence, my boss had asked to write up how to evaluate third party libraries (indeed, any third party software). Here’s some of what I wrote:

The first rule is don’t unquestioningly believe vendors’ claims. This isn’t to say that they are lying (although some are); perhaps they made their components believing them to be accessible, but didn’t know how to test; perhaps they started off accessible but subsequent contributors/ maintainers let bad code into the product.

Nothing replaces thorough testing with actual devices, but that’s time-consuming, so it’s useful to draw up a shortlist, which is as much an art as it is a science.

• Is the marketing website accessible? (Give it a quick test with the Tota11y tool. If yes, it doesn’t mean the components are, but if the site lacks alt text, can’t be used with keyboard and has bad contrast, can we really trust the components?)
• Does the project website/ repo mention a11y prominently, e.g. is it featured?
• If they do, do they indicate what they tested (WCAG 2.1 A, AA?), on what (JAWS, NVDA, VoiceOver? etc), and when (3 years ago, yet there have been 6 subsequent releases)?
• Do they have a named person looking after a11y? (If “no”, this isn’t necessarily a problem; if yes, it’s a good sign)
• Does a web search for the project name + “accessibility” come up with positive or negative results?
• Do recent PRs suggest that code reviewers took a11y into account? (An original dev may have been a11y-minded, but moved on, so any a11y promises might be stale.)

Hidde de Vries (of W3C) recommends asking the following questions:

• How did they test? (e.g, automated tests only? Against WCAG? With screen readers? If so, which ones?)
• Who did they test with? (e.g., did real screen reader users test? Was a broad range of disabilities included?)
• Are they open about pros and cons of their approach? (Do they claim to be a magical fix-all? Or is there an accessibility statement with known issues and planned fixes?)
• Who created them? Is it a reputable org with a public service remit, eg GDS, BBC? Or well-respected a11y practitioners, eg Tenon, Tertralogical?

Today, Erik Kroes wrote

I wrote a quick blog for #LionComponents about accessibility in design systems, and specifically what it means in the context of Lion.

Lion is an open-source set of “white label” UI Web Components, developed and tested with assistive technologies on behalf of ING Bank. Erik’s blogpost The Accessibility of Lion is an excellent transparent statement of accessibility. It says what it does, doesn’t over-promise, and is transparent about what it doesn’t do:

Using Lion does not ensure an accessible outcome. Sorry, it doesn’t work like that. What it does provide is a solid base for you to build your own design systems and/or components with. It covers things like keyboard accessibility, UX design and semantics but a bad visual design can still ruin a lot.

It also tells me what testing has been done, and with what assistive technology (although not which browsers and operating systems; for example, is Talkback on Android tested?):

It’s thoroughly design, built and tested for you to meet (and exceed) WCAG 2.1 AA. Components are based on the theoretic ARIA Design Pattern Examples but made practical by automated testing, extended manual testing, heavy scrutiny and testing across platforms with screen readers like VoiceOver, NVDA and JAWS.

It also transparently points to any accessibility-related Github issues, so I can see how quickly things get resolved, the rationale behind any decisions, and whether there are any issues that might prohibit my adoption of it.

More of this stuff, please, component library creators!

(Update 8 Dec 2021):

• Also see glamorous Adrian Roselli’s post Be Wary of Accessibility Guarantees from Vendors which is 4 years old, because he’s so far ahead of the curve, he’s like sultry yankee tachyon.
• The Business Disability Forum created an Accessibility Request for Proposal that you can use within your organisation.
• Disability:IN has an Accessible Technology Procurement Toolkit

By far the post on this blog that gains the most long-term interest and attention is why inheritance never made any sense. In this post, I explain that there are three different ways to think about inheritance—ontological inheritance (this sort of thing is a special type of that sort of thing), subtype inheritance (this program that expects these things will work with these things too), and implementation inheritance (the code in this thing is also in that thing)—and that trying to use all three at the same time is a recipe for disaster.

People interpret the message behind this as they will: that you should only ever compose objects, that you should only use pure functions, whatever. The message I tried to send was that you need to not use all of these different forms of inheritance at once, but OK. In this paper from the very early days of industry OOP, the late Bill Cook and colleagues resolve implementation and subtyping inheritance, by treating them differently (as I argued for).

I feel partly to blame for the current minor internet shitstorm.

But first, some scene-setting. There have long been associations between the programmer community and particular subcultures, some of which have become—not monocultural—at least dominant cultures within the world of computering. When I entered the field in the early 2000s, it was the tail end of the cyberpunk subculture: electronic and rock music, long hair on men, short hair on women, often dyed, black band or logo t-shirts, combat trousers or jeans, Doctor Martens 1460 boots. Antisocial work hours, caffeine-fuelled weekend long hacks, “all your base are belong to us” memes. Obtuse, but workhorse, C and Perl code. Maybe some Scheme if you were in the Free Software Foundation.

Then toward the end of the decade the hipster subculture rose to dominance. Mac laptops. Nice clothes, worn ironically. Especially the bow tie. Dishevelled hair. Fixed-gear bicycles. Turned up trouser cuffs and no socks. Looking to be the technical cofounder, looking down on those who ask them to be the technical cofounder. Coffee, now daytime only, had to be incredibly fussy. The evening drink of choice was Pabst Blue Ribbon. If your software wasn’t in the tech stack of choice—a Ruby on Rails app, deployed to Heroku, edited in TextMate, hosted on Github—then were you crushing any code? Bro, do you even lift?

After a few years of this I noticed that one difference between these two cultures was an approach to knowledge, or more specifically its lack. It was easy to nerdsnipe a cyberpunk: if they didn’t know something they would go and find out. Usenet groups had multiple FAQ lists because many people would all try to find the answers to the questions, and wikis weren’t yet popular. In the hipster craze that followed, confidence in one’s own knowledge reigned supreme. You showed that you knew everything you know, and you showed that everything you didn’t know wasn’t worth knowing.

This came to a head in my little Apple-centric niche of the computering field in 2015, when that whole community had chased monad tutorials and half-digested chapters on category theory into every corner of the conference and mailing list ecosystem. People gave talks not to share their knowledge, but to share that they were the people who knew the knowledge. Attendees turned up to product development conferences expecting to learn how a new programming language made it easier to develop programming, and came away confused about endofunctors.

I should be clear here that not everybody in the field was like that, and there are plenty of people who can make difficult maths accessible. There are plenty of people who can make computering accessible without difficult maths. Those people were still present.

But still I determined that something we didn’t have enough of, that had been present in the cyberpunk-esque culture that came before (for all its other faults) was a willingness to say “I have no idea what I’m doing”. Not in a “har har look at me get this wrong” way, but in a “this is interesting, let’s find out more about it” way. An “I’m not the right person to ask, let’s bring in an expert” way. A “to the library!” way.

So after a bit of writing about learning things I didn’t know, I took my (then) decade of experience and position of incredibly-minor celebritydom in that niche little bit of computering, and submitted a talk called “I have no idea what I’m doing” to AltConf 2015. I think it may even have been a very last minute submission, with another speaker pulling out sick. The talk was a collection of anecdotes about things I didn’t understand when the problem came my way, and how I dealt with that. Particularly, given that Swift was a year old at the time, I admitted I had less than a year of Swift experience and knew less about it than I did about Objective-C. I even used the dog picture. The talk was recorded, but unfortunately no longer seems to be available.

My hope in delivering this talk was partly that the people in the room would learn a little about problem solving, but also that they’d learn a lot about how an experienced person can say “here are the limits of my knowledge, I can’t help you with that problem. At least, I can’t yet, but it might be fun/interesting/remunerative to discover more about it.” How it’s OK to not know what you’re doing, if you have a plan or can make one.

In retrospect, I think that what happened was simply that 2015 was too many generations in the software industry after all of the great forcing functions that led to the way computering was currently done. The Agile folks had worked out that we don’t know what the customer will want at the end of the project, so we should optimise our work for not knowing, but they’d done that at the turn of the millennium. The dot bomb had exploded at the same time, so the Lean Startup folks had worked out that there’s no money in the things the customer doesn’t want and you have to very quickly discard all of those.

Everything had shifted left, but it had done so at least a decade earlier. Now those things, Agile and Lean Startup, were the way you did computering, and you could be expert in them. There was certification. They were no longer “because that thing before wasn’t great”, they were “because this is how we do it”. There was another round of venture capitalists in town, and the money taps were starting to turn back on. There was no great need to find out that you were wrong, so it became a cultural taboo to admit it.

Anyway, if we believe DHH, I overshot. Apparently we went from “it’s professional to own up to the limits of your knowledge” to “it’s a badge of honour to not know programming as a programmer.” To be honest I find that the weak part of the post, mostly because I don’t recognise it and he doesn’t supply evidence. The rest—that we are beings capable of learning and growth and we should not revel in ignorance—is the same as what I was trying to say with my dog-meme talk in 2015.

But now the dominant non-monoculture is the “if you’re not with us you’re against us” variant. The “come on internet, you know what to do” quote tweet. Saying that you may have things to learn, and should not still be at the same level of copy-and-paste code years into your job is now the same as saying you must memorise all algorithms and programming language quirks to call yourself a real programmer. And how very DARE he say that, what does he know about programmers anyway?

Discussions of the DHH post seem to be predicated on the idea that it’s a personal attack on people who aren’t DHH-level success, when if it’s an attack at all it’s attacking a straw man identity and in fact is worded more like this non-attack: you have more potential to live up to, find it in yourself to surpass your current limits. But scrape the surface (by showing that DHH didn’t say the things that are claimed to be “ruining it for everyone”), and it seems there’s a certain amount of hating the messenger, not the message, going on.

I’m not sure the cause of this, but I suspect it may be that having learned not to punch down, folks are looking up for targets. That DHH is successful, has said things that people don’t like in the past, so it’ll be OK to not like what he says this time. And the headline is something not to like, therefore the article must just expand on why I was correct not to read it.

I’ve certainly disagreed with DHH before. When he did the “TDD is dead” thing, I went into that from a position of disagreement. But I also knew that he has experience at being successful as a programmer, and will have reflections and knowledge that are beyond my understanding. So I listened to the discussions, and I learned what each of the people involved thought. It was an interesting, and educational experience. I gained a bit more of an idea of what I’m doing.

Having benefited from the imagined history of Object-Oriented Programming, it’s time to turn our flawed retelling toolset to Agile. This history is as inaccurate and biased as it is illuminating.

In the beginning, there was no software. This was considered to be a crisis, because there had been computers since at least the 1940s but nearly half a century later nobody had written any software that could run on them. It had all been cancelled due to cost overruns, schedule overruns, poor quality, or all three.

This was embarrassing for Emperor Carhoare I, whose mighty imperial domain was known as Software Engineering. What was most embarrassing was that at every time when the crisis came to a head, a hologram of Dijkstra would appear and repeat some pre-recorded variation of “I told you so, nobody is clever enough to write any software”.

In frustration, software managers marched their developers off of waterfalls to their doom. If you ever see a software product with a copyright date before, say, 2001, it is a work of fiction, placed by The Great Cunningham to test our faith. I know this because a very expensive consultant told me that it is so.

Eventually the situation got so bad that some people decided to do something about it. They went on a skiing holiday, which was preferable to the original suggestion that they do something about this software problem. But eventually they ended up talking about software anyway, and it turned out that two of them actually had managed to get a software project going. Their approach was extreme: they wrote the software instead of producing interim reports about how little software had been written.

With nothing else to show than a few photographs of mountains, the rest of the skiing group wrote up a little document saying that maybe everybody else writing software might want to try just writing the software, instead of writing reports about how little software had been written. This was explosive. People just couldn’t believe that the solution to writing software was this easy. It must be a trick. They turned to the Dijkstra projection for guidance, but it never manifested again. Maybe he had failed to foresee this crisis? Maybe The Blessed Cunningham was a mule who existed outside psychohistory?

There were two major problems with this “just fucking do it” approach to writing software. The first problem was that it left no breathing room for managers to commission, schedule, and ignore reports on how little software was getting written. Some people got together and wrote the Project Managers’ Declaration of Interdependence. This document uses a lot of words to say “we are totally cool and we get this whole Agile thing you’re talking about, and if you let us onto your projects to commission status reports and track deliverables we’ll definitely be able to pay our bills”.

The second problem, related to the first, is that there wasn’t anything to sell. How can you Agile up your software tools if the point is that tools aren’t as important as you thought? How can you sell books on how important this little nuance at the edge of Agile is, if the whole idea fits on a postcard?

Enter certification. We care more about the people than the process, and if you pay for our training and our CPDs you can prove to everybody that you’ve understood the process for not caring about process. Obviously this is training and certification for the aforementioned co-dependent—sorry, interdependent—project managers. There is certification for developers, but this stuff works best if they’re not actually organised so you won’t find many developers with the certification. Way better to let them divide themselves over which language is best, or which text editor, or which blank space character.

And…that’s it. We’re up to date. No particularly fresh theoretical insight in two decades, we just have a lot of developers treated as fungible velocity sources on projects managed top-down to indirect metrics and reports. Seems like we could benefit from some agility.

The idea of a second brain really hit home. Steven and I were doing some refactoring of some code in our Amiga podcast last night, and every time we moved something between files we had to remember which header files needed including. Neither of us were familiar enough with the libraries to know this, so people in the chat had to keep helping us.

But these are things we’ve already done, so we ought to be able to recall that stuff, with or without support. And when I say with support, I mean with what that post is calling a “second brain”, i.e. with an external, indexed cache of my brain. I shouldn’t need to reconstruct from scratch information I’ve already come across, but neither should I need to remember it all.

There are three problems I can see on the path to second brain adoption. The first, and the one that immediately made itself felt, is having a single interface for all my notes. When I read this article I thought that blogging about it would be a good way to crystallise my thoughts on the topic (it’s working!). So I saved the URL to Pinboard, I wrote a task in OmniFocus to write a blog post, and then when I was ready I fired up MarsEdit to write the blog that would end up on my WordPress.

Remembering that all these bits are in all these systems is itself a brain overload task. And there’s more: I have information in Zotero about academic papers I’ve read, I have two paper notebooks on the go (one for computing projects and one for political projects), I have a Freewrite and a Remarkable, which each have their own sync services, I have abandoned collections of notes in Evernote and Zim…

I have a history of productivity porn addiction that doesn’t translate to productivity. I get excited by new tools, adopt them a bit, but don’t internalise the practice. So then I have another disjoint collection of some notes, maybe in a bullet journal, a Filofax, Livescribe notes, Apple Notes, wherever…making the problem of second brain even harder to manage because now there are more places.

So step one is to centralise these things. That’s not a great task to try to do in a Big Bang, so I’ll do it piecemeal. Evernote is the closest thing I already use to the second brain concept, so today I’ve stopped using my paper notebooks, writing those notes in Evernote instead. I also moved this draft to Evernote and worked on it there.

The second problem is implicit in that last paragraph: migration. Do I sit and scan all my notebooks, with my shocking and OCR-resistant handwriting, into Evernote? Do I paste all my summaries of research articles out of Zotero and into Evernote? No, doing so will take a long time and be very boring. What I’ll do instead is to move toward integration from this moment on. If I need something and I think I already have it, I’ll move it into Evernote. If I don’t have it, I’ll make it in Evernote. It will take a while to reap the benefit, but eventually I’ll have a single place to search when I want to look for things I already know.

And that’s the third of my three problems. Being diligent about searching the second brain. You have to change your approach to solving knowledge problems to be “do I already know this?” The usual, for me at least, is “what do I do to know this?” Now I’m good at that, with lots of experience at finding, appraising, and synthesising information, so doing it from scratch every time is mostly a waste of time rather than a fool’s errand. But it’s time I don’t need to waste.

I think that the fact I haven’t internalised these three aspects of the second brain is due to the generation of computing in which I really invested in computers. Most of the computers I learned to computer on could only do one thing at a time, practically if not absolutely. They didn’t have much storage, and that storage was slow. So that meant having different tools for different purposes. You would switch from the place where you recorded dance moves to the place where you captured information on Intuition data types, and rely on first brain for indexing. You wouldn’t even have all of it in the computer: I was 23 when I got my first digital camera, and 25 before I had an MP3 player. I did my whole undergraduate degree using paper notes and books from libraries and book stores. First brain needed to track where physically any information was in addition to where logically it was.

What I’m saying is I’m a dinosaur.

• Google’s special Android for India revealed – Partnership with Jio brings 5.45 in touchscreen, 2GB RAM & 32GB storage, in-built translation into 10 Indian languages & read aloud, voice activation. 6,500 rupees (£64, $87) or instalment plan. Gamechanger? (Marketing site)
• Photoshop’s journey to the web – Next time someone says “web isn’t powerful enough for my app”, show them Photoshop in the browser, or the Clipchamp video editor PWA
• SQLime is an online SQLite playground for debugging and sharing SQL snippets. Kinda like JSFiddle, but for SQL instead of JavaScript.
• The ADA lawsuit settlement involving an accessibility overlay: using an accessibility overlay is NOT a valid substitute for a real and valid accessibility strategy.
• Less Absolute Positioning With Modern CSS – an interesting article by Ahmad Shadeed
• Making data visualizations more accessible – “Researchers find blind and sighted readers have sharply different takes on what content is most useful to include in a chart caption.”
• Let’s Talk about Native HTML Tabs – Spicy Sections! I approve both name and concept.
• Line length revisited: following the research – Longer line lengths on screens no longer considered harmful
• Enhancing the Manifest – Aaron Gustafson on some ideas for making PWAs almost as groovy as he is with some proposed additions to the Manifest
• Accessible Writing with Ashley Bischoff – 1 hr video on writing accessible content
• The State Of Web Scraping in 2021 – a look at some utilities available for scraping data out of HTML for processing in a structured way
• AMP Has Irreparably Damaged Publishers’ Trust in Google-led Initiatives: as Bobo Berjon writes, a clear and dispassionate overview of the damage wreaked by AMP and the reason why it’s become very difficult to treat Google-led initiatives with anything other than intense suspicion.
• Apple, Its Control Over the iPhone, and The Internet – “There is no open web on the iPhone, either — only the “iPhone web.””
• Lena – a very thought-provoking short story in the form of a “wikipedia” article about the earliest executable image of a human brain.

(Last Updated on 10 December 2021)

I can’t reveal my sources, but this letter from two years ago today recently came into my possession while I was doing some research prompted by Eve Fullard, a highly-trained virologist/ epidemiologist/ political commentator and legal scholar who finds time in her busy schedule to post lots of spelling mistakes on GB News.

Bill Gate’s office
Area 51
Nevada

11 November 2019

Dear Soros,

I was recently contacted by Zogmuffin, King of the Reptilians. He confirms that they have finished kidnapping humans, whisking them away in UFOs and sticking probes up their bums, and have decided to move onto Phase 2 of their plan to take over the world.

At our last meeting at the Bilderberg Illuminati Group, you mentioned that you and a cabal of Chinese Jews have a secret lab in Wuhan. Do you think you could release a virus (make it look like an accident, like we did with Chernobyl!), so I can co-ordinate all the world’s governments, scientists and academics in a secret plan to inject the world with a “vaccine” filled with 5G nanobots that will change everyone’s DNA and make them willing fodder for the Reptilians to eat?

Have a think and let me know at Epstein’s Xmas Pizza ’n’ Pedophilia party.

All the best, and Hail Zogmuffin!

Bill

Smoking gun, there. WAK UP SHEEPLE!!!!

I use iTerm2 instead of the default MacOS terminal, and here’s how I have it set up:

• Twee terminal background with MOTD from this project because if I’m going to spend all day looking at a prompt, it should be pretty.

• Zsh and Oh My Zsh for really good tab-complete and git status on your prompt.
• Split panes. I find it really useful to a webserver process log on the left and be able to run tests and other commands in the right.
• Unlimited scroll buffer. Sometimes I run a really long command and want to paste the output into a file for safekeeping. Burning a little extra RAM is better than realising some vital bit of information has crept off the top of the screen.
• ⌥ + click anywhere in a command to move your cursor straight there.
• Bind keys to move between word boundaries, allowing you to skip back and forth within a command at a much higher speed with ⌥ + ←/→. Esc + b and Esc + f will move your cursor left and right, respectively.

• Silence terminal bell because I hate it.
• Enable tab icons for running apps.

If you’re like me, you probably spend a lot of time in the Rails console interrogating objects and fiddling with data to debug your application. As I work on a project, I end up with a growing list of useful snippets to lightly modify and paste into the console to complete common tasks.

A tweet by Sebastien Auriault showed me that you can define methods that will be directly accessible in your Rails console without necessarily affecting your production code.

How?

Depending on where you want these methods to be available, you can add the following code to config/initializers/console_methods.rb or to lib/console_methods.rb and require the file in the appropriate environment(s).

module Rails::ConsoleMethods
  # Grab your favourite test user without having
  # having to remember or type much about them
  def test_user
    User.find_by(email: 'my_test_user@example.com')
  end
  
  # Reset your test user back to some baseline
  def reset_test_user
    test_user.update(
      status: :pending,
      registration_confirmed_at: nil,
      current_balance: 0
    )
  end
  
  # Quickly benchmark some code
  def bm(&block)
    puts "Running a quick benchmark:"
    puts Benchmark.measure(&block)
  end
  
  # Clear all of your queued Sidekiq jobs
  def nuke_sidekiq
    Sidekiq::Queue.new.clear
  end
end

Why?

None of these examples are breathtaking. Why bother at all?

1. Sharing knowledge. A shared, well-documented set of custom commands allows the entire team to take advantage of these little time-savers.
2. Safety. If you mistype reset_test_user you’re a lot less likely to encounter unexpected behaviour than if you attempt to manually update records by hand.
3. Repeatability. Encouraging developers to use the existing methods for common tasks makes it easier to add appropriate guard rails and logging, and ensures that the action is performed in the same way every time.

Why not?

Consider the following example which puts an app into maintenance mode, logging users out and preventing further access.

module Rails::ConsoleMethods
  def enable_maintenance_mode!
    authenticate_developer
    log_action(:enabled_maintenance_mode)
    
    MaintenanceMode.enable!
  end
end

This is a good idea on the surface, but there’s nothing to prevent a developer from bypassing the authentication and logging entirely and calling MaintenanceMode.enable! directly on the console. As cool as this technique is, if security and auditing is a priority, it’s not sufficient to trust developers to use the approved methods.

If these issues are relevant to your use case, you’d be better off looking at this technique in conjunction with something like Basecamp’s console1984 which is a more robust attempt to provide secure authentication and logging in Rails console sessions.

LaTeX (and TeX, for that matter), syntax is relatively consistent, and uses a lot of backslashes.

Bourne shell syntax is somewhat inconsistent, and also uses backslashes.

Regular expression syntax I seem almost perversely disinclined to remember, and definitely sometimes often uses maybe backslashes.

Therefore, when I need to use a regular expression to work on a LaTeX document, I do it interactively in the shell until it works then paste that into a shell script. Now I need never remember or even uncover how to write that unholy combination of regex, shell, and LaTeX ever again.

For example I have defined a LaTeX macro \todo{I need more examples here.}, that draws the text “TODO: I need more examples here.” with a box around it in the document. I review outstanding sections by searching for lines on which todo items appear, using this script:

#!/bin/sh

grep -n todo\{ "$1" | sed s/\\\\todo\{\\\(.\*\\\)\}/\\1/

Now I get to blank from my mind the unholy combination of syntaces that led to 15 backslashes on one line, but still use the results.

Here’s a song I wrote many years ago when I lived in Turkey. “Laleli” is actually a rather drab suburb of Istanbul, but I’m using it here as a woman’s name purely because it sounds nice and rolls off the tongue!

Bass and knob-twiddling are by Shez, as is customary. The image is of @naWa53, photographed by Farhad Eidi, combined with some tiles from Topkapı Palace, taken by Meriç Dağlı, used with thanks. The song contains a fragment of a poem by Turkish folk poet and Sufi mystic Yunus Emre, read by Kivanc Atmaca for LibriVox, and some Persian vocal samples from Rast sound. The rest of the vocals and instruments are by me.

I was moving through my strangest dream,

watching how you build your bridges.

I was underneath the lights that seem

to drain the colours from your pictures.

Laleli, my love for you

is wider than these continents.

If all that’s in your mind were read,

who am I to understand or blame you?

I was spinning on the carousel

that makes me end in my beginning.

I was opposite the screens that tell

who is losing, who is winning.

Laleli, my only love –

come watch the evening like a dream.

If all that’s in your mind were read,
who am I to nominate or name you?

I was moving through some stranger’s dream,

watching how you burn your bridges.

I was underneath and in-between

my expectations and your mysteries.

Laleli, my only love -

silver like the Bosphorous.
if all that’s in your mind were read,
who am I to comprehend or claim you?

Words and music © Bruce Lawson 2021, all rights reserved.

• Link o’ the week: The Future of CSS: Cascade Layers is a jolly useful guide by @bramus that’s helped me understand the syntax and subtleties
• Apple to face EU antitrust charge over NFC chip – Only Apple Pay can use it because (checks notes) “privacy and security, absolutely not monopolistic behaviour. Who, us? Ha ha! Never!”
• New study reveals iPhones aren’t as private as you think – “Android phones collect more data by volume, but iPhones collect more types of data, a study finds”
• Make your PWAs Look and Launch Beautifully a presentation a by Önder Ceylan at PWA summit on the new developments on cross-platform icons, splash screens etc.
• Making the whole web better, one canvas at a time – Uncle Brian on OffscreenCanvas
• In Quest of Search – “On why I think adding a new HTML sectioning element for search is a good idea” by Sara Soueidan
• Datasette Desktop – “Datasette was originally designed as a tool for data journalists, to help report on data-driven stories, crunch through large datasets and publish the results…Datasette can be used to power dynamic-static websites: sites that run on serverless hosting while providing dynamic data-backed functionality.”
• Google found guilty of restricting Android forks in South Korea, fined $177 million
• Me Me Me! corner: The F-Word Episode 13 – Does the iOS browser ban harm or help the web? Now with added Stuart Langridge!

I only have 17 years of experience, but every point on this list accords with my experience. I’ve made my own attempt to catalogue things software developers should know (that are not writing code), but this is a succinct and great summary.

A couple of weeks ago, my grandma died.

This was not wholly unexpected, and at the same time it was completely unexpected. I should probably explain that.

She was ninety, which is a fair age for anyone, but her mother (my great-grandmother) lived to be even older. What’s different is that nobody knew she was ninety, other than us. Most of her friends were in their mid-seventies. Now, you might be thinking, LOL, old, but this is like you in your mid-forties hanging out with someone who’s 30, or you in your late twenties hanging out with someone who’s 13, or you at eighteen hanging out with someone who’s still learning what letters are. Gaps get narrower as we get older, but the thing that most surprised me was that all her friends were themselves surprised at the age she was. She can’t have been that age, they said when we told them, and buried in there is a subtle compliment: she was like us, and we’re so much younger, and when we’re that much older we won’t be like her.

No. No, you won’t be like my grandma.

I don’t want to talk much about the last few weeks. We, my mum and me, we flew to Ireland in the middle of the night, we sorted out her house and her garden and her affairs and her funeral and her friends and her family, and we came home. All I want to say about it is that, and all I want to say about her is probably best said in the eulogy I wrote and spoke for her death, and I don’t want to say it again.

But (and this is where people in my family should tune out) I thought I’d talk about the website I made for her. Because of course I made a website. You know how some people throw themselves into work to dull the pain when something terrible happens to the people they love? I’m assuming that if you were a metalworker in 1950 and you wanted to handle your grief that a bunch of people got a bunch of metal stuff that you wouldn’t ordinarily have made. Well, I am no metalworker; I build the open web, and I perform, on conference stages or for public perception. So I made a website for my grandma; something that will maybe live on beyond her and maybe say what we thought about her.

Firstly I should say: it’s at kryogenix.org/nell because her name was Nell and I made it. But neither of those things are really true. Her name was Ellen, and what I did was write down what we all said and what we all did to say goodbye. I wanted to capture the words we said while they were still fresh in my memory, but more while how I felt was fresh in my memory. Because in time the cuts will become barely noticeable scars and I’ll be able to think of her not being here without stopping myself crying, and I don’t want to forget. I don’t want to lose it amongst memories of laughter and houses and lights. So I wrote down what we all said right now while I can still feel the hurt of it like fingernails, so maybe I won’t let it fade away.

I want to write some things about the web, but that’s not for this post. This post is to say: goodbye, Grandma.

Goodbye, Grandma. I tried to make a thing that would make people think of you when they looked at it. I wanted people to think of memories of you when they read it. So I made a thing of memories of you, and I spoke about memories of you, and maybe people who knew you will remember you and people who didn’t know you will learn about you from what we all said.

Goodbye, Grandma.

kryogenix.org/nell

The “return a command” trick

This is a nice trick, but we need a phrase for that thing where you implement extreme late binding of functions by invoking an active function that selects the function you want based on its name. I can imagine the pattern catching on.

As you may know, every browser on iOS is actually just a branded re-skin of WebKit, the engine that Safari uses, because Apple won’t allow other engines on iOS.

Supporters of the Apple Browser Ban tend to give one of three reasons (listed here from most ridiculous to most credible):

The web shouldn’t be “app-like”, it’s for documents only

Whatever. (See A Brief History of Web Apps for more on why this is nonsense.)

Privacy and security are protected by not allowing non-Apple code on devices

This doesn’t really make sense when non-Apple apps are allowed on iOS, which can leak data so valuable that Amazon and eBay will pay you to use their apps rather than web. Apple’s most recent zero-day vulnerability was exploited along with a flaw in WebKit, and so left all users exposed because users of other “browsers” are forced to use WebKit. Stuart Langridge has a great post going deeper into Browser choice on Apple’s iOS: privacy and security aspects.

Allowing other rendering engines leads to Chromium taking over the world

This one kind of makes sense. After all, Opera abandoned its Presto engine and Microsoft abandoned Trident, and both went to Chromium. Firefox risks sliding into irrelevance due to inept lack of leadership. If Apple were forced to allow Chrome onto iOS, then domination would be complete!

The interesting predicate of this argument is that Apple intend to keep Safari as the sad, buggy app that they’ve allowed it to wither to, because it has no competition. I emphatically do not want Chromium to win. Quite the opposite: I want Apple to allow the WebKit team to raise its game so there is an *excellent* competitor to Chromium.

WebKit is available on Windows, Linux and more. Safari was once available on Windows, but Apple silently withdrew it. SVP of software Eddy Cue, who reports directly to Tim Cook, wrote in 2013

The reason we lost Safari on Windows is the same reason we are losing Safari on Mac. We didn’t innovate or enhance Safari….We had an amazing start and then stopped innovating… Look at Chrome. They put out releases at least every month while we basically do it once a year.

There is browser choice on MacOS, and 63% of MacOS users remain with Safari (24% use Chrome, 5.6% use Firefox). As everyone who works on browsers knows, a capable browser made by the Operating System’s manufacturer and pre-installed greatly deters users from seeking and installing another. There is no reason to believe it would be different on iOS. (Internet Explorer on Windows isn’t a counter-example; there were much better alternatives, long before Edge came along.)

But let’s set out aspirations higher. Imagine a fantastic Safari on iOS, Mac, Windows and Linux, giving Chrome a run for its money. If anyone can take on Google, Apple can. It has talented WebKit engineers, excellent Standards experts, a colossal marketing budget, and great brand recognition.

If Apple allowed Safari to actually compete, it would be better for web developers, businesses, consumers, and for the health of the web. Come on, Apple, set Safari free!

(You could also read my Briefing to the UK Competition and Markets Authority on Apple’s iOS browser monopoly and Progressive Web Apps.)

The biggest missing feature in the manifesto for agile software development and the principles behind it is anyone other than the makers and their customer. We get autonomous, self-organising delivery teams but without the sense of responsibility to a broader society one would expect from autonomous professional agents.

Therefore it’s no surprise to find developers working to turn their colleagues into a below-minimum-wage precariat; to rig elections at scale; or to implement family separation policies or travel bans on religious minorities. A principled agile software developer only needs to ask “how can I deliver this, early and continuously, to the customer?” and “how can we adjust our behaviour to become more effective at this?”: they do not need to ask “is this a good idea?” or “should this be delivered at all?”

Principle Zero ought to read something like this.

We build software that transforms the workplace, leisure, interpersonal interaction, and society at large: we do so in consultation with as broad a representation of those interests as possible and ensure that our software is beneficial to those whose lives are being transformed. Within that context, we follow these principles:

I know that there are bigger problems to discuss about Apple’s approach to business and partnerships at the mo, but their handling of security researchers seems particularly cynical and hypocritical. See, for example, this post about four reported iPhone 0days that went ignored and the nine other cases linked in that article.

Apple advertise themselves as the privacy company. By this, they really mean that their products are designed to share as much of your data with Apple as they are comfortable with, and that beyond that you should probably assume that nobody else is involved. But their security development lifecycle tells another story.

“Wait, did you just pivot from talking about privacy to security?” No! You can have security without privacy: this blog has that, on a first glance. All of the posts and pages are public, anybody can read them, but I want to make sure that what you read is actually what I wrote (the integrity of the posts) and that nothing stops you from reading it when you want (the availability). On a closer examination, I also care that there are things you don’t have access to: any of the account passwords, configuration settings, draft posts, etc. So in fact the blog has privacy requirements too, and those are handled in security by considering and protecting the confidentiality of those private assets. You can have security without privacy, but not privacy without security.

Something, I’m not sure what from the outside, is wrong with the security development lifecycle at Apple. As a privacy-focused company they should also be a security-focused company, but they evidently never had the same “trustworthy computing” moment that Microsoft did. I’m not going to do any kind of deep dive into CVE counts here, just provide the following high-level support for the case that Apple is, at best, doing no better than anybody else in the industry at this.

• Gil Shwed on the threats on iOS and Android being roughly balanced
• Android vulnerabilities command a premium over iOS (2019)
• Xcode 13 Server fixes multiple vulnerabilities by updating nginx. I include this to show that Apple are not taking the lead on infosec: they are incorporating vulnerable third-party components and fixes from upstream sources.

Meanwhile, they fail to acknowledge external contributors to their product security, do not pay out agreed bounties, and sue security researchers or ban them from their store. Apple say that the bounty program has doubled in 2019-2020 and continues to grow. You could say that maybe they aren’t doing any better, but they certainly aren’t doing any worse. Every new product announcement, senior managers at Apple up to their CEO tell everyone how great they are at privacy. Their intent is that people believe they are doing the best at this, when they are around the middle of the pack. This is disingenuous.

A bug bounty program is a security process of last resort. You didn’t design, implement, or fix flaws out of your product before it got to customers and attackers: and that happens, that’s fine, but these escapee threats that are realised as vulnerabilities should be a small fraction of the total possible problems, and the lower severity ones at that. You also didn’t detect it yourself once the customers and attackers had access to the product: that also happens and is fine, but again the vulnerabilities that escape your detection should be the lowest down the stack. Once someone else is discovering your vulnerabilities, the correct thing to do is to say thank you for bringing this to our attention before exploiting it yourself, here is compensation for the time and work you put into making our product better.

Apple is not doing this. As seen from the various linked stories above, they are leaving security researchers with a bitter taste and a questioning feeling over whether they would want to work with Apple again, but not doing the heavy lifting to ensure their SDLC catches the highest-severity problems on campus, before or after release. I don’t know what is at fault here, but I expect it’s systemic rather than individual leader/department/activity. The product security folks at Apple are good at their jobs, the software engineers are good at their jobs…and yet here we are.

I suspect a certain amount of large-company effect is at play. “As Tim told you, our products are best in class for privacy,” says anonymous and fictional somewhat high up marketing person, “and if you had any specific complaint I couldn’t hear it over all the high-volume stock cash register sound effects we play in the board room to represent our success in the marketplace.”

I was having a think about this short history of Objective-C, and it occurred to me that perhaps I had been thinking about ObjC wrong. Now, I realise that by thinking about ObjC at all I mark myself out as a bit of an oddball, but I do it a lot. I co-host the [objc retain]; stream with Steven Baker, discussing cross-platform free software Objective-C every week. Hell of a time to realise I’ve been doing it wrong.

My current thinking is that the idea of ObjC is not to write “apps” in ObjC, or even in successor languages (sorry, fans of successor languages). Summed up in that history are Brad Cox’s views which you can read in more length in his books. I’ve at least tangentially covered each book here: Object-Oriented Programming: an Evolutionary Approach and Superdistribution: Objects as Property on the Electronic Frontier. In these he talks about Object-Oriented Programming as the “software industrial revolution”, in which the each-one-is-bespoke way of writing software from artisinally-selected ones and lightly-sparkling zeroes is replaced with a catalogue of re-usable parts, called Software ICs (integrated circuits). As an integrator, I might take the “window” IC, the “button” IC, the “text field” IC, and a “data store” IC and make a board for entering expenses.

So far, so npm. The key bit is the next bit. As a computer owner, you might take that board and integrate it into your computer so that you can do your home finances, or so that you can submit your business expense claims, or so that your characters in The Sims can claim for their CPU time, or all three of those things. The key is that this isn’t some app developer, this is the person whose computer it is.

From that perspective, Objective-C is an intermediary tool, and not a particularly important or long-lasting one. Its job is to turn legacy code into objects so that it can be accessed by people using their computers by sticking software together using objects (hello NSFileManager). To the extent it has an ongoing job, that is to turn algorithms into objects, for the same reason (but the algorithms have been made out of not-objects, because All Hail the Perform Ant).

You can make your software on your computer by glueing objects together, whether they’re made of ObjC (a common and important case), Eiffel (an uncommon and important case), Smalltalk (ditto) or whatever. Objective-C is the shiny surface we’re missing over the tar pit. It is the gear system on the bicycle for the mind; the tool that frees computer users from the tyranny of the app vendor and the app store.

I apologise for taking this long to work that out.

(Last Updated on 30 September 2021)

I watched this week’s Apple Event for a while, but there was nothing that interested me; I have a mobile phone which works fine for me, I don’t need a watch and I can’t afford a new computer.

But here’s one Apple event speech I genuinely found really energising. In 2007, Steve Jobs made a bold announcement at Apple’s developer conference, that I still find inspiring today:

On open Operating Systems, Progressive Web Apps live up to this promise; truly cross-platform code that can be responsive to any form factor, using a mature technology with great accessibility (assuming a competent developer), that is secure and sandboxed, that requires no gatekeepers, developer licenses or expensive IDEs. They’ll work on Android, Windows, ChromeOS and Mac.

But 14 years after Jobs had this bold vision for the open web, iOS hasn’t caught up. Apple has imposed a browser ban on iOS. Yes, there are “browsers” called Chrome, Edge, Firefox that can be downloaded from the App Store for iOS–but they only share branding and UI features with their fully-fledged counterparts on open Operating Systems. On iOS, they are all just differently-badged skins for the buggy, hamstrung version of WebKit that Apple ships and occasionally patches for security (often waiting long after WebKit has been fixed before pushing it to consumers).

Apple knows Safari is terrible. SVP of software Eddy Cue, who reports directly to Tim Cook, wrote in 2013

The reason we lost Safari on Windows is the same reason we are losing Safari on Mac. We didn’t innovate or enhance Safari….We had an amazing start and then stopped innovating… Look at Chrome. They put out releases at least every month while we basically do it once a year.

Forcing other iOS “browsers” to skin Safari’s engine rather than use their own more capable engines is a deliberate policy decision. Apple’s App Store guidelines state

Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.

Job’s 2007 speech felt like a turning point: a successful, future-facing company really betting on the open web. These days, Apple sells you hardware that they claim will “express your individuality” by choosing one of two brand new colours. But, for the web, choose any colour you want, as long as it’s webkit-black.

Some of us are trying to change this. Earlier this month I was part of a small group invited to brief the UK regulator, the Competition and Marketing Authority, as part of its investigation into

Apple’s conduct in relation to the distribution of apps on iOS and iPadOS devices in the UK, in particular, the terms and conditions governing app developers’ access to Apple’s App Store.

You can watch the video of my presentation, and see Stuart Langridge’s slides.

Words interest me. As I’ve been getting interested in green woodworking and the appropriate tools, I’ve become more aware of the US term “shop”. A few days ago, in a discussion of why America is lagging behind on lower level tech education, someone suggested schools needed to reintroduce ‘shop’, to get kids interested in designing and making things. I think young Brits would know this as ‘Design Technology, Resistive Materials’. I did ‘Woodwork’ and ‘Metalwork’.

America takes its cars ‘to the shop’ because their ‘garages’ are being used as ‘car parks’. Obviously, it means ‘workshop’.  A shop where you buy work, a service instead of a product, as you walk down main street. Not at all like a job-shop in Britain where we try to sell spare labour to employers, or shop for jobs, if you prefer.

I came across a meaning from the world of share trading. A stock may be ‘shopped’ – actively sold. I think we’re finally getting to the meaning. A shop is a place (real or virtual) where goods, services and labour are traded, in either direction. A market stall. I almost wrote “store” but stores are where you keep things before selling our when they haven’t sold.

I was slightly side-tracked by coppers, copping criminals and taking them to the cop shop, trading their liberty for their crimes. My government assures me that if I haven’t committed a crime I won’t cop it. I wish I believed them. That’s the cost of lying in a market that depends on trust and information. Their share price is down.

(Last Updated on 30 September 2021)

On 4 March this year, the UK Competition and Markets Authority announced that it is

investigating Apple’s conduct in relation to the distribution of apps on iOS and iPadOS devices in the UK, in particular, the terms and conditions governing app developers’ access to Apple’s App Store.

Submissions from the public were invited, so I replied and was invited, with “Clark Kent” (a UK iOS Web-Apps developer who wishes to be anonymous) and Stuart Langridge to brief the CMA in more detail. We were asked to attend for 2 hours, so spoke for one hour, and then took questions.

CMA are happy for our presentations to be published (they’re eager to be seen to be engaging with developers) but asked that the questions be kept private. Suffice it to say that the questioning went over the allocated time, and showed a level of technical understanding of the issues that surpasses many engineers. (The lawyers and economists knew, for example, that iOS browsers are all compelled to use WebKit under the hood, so Chrome/ Firefox/ Edge on iOS share only a name and a UI with their fully-fledged real versions on all other Operating Systems).

Clark’s presentation

Clark talked of how Steve Jobs’ 2007 announcement of apps for iPhone inspired him to use his webdev skills to make iOS web-apps.

you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services … And guess what? There’s no SDK that you need! You’ve got everything you need if you know how to write apps using the most modern web standards to write amazing apps for the iPhone today.

Unfortunately, Safari’s bugs made development much more expensive by breaking Indexed DB; breaking scrolling etc. Also, Apple refuses to support Web Bluetooth, so his customers had to purchase expensive iOS-compatible printers for printing receipts, at 11 times the cost of Bluetooth printers. iOS apps can integrate with Bluetooth, however.

He can’t ask his customers to jettison their iPads and buy Android tablets. Neither can he ask them to use an alternative browser, because there isn’t any meaningful choice on iOS. Clark simply wants to be able to make “amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone”, as Jobs promised. He summed up:

All these business costs inevitably get passed onto consumers. Or worse applications simply never get built, due to the increased cost.

From the perspective of software developers there is no browser competition on iOS.

Apple has banned all the other browser engines and Safari’s bugs and missing features means that web-apps struggle to compete with the AppStore. If third party browsers were allowed, with full access to all the APIs that Apple gives Safari, this would provide Apple the incentive to keep pace with the other browsers and give consumers a means of voting with their feet by moving to a competing browser if they fail to do so.

This would then lead to a universal open app development and distribution platform which would substantially reduce development and maintenance costs for a wide range of business and consumer applications. The open web offers an alternative future where the control from corporate intermediaries along with their fees are replaced with consumer choice and the freedom to easily shift from one platform to another. Instead of having to write multiple separate applications for every device, it allows developers to build their application once and have it work on all consumer devices be it desktop, laptop, tablet or phone.

Write once, deploy everywhere, no gatekeepers, no fees. just as Steve Jobs originally promised.

Stuart’s presentation

Stuart examined whether Apple’s assertion that lack of real browser diversity is actually better for consumers’ privacy and security.

My presentation

Here’s my captioned video. Below is the marked-up transcript with links. Note: this submission is my personal opinion and does not represent the opinion of any of my past or present clients or employers.

Last week I was part of a meeting with the UK’s Competition and Markets Authority, the regulator, to talk about Apple devices and the browser choice (or lack of it) on them. They’re doing a big study into Apple’s conduct in relation to the distribution of apps on iOS and iPadOS devices in the UK, in particular, the terms and conditions governing app developers’ access to Apple’s App Store, and part of that involves looking at browsers on iOS, and part of that involves talking to people who work on the web. So myself and Bruce Lawson and another UK developer of iOS and web apps put together some thoughts and had a useful long meeting with the CMA on the topic.

They asked that we keep confidential the exact details of what was discussed and asked, which I think is reasonable, but I did put together a slide deck to summarise my thoughts which I presented to them, and you can certainly see that. It’s at kryogenix.org/code/cma-apple and shows everything that I presented to the CMA along with my detailed notes on what it all means.

Bruce had a similar slide deck, and you can read his slides on iOS’s browser monopoly and progressive web apps. Bruce has also summarised our other colleague’s presentation, which is what we led off with. The discussion that we then went into was really interesting; they asked some very sensible questions, and showed every sign of properly understanding the problem already and wanting to understand it better. This was good: honestly, I was a bit worried that we might be trying to explain the difference between a browser and a rendering engine to a bunch of retired colonel types who find technology to be baffling and perhaps a little unmanly, and this was emphatically not the case; I found the committee engaging and knowledgeable, and this is encouraging.

In the last few weeks we’ve seen quite a few different governments and regulatory authorities begin to take a stand against tech companies generally and Apple’s control over your devices more specifically. These are baby steps — video and music apps are now permitted to add a link to their own website, saints preserve us, after the Japan Fair Trade Commission’s investigation; developers are now allowed to send emails to their own users which mention payments, which is being hailed as “flexibility” although it doesn’t allow app devs to tell their users about other payment options in the app itself, and there are still court cases and regulatory investigations going on all around the world. Still, the tide may be changing here.

What I would like is that I can give users the best experience on the web, on the best mobile hardware. That best mobile hardware is Apple’s, but at the moment if I want to choose Apple hardware I have to choose a sub-par web experience. Nobody can fix this other than Apple, and there are a bunch of approaches that they could take — they could make Safari be a best-in-class experience for the web, or they could allow other people to collaborate on making the browser best-in-class, or they could stop blocking other browsers from their hardware. People have lots of opinions about which of these, or what else, could and should be done about this; I think pretty much everyone thinks that something should be done about it, though. Even if your goal is to slow the web down and to think that it shouldn’t compete with native apps, there’s no real reason why flexbox and grid and transforms should be worse in Safari, right? Anyway, go and read the talk for more detail on all that. And I’m interested in what you think. Do please hit me up on Twitter about this, or anything else; what do you think should be done, and how?

Last week I sat down with the UK Competition and Markets Authority to talk about browser choice on Apple devices, and whether the claims that limiting choice is good for security and privacy actually hold up. Here's the presentation I gave.https://t.co/7i35fwdnrM

— Stuart Langridge (@sil) September 6, 2021

• Link o’ the Week: iOS Engine Choice In Depth – Big Al doing his forensics on Apple’s disingenuousness.
• Australian watchdog considers regulating Apple and Google to boost app store competition = ” both companies faced very little competition in app distributions on their respective mobile platforms. The competition watchdog suggested the companies were stifling competition with their control over what apps could do on their platforms.”
• Russia slaps Apple with warning over abusing dominant market position – “it was cheaper to buy goods on a seller’s website… Apple gets a commission from 15% to 30% for each payment in the App Store, yet users are blocked from being informed about the possibility of purchases outside of it”
• After Apple rejections, FlickType gives up on popular iPhone keyboard for the blind – “Apple has thrown us obstacle after obstacle for years while we try to provide an app to improve people’s lives, and we can no longer endure their abuse.”
• Postcodes.io – Postcode & Geolocation API for the UK. Free, Open Source and based solely on Open Data
• A guide to designing accessible, WCAG-compliant focus indicators by Sara Soueidan
• Good stablecoins, a protocol for money, and digital wallets: the formula to fix our broken payment system. Hurrah! Facebook’s ZuckCoin is about to launch. And apparently, anyone who doesn’t love the idea of Facebook knowing all about your “money in the MetaVerse” (really!) is “profoundly unAmerican”.
• End of the line for Uber – Cory Doctorow on Uber’s probable demise. The saddest thing about Uber (and Airbnb) is they *could* have been good ideas if they actually were about real people’s spare capacity meeting some genuine excess demand. But (perhaps inevitably) they turned into hideous Silicon Valley monsters.
• Goodbye, Michael Jones, the man who gave the power of maps in our hands – Obituary of Michael Jones, the man behind Google Earth, and his mission to democratize maps.

There’s been a bit of a thing about software user experience going off the rails lately. Some people don’t like cross-platform software, and think that it isn’t as consistent, as well-integrated, or as empathetic as native software. Some people don’t like native software, thinking that changes in the design of the browser (Apple), the start menu (Microsoft), or everything (GNOME) herald the end of days.

So what’s going on? Why did those people make that thing that you didn’t like? Here are some possibilities.

My cheese was moved

Plenty of people have spent plenty of time using plenty of computers. Some short-sighted individual promised “a computer on every desktop”, made it happen, and this made a lot of people rather angry.

All of these people have learned a way of using these computers that works for them. Not necessarily the one that you or anybody else expects, but one that’s basically good enough. This is called satisficing: finding a good enough way to achieve your goal.

Now removing this satisficing path, or moving it a few pixels over to the left, might make something that’s supposedly better than what was there before, but is actually worse because the learned behaviour of the people trying to use the thing no longer achieves what they want.
It may even be that the original thing is really bad. But because we know how to use it, we don’t want it to change.

Consider the File menu. In About Face 3: The Essentials of Interaction Design, written in 2007, Alan Cooper described all of the problems with the File menu and its operations: New, Open, Save, Save As…. Those operations are implementation focused. They tell you what the computer will do, which is something the computer should take care of.

He described a different model, based on what people think about how their documents work. Anything you type in gets saved (that’s true of the computer I’m typing this in to, which works a lot like a Canon Cat). You can rename it if you want to give it a different name, and you can duplicate it if you want to give it a different name while keeping the version at the original name.

This should be better, because it makes the computer expose operations that people want to do, not operations that the computer needs to do. It’s like having a helicopter with an “up” control instead of a cyclic and collective controls.

Only, replacing the Open/Save/Save As… stuff with the “better” stuff is like removing the cyclic and collective controls and giving a trained helicopter pilot with years of experience the “up” button. It doesn’t work the way they expect, they have to think about it which they didn’t have to do with the cyclic/collective controls (any more), therefore it’s worse (for them).

Users are more experienced and adaptable now

But let’s look at this a different way. More people have used more computers now than at any earlier point in history, because that’s literally how history works. And while they might not like having their cheese moved, they’re probably OK with learning how a different piece of cheese works because they’ve been doing that over and over each time they visit a new website, play a new game, or use a new app.

Maybe “platform consistency” and “conform with the human interface/platform style guidelines” was a thing that made sense in 1984, when nobody who bought a computer with a GUI had ever used one before and would have to learn how literally everything worked. But now people are more sophisticated in their use of computers, regularly flit between desktop applications, mobile apps, and websites, across different platforms, and so are more flexible and adaptable in using different software with different interactions than they were in the 1980s when you first read the Amiga User Interface Style Guide.

We asked users; they don’t care

At first glance, this explanation seems related to the previous one. We’re doing the agile thing, and talking to our customers, and they’ve never mentioned that the UI framework or the slightly inconsistent controls are an issue.

But it’s actually quite different. The reason users don’t mention that there’s extra cognitive load is that these kinds of mental operations are tacit knowledge. If you’re asked about “how can we improve your experience filing taxes”, you’ll start thinking tax-related questions, before you think “I couldn’t press Ctrl-A to get to the beginning of that text field”. I mean, unless you’re a developer who goes out of their way to look for that sort of inconsistency in software.

The trick here is to stop asking, and start watching. Users may well care, even if they don’t vocalise that caring. They may well suffer, even if they don’t realise it hard enough to care.

We didn’t ask users

Yes, that happens. I’ve probably gone into enough depth on why it happens in various places, but here’s the summary: the company has a customer proxy who doesn’t proxy customers.

Respectable persons of this parish of Internet have been, shall we say, critical of Scrum and its ability to help makers (particularly software developers) to make things (particularly software). Ron Jeffries and GeePaw Hill have both deployed the bullshit word.

My own view, which I have described before, is that Scrum is a baseline product delivery process and a process improvement framework. Unfortunately, not many of us are trained or experienced in process improvement, not many of us know what we should be measuring to get a better process, so the process never improves.

At best, then, many Scrum organisations stick with the baseline process. That is still scadloads better than what many software organisations were trying before they had heard of Agile and Scrum, or after they had heard of it and before their CIO’s in-flight magazine made it acceptable. As a quick recap for those who were recruited into the post-Agile software industry, we used to spend two months working out all the tasks that would go into our six month project. Then we’d spend 15 months trying to implement them, then we’d all point at everybody else to explain why it hadn’t worked. Then, if there was any money left, we’d finally remember to ship some software to the customer.

Scrum has improved on that, by distributing both the shipping and the blaming over the whole life span of the project. This was sort of a necessary condition for software development to survive the dot-com crash, when “I have an idea” no longer instantly led to office space in SF, a foosball table, and thirty Herman Miller chairs. You have to deliver something of value early because you haven’t got enough money any more to put it off.

So when these respectable Internet parishioners say that Scrum is bad, this is how bad it has to be to reach that mark. Both of the authors I cite have been drinking from this trough way longer than I have, so have much more experience of the before times.

In this article I wanted to look at some of the things I, and software engineering peers around me, have done to make Scrum this bad. Because, as Ron says, Scrum is systemically bad, and we are part of the system.

Focus on Velocity

One thing it’s possible to measure is how much stuff gets shovelled in per iteration. This can be used to guide a couple of process-improvement ideas. First up is whether our ability to foresee problems arising in implementation is improving: this is “do estimates match actuals” but acknowledging that they never do, and the reason they never do is that we’re too optimistic all the time.

Second is whether the amount of stuff you’re shovelling is sustainable. This has to come second, because you have to have a stable idea of how much stuff there is in “some stuff” before you can determine whether it’s the same stuff you shovelled last time. If you occasionally shovel tons of stuff, then everybody goes off sick and you shovel no stuff, that’s not sustainable pace. If you occasionally shovel tons of stuff, then have to fix a load of production bugs and outages, and do a load of refactoring before you can shovel any more stuff, that’s not a sustainable pace, even if the amount of work in the shovelling phase and the fixing phase is equivalent.

This all makes working out what you can do, and what you can tell other people about what you can do, much easier. If you’re good at working out where the problems lie, and you’re good at knowing how many problems you can encounter and resolve per time, then it’s easier to make plans. Yes, we value responding to change over following a plan, but we also value planning our response to change, and we value communicating the impact of that response.

Even all of that relies on believing that a lot of things that could change, won’t change. Prediction and forecasting aren’t so chaotic that nobody should ever attempt them, but they certainly are sensitive enough to “all things being equal” that it’s important to bear in mind what all the things are and whether they have indeed remained equal.

And so it’s a terrible mistake to assume that this sprint’s velocity should be the same as, or (worse) greater than, the last one. You’re taking a descriptive statistic that should be handled with lots of caveats and using it as a goal. You end up doing the wrong thing.

Let’s say you decide you want 100 bushels of software over the next two weeks, because you shovelled 95 bushels of software last week. The easiest way to achieve that is to take things that you think add up to 100 bushels of software, and do less work so that they contain only, say, 78 bushels, and try to get those 78 bushels done in the time.

Which bits do you cut off? The buttons that the customer presses? No, they’ll notice that. The actions that happen when the customer presses the buttons? They’ll probably notice that, too. How about all the refinement and improvement that will make it possible to add another 100 bushels next time round? Nobody needs that to shovel this 100 bushels in!

But now, next time, shovelling software is harder, and you need to get 110 bushels in to “build on the momentum”. So more corners get cut, and more evenings get worked. And now it’s even harder to get the 120 bushels in that are needed the next time. Actual rate of software is going down, claimed rate of software is going up: soon everything will explode.

Separating “technical” and “non-technical”

Sometimes also “engineering” and “the business”. Particularly in a software company, this is weird, because “the business” is software engineering, but it’s a problem in other lines of business enabled by software too.

Often, domain experts in companies have quite a lot of technical knowledge and experience. In one fintech where I used to work, the “non-technical” people had a wealth (pun intended) of technical know-how when it came to financial planning and advice. That knowledge is as important to the purpose of making financial technology software as is software knowledge. Well, at least as important.

So why do so many teams delineate “engineering” and “the business”, or “techies” and “non-technical” people? In other words, why do software teams decide that only the software typists get a say in what software gets made using what practices? Why do people divide the world into pigs and chickens (though, in fairness to the Scrum folks, they abandoned that metaphor)?

I think the answer may be defensiveness. We’ve taken our ability to shovel 50 bushels of software and our commitment (it used to be an estimate, but now it’s a commitment) to shovel 120 bushels, and it’s evident that we can’t realistically do that. Why not? Oh it must be those pesky product owners, keep bringing their demands from the VP of marketing when all they’re going to do is say “build more”, “shovel more software”, and they aren’t actually doing any of it. If the customer rep didn’t keep repping the customer, we’d have time to actually do the software properly, and that would fix everything.

Note that while the Scrum guide no longer mentions chickens and pigs, it “still makes a distinction between members of the Scrum team and those individuals who are part of the process, but not responsible for delivering products”. This is an important distinction in places, but irrelevant and harmful in others. But it’s at its most harmful when it’s too narrowly drawn. When people who are part of the process are excluded from the delivering-products cabal. You still need to hear from them and use their expertise, even if you pretend that you don’t.

The related problem I have seen, and been part of, is the software-expertise people not even gaining passing knowledge of the problem domain. I’ve even seen it working on a developer tools team where the engineers building the tools didn’t have cause to use, or particularly even understand, the tool during our day-to-day work. All of those good technical practices, like automated acceptance tests, ubiquitous language, domain-driven design; they only mean shit if they’re helping to make the software compatible with the things people want the software for.

And that means a little bit of give and take on the old job boundaries. Let the rest of the company in on some info about how the software development is going, and learn a little about what the other folks you work with do. Be ready to adopt a more nuanced position on a new feature request than “Jen from sales with another crazy demand”.

Undriven process optimisation

As I said up top, the biggest problem Scrum often encounters in the wild is that it’s a process improvement framework run by people who don’t have any expertise at process improvement, but have read a book on Scrum (if that). This is where the agile consultant / retrospective facilitators usually come in: they do know something about process improvement, and even if they know nothing about your process it’s probably failing in similar enough ways to similar processes on similar teams that they can quickly identify the patterns and dysfunctions that apply in your context.

Without that guidance, or without that expertise on the team, retrospectives are the regular talking shop in which everybody knows that something is wrong, nobody knows what, and anybody who has a pet thing to try can propose that thing because there are no cogent arguments against giving it a go (nor are there any for it, except that we’ve got to try something!).

Thus we get resume-driven development: I bet that last sprint was bad because we aren’t functionally reactive enough, so we should spend the next sprint rewriting to this library I read about on medium. Or arbitrary process changes: this sprint we should add a column to the board, because we removed a column last time and look what happened. Or process gaming: I know we didn’t actually finish anything this month, but that’s because we didn’t deploy so if we call something “done” when it’s been typed into the IDE, we’ll achieve more next month. Or more pigs and chickens: the problem we had was that sales kept coming up with things customers needed, so we should stop the sales people talking either to the customers, to us, or to both.

Work out what it is you’re trying to do (not shovelling bushels of software, but the thing you’re trying to do for which software is potentially a solution) and measure that. Do you need to do more of that? Or less of it? Or the same amount for different people? Or for less money? What, about the way you’re shovelling software, could you change that would make that happen?

We’re back at connecting the technical and non-technical parts of the work, of course. To understand how the software work affects the non-software goals we need to understand both, and their interactions. Always have, always will.