Hacker News Reader

Comment by codingdave | Hacker News Reader

The quote of "If I had more time, I would have written a shorter letter" has been quoted so often that it is arguable who said it first, but it is definitely at least a 300+ year old concept.

Simplicity takes effort. It takes time. And you often cannot write simple software in the first version because you are designing it as you go. Simplicity comes from maturity both in the product design and the development staff, and is a long term goal.

It is not something that you achieve by critiquing individual PRs, but by insightful long-term thought into how to solve your problem with your code, and many refactors over time.

It is wise strive for simplicity in all code you write, but wiser to have the patience to let it develop over the lifecycle of your product.

View on HN

"Making things simple is hard work." - Rich Hickey

When I think of the simple vs complex bifurcation I think of fractals, a "simple" set of rules expressed in a complex way. The complexity arises from their expression/expansion iterated over time, but the rules that govern that expression are economical and compact. Think of an acorn: the encoding of a tree is all there. Its self-similarity, recusively expressed, creates the complex output of a tree. But nature always prefers the most economical solution because in the physical universe, resources are limited.

It might make more sense to s/simple/economical/.

Agreed. I learned the most working with a system I built from scratch and managed for 4 and a half years. You can't blame other people when you have built it yourself. You see what areas of code constantly needed updating, and where you could have improved the design. With any luck you will be given enough time to refactor it and improve it.

> "If I had more time, I would have written a shorter letter"

I don't like seeing this quote in the context of programming.

Sure, they're both about writing, but in different settings. A person who writes a letter has one goal: for the intent of the letter to be understood by the recipient. However, a programmer writing code has two goals: not only for the intent of the code to be understood by future programmers, but also to make the code easy to change in response to unknown requirements without causing any regressions.

The article is a bit all-over-the-place, but I do agree with it in general, because I've seen far more bugs in production caused by changing code than by adding it. Therefore, I would rather use a language with advanced features I can use to make my code harder to change in the wrong way. I think that if you phrase it like that, it makes it more acceptable to "avoid simplicity".

I get what you mean but tend to think of them to be so.ilar with in a different respect--that the concepts being expressed are clear. If the reason why code is organized by n a certain way is clear along with its effect then there would not be the motivation to stray from it. The problem is that often the organization is the result of achieving multiple effects rather than behaviorial factoring.

>> "If I had more time, I would have written a shorter letter" >I don't like seeing this quote in the context of programming.

Maybe you're overthinking it? Just yesterday I delivered a temporary fix with copy/pasted code inside because I didn't have the time to make the 'correct' code..

This is such a well written comment. Often what starts as 'simple' turns into spaghetti complex over time due to the lack of foresight. It's a hard task job and requires a lot of experience to create systems that are simple to understand and to ensure the integrity of the system isn't lost when new things are added on top of them. Foresight into what might be realistically added in future is what seniority enables.

Not to nitpick too hard, but I'm pretty confident we know that was Pascal. The rest are misattributions.

Reply on news.ycombinator.com