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.