Complex systems are best built iteratively. You start small, plan, test, make things work well, and then continuously improve, clean, and polish over time, with a focus on maintainability, otherwise known as "this thing is easy to change"
Bigger systems are made out of smaller systems that are, themselves, built this way.
The clean-and-polish bits are critical. The issue with most software is that management at most organizations only focuses on "move fast and break things" and fails to reward -- or actively penalizes -- maintainability.
"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system."
Sometimes I think that this arises out of factors usually considered external to the system. As in, a complex system is so embedded in its environment that it can't be said to start or stop at all, which implies that starting a complex system is an oxymoron of sorts, and that is the reason that creating one from scratch can't normally be done.
In turn, this implies that a working (or, to my way of thinking, running) complex system can be created from scratch, but only if you deliberately create the simpler system it bootstraps from. This makes "creating a complex system" look more like biological reproduction.
With that in mind you start to see echoes of this constraint all over the technology ecosystem, like new programming languages piggybacking off of another toolchain until they can self-host.
Just a random example, from this very forum, from Kenton Varda, who at one time maintained Protobuf at Google.
"Nah, you're assuming too much. Protobuf was thrown together in a fairly ad hoc way by a couple (brilliant!) engineers (Jeff and Sanjay) to help make the Google search index protocol easier to maintain. The specific design decisions in Protobuf were not carefully tested or weighed against other possibilities. They just did something that worked well enough, and it worked well enough that it was rapidly adopted by the rest of the company. It was then too late to change anything." [0]
> They just did something that worked well enough, and it worked well enough that it was rapidly adopted by the rest of the company. It was then too late to change anything.
Similar story with the decision to utilise tab characters in makefiles:
"Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history."
That’s not how we build cities; modern cities have urban planning departments, traffic engineers, zoning etc.
Of course, completely rational city planning is a failure and the only ones people like were built before urban planners and zoning were invented. So far this hasn’t stopped them.
> That’s not how we build cities; modern cities have urban planning departments, traffic engineers, zoning etc.
Yeah... Modern, already existing, cities. That's not how cities are "built", in the sense of a city coming to exist where a city hadn't existed before.
Sure it is. When the plans are never completed, change faster than the cities do, and there are more exceptions granted to the plan than compliance, it is hard to say cities are "planned".
By contrast, cities are reasonably good at setting, adopting, enforcing, and evolving standards of various sorts (curbcuts, signage, building codes). The story of the past few decades has been efforts to bridge the gap to slightly larger patterns at the level of streets and neighborhoods rather than leaving that largely to a minmaxing process that litters our cities with endless small and medium tragedies of the commons (eg. giant parking lots surrounding isolated fortress-like stores, office blocks surrounded by blank-walled alleys, or suburban cul-de-sacs forcing long circuitous routes that require a car to get anywhere).
> That’s not how we build cities; modern cities have urban planning departments, traffic engineers, zoning etc.
I don’t know. My father spent his career as an Urban Planner in a Planning Department (in Ontario, Canada), and he never had the power to remake cities that you’re alluding to.
Mostly his job was to do studies of proposed zoning changes of land use and the impact, and make a recommendation. The recommendations were presented to the Planning Board at public meetings.
The board meetings were, of course, part of the larger democratic process, and were just as subject to popular whims as any other parts of government. Landowners and developers had a huge amount of influence, and worked hard to get their projects approved.
I think the “Urban Planners did this” is mostly just a deflection (in Canada and the U.S. at least.) I point to the “smart neighborhood” that Google and the Province of Ontario (on behalf of developers) were pushing hard for in Toronto a few years ago [1] as a more visible example.
patio11 has even written about this process, more from the developers side. [2]
> Mostly his job was to do studies of proposed zoning changes of land use and the impact, and make a recommendation. The recommendations were presented to the Planning Board at public meetings.
But that's the bad part - there shouldn't be zoning or planning boards. People who want to have opinions here should keep them to themselves instead of being able to enforce them; they're the reason for the US housing crisis and nearly everything else. Of course, there's a few more reasons like property tax systems (CA's encourages keeping old single family homes) and paranoid fire codes (which cause giant streets in the US so our giant fire engines will go down them).
If you're reading patio11 you'll probably know that Japan does everything right here by having national zoning where cities aren't allowed to stop you from doing anything.
As a result Tokyo is still livable, cheap compared to US cities, and a house in Japan is affordable because it depreciates like a car rather than being your main retirement asset through land hoarding.
I studied English alongside CS and was really into the creative nonfiction genre in my university days. I remember really enjoying "Close to the Machine" by Ullman, might be worth checking out.
Demistify what? Modern code is a construct of patches over patches over hard-coded parameters that nobody understands how it works as a whole and nobody dares to put it through formal verification.
Airplanes crash, money is lost, data is stolen but nobody seems to care.
Airplane code certainly is put through “formal verification”, but also “putting it through formal verification” is not a magic spell that removes bugs from a program. It only proves it does what is in the spec.
It seems like the word “formal” impresses people too much.
Usually, it only proves that a simplified version of the code satisfies to some extent a translation of the spec to some formal language. And "prove" only means that some rather buggy tool printed "Valid".
Every point in this chain can and often does introduces bugs.
However, this does find real bugs in the code, and formalizing code and specs require people to think deeply and formally on aspects of the problem.
It just doesn't prove the code to be correct, or even that it satisfies the actual spec.
I really loved "Life in Code". The book's combination of intimate autobiography and job description, and a somewhat outsider's view on programming, which she sort of stumbled into, just felt right.
I also liked the interview posted by OP, it summarizes her opinions in a slightly different format. I somehow managed to miss it when I searched for interviews with her after reading the book. Thanks OP!
Things from the book that reverberated with me:
- Her relationship with her father, how she wrote some code to help him with his business. This mirrors a very similar experience I've had, writing simple applications for my dad during junior high and high school to help him with various things for his job. That was a sort of bonding between us.
- Her work in IBM, and how soul-crushingly it was, also reminding me of my first few months in a "real" job.
- Her work in a sort of artists' collective as a young woman, and how they slept in a remote farm and helped the farmer there. Which is wholly different from my own experience and therefore like a peek into a distant world, and yet very real.
- Her fluid sexuality - she had a girlfriend but is now married to a man, which the book mentions in passing but doesn't make a great deal of, which I found refreshing.
Edited to add:
- Her descriptions of how San Francisco has changed over the years by the technology boom and bust cycles.
- How she almost became one of the first employees in Google because Larry Page was interested in her opinions.
And that quote from this book already referenced in a sibling comment, “We build our computer systems like we build our cities - over time, without a plan, on top of ruins.”...
That quote also affected me deeply since it has a deep connection to my day to day work. For the last decade I've been part of a changing team, maintaining a big sort of internal legacy system, that is sort of mission critical, which started as a messy semi-personal project years ago, and then grew and grew to the point where no one knows it all.
I've printed out this quote and hang it above my desk. I don't explain it to people, but the ones who bother to read it nod their head in understanding.
jbq wrote fantastic essay on a similar topic, Dizzying but Invisible Depth [1]. There was also an HN discussion at the time [2].
[1]: The original was posted on Google+ and is, of course, long-since gone. Wayback machine also doesn't seem to have captured it, but I found https://josh.works/dizzying-but-invisible-depth, which matches what I remember.
Given that code is a medium created to be written and understood by humans, I don't think the idea is particularly unreasonable or outlandish.
A better analogy is probably something like "demystifying music". Not something that everyone is into by any measure, but certainly there are more people around who "get" music than there are musicians who make music, and there are accessible and approachable entry points for people to learn a little or a lot without obscurantism. There are of course people to whom music is just noise, but they are a tiny minority. There may be an equivalent tiny minority of normally intelligent adults that are incapable of computational thinking, but I haven't seen any evidence for it (dyscalculia isn't it any more than dyslexia is).
So in a way she is coming from the perspective of starting off with some basic assembler like functions that build out to more complex function in higher languages. Obviously there is the Ring 0 security model built into OS's to be aware of, but it all starts from machine code, and even then, do you class the minute voltage difference which can flip a bit as code or hardware?
On the point of music, just like some chemicals react to light (serotonin blue light) or darkness (melatonin), and some react to heat more than others besides the obvious reaction to other chemicals in the body, I do wonder if some chemicals react to sound to stimulate the release of (nora)adrenaline and dopamine aka the catecholamines. Certainly infrasound increases anxiety and we get this around earthquakes which can affect the vision I think, based on my own experience of seeing walls going flexible in a (minor) earthquake whilst the logic side of the brain kept reminding me the wall is still solid as they have not broken apart and not liquified in any way.
Regarding chemicals' sensitivity to light, heat, sound, it is worth contemplating that there must be a chemical pathway that translates mechanical pressure however delicate to nerve impulses or we wouldn't have a sense of touch. Our sense of hearing is likewise dependent on precise indirect mechanical sensation of vibration in a range of frequencies.
The Rube Goldberg chain reaction that turns minute variations in pressure upon skin into an interpretable sensation of texture is mind-blowingly difficult to imagine.
I read on here somewhere that someone suggested sodium caused tinnitus and 4-6 weeks on a low or no sodium diet got rid of or seriously reduced their tinnitus, so when is it not just some pressure in a contained membrane? I'll check out the Rube Goldberg reaction it sounds intriguing.
Sorry, Rube Goldberg was a cartoonist who drew ridiculously over elaborate machines. Some biochemical pathways strike me the same way (though this is mostly due to contingency and opportunistic reuse, and definitely not gratuitous complication per-se).
Edited to add: and I AM aware that much of the "over complication" affords opportunities for positive and negative feedback loops that subject a pathway to external control of various sorts and variable expression in different conditions, cell types, and tissues.
Perhaps I have been reading too much about the Wirth-descended programming languages, from Pascal to Clascal/Object Pascal, Modula-2, the Lilith workstation and Oberon the language (for which there are many implementations that cover almost all OSes and architectures); but I wonder if Wirth languages were more prevalent, with their emphasis in regularity and ease of reading... would the tone of this discussion be different?
"Close to the Machine" is a great book. I often think of the passage in it where the author is offered a large sum of money to take the job of maintaining a legacy system, but turns it down because it would be such a soul-crushing task which she could see in the person who was offering the job.
> In 1984, at the dawn of the personal-computer era, novice software tester Roberta Walton stumbles across a bug. She brings it to its inadvertent creator, longtime programmer Ethan Levin, and the two embark on a hunt for the elusive bug
This was such a good and interesting book. There aren’t many solid novels I’ve found where the protagonist is a programmer and the novel is about software itself.
Ullman spends a lot of time talking about Conway’s Game of Life and I’ve regretted not spending more time playing with it IRL.
The larger an organization grows, the more complex and arcane and bureaucratic it gets. More and more weird emergent behavior pops up that isn't directly related to the original charter of the organization. Companies, governments, academic institutions... all across the board.
Is it any surprise the code we right at the direction of these organizations does the same thing?
In other words, I don't think it's our relationship with code turning us into automatons. I think its our relationship with each other that pushes both our organizations and our code into those paths.
I wish Peter Welch would take on the challenge of demystifying code, he's already written a fun diatribe on (against?) programming that even non-programmers can enjoy. See here: http://www.stilldrinking.org/programming-sucks
"There must be a new army of programmers who can question the intentions in the code. When our social and political adversaries are armed with algorithms, we, too, must take up the study of algorithms."
Good luck with that 'new army' thing.
You can hear the calls growing daily, in the EU, from Elon Musk, and from the political classes: "make the algorithms public."
I agree it sounds hard, but why give up? Code is written by people, for people—the current unaccountability that these algorithms possess isn't part of their nature. It's a choice that people have made, and in the future, people can choose—or be forced to choose—differently.
“We build our computer systems like we build our cities - over time, without a plan, on top of ruins.” — Ellen Ullman
…and was prompted to search the web for the author. Wasn't at all disappointed when I read this interview, and decided to share.