Object Oriented Hell

Did object oriented programming manage to keep its promise of better code structure?

I stumbled upon this quora answer a couple of days ago and I can’t but agree more with the points made:

OO didn’t lead to better code

It’s just an abstraction like others (i.e. functional programming) to be honest. Not a magic wand that will make programs write themselves.

Java and to a lesser extent C++ were used improperly leading to increased complexity instead of encapsulating it when really necessary

Avoid at all costs inheritance. The only place I’ve seen inheritance work properly is with UI frameworks. So unless you are rewriting Swing or the Flash Virtual Machine don’t do it.

An excuse for ignorance

Many Java developers end up knowing nothing about how a computer actually works. They are just trained to write classes but can’t tell you how an http call works… what is a host header… how cookies work etc

When asked to help with recruiting web developers the first question I ask is where cookies are stored by default in the technology most familiar with the candidate: 99% of times their first answer is wrong. Java devs score even worse than PHP ones.

Classes everywhere

Not sure why but I had seen simple Java webapps with over 1000 classes and 100k instances loaded at runtime. It’s a miracle that the JVM can cope with that…

The usual pattern is as follows:

• a class that receives some dependencies (through some form of DI) and exposes 3 or 4 methods
• each of those methods pretty much just invokes one or 2 methods on the injected objects but adds very little
• rinse and repeat 20 times for each feature

A well written web app (no matter what technology) should have only controllers, services and a DB abstraction layer. nothing else.

If-then-else abuse

I’ve seen this over and over

if(specialCondition) {
  handleSpecial(...)
} else {
  handleNormal(...)
}

which over time becomes

if(specialConditionNew) {
  handleSpecialNew(...)
} else if(specialCondition) {
  handleSpecial(...) 
} else {
  handleNormal(...)
}

Don’t use if-then-else statements to branch based on your dataset. It most likely a symptom of bad programming. Use polymorphism instead and keep your execution flow one (no branches).

Unit testing everything

Testing or automated testing is a growing necessity. Unit testing just does that: tests a unit (or class). When you test hundreds of useless classes with no business logic, what do you achieve? Nothing but you end up having way too many tests to write and maintain for no reason.

Prefer functional testing and use unit testing only when there is some business logic to test (i.e. input sanitization, parsing, regex manipulation)

Small is better

It’s much better to have 1 developer working on many projects that many developers on one project

Build many small programs that talk to each other (micro services) and do one thing and one thing only

• Have 1 developer per sw max (extreme but doable)
• Have all developers work on multiple programs throughout a year so that they can build reusable libraries

This is how small software companies operate. No surprise they usually make better software.

This approach is more difficult to KPI as it clashes with sw engineer commoditization and outsourcing but also with time/power tracking.

Big means more overhead

A big software:

• requires onboarding, pundits and sw architects
• make talent hard to identify: if you have 5 people working on a project, who’s the drag and who’s the lead?
• ultimately becomes a platform with a fancy name that require more and more people, more and more onboarding efforts, more and more overhead