The Efficiency-Destroying Magic of Tidying Up
florentcrivello.com
florentcrivello.com
Yes, because the computer assumes they're not going to change. The "tensile structure" looks cool now, but throw it in the back of a truck for 3 months and see if it's still algorithmically perfect. Parts get beat up. Tabs get bent a little. Maybe we'll want to grind off one of those tabs that we're not using because it's in the way, or weld on a new one. With the old structure, I can see which parts are relevant to maintaining the integrity of the system.
It looks like an un-optimized binary, which is very close to its source code. That's a feature. I can reason about the parts on their own.
The "topologically optimized" one is like an optimized binary. It's great for saving a few grams as long as you never have to change anything. The downside is that it's impossible to reason about. If one tab gets a little bent, that may be harmless, or it may cause the entire structure to lose its strength. You don't know.
Similarly, the truss on the catwalk over the crazy-looking Wendelstein 7-X is made of nice even rectangles and right triangles, and I guarantee that's not because it's a topologically optimal shape for this truss.
The house I'm living in has been around 30+ years, but in the last 5 years, I've witnessed several trees in the yard die.
I guess what I'm saying, is there is a trade off between easy to understand and fix (orderly) and resiliency(biological), and even then I see a lot of orderly things outlast the chaotic systems.
Not for any practical reason. The tolerances on some parts are tighter, but in general anyone who takes the same interest that the average man took in the '80s can repair the vast majority of a current vehicle, safely, as long as they're not deliberately impeded by a computer.
But I meant exactly that - at least from the stories I hear (I don't own a new enough car), half of the breakage in modern cars seems to require interfacing with the computer to at least clear an error flag. I once helped a guy with a software project, and learned that he's operating a workshop fixing a specific car brand. He showed me the device he uses to interface with the computer, and explained to me how the official software costs such ridiculous amounts of money that he instead hired some Chinese company that would remote-connect to his laptop and do some trickery to keep the software work without the license. Neither official nor the "unofficial" route seems to me to be accessible to a regular car owner.
Yes, you need an odbII tool. they are not expensive by the standards of decent '80s automotive tools (the cost of 'minimum viable analog tools' has dropped precipitously during my lifetime. )
The cheapest ODBII tools are bluetooth, and there is a cornucopia of apps to interface with them in the app store. You can get one that is easier to use that doesn't require a phone for $100 that will work for most problems on most cars.
(Of course, the more expensive ODBII tools are better, I'm given to understand, and allow you to do more, but you can do a lot with the cheap junk; and resetting the codes is generally the most basic functionality; unless you've got a fancy car, even the cheapest one that fits your brand should work for that. )
Having come of age at a time when I was driving and repairing (older) carberuated vehicles, I personally think that fixing a carb is like a thousand times harder than interfacing with the ODB system. Modern injection systems just solve so many problems without trying.
My experience of the modern diagnostic systems is that it's actually way easier. The scan tool saves you so much time and effort vs. the old manuals "go to page 5 if it doesn't X, 32 if it does" A lot of the time, the cheap scan tool gives you a code and description; you punch that into a search engine and you get a goddamn video of someone doing the repair. It's amazing compared to screwing around with an exploded parts diagram. (I mean, from the perspective of someone who isn't really a car guy) - I mean, there's always problems the scantool doesn't catch, but... I mean, I'm talking about all this from a shadetree perspective, there have always been a lot of automotive problems I couldn't fix, just 'cause I'm not an automotive specialist.
I think you're bother over estimating the complexity of modern vehicles and under estimating the simplicity of old ones. Back in the carburetor days people were complaining about vacuum line spaghetti to run the emissions system. People always complain about new stuff.
The reason new stuff is harder for DIYers to work on is because there isn't yet a body of knowledge on how to work on them without all the stuff a shop had.
No! Life is huge proof that efficiency lowers maintenance possibility.
> And yet the final result is incredibly resilient.
It depends on whether you consider a species or an individual. Evolution is great as having species adapting and surviving. But this also means that the individual is hopeless against major incidents.
What? Your body maintains itself daily in harsh environment and onslaught of other life that tries to eat you (mostly microscopic). Once it stops maintaining itself irreversible damage occurs in minutes and you physically fall apart in days.
Your body can keep maintaining itself for many decades. Any natural non living things that can exist that long are rocks. And that's only because they don't move. Show me a non-living solid thing that can move for 70 years at human pace.
A complaint that you can't swap liver the way you swap car battery completely neglects the fact that the liver can maintain itself without moving anywhere, gradually rebuild itself in place for decades despite being regularly poisoned.
I'm not complaining! I'm grateful to evolution for providing me such a wonderful mechanism called body.
But, I suppose you don't work in software development, do you? I say so because you, rightfully, took "maintenance" in its literal meaning, like "maintaining it the way it always was".
Unfortunately, in software development (and maybe other professions) maintenance mean simply that people changed their minds or discovered a new business case and your product must adapt, WITHOUT CHANGING ANY OTHER INTERACTION!!!
In real life, you can say: "he died because he drank poison", and it is a sad but accepted statement.
In software development, the same sentence will be rephrased like: "he died because the crappy developer left an unfixed bug in his Liver plugin".
Again, life is wonderful thing, and evolution clearly has to optimize for maximum efficiency. But in businness there are several times when you must give up some (or even much) efficiency for adaptability.
It looks like the author of the article does not understand the need for this tradeoff.
Rather "He died because dna replication wasn't perfect and caused his liver to develop cancer", but I don't fully agree with article author either.
Chaos is a result of optimising for efficiency but also by doing do very gradually in a piecemeal manner. This kind of process can lead to local optima that are hard to get out of if you don't stop occasionally to rethink things and clean up. The thing is that cleaning up must also be very thoughtfully driven by efficiency. When it's done for aesthetic reasons you end up loosing much of efficiency you worked so hard to discover by making a mess.
I think they meant the "unfixed bug" was that the liver can't process the lethal poison (as it does other toxins).
It would be less of a bug than a vulnerability though; imperfect DNA replication leading to cancer is spiritually closer to a bug, IMO.
The reason your metaphor doesn't work is actually the same reason the original author is wrong as well. Biology is a science that begins with reverse engineering and a lot of guess work, and the human body has no official documentation or handbook.
When developing a new software system it's extremely important to document the business rules implemented, and to use an organized architecture because the guys who built it will very likely not be the people maintaining or updating it.
The frequency of "Phoenix" projects is often the result of code becoming unmaintainable because of how chaotic the design and architecture has become. Even the best documentation and the best engineers cannot make poorly architected and disorganized code maintainable. This is because as a system's code base grows, if the complexity of the architecture also grows it becomes more difficult to make changes without causing defects. This inevitably results in a point where it's faster to completely re-develop the system from scratch than to maintain it in order to add a new feature or even resolve defects.
I've seen this exact scenario play out in every development project I've ever seen that didn't accept the very easy design principal of using and documenting a set of standard design patterns that follow a clear architectural framework.
Losing some efficiency in code is frequently necessary to make the application maintainable beyond the forseable future. Those last 5 words is where everyone seems to get it wrong. A chaotic design is maintainable for the forseable future, but the guys who will maintain the application for its intended life span are beyond the forseable future. They will likely have to work with insufficient design documentation, and a lack of subject matter expertise. Because of these factors, a design which is insufficiently legible is therefore unmaintainable.
(Whether that's ultimately a good approach, I don't know. I haven't thought about this too deeply yet.)
I think you need to provide citation for this because I do not accept this assertion at face value as there are 10x the number of single cellular organisms on your body than you have human cells. Biological evolution is proceeding on your own body faster than you can write software. And it's all happening in parallel and concurrently. In fact, every cell, even neurons, are providing feedback into the system of "biology" that includes the entire planet.
To assume that our own cognition is somehow superior to life itself feels full of hubris.
Man-made structures do have some redundancy, but in general we don't build like that. When we install brackets like the one in the picture, we don't install a few extra ones with the expectation that some will fail. We make them much stronger than necessary ("safety factor") so we're sure none will ever fail.
Mother nature can't afford to put all her eggs in one basket. Humans often can't afford not to.
Here's some pictures https://medium.com/design-matters-4/a-new-approach-to-design...
For instance, nature has not figure out how to evolve wheels even in flat regions.
Also, you're assuming that wheels are the most efficient design for traveling, but bullions of dandelions seem to spread their seeds every year along with dozens of other plants.
Instead, they should have sold it as more organic and advanced to the customer, and explained why it is so, like the article did...
That would gain them even more respect from the customer, whereas now they merely caved in and looked incompetent of getting it right at first (since the customer nows thinks it's his complains that made them finally do it properly).
There are any number of reasons they might not have liked it. Maybe it looked odd because it didn't match the rest of the design. Maybe they were worried about their own customer (of the end product that the part goes into) thinking it didn't look sturdy enough.
If you're designing parts for a rocket then by all means worry about every ounce of weight, but for most stuff if the customer wants it to look less weird you can just make it look less weird. And then charge them for the extra material.
> Here, I propose Scott’s Law: never put order in a system before you understand the structure underneath its chaos.
James C. Scott wouldn't probably never underwrite re-ordering of systems from the top down.
Central to his argument is that viewing complex systems from any singular position requires a process of simplification (legibility) that prevents a complete understanding.
The presumption that one has gotten to a place of "understand[ing] the structure underneath [the] chaos" is in fact the false confidence he attributes to most of these ordering projects.
I think if you want to wrangle a suggestion from Scott's book, it's more about making lots of small pokes at a system and seeing how it reacts, and slowly building on positive reactions from the system.
(Also, messiness and complexity are not intrinsically linked to the efficiency of a system — systems can optimize for lots of variables and it's really context-specific. So as much as you shouldn't take order to be innately good, don't take messy to be innately efficient!)
I can feel a bit for it. I have worked on a complex multi-million line codebase. There was this predictible behavior when a new guy came to join us. Many times they had never worked on such a large project.
First they rant about how terrible the system is, than tell us how wrong the system is, followed by advice about how we should use this an this method or design patterns to make things right.
Only after months of working with the code the guy would cool down. When a (software) system is really complex, you have to get familiar with it. No matter how you structure it, a minimum number of logic and dependencies will always exist. Restructuring will not take away the complexity. It's just replacing them.
Offcourse a clear structure is better for you're understanding than a messy one, but even in the most clearly written code a lot of complexity can exist. I think Scott is talking about this, the point beyond clear structure.
thats complexity :)
By coincidence I just read Scott’s book not too long ago and can attest that it contains not a single suggestion that imposing any sort of order on a system is ever a good idea. Quite the opposite, in fact.
There may be lessons for city planners and agriculturalists in the book, but I’m pretty sure there isn’t a single one for software developers.
Previously formulated as Chesterton's Fence [0], among others.
There's definitely a blind spot in software for the general principle that you should understand a thing well before you decide to remove it. Anyone want to propose some theories on why disregard for an extant body of work tends to plague software so extensively?
Removing stuff isn’t restricted to software practitioners but there’s no need to reach for a flashy theory for something that can be adequately explained by human nature, in this case hubris.
Hubris is bound to manifest in any situation when a person with incomplete understanding of the situation, acts like they ‘know best’.
For those who don't know, the Borg are a machine intelligence hive mind species that roams the galaxy in their cubes, spheres, diamonds and other ships shaped like basic solids, destroying or assimilating anything interesting in their path, and speaking a lot about "bringing order to chaos". Yet seemingly despite their focus on order and perfection, the individual drones and the microstructure of the ships both look like a haphazard bundle of lights and wires. This is in line with the article - machine intelligence optimizing for extreme efficiency across multiple dimensions isn't going to create sleek-looking constructs.
This article however rubs me the wrong way right from the start. 'Cars running at the same speed' aren't "efficiency-destroying" nor about spurious 'appearance'. A controlled laminar flow is incredibly more efficient than chaotic turbulence.
It does not get any better later on, when the author waxes lyrically about 'beautiful equilibrium that evolved to satisfy a thousand competing constraint' in the absence of planning, casually glossing over the part where communal zoning regulation prevents not just externality dumping races to the bottom and the basis for non-speculative investment to those that can't afford to gamble or force their own "manu militari" regulation.
While self proclaiming "not suggesting all chaos is good", it is exactly what the rest of the article's suggestive language tries to convey. The deregulation agenda, while not explicitly spelled out, is omnipresent in the tenure of the writing.
P.S. I'm not surprised to learn that the author works for Uber.
And wouldn't Uber be more profitable if people lived and worked in different parts of the city?
You shouldn't defend it by trying to assign positive attributes to it (its effecient. ...yeah). Maybe there's nothing good about bad code and we should use being called out on it as an opportunity for improvement.
No, lets double down on our delusions of superiority by telling ourselves that crap we wrote is somehow effecient in some way.
Im tired of it. Its not effecient. Its bad and you should feel bad.
When I asked about this, I was told it was "best practice" and that if they ever needed to scale, there were now many places they could separate things. I pointed out that for the target audience, they probably wouldn't need to scale. But that if they did, it would be because they were doing 7x the work necessary.
The code was certainly "tidy" from the perspective of the guy who got paid a lot of money to produce architecture diagrams. But it was a nightmare from the perspective of an individual programmer trying to add a feature. They would have been way better off without a lot of quasi-religious design theory slowing them down.
And really, it turns out most of the time that not only you don't need the complex abstractions designed early on, you actually need a set of different ones. That's why keeping the design process continuously grounded in reality is important.
My solution for not producing spaghetti code with this method? I don't release the first version that works. I don't mark the ticket as "done", and I don't even push it out of my local repo. Instead, I clean it, or even straight up rewrite it, until it reaches a sleek and acceptably elegant state. It's the responsibility of a programmer to decide when the code is ready, and it doesn't have to be at the first moment it passes all the tests.
Because that's the time when you've learned to understand the problem, and you already have working code to move around.
On reflecting, I've had a similar process, too, though now I'm at least consciously aware of it as an actual development strategy rather than just believing I'm a shitty programmer who's forced to rewrite things because he can't fix his prior horribly-broken implementations, lol.
It's a long way from printf to framebuffer pixels. There's good reasons for every layer inbetween, too. (I like C compilers, format strings, buffered I/O, I like file descriptor semantics; I like having an operating system and it providing terminal emulation and framebuffer text rendering services!)
So I'm fine with 15 layers of abstraction to print hello world.
I'm not saying abstraction is bad - just that it's constraining, and prematurely introducing a whole ladder of constraints is going to grind code evolution to a halt.
> Im tired of it. Its not effecient. Its bad and you should feel bad.
You're ignoring that sometimes, measurably more efficient code is less readable, possibly much less readable. If this weren't the case, there'd be no such thing as sophisticated data-structures and algorithms.
This doesn't mean anyone should make an uncommented ball of mud with no comments, of course.
> No, lets double down on our delusions of superiority by telling ourselves that crap we wrote is somehow effecient in some way.
The usual wisdom about efficient code, answers this: if you aren't measuring performance, that means you don't really care about performance.
If you're going to great efforts, and writing less readable code, on the hunch that this is more efficient, then sure, you're doing it wrong.
That's pretty much what I've done in this last calendar year, taken two messy systems chaotically (in this article's sense) interfaced with the rest of the company, and upgraded them. I gave them new, hopefully-non-crap code, certainly better documented code, documentation on the system structure, better operational deployment, massive upgrades to security, general speed improvements, and in one case, a fundamental architectural change at the most foundational level even though the surface that the users interacted with hardly appeared to change.
And yet... despite all that, I would not say I "rewrote them from scratch", because I did not simply start with a blank sheet of paper and start scribbling what I think the ideal solution would be. I took the underlying adaptations, respected them, assumed that they likely had a reason even if I didn't know what they were, and built systems that largely dropped into place on top of the old ones rather than being totally foreign bodies that cause cascading requirements for other systems to also be significantly rewritten.
If, in the future, those other systems do get rewritten, I even have some paths prepared (but not yet written) in the code for true architectural upgrades to occur in the future. But in the meantime, I have improved systems that work now.
It's a much better approach to replacing a system that denying the chaotic adaptations. Even "crap code" can be mined for them, and they are not generally the crappiness itself.
https://lemire.me/blog/2017/01/20/how-quickly-can-you-remove...
IOW, local complexity in exchange for global simplicity is often a good tradeoff.
"His room" is a private space that doesn't affect other people. I don't tell my co-worker to clean up his side-project on github.
"Don't write crap code" is a terribly empty statement. Trying to "tidy up" "crap code" is also a great way to screw things up further if you turn out to be wrong about it.
In the course of writing the concepts in a dumbed-down format for an instruction machine, context is inevitably lost. You can say "write comments" until you're blue in the face, but it doesn't solve the problem.
Then, someone new comes along, and they don't understand the context, they never knew anything about it before, and you quit 8 months ago. This person must infer the context and determine an accurate conception of the context from the pieces left behind.
The approach taken when one finds themselves in that position is one of the key tells of their skill and experience IMO. Regardless, it seems that if the software got out of the loose demo/messing around phase, it deserves at least some consideration before it's dismissed out of hand as "bad code".
For example, a mix of exception and error returns, direct access to class members combined with accessors, etc... I like to see best practice rules being broken when there is a good reason for that.
Rule of the thumb: good code is short code. If your "tidying up" makes the code longer, then it is probably better to leave it as it is. What you are going to do is most likely add useless layers of abstraction or try make it abide by some made-up rule that shouldn't apply here.
As for "efficient" code. Most efficient code I see is actually quite good and readable. The worst code I see usually gives no fucks to efficiency. At least premature optimizers show some love to their code.
To me it seems like a failure to take a look at the bigger picture. In the end it is all about the value provided. You are creating a start up that has 10 percent chance of succeeding and only if it gets to market fast.
Also it is never binary. It is always time invested vs quality of the code. It is a spectrum. From what point can you call code crap?
The closer you get to perfect code the more time it takes to get it better as you are closing near perfect.
Problems arise when the first system gets left in place for too long. It starts to grow developers sometimes whole teams arise, and many people ask why, but are too afraid to touch it
I can, however, imagine quitting if my manager is a shitty person.
People don't quit work - they quit managers.
But I think it's also bad for the developer. Giving up and accepting bad code and low productivity means we develop habits and attitudes appropriate to that environment. It keeps us from getting better at our jobs, from keeping up with new technologies and new approaches. And given how our industry keeps changing, I think that's a recipe for disaster.
If most of my income derived from being an owner of a company, I would care deeply about this problem.
Since it doesn't, its really no sweat off my back, either way.
> It keeps us from getting better at our jobs, from keeping up with new technologies and new approaches.
In my experience, tech churn is one of the top reasons for why code has gone to shit. "It's been three years since the last re-write, let's rebuild the product again, in a framework that nobody here knows how to use!"
On the bright side, both the re-write, and the cleanup of the resulting mess means steady employment.
Again, only in the short term. A failing company is not a fun place to be, and a failed one even worse. And if you end up with a resume that has a long string of losers as your employers, it's going to get harder to get good jobs.
Any manager who can put two and two together should be well aware that the impact that an average IC has on the success of a failing company that's bigger than 100 people is near-zero.
It's just pedigree snobbery, to look at a resume, and go: "Oh, well, he worked for losers, he must be a loser, reject."
Most people do exactly that for a living. I don't let my 9-5 define my life. It means I'll retire in two years, and be able to work for a cause that I deeply care about - or, better yet, for myself.
A better thought experiment is to ask yourself how many of your co-workers will come in tomorrow, if all your code became the most beautiful code ever written, with rainbows, and unicorns... but on the flipside, that they stopped receiving paycheques.
From what I've seen, this may be true in some particular cases, but this is not a general pattern.
I've found that beauty, in software (as in art and design in general) very often has common elements. People certainly have different preferences in how the elements are put together, but I think many people can appreciate the underlying principles.
Here are some examples of the principles behind beauty in software:
* A component obeying the principle of least surprise
* A function having a clear purpose
* A function using a small (perhaps minimum) number of arguments for its purpose
* A codebase cleanly separating concerns
* A codebase reusing standard components
* A codebase having appropriate documentation suited to the team working with it
* A codebase having good testability
* An algorithm (e.g., one based on a published paper) solving a problem by doing less work
* A function having fewer lines of code
None of these are absolute. (For example, the last two may sometimes exist in tension with one other.) I see the concept of beauty as relative to a set of goals and values. Beauty almost always often involves a sense of balance and proportion: trading-off principles that are not perfectly orthogonal.
Of course, there are different perspectives on how to achieve a particular balance for a particular situation.
I'd like to add an unsupported claim (that I happen to believe, given a set of mostly rational people working together in a healthy work environment): If you get these people together and say "is codebase X beautiful for purpose Y?" I think you'll find a lot of consensus. In areas where they disagree, I think the resulting discussion will likely be constructive. I would bet that the discussion will lead to a better design in the end -- as perceived by the participants. This assumes that the people learn from each other; e.g. proponents who tend to favor one principle are willing to listen to proponents of other principles.
I suspect aiming for beauty gives you neither.
My own biggest beef with the article is it entirely misses the deep point of Marie Kondo's work, which is about efficiency and joy. If the article is not actually a response to her philosophy and definition of tidiness, and just needed a cute title, well, that's confusing at the very least. The commenters who point out that codebases, for example, need to be reasonable for humans to work in, or that it sure is easier to change source code than a compiled binary, are on the right track.
Kondo's method is all about identifying the clutter _that is actually clutter_, and deleting it. Would you rather maintain a program that's 1000 lines, or 100? If the 1000-line program was written by you, for you, over the course of your life, and by your own admission is extremely messy and moderately unpleasant to deal with, containing lots of unused stuff, yet you run it, and modify it, every day, no one is going to force you to clean it up, but you can find joy in doing so.
Actually, I think this article is not about software at all, or decluttering a room, it’s about “ complex systems — like laws, cities, or corporate processes,” and then uses the word “systems” as shorthand for this, and then talks a bit about managing software projects but it’s really still about good corporate process, and then mentions tidying a room but mostly as a joke.
I think the actual point is more about large groups of people or organisms that function well together, and how you shouldn’t assume it is better to impose uniformity. Even then, though, it is easy to argue both sides of this point, pick apart the examples given in the article, and use a codebase as an analogy to an organization.
Some elements of Konmari’s method actually are consonant with that, since evaluation of your self and the place of objects in your life are a continuous part of the process. Just throwing all your stuff away every week, whether you need it or not, would definitely be efficiency destroying although it would also be very tidy. Speaking from experience, however, this is not a behavior that developers struggle with. The heedless piling up of trash, code and tickets is far more common.
It would be interesting to see a movie where an AI takes over and turns reality in to a Rube Goldberg machine.
E.g. older houses were hand-built, but nowadays houses are built with straight walls and standardised heights for everything so that mass-produced furniture can fit in them. But if in the future our furniture is made on-demand by AIs, then there's no reason to do it that way; you can have a non-standard height for your kitchen counter (for example) and if/when your dishwasher breaks, the AI system will fabricate you a new non-standard dishwasher to go under it.
A Rube Goldberg machine usually accomplishes one task. Corporations at scale don’t resemble them mostly because, as there are a multitude of concurrent tasks in flight, the Rube Goldberg machines are neither complex nor absurd enough.
The majority of companies are run by people who would have trouble understanding the details of what their company does.
That means we already have AGI, right? The corporation.
I always thought it would be interesting to have a prequel about the first person to escape. Office Space meets X Files, and the order of the complexity slowly becomes more apparent, until the movie turns into Playtime.
How would that be distinct from actual reality?
>confirming that our intuitive preference for “straight line” designs has nothing to do with performance
As the first is made to be made because of its 'straight lines'. You can see the welds and logic in it, as something easily made.
While the second is something only achievable via 3D-Metal printing or possibly very complex 5 axis CNC.
1. Theoretical: chaotic and complex are not the same thing. Organized and tidy are neither the opposite from or excluding complex systems. Some very tidy systems can still be mind-boggling complex. Furthermore Chaotic systems have a single underlying order (it might just be impossible to discern), but they are not complex. Complex systems might have multiple orders, none at all or everything in between.
See for an in-depth discussion: The Collapse of Chaos; Discovering Simplicity in a Complex World, Jack Cohen & Ian Stewart, Penguin, 2000.
2. Practical: The amount of tidiness in a complex system does not say anything about its efficiency, but neither does its untidiness. Complex systems might be untidy through sunken costs, like most cities are, revolution, evolution, historical accident, or even attempts to make an ordered system (like a system of law) always leaving some gap. The fact that a complex system exists does not say anything about it being efficient or its fitness for purpose. Like the three year old who thinks the mess is beautiful, but cannot find her favorite plush toy.
Changing complex systems is indeed hard, because different subsystems will interact, have feedback loops, create externalities, exclude external information or are near impossible through sunken costs. But that still leaves the calculation of how much the new system or altered system might be more efficient or better than the current system and what the risks involved are.
Tiding up complex systems has risks, but also benefits even if you don't believe the second law of thermodynamics applies to human created systems. Tidied up systems are more easy to reason about and thus can be more easily fixed, adapted or expanded upon. The act of tiding up has the additional benefit of adding to our knowledge about how a system actually works.
3. This guy works for Uber. The cab company with a computer that wants to uproot the current (complex) systems and replace it with something simpler. Yet fails to turn a profit. Do we need to read something into this article, or did he just not realize he contradicts his employers mission?
The article is not talking about the kind of tidiness that is the hallmark of a well-run workshop, IMO. That kind of tidiness is part of what makes more efficiency in that context.
This is something my wife and I have figured out over time - If it's your own space and nobody else uses it, it's fine to descend to 'chaos' because you can just remember where you last put something.
That model breaks if the space is occupied by more than one person, because where one person put something isn't witnessed by the other person. So, having designated places for things and returning them to their 'home' makes the space most usable by multiple people.
Personally, even for solo spaces, I still favor everything having a home because I don't have a good memory for where things were placed.
His idea is that there is a pretty high standard of cleanliness in a bakery, just not the obvious one. A similar "hidden rule" presumably applies to cities etc.
> I’m using the word kind on purpose, there, because Simonyi mistakenly used the word type in his paper, and generations of programmers misunderstood what he meant.
It sure doesn't sound like Simonyi was the one making a mistake here! It sounds like Hungarian notation is what you use to compensate for missing types; it got its bad reputation from people using it for types that the language already provides, because that's easier.
The optimization it praises only has single focus (operational efficiency), whereas if you take into account all of the aspects of the things in question, suddenly you see that the way things are are usually a solid compromise between the aspects it's really optimizing for. That includes human interactions such as analysis, repair, modification, and so on.
2. It's not too surprising given the way ntural selection finds efficiencies in quite complex structures. But trying to reason about how they work is tricky. When engineering things, being able to reason about a system is often a lot more important than that system being close to maximally efficient. Main point is, I think you should always be aware of what trade offs are you making.... much like my point #1, if you use this to justify being messy, then it's probablly the wrong tradeoff, but shhh, my partner doesn't read this :)
If you had unlimited time, you would tidy and organize everything in real time. However, we don't have unlimited time and so we borrow time from the future by leaving things slightly messy.
The behavior to avoid, as in money ledgers, is not using the ledger but never paying it back.
[1] https://twitter.com/jo_liss/status/674332649226436613/photo/...?
[2] https://en.wikipedia.org/wiki/Neuf-Brisach#/media/File:Neuf-...
You can also see them in wear patterns on old handles and stairs.
Hence why I think before you try and change a system it's important to know what your baseline outcomes are and then instrument the system to measure where these "desire paths" exist in complex systems like computing.
When I worked at Amazon, everyone worked out of the same repo(s), used the same build system (Brazil), deployment system (Apollo), deployed to the same place (EC2), most APIs were written using the same framework (Coral), etc. This is not that unlike the other large tech companies, and now that I'm back at a large non-tech company where everyone builds their own slightly-incompatible tools and deployment pipelines, I do miss that standardization.
Sure, some people chose to use different tools here and there, but most people wouldn't choose to reconstruct the universe just to stand up a microservice. It's not like all the "two-pizza teams" were all doing completely different things with incompatible tooling.
It's been a while since I worked there, so things might've changed completely since then. But as a shareholder, I hope not.
Anyone familiar with the magical number seven knows that systems need to be simple not for the sake of the computers, but for the sake of the people who work on it. As much as we like to think of ourselves as geniuses, at the end of the day we're animals with a finite amount of brain power. We cannot grasp large complex systems, and we need compartmentalization and simplicity so we can keep building on top of what we already have.
Maybe one day the computers will take over programming for us, but that day isn't today.
What was that russian electronic board design software where nothing is vertically/horizontally aligned, no trace is straight?
https://en.wikipedia.org/wiki/TopoR#Features
TopoR, destroy all autorouters:
Then, along came Fast Fourier Transform based algorithms.
Grids make it easier to navigate for humans, to plan for public transport, and improves the city's connectivity.
Waiting in clean lines reduces the chances of fighting in the queue.
Cars running at the same speed dramatically reduces the chances of a lethal impact.
And what exactly is the cost of these things? Is a grid that much harder to make? Does anyone want to cancel the dedicated highway, or let cars stop in the middle of it?
I think this author just doesn't understand the concept of efficiency at all.
> “Please clean up your room,” asks the mother. “Fool,” retorts the three-year-old with an eerily deep voice. “Can’t you see the beauty in my glorious chaos?”
Sounds like he's still upset about that..
> Symmetry underlies almost everything in mathematics and nature.
> It's much more reasonable to assume that our computer programs are not yet good enough to recover that symmetry, than to take the output of current programs as some sort of evidence that asymmetry itself is some sort of ideal.
And then I looked out my window at a tree without leaves, between two buildings, and I'm looking at how unorganized the branches look, and I'm not so sure anymore. It's like the "spherical chickens" joke.
(Sidenote: it's incredible how angry and volatile this comment section is --- my original comment included. Seems this subject can really strike a personal nerve in many of us. Why?!)
I find that to be particularly true when you are starting to experiment with some product or solution. At that time, you need to be messy (hacking a solution). The need initially is ability to quickly move in trying ideas and discarding ones that don't work.
Then you reach a time when you have figured out a very elegant solution that a user of product would just love. At this time, it is right opportunity to optimize for legibility and orderliness (refactoring) before your solution turns into a mess that works very well but no one can understand or update.
And yet, many people today don't like C and assembly language, and hate "goto" and some other stuff like that, but I think that it is good.
(Also I do not always clean the stuff, because where it is, I know where it is and do not have to move it again when using it again.)
I think the author may be wrong here, and actually the pattern is how it is for very complex reasons.
Instead, I've been designing for aesthetics, for symmetry or clean lines or linear solutions. When I've given in to the desire to chase the metrics, the results have been much messier in appearance.
Working in a large code base that has little structure/consistency is another example of high cost/friction.
There is some benefit to organization.
nature certainly doesn’t optimize for “efficiency”
https://slatestarcodex.com/2017/03/16/book-review-seeing-lik...
Tidying systems up so they are organised "from my perspective" is not done, "for my benefit". It's done to make things easier to change.
Yes, it can make things less performance, no, most of the time that is irrelevant.
Refactoring is not optimisation. They are different things and both need to happen.
They both require you to make trade offs against future difficulties.
A classic case of Chesterton’s Fence
In the original version, it was in some animal like a fish, and the top part of the aorta was in the gills, so the way from the brain to the eye though the hole that is below the aorta was a straightforward path.
A few million years later, when we lost the gills, and got a neck, the top part of the aorta moved inside the chest to avoid a stupid long trip to the neck and back (and probably lost a lot of speed in the blood). The nerve was hooked, so the aorta got shorter, but the nerve has to go down to the chest, pass below the aorta, and then go back to the eye.
In the case of the giraffe, the trip to the chest and back to the eye is stupidly long.
The problem with evolution is that mutation can do only small changes (most big changes are just deadly). The connections of the nerve and the artery form very early in the development of the fetus, when it looks almost like an ugly fish. You can't unentangle the nerve and the artery later.
More details: https://en.wikipedia.org/wiki/Recurrent_laryngeal_nerve