Discussing software, the web, politics, sexuality and the unending supply of human stupidity.

Smartwatches and one-shot interactions

For a while, I’ve had an Apple Watch, mostly out of industrial curiosity—I am interested to see what a smartwatch does, how they are interacted with and how they will change the tech industry. Before the Apple Watch, I had a Fitbit but when it fell apart, I thought “let’s try out a fully fledged smartwatch”.

The main things I use the watch for are: telling the time, health tracking and as a quick reminder of what I need to do (calendar and tasks). I also use it to pay with Apple Pay (which itself is a bit of an unreliable experience: some places that take contactless don’t take Apple Pay, some places will take contactless and Apple Pay but will be picky about what types of card they take contactless).

The more I use the watch, the less convinced I am about the app model. Each app becomes its own little silo that you have to jump in and out of. Not interesting. Finding and launching an app on the Apple Watch is fiddly. If you have a phone full of apps, when you set up the Apple Watch, there’ll be loads and loads of quite pointless apps that you don’t want or need. To pick on one random category: Flipboard and Feedly have Apple Watch apps. I have no idea why anyone would want to try and sit and read news on a watch. Just pull your damn phone out. Hell, there’s even dating apps like Scruff for the Watch now.

What I’ve found is that the apps which work really well on the watch are ones that require minimal to no interaction. The built-in Apple Maps app is great precisely because you don’t need to interact with it much. Just set where you are going, and you’ve got a little screen you can glance at when you want to see where you are and where you are going. It works really well when trying to walk some of the fiddlier streets in London. (Same with Google Maps, and I’m excited to see that the OSM-based now has a watch app.) The Citymapper app is similarly great: you set where you are going, and when you need to get off the bus, it’ll tap you on the wrist and show up on the screen.

One thing I think could be improved on the Apple Watch is the use of the button. Currently, pressing the button once will bring up a list of friends. I have found absolutely no use for this. This may just be that I’m anti-social but I use the watch mostly as an accompaniment to the world around me, not as a way to talk to or contact people. The phone is a much more natural way to talk and text people. The ability to send a pre-canned response from the watch is handy when someone texts you and you just want to fire back a quick reply, but if I want to text, the watch is a poor way of doing so compared to the phone in my pocket. It is interesting that Apple have tried to build a socially-focussed (rather than app-focussed) UI here, but it isn’t something I use at all. It is just this thing that comes up when one is trying to use Apple Pay.

Given that this social UI isn’t much use, what would be nice is if the future evolution of the Apple Watch would lean away from apps and instead focus on simple one-shot, sightless interactions. An app I use all the time on both the Watch and the iPhone is Shazam. Shazam itself is a horrendous mess of ads and crap, but here is how it used to look before growth hacking marketing droids fucked it all up:

Beautiful. As interactive experiences go, Shazam was like Kodak. You press the button, we do the rest. Even better than Kodak, you don’t even have to point the box in the right direction. You press the button, we tell you what song you are listening to. There’s now SoundHound which brings back the good old days of Shazam, but the library isn’t as good as Shazam, so I always end up going back to Shazam despite its terrible UI.

Shazam is a perfect example of a one-shot, sightless interaction. You are in a bar or a nightclub or waiting in line in a shop and a song comes on you like. So you reach down to your watch and you press the button—the one that currently brings up the pointless friend list UI that I don’t use—and it works out what the song is and stores it in a list for me. And that’s it. You don’t have to look at the screen. Maybe after the song has been recognised, it’ll vibrate slightly to tell you that it has recognised it, and maybe drop a notification to tell you. That’s all customisable.

(It being Shazam, it then doesn’t work with Spotify this week because their biz dev guy decided that they didn’t like Spotify anymore.)

The point here is that instead of interacting with an app, having to open the app and press the button, the app just sits there waiting for you. Now, Shazam is something I’d want to be able to use frequently because I care about music. Other people are different. They could wire up the button to their favourite interaction. Maybe that’s texting their partner saying they are on the way home. Maybe that’s checking in on Swarm. Maybe that’s play/pause on their audio. Once we start breaking out of the “app” way of thinking and start thinking about the interactions that people want to do while in the world. Rather than having to delve into the watch and into the apps, the watch makes the individual interactions you care about ready-to-hand.

