"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

This is my favorite research quote from a Civilization game (Civ IV, narrated by Leonard Nimoy). I use this as my mantra for all design-oriented aspects of my life now. Or... I try to. Sometimes it's hard not to want to add more haha.

FYI that quote is from Antoine de Saint-Exupry, author (and pilot) famous for "The Little Prince".

Do you know what the context of that quote is? I have used it as a sort of mantra specifically when programming, but I'm guessing it probably was intended for writing.

https://en.wikiquote.org/wiki/Antoine_de_Saint_Exup%C3%A9ry has the preceding paragraphs. It’s about the design of airplanes.

I don't, but it seems like it would find good use in both writing and aviation.

A story about that from the early Apple team: https://www.folklore.org/StoryView.py?project=Macintosh&stor...

I always tell my team that deleted code is the best code. Obviously less code is often more maintainable but there is also the element of being willing to throw away stuff you did earlier and not being attached to it.

I have a similar take on this, but expand it a bit by arguing that any line of code added – no matter how innocuous – is a liability. It's a line of code that has to be maintained, with all of the responsibilities that come with that. It may be a line that's responsible for adding more value than it costs, but it's still a liability. It won't add value forever, most likely, and when it stops it'll just be debt. It may be cheap debt, but debt nonetheless.

Deleted code on the other hand, is never a liability. The act of deleting it may be, but due diligence should ensure it is not.

Yes! Every addition carries some risk. The real world example I give to clients/managers of the risk of adding a feature is this:

Once I was using an industrial camera that had a mode that allowed it to mirror or “flip” the image output. Unfortunately, after running for a few hours, sometimes it would decide to flip the image on its own. Had that “flip” feature not existed, the bug could never have occurred.

The point isn’t that you shouldn’t add useful features, but that even easy to add features aren’t as “free” as they might seem and the risk of adding them should be recognized and weighed against their utility.

I remember teaching a guy about YAGNI - You Ain't Gonna Need It.

He would write helper functions that he thought would be useful before writing actual code and often ended up wasting time. Half the functions he wrote, he never actually used, but he'd still spend time writing them and unit tests for them.

Its interesting that University puts an emphasis on re usability, when in reality it often makes code a lot more difficult to understand.

Sometimes deleting code isn't enough and you have to do a rewrite. I once rewrote 2,650 lines of C as a seven line shell script. The previous programming team had written a data transfer program with its own implementation of ftp. I just used the one that was already on the computer.

"The only good diff is a red diff"

Nothing irrational about feeling joy over what is hopefully more succinct and efficient code.

Yes, as long as you recognize where that line of obfuscation (LOO) is and stay just short of it.

The less code there is, there less opportunity there is for bugs.

It's really code tetris