Hacker News Reader

Comment by jmnicolas | Hacker News Reader

Since I accepted I was no Einstein I embraced the KISS principle.

My code became simpler, easier to understand.

Of course it wouldn't get the approval of any software architect or any design pattern fanatic, but I can take any code I wrote 3 years ago, understand it on the fly and edit it with confidence. There are few bugs and they're never a nightmare to find.

Now if I have to modify the code I was writing before my KISS revelation, when I was reading too much about OOP and design patterns then the headaches start. Often I'm left wondering why oh why I had to use so many levels of indirection to solve what is a simple problem.

View on HN

Einstein himself would approve this philosophy. As he once said, "Everything should be made as simple as possible, but no simpler."

Still, finding the simplest-possible solution to complex problems is often challenging in itself, especially considering what is "simple" or "intuitive" can be highly subjective. Engineers are often uncomfortable thinking about these problems because the domain is shifted somewhat away from the realm of logic machines and towards psychology and UX, in which they have little to no education or experience.

An idea I carried over from mechanical engineering is the idea of degrees of freedom. If your solution has fewer degrees of freedom than the problem, it doesn't work. If it has too many it's unconstrained and requires hacks to keep it from doing something terrible.

The problem with "simple" is precisely the problem of removing what is not necessary. In most commercial software design, we tend toward making designs so flexible we make them tougher to reason about than necessary. One of the other problems in software is that software that is good is also the code that is easiest to understand and therefore replace. This doesn't happen so much with things like houses evidently.

This so many times over. OOP encourages clever implementations, I believe. That is, when I and others use it, I often think about how clever it is. Until I need to debug it and fix it. Then I start cursing.

Amen. I think the mistake is to reach for the complicated patterns first. Rather than refactoring later when it’s obvious they are needed to simplify your code.

I like the theory behind app architecture, but I haven't seen a complex design pattern work well in practice (unless the team is small, and everyone has a solid understanding of how it works).

I worked on a mobile app once that really tried to force one of the fancier design patterns — it required something like six files to handle one screen (because, of course, it's best practice to separate your view, view model, controller, etc.) However, a good part of the org didn't understand the nuances of what code should go where, and found it absurdly tedious to manage all of these files to build one minor screen. Velocity plummeted.

I think a good design pattern allows you to scale as complexity increases. Let folks start simple, then provide a clear path to a consistent design pattern that handles more complexity as it's needed.

OOP can be useful and simple like that. Typically when it is applied to things it solves well.

---

Modelling system state and effects (not data) is a good application. The article criticizes the following statement originally from the Oracle Java docs:

“Objects are key to understanding object-oriented technology. Look around right now and you’ll find many examples of real-world objects: your dog, your desk, your television set, your bicycle … Software objects are conceptually similar to real-world objects.”

I call this "Kindergarten-OO": It attempts to simulate things in the world as stateful Objects, which often should be modeled as plain data with generic data manipulation tools.

System state and effects however are _inherently_ stateful and effectful. File systems, DB/network connections, peripheral devices, that sort of thing. It makes sense to apply OOP here because you want to model these things with state-machine behavior and configuration/constructors in mind.

---

Also there is an interesting move away from "traditional" OOP by modern languages like Go and Rust. They emphasize set-like composition instead of hierarchical inheritance and implicit/user-defined interfaces/traits to both enable common abstractions/naming as well as increasing flexibility.

Both of these things essentially lead to simpler code and IMO address one of the original OO ideas of data-less programming (AKA I only care about this type of behaviour, not the whole thing) but improve the paradigm by rejecting inheritance and explicit (rigid) interface declaration.

In my opinion, a big thing many developers forget, especially those that are obsessed with design patterns and code rules, is that simple machines to solve complex problems are actually harder to design than convoluted ones. Leave a designer to their own devices, they immediately start spitting out way to many levels of indirection, it takes real thought to collapse those levels of indirection to something simple. Many less-experinced devs think that if they keep slapping on more layers, hide the problem more, more abstraction, they will reach some sort of inception-like base-case nirvana where the complex problem will magically become simple. But they are running the wrong directions. Simple, powerful, abstractions that make great tools great are generally pretty thin. They don't mask the actual problem, instead they provide good hand holds on it. C is a decent abstraction of assembly because it simplifies it, not because it hides it. All that being said, OOP, like many patterns, is perfectly fine if it makes a good abstraction. There is no one great pattern to rule them all.

Reply on news.ycombinator.com