On a watch computer, I don’t care about having a hundred apps. I care about having the interactions I do most frequently possible in a seamless way. That’s what smartwatch designers should think about. It might have the nice side effect of making people less obsessed with apps as some kind of brand vehicle, something you use to measure how many DAUs or MAUs or whatever you have and instead something you use to deliver valuable experiences to users through. Some of those experiences will involve your users not even seeing your app or your brand.

Standups: just use text (and maybe Slack)

Having written one long post today on software methodology, I’m going to write a short one. I have one simple argument to make: replace your morning standup with a text-based update (e.g. via Slack).

I’ve rarely ever seen standup meetings work well. I know people who have worked at companies who say that they got standups working right. But I’ve seen so many problems with them that I’ve never really seen the value in them.

First of all, people make standups way too large and with people whose jobs have no relevance to the job of building software. I’ve seen standups with over 20 people in them. Then there’s the standups where everyone gets dragged in. Senior management, middle management, marketing, sales, pretty much anyone. Quite how what they were doing yesterday or today is of any relevance to the developers—who knows? What value is hearing about what the CEO had for lunch yesterday having on helping the developer build the product? None. But standups are agile and if you are cargo-culting, the best way to be more agile is to have more people in standups and more standups and so on.

I’ve also seen people running standups on the basis of office politics rather than based around product delivery. Rather than having separate standups for different products, just chuck everyone in together. Because what someone building a completely different product is doing is somehow of relevance to people on a different project.

The only time I’ve seen a standup work successfully is when it wasn’t a standup at all but a status update posted via Slack. Now, there’s the same format and the same time constraint. You tell the team “at 9:45am (or whenever) you need to post your status update”. But it gives them flexibility. If they do some kind of personal productivity mechanism like GTD or Pomodoro, they can copy in notes from that system into the standup comment. They can keep notes from the previous day. Being at their computer means they can actually look at what is in front of them (Git commits, issue tracker updates etc.) to determine what they are working on, and they can link to those if they feel like it.

It gives more flexibility for remote workers or even just people running a few minutes late for the office. Bus got stuck in traffic? You can still post your update on Slack.

It gives more permanence. You can see what you posted yesterday and see whether the things you said you’d do yesterday were the things you actually did. This gives you more accountability. Also, having a clear log of what you did every day you worked helps when compiling timesheets, or invoices if you are a contractor.

It prevents people from going off on pointless discussions about stuff that is of no relevance to the rest of the team. They can still discuss it, just not in the standup channel.

In every standup, there’s often someone who is extremely quiet or who doesn’t like speaking. Given that people with hearing loss now make up 20% of the population, the likelihood is that the quiet or shy person can’t be heard by at least one member of the team. If you are using text-based chat, no problem. Also, I bet that the place where you do your daily standup probably ain’t wheelchair accessible.

For the remote workers, they don’t have to futz around getting Skype or Hangouts or whatever setup so they can see their coworkers looking into the middle distance.

For teams working in a shared open-plan office (so much ugh), it means less noise bouncing around and annoying other people in the office.

That person whose job has almost no overlap with yours? You can skim read their contribution and only really pay attention if it is relevant. That pointless waffler who goes into long and dull detail about his day-to-day work? He’s not wasting anybody’s time but his own.

Slack or text-based standups are literally better in every single way. There’s now a whole litany of tools you can use to have text-based standups in Slack: Squash Reports, Tatsu, GeekBot, Jell and… just having a Slack channel that you ask people to post in every day. Or Hipchat. Or Campfire, or IRC, or Skype, or whatever. However you do it, it is probably going to be less dysfunctional than most actual standups.

The software assembly line fallacy

Many software developers now smile nervously when their employers say that they are “doing agile” (doing agile what?, the pedant in me asks—an adjective modifies a noun or pronoun). You just know that the old-school project manager has gone and ‘upgraded’ their PRINCE2 certificate over to a ScrumMaster certificate from some shady place that does a weekend-long course on how to do stand-ups and retros. Getting said certificate and buying a whole boxful of post-it notes from Ryman’s is apparently all you need to be an agile project manager. Unlike a number of the world’s great religions, there’s no baptism or genital mutilation required for the agile cult, just accepting the various doctrines and the transfer of money into the hands of a local friendly guru.

