'Code is Sourdough' (increment.com) 70
Romello Goodman, a software engineer at The New York Times, writing at Increment: Like a sourdough starter passed through the hands of many bakers -- some novices, some experienced -- a codebase reflects how teammates communicate with one another. It's a snapshot of our thinking and our best attempts at codifying norms and assumptions. It's a conversation in which each person contributes and is in conversation with those who came before them. With each new feature or bug report, we understand our code better. We identify areas where new logic doesn't quite fit with existing logic. We're constantly in touch with our own past decisions and those of our coworkers. We're working together, trying to harmonize and match one another's thinking patterns and assumptions. We trust one another to make decisions for the good of the team and the organization. Every piece of new code adds to the culture and cultivates our shared understanding.
If code is sourdough, we have an opportunity to better appreciate the histories and context that have gone into it. In software, we tend to think of legacy code as something that should be thrown away or rewritten, often conflating a codebase's age with its health and viability. But code doesn't age in a vacuum. If sourdough can be passed down from person to person over decades, then so can code. The preservation of decisions and experience is tied to the preservation of our codebase. Even when the code itself is no longer being updated, documentation around the logic or the underlying platform and adjacent technologies can keep a codebase and its culture vibrant. You can then pass that culture on for another team to bake with. It might just taste better than you'd expect.
If code is sourdough, we have an opportunity to better appreciate the histories and context that have gone into it. In software, we tend to think of legacy code as something that should be thrown away or rewritten, often conflating a codebase's age with its health and viability. But code doesn't age in a vacuum. If sourdough can be passed down from person to person over decades, then so can code. The preservation of decisions and experience is tied to the preservation of our codebase. Even when the code itself is no longer being updated, documentation around the logic or the underlying platform and adjacent technologies can keep a codebase and its culture vibrant. You can then pass that culture on for another team to bake with. It might just taste better than you'd expect.
How is this different than anything else? (Score:3)
Does this not apply to basically everything?
Building science? Material science? Education in general?
Literally everything that people do. If you don't take care of the knowledge you can lose big chunks of it .
Re: (Score:2)
The science behind it, but not the actual product. ("Code")
I agree that legacy code isn't neccessarily bad just because it is old. But if it is not properly handled (documented), the usability diminishs alone based on the fact that you don't have anyone near who knows the stuff about the code that isn't documented. And - let's be honest - code, like sourdough, tends get infected with stuff that shouldn't be in there but still grows on it. (feature creep)
Re:How is this different than anything else? (Score:4, Insightful)
Does this not apply to basically everything?
Yes of course, but some software engineer learned to make sourdough bread during the pandemic and, like a lot of people who've led sheltered lives, it caused him to experience a low level epiphany.
It is almost like most human endeavors proceed along very similar courses so at very high levels of consideration they look alike.
Re: (Score:2)
You have just discovered the great underlying principle that governs the universe: everything is connected.
Please go forth and infect the dough of the world with your newfound wisdom.
(I still like Paul Graham's great insight that since he likes coding and painting there must be some deep underlying connection between the two activities.)
Re: (Score:2)
Yes, but now he's doing it on a computer. Totally new, patent please.
Re: (Score:2)
Or doing it "on the Internet". It's totally new...patent please.
The whole concept of software patents on "software sourdough" is what differentiates software from everything else.
Re: (Score:2)
It applies to basically everything except sourdough.
You don't need to know anything about the history of the sourdough to use it. The previous caretaker didn't tweak it to take care of some tricky and non-obvious corner cases. Careful thought and planning isn't added to the sourdough for each generation. There are usually no hidden surprises like finding out the previous owner added asbestos and lead to the mix.
Also, sourdough doesn't go out of fashion or become obsolete. It has basically been the same for
Wholeheartedly disagree (Score:2)
Yes, there is something to be said about "don't fix what isn't broke", or "new and shiny", or "not invented here syndrome".
But this summary comes off more as keeping things around for sentimentality reasons.
If a programming language introduces syntax sugar that makes code easier to read, follow, and create (eg: async/await vs any of the alternatives), then it's worth the effort to start migrating your code over to it, even if the code as it is now, is functioning fine.
And that's just one example. Programmer
Re:Wholeheartedly disagree (Score:4, Insightful)
If a programming language introduces syntax sugar that makes code easier to read, follow, and create (eg: async/await vs any of the alternatives), then it's worth the effort to start migrating your code over to it, even if the code as it is now, is functioning fine.
No, no. Code is sourdough. If you add syntactic sugar to it, it no longer qualifies as code, because code is not white bread. :-D
Git off the bloated fad lawn! (Score:3, Insightful)
Most "business logic" doesn't need fancy constructs. Conditionals and loops are plenty sufficient. What I see is "infrastructure concerns" leaking into biz logic, making the need for fancy crap that's probably unnecessary if factored better.
For e
Re: (Score:2)
It's better to do must the joins on the database via SQL in my opinion. ("Light" LINQ fine.) For one, if you learn SQL you can use it for any app language. LINQ and cousins are language-specific.
Doesn't LINQ do the joins *in* the database and *using* SQL? (And SQL isn't "language specific"? It's SQL, not GDML or Tutorial D. SQL's constructs are specific to SQL.)
Re: (Score:1)
It can, yes. But not always in ways you expect and not always in ways easy to read.
Developers should know SQL regardless. For one, to debug LINQ translations, per above (if LINQ used). Did my "40 reinvents" scenario not make sense? How did you interpret it?
Re: (Score:2)
LINQ is great for prototyping or in-memory set logic. Most horrible for maintaining production code.
Re: (Score:2)
Re: (Score:1)
If I'm not mistaken, the application LINQ code is typically translated into SQL by the application LINQ libraries (with EF?), and then SQL-Server creates the query plan from that SQL. Problems can arise in and from both steps: it's one of the reasons why ORM's can suck bigly if there's no expert around to fix and tune. "Automagic" can mean "Automigraine".
Re: (Score:1)
Then use it where it helps instead of everywhere, cluttering up code.
Re: (Score:2)
Right, just like we do for disk IO.
Don't worry, you'll eventually be a programmer.
Re: (Score:1)
Le Huh? Where's my Neckbeard-to-English Dictionary?
Re: (Score:1)
Addendum:
The wonder of the web: there really is such a thing. [reddit.com]
Corrections [Re:Git off the bloated fad lawn!] (Score:1)
Should be "most joins..."
Reworked: "I wish ORM's focused more on helping with SQL rather than hiding from it. Too much auto-translation from LINQ to SQL makes messes when things go wrong in ORM's that are a royal pain to unroll. Machines generally don't write very human-friendly SQL."
Re: (Score:2)
I find it amusing that view programming as web apps. Sure, that's something, but there's a huge programming world that has nothing to do with anything you mention.
Re: (Score:1)
I'd say small and medium web-based CRUD/business apps to be specific.
You are correct that I should have included a domain scope disclaimer. I forgot one this time. But it is a pretty big niche. I'd estimate about a fourth of all developers are in it based on job ads. Thus, if this niche is fouled up, it affects roughly a fourth of all development.
Re: (Score:2)
For example, in Java Swing, why can't one attach an on-click event to a button without using a lambda? The code should look something like this:
(I'm not sure whether Swing library is the fault or Java's weak OOP model.)
Maybe you learned to program before CS degrees? An event handler is a function. How do you propose to attach a function to an object some other way? Do you not like lambdas or do you not understand functional programming? I feel like you are pontificating upon issues about which you have little insight. Also, never do a join outside of SQL if you care at all about performance. And finally, microservices are not a fad. They are a response to insane project management in corporate environments. If you
Re: (Score:1)
Smalltalk can do it because it makes no distinction between a class and an object.
It's a fad to use them where they don't belong. I can say the same about the NoSql movement. People rushed into it ass-first, using it where it doesn't belong. Maybe "fad" is not quite the right word, but I don't know of a compact alternative. "Abuse fad"?
OOP had a similar pattern: overused and misused when mainstream learned of it until time taught the industry how and where to use it
Somewhat agree with your wholehearted disagreement (Score:2)
Too many people replace, rewrite, or refactor code that they don't understand. They of course believe they understand the code, but often there is nuance they have overlooked. I think that is different than sentimentality.
Eventually, if code isn't reliable or the requirements expand beyond what the original design can handle, you're force to rewrite it. At that point you make a conscious decision to invest the effort into rewriting with the full expectation that surprises will occur and time will be spent d
Re: (Score:2)
I am very biased in my experience because I get involved with the kinds of problems that others can't figure out. I would guess that about 80% o
Re: (Score:1)
Except... when it's not. (Score:2)
I have worked on MANY projects where the total number of contributors of 10 or more years are less then 5 and their is generally only 1 person writing code.
( these are all largish companies, military , banks, etc.) The place where many people work on one code place base are more often 'software companies' but the problem is that often times the 'methodologies' develop for such teams do not translate well to one person working on their own with little or no communication, they don't scale down well.
toxic culture (Score:5, Funny)
MORE shit analogies ?! (Score:2)
Software is like a car. Nope. ... SHIT. Definitely.
Hardware is like a banana. Possibly.
Lazy journalism is like
Sourdough (Score:2)
If sourdough can be passed down from person to person over decades
Wait, what!? I thought it was a recipe for bread, not something you keep around for decades...
Re: (Score:2)
Wait, what!? I thought it was a recipe for bread, not something you keep around for decades...
Sourdough bread is made with yeast. The yeast is a live culture. So you mix the "starter" (some dough leftover from last time) with flour and water. Then, before you bake the loaf, you break off a bit of dough to save for tomorrow.
This can continue for decades. Over the years, wild yeast will sometimes colonize the dough and change the flavor of the bread.
Store-bought dry yeast will not work to make sourdough. Dry yeast will produce a more bland bread without the acidic tang of sourdough.
Re: (Score:3)
Sourdough dough, like active-culture yogurt, contains living microorganisms. If you break off a chunk before you cook it, and add more flour and water, the microorganisms will continue to thrive and generate more sourdough dough. These unique microbiomes produce different flavors, and are often honed - good ones are kept and can be refined over decades. Similarly, if you take milk and add it to active culture yogurt, for the right time and temperature, you get more yogurt. Beermakers do the same thing t
example of the problem (Score:2)
Thinking that "code is sourdough" is a fundamental part of the problem. A "software engineer" would evaluate code on its objective merits, but a "software engineer at The New York Times" apparently not. I would discard this guy's resume.
My code is crap, so is yours. (Score:3)
Here is the thing about Code that works in the real world, vs academic methodologies. Programmers are Humans. We have our good days and our bad days, we still need to work on our bad days, so we will create code, that when you look at it a year or a decade later you may ask yourself why the hell did I code that. If you switched jobs the developer who takes over looking at your code will assume you are a mindless idiot, who can't code. Where they themselves over time will replace their stuff with new Crap that is just as bad.
Normally a rewrite is only required if the software will not run on the new hardware, it is excessively expensive to find developers who will code in that language or platform, or if the business process has greatly changed.
However a legacy program written like crap, with decades of patches and fixes, are often extremely complex and handles a heck of a lot of nuance that will take a long time for the developer with new and fancy to rebuild over again.
Re: (Score:2)
I am not saying that at all.
But you can't put your A game in all the time. Also the company that is paying you to code, is expecting some sort of outcome from you. Spending Weeks or months to make sure a Method or Procedure is perfect probably will not give you too many favors with your boss or the company, who is delaying release for weeks or months because you need to make sure it is perfect.
We all mess up, and at the time it is often good enough. Not necessarily faulty code, it just looks a bit wonky
Re:My code is crap, so is yours. (Score:4, Informative)
I completely agree. Normally when you rewrite a large code base, you (plural, not singular) wind up making the same mistakes again as well as create a bunch of new ones. This is an old but good article on the subject that puts it better than me.
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
To summarize, most programmers will think other programmer's code is crap and want to rewrite it (possibly using a fancy new language/framework/whatever). The better answer (almost always) is to incrementally rewrite the areas where it is needed (perhaps where the old code is truly crap), keeping the old code (and old bug fixes) where possible.
Re: (Score:3)
Re: (Score:2)
Not all programmers. That's why I used the word "most" :). And I also omitted that most programmers think their own code is crap after a few months away from it.
If you followed Knuth closely, you already had a major boost to your code. He cared about performance more than most programmers do today. (His often-quoted line about premature optimization is taken completely out of context - he was actually arguing that performance is quite important and advocating that 10% speed-ups are well worthwhile). So it i
Re: (Score:2)
Objection. Assumes facts not in evidence.
Re: (Score:2)
However a legacy program written like crap, with decades of patches and fixes, are often extremely complex and handles a heck of a lot of nuance that will take a long time for the developer with new and fancy to rebuild over again.
This is where I excel. My lead says I have insane attention to detail. For this reason I spend much of my time re-writting other people's projects when they've spent way too much time and a contract is on the line. I've learned over the years that customer's generally deal really well with getting strait answers, as long as they're real answers and not just guesses.
stick to code (Score:3)
He should stick to writing code, not pretentious essays.
Re:stick to code (Score:4, Funny)
He should stick to writing code, not pretentious essays.
Are you sure? I would bet the author's code is even worse than their analogies.
Reusable code accelerates development (Score:2)
Re: (Score:1)
I've learned the best reuse comes from lots of small abstractions instead of big overarching abstractions. Small abstractions allow one to mix, match, glue, and toss as needed. You can date them instead of marry them, reducing messy divorces.
For example, if you have a bunch of HTML generation functions that generate text as output, then you can glue them together easily and easily make new ones without overhauling anything.
However, if you use an HTML "object" library with arbitrary little rules and interf
Code is not sourdough. Code is a penis. (Score:3)
It's not the size of it, it's how you use it.
But, where many people like to stick it in, thus a lot of it is shitty.
And while it can be hard, it is still soft.
There. Another edible yet pointless metaphor for code.
Sourdough? (Score:2)
Re: (Score:2)
This analogy is half-baked.
Yeah, but it ain't half bad...
Comments, comments, comments! (Score:2)
Code without any comments will become useless either because you won't even understand your own code months or years from now, or because someone else will try to use it and won't be able to understand what you did and why.
If you think it's bad to have, say, a 50%/50% comments/code ratio, you're not thinking correctly. There isn't any good ratio. There should be enough comments, along with self-descriptive variable names, that any programmer should be able to understand what a block of code does.
Re: (Score:2)
This comment could have been cut and pasted from countless previous sources, but ultimately it says nothing. It's not the quantity of comments that matters nor does telling people to comment actually make any difference. Often times programmers are better off ignoring comments and studying the code itself (since comments are so frequently poor).
For comments to be valuable, they need to say more, better and faster, than the code itself does. Too often comments are there to meet quotas (because of views li
Re: (Score:2)
I said there's no perfect code/comments ratio, how did you get "meet quotas" from that? I never even mentioned quotas. And if you work at a place that calculates productivity from lines of codes/comments written in a day, your place sucks.
Re: (Score:2)
Re: (Score:2)
But sometimes method and variable names won't explain why you're doing something, nor can it explain some undocumented bug you're trying to work around, or a feature that's working correctly but very badly explained in the official documentation.
Re: (Score:1)
Re: (Score:2)
Really? (Score:1)
Write a book (Score:1)
Or a book on philosophy! even better
Sourdough what? (Score:1)
It's a Big ball of Mud (Score:2)
While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture. These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture. What are the people who build them doing right? If more high-minded architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them. A number of additional patterns emerge out of the BIG BALL OF MUD. We discuss them in turn. Two principal questions underlie these patterns: Why are so many existing systems architecturally undistinguished, and what can we do to improve them?
Not all code is sourdough... (Score:2)
Crappy documentation (Score:2)
And just like an old recipe, it's poorly documented. So, you might be able to use it but chances are something won't be quite right.
Analogies are like a non sequitur (Score:2)
oops (Score:2)