It's always bothered me how software teams view internal and external users differently. We'll spend lavishly on designing an amazing experience for customers... But internal users are stuck clicking through 500 VB6 forms to get anything done.
Companies forget that selling more isn't the only way to make money; cutting internal costs can also make you more money. A happy team is a productive team, and a streamlined team is a productive team. More productivity means less people you have to hire and train.
But hey, that comes out of a different budget and our internal people are already being paid peanuts, so work on this feature the sales team claims will help them sell more. Operations people are just there to clean up the crap no one else will, right? (/sarcasm)
I'm sure many of us can relate to this article. There's only a very small handful of real-life software that I've felt embodied our ideals of design, contruction, clarity of organization, performance, reliability..
> Software development has borrowed its working language in part from architects and builders, but this is the worst mistake we ever did. The language itself makes everybody underestimate the difficulty in everything we do.
I wonder what other metaphors we can use, which would be more appropriate/insightful to describe and understand the software development process.
I think architecture is a fine metaphor for actually constructing software, just no one treats software the way we treat architecture.
Imagine putting an architect on a plane, and during the flight briefly explaining some elements of a house to be built: It needs to be 2 stories and have a big kitchen, open concept, 4 bedrooms. Something like that, yes? How long will that take?
I couldn't possibly say! Well, just give me a range. Etc.
So the plane lands and the architect wonders exactly where he is. This is a plot in a forest. Before we can begin we need to clear these trees and get plumbing and electricity hooked up... Hey, you didn't mention any of this in your estimate!
Now we are months behind schedule but the groundwork is finally laid. We are really behind the 8 ball schedule-wise! Just do a quickie job the rest of the way, ok?
But when the architect goes to hire carpenters he discovers they only speak French! Didn't you know you this house is being built in France? I forgot to mention it. You speak that language, right? Well, figure it out. You are the architect after all.
My goodness, you're right.. And the poor architect often doubles as the carpenter, plumber, unqualified electrician..
When the house is halfway built, we ask the architect to add a basement floor with temperature remotely controlled via a spotty WiFi signal. Oh, and a satellite dish on the roof too, after all we're practicing "agile architecture"!
They're NOTHING like each other. Experience says otherwise.
Everyone thinks that until they've done both ship their first SaaS and get an occupancy permit for your first building. I can say that while there are some similarities in managing complex inter dependencies even if you waterfall the code.
You're right, current terminology fails to elucidate what it actually is we do. For one, real architects have regulations to follow and need to keep up with evolving trends.
Maybe a journalism metaphor would be better. That would make it obvious our work is seldom done the first go around and also make it clear we can't do our work without sources - in my experience, that's what often leads to bad/fragile software. Like in journalism, there are obvious differences in quality and style between individuals. Objectivity is the expectation, but you'll find bias anyway. And finally, people might be able to intuit that time spent is hardly ever fully on just writing code.
True, and the same goes for engineers. I suppose the latter is another metaphor for the software development process/person: "..people who invent, design, analyse, build, and test machines, systems, structures and materials".
> need to keep up with evolving trends
This sounds like it could apply to much of software field, esp. web frontend.
> Maybe a journalism metaphor would be better
Good one! Software is definitely an art/science of writing, and about media, publishing too.
I also agree about the need for many "drafts", writing and rewriting. The metaphor might help stakeholders understand the process better, compared to architecture which gets built only once (usually).
I like how you chose journalism, and not just writing or literature. Journalism is associated with marketing/advertising, in which software is definitely involved. There's also the parallel of research and investigation being necessary preparation.
For the fun of it, I thought of flipping the direction of metaphor.
An architect is like a software developer, except their code is physical material and their runtime is space.
A journalist is like a software developer, except their code is human language and their runtime is the public mind..?
Companies forget that selling more isn't the only way to make money; cutting internal costs can also make you more money. A happy team is a productive team, and a streamlined team is a productive team. More productivity means less people you have to hire and train.
But hey, that comes out of a different budget and our internal people are already being paid peanuts, so work on this feature the sales team claims will help them sell more. Operations people are just there to clean up the crap no one else will, right? (/sarcasm)