Obviously, I must now make the obligatory statement that there’s nothing at all wrong with agile, ever. It is perfectly fine and truthful and excellent and if it doesn’t work for you, you are just doing it wrong and need to go to confession (retrospective) and do penance (hire a consultant to train the team more). Praise be to agile. Amen.

A recurring theme I see in a lot of companies, and online at sites like StackOverflow/Programmers StackExchange, and in personal conversation with other developers is what I’ve come to call the assembly line view of software development. It seems to be popular with people who do agile really badly (i.e. as a cargo cult slavishly following the diktats of trainers and consultants). Many people seem to think that they can deliver software in an assembly line manner while also “being agile” (I try not to ask too many questions about what they mean by that so as to save the eventual embarrassment).

Waterfall is essentially an assembly line approach. You start with requirements, and then you proceed to design, then to construction, testing, release, documentation, integration, then support. Modern assembly line software development mostly isn’t this type of waterfall anymore. Waterfalls assembly line was subdivided up by the familiar steps of the waterfall.

These days, assembly line projects are divided up based on team ability, but the waterfall nature of those projects is broadly the same. You have a project that starts with business needs collection: this is done by salesman who ask the client what they want. He doesn’t really know anything about, say, the web or software development or about apps or the current state of what is possible with technology. But he does have nice shoes and an excellent line in buzzwords. So he’ll bring back a project brief that is extremely vague and keep it hidden away in his email account, inaccessible to developers or designers.

Then the project gets handed over to designers (or “creatives”, if you are in the kind of place that calls them that). Having got the business requirements from the salesman, they then design the product in Adobe Photoshop, a photo manipulation tool that is commonly used to model complex interactions, animations and modern responsive design approaches despite not being very good at doing any of those things. At the end of this, you will have PSD files.

The next step is to hand the project to front-end developers. The front-end developers will then convert the PSD files into HTML and CSS, without any specific knowledge of where the site will be deployed or which back-end technology stack is to be used (and thus what templating languages need to be used), nor any real knowledge of the complexity of any third-party services or APIs that the system needs to hook up to. Even worse, they may not really have any idea who is using the site, or on what devices. This is not their fault: nobody ever explained to them what needs doing. You don’t have to explain to assembly line workers anything about what the other people on the assembly line are doing.

Then the application is handed to back-end developers who try and cobble what the front-end developers have done to match the back-end technology of choice. They then have to set up the integrations with the third-party services, even though said services were not understood either by the front-end developers or the designers. When none of this works, well, there’s not really a plan for that.

Finally, the application is handed off to the operations team who deploy the application. They have had no input at any stage prior to this, so if some front-end build tool or back-end or database technology isn’t compatible with whatever the cloud deployment stack they are using demands, well, that’s going to be fun. And, sure, they may have to break some stuff to make it all deploy. But it’s not like anyone is going to have to change that code, so what’s the problem?

At this point, the familiar end-of-waterfall cycle happens. Design, front-end, back-end and operations all now get increasingly frantic to try and launch to deadline. The only functioning test server is the ops person letting you SSH into what will eventually become the production server. The front-end developer has moved onto another project, so the inevitable failures to map Photoshop designs pixel perfectly to HTML and CSS is remedied by having the original designer hover next to a developer pixel-tweaking it all in Chrome Dev Tools before checking it in with a commit message of “designers can’t make their bloody minds up”. It all gets out the door, but more by luck than judgment or careful planning.

You might assume wrongly that the assembly line metaphor would include time for testing and that there would be a person whose role would include spending a decent amount of time testing the finished product before it was handed off to customers. But that never really works out in reality, because hiring testing/QA people costs money and money is better spent on sales people to get you more projects that you’ll struggle to deliver due to, well, reasons too many to count.

By my tone, I’m sure you can tell that I am not seriously proposing this as a useful pattern for software development, but attempting to sign its death warrant.

The primary problem with this is a lack of communication. Each step in the process is treated as a predictable part of an assembly line when the expertise of each part of the process needs to be used to assist the other people working on the project. The developer with the expertise in how the third-party integration works needs to be talking to the project manager and the designer up front so they are fully aware of the limitations and issues that integrating with the platform will bring. The project manager needs to give some advice to the back-end developers how the thing is meant to operate, so they can have a first cut of a back-end working for the design to hook up to once the front-end developers are done.

