Solved the “open in app” nuisance by uninstalling the app.
Solved the “open in app” nuisance by uninstalling the app.
The recent leak of LinkedIn’s password database shows that passwords remain a fragile part of our security ecosystem. Users are bad at coming up with passwords. They use the same password among multiple services. Enterprise password change policies have been part of the problem: users simply take their existing passwords and stick an incrementing number on the end, or engage in other substitutions (changing the letter o for the number 0, for example). Plus, the regular password change doesn’t really help as a compromised password needs to be fixed immediately, rather than waiting three months for the next expiration cycle. CESG recently issued guidance arguing against password expiration policies using logic that is obvious to every competent computer professional but not quite so obvious to big enterprise IT managers.
Many users, fed up with seeing yet another IT security breach, have switched over to using password managers like KeePass, 1Password, Dashlane and LastPass. This is something CESG have encouraged in their recent password guidance. Password managers are good, especially if combined with two-factor authentication.
For users who are starting to use a password manager, they have the initial hurdle of switching over from having the same password for everything to using the password manager’s generated password approach. They may have a backlog of tens or hundreds of passwords that need changing. The process of changing passwords on most websites is abysmally unfriendly. It is one of those things that gets tucked away on a settings page. But then that settings page grows and grows. Is it ‘Settings’, or ‘My Profile’ or ‘My Account’ or ‘Security’ or ‘Extra Options’? Actually finding where on the website you have to go in order to change your password is the part which takes longest.
Making it easier for a user to change their password improves security by allowing them to switch from a crap (“123456”), reused, dictionary word (“princess”) or personally identifiable password (the same as their username, or easily derived from it: “fred” for the username “fred.jones”) to a strong password that is stored only in their password manager like “E9^057#6rb2?1Yn”.
We could make it easier by clearly pointing the way to the password change form so that software can assist the user to do so. The important part here is assist, not automate. The idea of software being able to automate the process of changing passwords has some potential selling points, but the likelihood of it being adopted is low. Instead, I’m simply going to suggest we have software assist the user to get to the right place.
In the form of a user story, it’d be like this: as a user of a password management application, I’d like to speed up the process of changing passwords on websites where they have been detected to be weak, reused or old. When I’m looking at a password I wish to change, I could click “change password” in the password management application and it’d take me to the password change form on the website without me having to search around for it.
There’s a few ways we could do this. There are some details that would have to be ironed out, but this is a rough first stab at how to solve the problem.
This is my preferred option. On the website, there is a link, either visible (using an
a element) or invisible (a
link in the
head). It would be marked with a
rel attribute with a value like
password-change. Software would simply parse the HTML and look for an element containing
rel="password-change" and then use the
href attribute. The user may have to go through the process of logging in to actually use the password change form, but it’d stop the process of searching.
Alternatively, have people put some JSON metadata in a file and store it in a known location, similar to
robots.txt or the various things spooked away in the
.well-known hidey-hole. This is okay, but it suffers from all the usual flaws of invisble metadata, and is also a violation of the “don’t repeat yourself” principle—the links are already on the web in the HTML. Replicating that in JSON when it already exists in HTML increases the likelihood that the JSON version will fall out of sync with the published reality.
Same principle as the JSON one, but using HTTP(S) headers. Same issue of invisible metadata. Same issue with same-origin policies.
As noted above, there are some security issues that would have to be handled:
My rather conservative answers to these three questions are all no, but other people might differ.
As I said above, this is a very narrowly specified idea: the ecology of web application security is pretty fragile, and the likelihood of radical change is low, so I’m not proposing a radical overhaul. Just a very minor fix that could make it easier for (motivated, security-conscious) users to take steps to transition to better, stronger passwords.
I’ve struggled to find where to report this issue, so I’m putting it on my blog as a canonical copy just in case I forget to jump through whatever hoops are needed to report the bug.1
file command that is widely used in UNIX land to detect file types doesn’t seem to detect an SVG file properly if it doesn’t have an XML declaration.
Fine, you might say, but if there’s no XML declaration, then that means it isn’t XML. Not so. §2.8 of XML 1.0 says that documents should have an XML declaration but that an otherwise well-formed XML document remains well-formed even without an XML declaration.
The application I’m working on will check manually to see if the data uploaded smells like an SVG and accept it per Postel’s law. But
libmagic ought to do the job…
Seriously, it is 2016, use Github or equivalent (GitLab, Bitbucket), not CVS… ↩
An excellent article on the silly Conversational UI trend: Bots won’t replace apps. Better apps will replace apps.
As the author of the piece notes, there’s plenty that’s wrong with the current trend in app design. Conversational UIs are orthogonal to fixing those problems. Each individual app has become its own silo. The model of “spend a bunch of money to hire a bunch of iOS and Android devs to build out a custom app for each platform, then spend a ton of resources trying to convince people to download those apps” has to wind down at some point. And there will be a point where we want a lot more fluidity between interactions. We still spend an enormous amount of time jockeying data between apps and manually patching pipelines of information into one another like some a telephone operator of old. Conversational UIs don’t fix any of those things. Better UIs, which is often less UIs, fix that. As does more focus on trying to make it so we can more efficiently and seamlessly have single-serving, one shot interactions (which goes against all the metrics: we often measure success by how much time someone spends interacting with something, rather than measuring success by how well that thing hides itself away and doesn’t need to be interacted with).
Actually, the full name is the strikingly memorable “NHS Digital: Information and technology for better health and care”, which sounds more like the name of an academic paper than a healthcare organisation. The first order of business for employees of NHS Digital will be to set up keyboard shortcuts so they can type the full name. We should perhaps breathe a sigh of relief that nobody managed to shoehorn the word “cyber” into the name.
The announcement states that the new name “should help to build public recognition, confidence and trust”. Presumably because when people think of “NHS Digital”, they’ll not associate the new brand with the colossal cascade of cock-ups that is care.data, the plan to share your confidential medical records including alcohol and tobacco use and mental health conditions on a centralised computing system that will undoubtedly be as secure and well-managed as most other central government databases. Rebranding HSCIC seems like a cynical way to distance themselves from this highly controversial scheme.
The latest revelations from GCHQ show them to be even more slippery and untrustworthy than previously thought. And the government want to give them more power rather than hold the leash tightly until they behave within the law? The intelligence services have shown a colossal lack of transparency or accountability that makes a mockery of any claim to being an institution compatible with democratic principles.
In things nobody should be the least bit surprised about, companies like 23andMe are being asked to provide DNA samples from their customers to law enforcement agencies.
There’s a way that the 23andme model could work that wouldn’t require creating a honeypot of DNA data for law enforcement. Instead of centralising the data, decentralise it. Have people send in their DNA sample, sequence it, then send that data back to the customer. Then to provide analysis of that data, give each individual customer a piece of software that runs on their computer and does the analysis on there. Then send back anonymous data, but giving each individual user the choice of what they share back to the centralised server. That would actually put users in real control.
Decentralisation and user empowerment isn’t just a nice idea in this case, it’s potentially the difference between being arrested and not. If companies like 23andMe don’t switch to some kind of decentralised model, it shows they are prioritising other factors above the privacy and security of their customers.
I was going to post a tweet about this, but I need a big canvas to illustrate the entirety of the mess. I’m struggling to find an up-to-date list of which countries people can visit the UK from as a tourist without a visa on GOV.UK.
User story #1: As a person living in the United Kingdom who occasionally helps to organise travel for friends and family members, I want to be able to see who is allowed to enter the UK without a visa.
I went to Google and I typed in “countries who can visit uk visa free”. Mostly it brought back news articles about how as a UK citizen, I can visit 175+ countries with a British passport. Which is awesome. Being a UK citizen has some great advantages. I’d recommend it, along with Amazon Prime and an Amex Gold Card. Oh, wait, citizenship, it’s not just a consumer product. Fealty to sovereign powers and all that jazz.
The only GOV.UK result I could find on Google was this: Standard Visitor Visa. Now I’m pretty sure that this isn’t what I want, but it is close. So I start clicking through the pagination (sigh, my scroll bar works…) looking for a list of countries that are visa-exempt. You know, like, the US has the Visa Waiver Program, and on the US State Department website, it lists all the countries that can visit the US on the VWP. Can I find such a list? No.
Then I clicked the link on there to the Visas and immigration section of GOV.UK because the list must be there, surely.
Nope. Nada. Sigh.
Then I go back to the visitor visa page and hidden away on the second page, there’s a link titled “Check if you need a visa to enter the UK.”
I click that and it takes me to a page called Check if you need a UK visa.
Well, I mean, I don’t need a UK visa. I’m not checking for myself. I’m just curious now which countries need visas and which don’t. Government websites are there to inform all sorts of decisions, not just the person directly using that service.
Anyway, this “Check if you need a UK visa” thing doesn’t have anything as simple as a list of countries which visa exemptions. No. Instead, you have to click a big green button that says “Start now”, then it asks me what type of passport or travel document I have, and I’m asked to select from a big list. Then I’m asked to choose the purpose of my hypothetical visit. Tourism, say.
Then it shows me for the one country I’ve asked about.
That kind of solves the problem, albeit it requires about three more clicks than just having a list. Over-engineering.
User story #2: As a UK-based organiser of an international youth sporting tournament, I need to be able to check the visa requirements of 500 people who will be visiting the UK from around the world on scholarships.
Oh god, if you resemble the second user story, you are so screwed if you use the existing GOV.UK system. Instead of a simple list, you have to sort the list of students by country, then check each country by hand. Be sure to send the Cabinet Office the bill for the RSI you get from clicking through that form a couple hundred times.
Fortunately Wikipedia exists and has the list in readable HTML form rather than an interactive clicky thing that’ll make you want to stab someone. You better hope that someone hasn’t vandalised Wikipedia. Of course, if the government published a simple list of countries on a website with a stable URL, then Wikipedia could use that as a source and the editorial community on Wikipedia could use this to check that their copy is accurate.
I bet you someone spent a lot of time and effort making this interactive wizard thing. But it’s actually significantly less useful than a simple list on a webpage (like the one the US State Department or Wikipedia publish) for pretty much any use case that involves more than one person, which is pretty much everybody in the travel industry or anyone who has to organise travel for other people (so, schools, universities, businesses in almost all sectors, the government, charities, etc.).
This is an impressively strange case of over-engineering. I really hope someone fixes it.
Theresa May tried to alter drugs report because she didn’t like it. Never forget: the personal views of politicians is how we set drug policy, not scientific evaluation of harm.
Video of a 1974 debate on same-sex marriage. This is some archive gold.
There was an old lady who swallowed a fly. No, no, hold it, she didn’t swallow a spider or a bird or a dog. Firstly, that’s stupid and irresponsible and a form of animal cruelty. Plus, we’re in the twenty-first century. We’ve got technology and cyber and stuff.
She got a programmable nanobot off some darknet knockoff of Alibaba that sells experimental biohacking gear and put it in a capsule. She swallowed the capsule. Now, of course, she needed something to control the nanobot. So she wrote a server script. The nanobot would talk to the server which would do it all. Who needs spiders and birds to catch flies when you have REST?
She wrote the script in Python. Because Python is lovely. She tried Django and Flask and Pyramid too. This script would stop the flies. And of course, she needed a database. Only PostgreSQL. I mean, there ain’t no MongoDB controlling my programmable nanobots, thank you very much. And a message queue and a few other things.
But then where to run the server? She couldn’t host it at home because BT provided her Internet connection (and that’s less reliable than a pair of baked-bean cans and a piece of string), so she decided to host it in the Cloud. But, of course, you can’t just set up a server individually for this. What if it needed to scale? So she decided to do some DevOps®.
She wrote a script to spin up an AWS EC2 server. Then she wrote an Ansible playbook to deploy it and a
monitrc to ensure the servers were up. Then she set up Capistrano to deploy the script to the server. Then she set up Sentry to catch any exceptions. Better tie that into PagerDuty so she could programatically modify the notifications for when monit and Sentry had something to tell her.
Then she discovered Docker. Then she ended up on Hacker News reading about Kubernetes and decided that the whole thing really needed a microservices architecture.
And the fly is still inside her. Because the server never got deployed and the scripts never got written because she went down the pub instead.
Perhaps she’ll die. Or she’ll just crank it out in PHP.
For the last year or so, I’ve been using a variety of exercise trackers: originally, I used the Fitbit and now I use an Apple Watch. They do seem to help in increasing the amount of activity one does: step or activity goals, nagging reminders, achievements, gamification and all that guff is a little nudge to get up off the couch and go move one’s posterior.
I was chatting to a friend who is not only using a Fitbit with their Android watch, they are also logging what they ate in an app. There’s plenty of said apps to choose from. MyFitnessPal is the one most people use. I’ve looked at a few and there are two pretty much universal facts about them.
There’s also the secondary factors that the databases often aren’t properly localised. Like so many things, if you happen to not be an American, well, sucks to be you. Food brands operating in your country usually aren’t in the database. Then you’ve got to add it manually, and you’ve then got to spend 10 minutes transcribing how many carbs and how much sugar, potassium, iron and vitamins there are in whatever you’ve just eaten. Given all these hurdles, a lot of people will try food logging and then give up.
These food logging apps are crying out for voice-based logging. Not in the app themselves. At the level of Siri or “OK Google” or Cortana or whatever. Compare the processes.
The best UI for food logging is no UI. Just as there’s no real UI for activity tracking, because our devices just do it for us, food logging needs to be as simple as just saying “I just had a turkey sandwich” and that’s it.
You might say: “okay, but a turkey sandwich? It could have very lean turkey meat and no sauces or it could have a whole lot more processed shit”. Alright, then say to the user: “I’ve logged that. If you know, would you mind telling me what the brand of sandwich was?” And then they can say something like “the Tesco low-calorie range” or they can ignore the follow-up question.
If they ignore you, then you just put in an estimate, an average based on other products of the same type. Yes, it won’t be accurate. But true accuracy in these things is impossible unless one sends a sample of everything one cooks at home off to nutrition lab for assessment. “This slice of pie is for grandma. This slice is for you. And this slice is for the guys at the lab.”
As a point of comparison, consider a similar category of software that people use: time tracking apps. I use an app for the Mac called Timer, which implements the Pomodoro Technique. Unlike most food logging apps, it is to hand. It is in the menu bar. And the interaction model is ludicrously simple.
I click on the timer, I click “Start Timer”, then I type in a brief description of what I’m doing and for how long (default: 25 minutes). Once the timer is done, it shows me a pop-up notification and it adds what I’ve just done to a calendar in iCal. When I need to then write a timesheet, I have this nice guide to what I’ve been doing every day, so I can see when I worked and what on. If the interaction model were any more complicated than this, I probably wouldn’t bother.
Siri and similar voice-command-based systems is the only way I can see food/calorie logging becoming something that people will do naturally and daily. Otherwise, for a lot of people, it will be too much hassle, even though there are real benefits to measuring that kind of data.
Every breath you take is measured.
Every move you make is stored on Fitbit.
Every bond you break gets your eBay seller rating downgraded.
Every step you take is in HealthKit.
I’ll be watching you, thanks to FireSheep.
Every word you say, you tell Amazon’s Alexa.
Every game you play is tracked on Steam.
Every night you stay; I’ve hacked your Airbnb.
I’ll be watching you, because I’ve put spyware on your laptop.
Every smile you fake you post on Instagram.
Every claim you stake you store on a blockchain.
Since you’ve gone I’ve been lost without a trace, thanks to turning Location Services off.
I dream at night, I can only see your face, because you hacked my smart TV.
I look around but it’s you I can’t replace, but I’ll keep trying to talk dirty to Siri.
I feel so cold and I long for your embrace, but I’ll make do with a Grindr hookup.
I keep crying, “Baby, baby, please”, mostly on my Tumblr.
The horrors of dictators and military coups, the dirty wars and disappearances, that took place—with the backing of Western powers like the US—in southern and central America are tragically understudied in the rest of the world.
The requirement that every teenager study a foreign language to GCSE level was dropped in 2004. Linguistically, we have already exited Europe and disappeared into Little England. The decline in foreign language skills in Britain is utterly shameful.
There are services like Duolingo showing that people have a passion for learning more languages as adults. Cities are filled with people from hundreds of different countries and we have people born here unable to speak any language but English. We shall look back on this era of monolingual education as a piece of cultural and intellectual vandalism by the government.
Australia are experimenting with builiding GOV.AU.
Any similarity with GOV.UK is purely coincidental.
There’s only so much stupidity I can cope with and this may have just blown my stupidity budget for the day.
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 maps.me 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.
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.
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.