I think the people who liked the above tweet think I’m being funny by choosing a cake instead of a pie; that I’m suggesting that cake is superior to pie. But I’m actually being serious – Cheesecake is a pie not a cake.
When you make pumpkin pie, you make the crust, then the filling; you pour the filling into the crust and then bake it. When you make cheesecake you make the crust, and then the filling, then you pour the filling into the crust and bake it. With cake, you typically mix everything in a big bowl, pour it into a pan and bake it as is – no crust, no filling. You see, just because cheesecake is called cake doesn’t mean it actually is cake.
Words matter. They affect the way we think about things. When something is mislabeled, or we use an inappropriate metaphor, it can lead to lots of misconceptions down the road as people try to reason about it with the mental model in their head that the name invokes.
I think this has happened to Software Engineering. After 20 years in the industry, and having earned an engineering degree, I think I can now safely say that almost none of what we do is engineering. It’s writing, similar to any kind of writing that uses a team, like television writing. This mislabeling has caused a great deal of confusion for many, many years about why our industry doesn’t seem to work like any of the other engineering disciplines. But perhaps more importantly, the engineering label has limited our thinking about both the field itself and important things related to the field such as compensation models.
A personal hero, John Carmack, might agree with this. In 2012 during one of his infamous QuakeCon keynotes John Carmack said:
“… It’s nice to think of myself as a scientist/engineer sort dealing in these things that are abstract or provable or objective… and in reality, in computer science just about the only thing that’s really science is when you’re talking about algorithms and optimization is an engineering task …
… But 90% of the programmers are doing programming work to make things happen, and when I start really looking at whats going on in all of these, there really is no science and engineering and objectivity to most of these tasks …
… we like to think [that] we can be smart engineers about this, that there are objective ways to make good software. But as I’ve been looking at this more and more, it’s been striking to me how much that really isn’t the case. That aside from these things that we can measure, measure and reproduce — which is the essence of science, to be able to measure something, reproduce it, make an estimation and test that — and we get that on optimization and algorithms. But everything else we do really has nothing to do with that, and it’s about social interactions between programmers or even between yourself over time …”
https://youtu.be/wt-iVFxgFWk?t=1821
I think that if I’m honest with myself, I agree with everything he’s saying, and actually this talk is the one that made me really start thinking about this.
What would it mean to be a Software Writer rather than a Software Engineer?
Writing and Translation
I think looking at software as an act of both writing and translation would explain a few things. Like why as an industry we’re notoriously off when trying to estimate how long things take. Just like fiction authors are typically over deadline. I mean how long would it take you to write a chapter of a book? How about a good chapter?
That to me sure feels the same as: How long will it take to implement feature X? What if we want it to be a ‘good’ feature?
What does it mean to write “good” code? What does it mean to write good prose? I’ve often felt that much of what people say are good coding practices are pretty arbitrary or a matter of style or personal preference. I felt the same way in English class when we talked about the rules for good writing.
“All writing takes the same amount of time. If you’ve thought a lot about what you want to say, it flows easily.”
– Jessica Hibbard, Head of Content and Community, Luminary Labs
The quote above reminds me of an argument I often hear from a certain class of programmer. They want people to stop and think more before they write code. Typically I hear this from the functional programming types, but I’ve heard it in other contexts.
Seeing software as language and writing would probably make it more appealing to women. For decades the number of women studying computer science was growing faster than the number of men. But in 1984, something changed. That thing was to make computer science appear to be more mathematically based.
Compensation
The parallels between writing and programming don’t stop there. When you write a book, all of the effort is upfront and then once it’s complete you can sell an unlimited number of copies. Does that sound familiar?
That model also applies to TV shows and movies. One thing all of those industries has in common? The writers get royalties.
I think software writers should get royalties too. I have code in Visual Studio from 2010 that is still shipping today long after I’ve left Microsoft. I’ve written software for traders to manage the risks on large portfolios, more volume than any human could keep track of themselves and yet the traders received the huge bonuses and I got nothing. I wrote a good chunk of the order processing system for Jet.com, a system which processes millions of dollars in orders every day and I didn’t even get a choice about keeping my stock or not when it got sold to Walmart. All of that code is still running, producing value for those companies and BONUS they don’t have to pay me anymore since I don’t work there.
If software was seen as writing then, for those people who want to (Google employees?), they could join the writer’s guild rather than trying to unionize workplace by workplace.
What do you think? In what other ways is writing software more like writing other media? Let me know in the comments.
Update:
After a discussion over on reddit about this piece I’ve come up with even more ways in which software is like writing.
Update2:
Since people keep reading, I’ll keep writing or clarifying things as they come to me. Appreciate the comments!
More Similarities to writing
Software projects can be successful without good engineering, just like books can be successful without good writing.
Following all the rules and best practices in software do not guarantee success of a software project any more than following all the rules of grammar will make your book successful. In fact I’ve never seen any published paper that shows any correlation between the two. Would love to read it if someone has it.
New ideas implemented in software (Google page rank, Uber, etc.) influence the real world as much as books like The Communist Manifesto, or The Prince did. I’d be willing to wager Excel has fundamentally changed as many economies as The Communist Manifesto did.
Video game developers seek publishers that do exactly the same thing as publishers in the book industry do.
“Good” code from 1998 (when I started) looks very different from “Good” code in 2019. “Good” writing from 1886 looks very different from “good” writing in 2019.
Some authors are better writers than others at coming up with eloquent ways to say things, just like some programmers are just better at coming up with elegant solutions.
Code reviews sure look a lot like sending your writing to an editor.
Consequences if true
If the analogy to writing is closer than the analogy to engineering, then to become a better software writer/author one should look to the tools that writers use to become better writers rather than to other engineering disciplines.
Software being like writing would also explain (to me) why the many attempts I’ve seen to bring more rigorous, formal processes, like those in other engineering disciplines, has failed so consistently over the last 20 years. Software just doesn’t need to be an engineering discipline in order to be successful. Usually the explanation for this is that this is some new kind of engineering the world hasn’t seen before. Between the competing theories that SE is somehow a new engineering discipline that conveniently doesn’t seem to work like any other engineering discipline and the theory that it is not engineering at all. Occam’s Razor would dictate the simpler “not actually engineering” is the better theory until proven otherwise.
Update 6/14/2020
Now confirmed by science with brain scans and published in the ACM:
https://medicalxpress.com/news/2020-06-language-brain-scans-reveal-coding.html
Interesting analogy.
I’d liken business software to a non-fiction book. Not really subjective, except maybe for the writing style / looks.
Games and other software might be more like fiction – pretty subjective, some people might really like it and others not.
I agree, I think games are definitely the closest to the analogy. I’d heard somewhere that the writers of Call of Duty get royalties, but no programmer does
And like books the most popular software must not necessarily be the one that is best written 😉
Exactly this, I think about Craigslist.org as the canonical example of this. I don’t know how well the code is engineered, but I’ve seen more serious engineering teams try and take them on only to be cast aside by the powers of network effects.
Sono d’accordo comunque la programmazione secondo me non deve essere concepita solo come scrittura elegante o fare soldi, io la faccio solo perché è interessante a risolvere problemi della nostra vita! Microsoft ad esempio aveva un sito code. msdn. Microsoft. Com e lo ha chiuso, con mia grande rabbia, molti dei miei commenti o spiegazioni sono spariti, ora di moda è il cloud, come azure, che spersonalizza la programmazione e ci rende tutti i programmatori come dei robot, per me è importante quello che facciamo in maniera onestà anche senza ricavare alcun guadagno!
If you’re writing a computer game or designing a mobile app then yes, you are more like a writer than an engineer. If there’s a bug in your software then only Pac Man will die because of it.
If writing software to monitor hospital equipment, manage traffic lights, monitor ships around ports or any number of other safety-critical systems then lives are at stake; we absolutely must be held to the same rigour as any other engineer.
The argument isn’t that there are NO Software Engineers, it’s that (according to Carmack and my own experience) only 10% of people are doing that hard core algorithm design and optimization. If only 10% of a square was colored blue and 90% was green, wouldn’t you scratch your head at why people were calling it “the blue square”?
Interesting article. This would nicely explain why when I was a child I wanted to become a novel writer and now I’m a software engineer. However, I know a few construction engineers and you would be surprised how wrong they get their estimates and how far they usually go over the deadline. Maybe it’s the case that all engineers (not only software engineers) are not that scientific and objective at all, seeing as they generally have to apply science to requirements from humans, and humans tend to be confused.
But, most importantly, sorry but I don’t think cheesecake is a kind of pie: to call something a pie the base needs to be pie pastry!!
Thanks for writing this article 🙂
Haha, I was nervous about that because I’d never actually made a cheesecake. It’s a graham cracker crust, right?
Yes I’ve seen overages in all the other engineering disciplines, but somehow I have it in my head that ours are worse. I could be wrong about that as I now can’t recall why I think that.
Agree! My English degree has been more relevant to my coding than any math or science except Algebra. (And Logic was a Philosophy course.)
Except for creating crypto routines, the generally more adept programmers I’ve worked with have been those with better language and writing skills. Interestingly, they generally prefer to begin by writing a description of the task, then fill in with code. (But until they learn to question what they’ve written, they are bad at debugging their own routines…)
But I’m not sure its specifically about writing, as much as visualizing. I’ve worked with giod programmers who were poor writers but could “see” the flow of decisions as if a tangible thing.
Accurately understanding and describing the structure, sequence, and transformations seems the common skillset to me. Combines writing with puzzle-solving.
Well said
Great article, that articulates some ideas that have been bubbling in my subconscious for some time.
I would add that the software development process is becoming futher removed from that used by other engineering disciplines. We have agile development, which emphasizes rapid prototyping where engineering oversight is relegated to second place.
We have the “move fast and break things” paradigm from Facebook, which places the onus on customers to find the problems.
Also, software is the only engineering discipline, where a product can be sold with a warranty along the lines of “THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND…”
There are exception, such as in the transportation, telecomms and medical fields, but in these cases, software is an enabling technology that is embedded in products that are manufactured by engineering companies.
Yep, most of us are definitely not dealing with the Code of Hammurabi
Great post.
At one time writers did not get royalties: publishers paid a lump sum and took all the rights. Any problems (Libel, Blasphemy) were the author’s problem.
I might well go back into programming if I were paid a royalty EVEN AFTER LEAVING THE COMPANY. Perhaps so much per sale and so much per server call.
The article makes a lot of sense, and developers are as precious and pretentious as luvvie writers but in a different way.
Writers have to keep updating their toolset too. OK Word is unlikely to go out of fashion but we need to watch market trends and switch from horror to fantasy to… and we need to look at word count, layout, submission guidelines.
But I know of few truly freelance developers. I would guess 99% are corporate. I would guess that less than 1% of writers are corporate and maybe 5% of translators.
You nailed it, I think per-sale or per-server call makes the most sense. I also think a model like this would align incentives. If the programmer lost some income when the service was down, maybe that would incentivize better construction. I think it could clear up “on call hell” over night.
Or the coder could choose “it’s actually not that big a deal if this service goes down for a few hours until I’m awake and the business people need to stop acting crazy”
Skin in the game
When you get to the end of the writing project, it’s time to start revising, and that can take as much or more time as writing the first draft. For fiction, you generally have alpha and beta readers, and you ask them what things don’t make sense, and where the story drags.
It’s a lot like testing software.
Only getting the grammar and spelling right doesn’t make a good story, like ‘no syntax errors’ doesn’t mean the program will work.
I think that if you would get paid (even after you left the company), you would also be held responsible for damages caused by your software. (even after you left the company)
I don’t think that most programmers/developer/software architects are willing to accept this.
It’s the same for someone who assembles cars in factory. they are not being payed every time someone takes the car to go to work or go shopping.
You have a few interesting, though not entirely new, points in here but you haven’t let them out…
You lump science and engineering together, but this is misleading. Algorithms and data structures are scientific tools – they are either correct or not. They do a job, whatever that job may be. Engineering is different though – it is using these scientific tools to solve human problems. You need humans to use these tools (via team processes) to engineer solutions to these human problems. One of your interesting points, I think, is that not all of these solutions (maybe 90%?) require high quality. They can be just good enough. It’s definitely a fair and good point that when a team is engineering a project they should think about what the necessary level of quality is, and use tools and processes to match that level.
But also, by solving these human problems, the solutions these teams produce create value and so earn money. How this money should be distributed is also a good point trying to get out of your article. I guess this gets back to the idea of software as a service rather than a product, and as a result that the payment for the service should go to the producers, rather than the owners of the service. I’m not sure that’s the world we live in at the moment, though I agree it would be great if it was. 😉 Would unions or guilds be your way of moving towards that world?
I don’t think any of my English professors would accuse me of being a good writer. I’m more of an orator and as such am not really up to the task of writing out this argument. You seem to have picked up on the points correctly though and helped me to state them. Thank you.
Yes, I think that unions and guilds are a way forward to a better distribution of the proceeds than the current salary system. When I say the word union here in the states, though, I am met with hisses and snarls from programmers as though I’ve just said something rather uncouth about their mothers.
Engineering tries to resolve real life problems where fully applied science is impossible. The world problems are more complex than the assumptions
made to develop scientific models. Filling the missing gaps between scientific methods and uncertainty caused by complex scenarios and entities is engineers job.
Also there is the human factor in software projects that require [engineering] methodologies for them to be close to success.
Well, the difference is that writers writing a book choose the topic and imagine and work out the entire story all by themselves.
In other words, they define the entire book.
They might get and advance amount of money to start working on it, but any additional income is dependent on the level of success of the result of their labour, the book.
While for software products, in most cases, developers are part of a team, and they are not the ones that came up with the idea of the product, nor most of the times with the way it will be developed. They just provide ‘a chapter’ in someone else’s book and idea.
For some types of software, like the aforementioned games and perhaps some applications that were completely and solely developed by a single developer or small group of devs, this might be analogous to writing a book.
In such that their reward for the efforts taken are dependent on the success of the product. And their contributions defined the entire product.