Like the assembly line of Henry Ford, the intention of assembly line development is to try and introduce predictability and modularity to the process. Is one developer not available? Oh well. We’ll switch in another one. Sure, he hasn’t worked with the design team, hasn’t really understood the technical complexity of what we’re asking him to do, but he’s a developer. He’ll figure it out. (About a week after it was due to go out.)

Ultimately, assembly line programming, like most methodologies, ignores experience or detailed knowledge and tries to magic creativity out of an assembly line. I’ve seen these projects and they succeed only in the sense that they get the product out the door. They succeed in spite of chaos and lack of planning and people having to pull weekends and late nights. (The contractor getting double their day rate to work the weekend is fine with this; the permanent staff member who missed their kids birthday party is slightly less happy.)

Don’t let this happen to you. If you spot your company trying to make an assembly line type of process, there are ways to fix it. If you are a developer or a manager of a development team, insist on getting the developers likely to build it in on early meetings with management and designers so said developers can guide them into designing things that will actually be possible (both technically and with the team that you have available). If you manage a developer team, make clear what they can and can’t deliver with the skills they have.

Ultimately, if you can’t stop the assembly line nonsense, people will leave. They’ll get fed up with the waterfall-style last minute crunch times, the stress and anxiety, the lack of value placed on their creative and technical skills, the disinterest in fixing these issues on the part of management, and the recurring lost weekends and overnights. They’ll disappear and they’ll take their expertise (which is needed for the next project) away with them. You probably want to avoid that. Or not. I mean, the best thing about assembly lines is that if a worker on an assembly line stops working, you can easily replace them with someone else. Because hiring good technical people is super easy, right?

The assembly line is a terrible model. What we really need are strong teams where all the people with skills are able to demonstrate those skills to each other, to use those skills to guide each other to build great software. Software projects aren’t repeatable like cars or tin cans or hammers are. Assembly lines are for building the same project over and over. Software and websites and so on are not like that.

I just learned about went, a Python library for webmentions that is built on mf2py.

Meta-point: it would be interesting to see if we could find a way to express “library X depends on library Y” using microformats and webmentions, so that when someone launches a new library that is based on a library you have created, you can be notified about it.

Question on signup form for a new web service: “Why do you want to use [product name]?”

My honest answer: “Pissing around, mostly.”

This is the usual answer for most things. Until you try them, you don’t know what you’ll be able to use them for.

On the dangers of a blockchain monoculture is an interesting takedown of Bitcoin’s flaws. It’s a standard refrain in the VC investments around Bitcoin and blockchains that while Bitcoin may not hold much value, blockchains are very interesting.

I see even less value in blockchains than I do in Bitcoin: an enormous, slow, lumbering, public database that you can’t remove private information from. Great. Just what privacy advocates have been fighting for.

I’m tempted to write a simple guide to current software development practices that explains them for developers. Specifically things like Scrum, Agile, TDD, BDD, DDD (and all the other *DD) and so on.

It’d take the form of answering the following questions.

  1. What is it? (e.g. TDD: “writing tests before you write code”)
  2. How do I do it? (e.g. TDD: “use a unit test library like JUnit or PyTest and enforce iron discipline on yourself”)
  3. Does it work? (Usual answer: we don’t know because we never fucking test any of our methodologies, we just adopt them on the basis of religious preference and/or hearsay)
  4. Who is making money off this trend? (Usual answer: consultants)

And, yes, the complete lack of useful answers to question 3 does tend to scupper this idea from the start.

What Does My Site Cost? shows you how much it costs to download your webpage.

And, yes, the extravagant cost of mobile bandwidth in various developing countries is a negative externality of shitty, but fashionable, web programming practices. Your pointlessly bloated JavaScript framework costs money for poor people to download.

Possible new emojis in Unicode 9.0.

With the addition of numerous sport-related emojis (wrestlers, water polo, handball, fencing, modern pentathlon), plus the first, second and third medal symbols, and the existing flag symbols, people will finally be able to report the results of the Olympics purely using emoji.

Probably won’t be ready for the Olympics in Rio de Janeiro in the summer, but maybe good to go for the 2020 Olympics in Tokyo.