Codeless – Simple or Complex?

intellij-edit

Developers write code. That’s how they represent their intent in a way a computer should execute it. In a world of cloud infrastructure, even infrastructure is code these days.

In You Must Like Typing, I criticise the developer who prefers to paste their way through life, or repeat themselves ad infinitum with the same old same old boilerplate.

That said, when Solution Architects have suggest to me in the past some sort of magic panacea solution that’s so good you don’t even need to write code I’ve often been unhappy.

This raises a few questions:

  • Working at the right level of abstraction
  • The flexibility of my code vs the fixed opinions of a framework, especially someone else’s
  • Understandability and bugs: why you always regret building your own framework, even if it’s the right thing to do (see also DSLs)

Working at the right level of abstraction

Programmers I know talk about the pleasure of lego programming that’s a decent metaphor for when you can quickly assemble powerful and complex solutions from simple building blocks. Any lego engineer will know that you want to put together pieces of about the right size each, rather than assemble everything from single dot, 1/3rd size pieces.

So it’s true with programming. You want your code, at least at the high level, to express the intent of what the program does, by assembling high level concepts, injecting detail only where it’s particular to the matter in hand.

A good metaphor for this is how Spring Data JPA provides you a full-blown DAO object for your database.

Compare the following pseudocode alternatives:

// manually using some sort of ORM library (a fictitious one)
User getUserById(int id) {
   getConnection()
      .select(User.class)
      .where("id", equals(id))
      .findFirst()
      .orElse(null);
}

// spring data jpa
public interface UserRepository {
   User getUserById(int id); // spring just writes the method for you
}

Clearly the second one leaves you free to have coffee, make friends, get on with your life, and most importantly: quickly change your mind.

If you only write low level code, all design changes are a complete rewrite!

Flexibility of lots of simple code

The problem with a framework or a template is that you can only do what the framework supports the way it supports it. The above example for selecting from a simple table starts to become heinous in a 15 table complex join situation, which you could develop in a SQL editor in about 10 minutes.

Simple code spells out exactly what’s going on, and is open to tweaking on a case by case basis, which would be hard to support in any framework. The counter argument for that is that you’ll lose those details in the noise of all the boilerplate, but simple is a powerful reason to adopt something ugly, long-winded or slow, if it’s ultimately easier to manage than a complex beast that you’re trying to tame to do your will.

Another issue of frameworks is that they become a dependency sharing issue. If you devise a helper or a template, you then need everything to get a copy of that to do their job. If the framework in question is a public module, then perhaps that’s fair enough, but my experience of frameworks is that you end up having surrounding customisations and helper functions that become a shared dependency.

The pain of sharing dependencies is sometimes not worth the result. I’ve seen a five line function get deliberately pasted across an organisation’s product code base, rather than that organisation slow down to the speed of the common-dependency-component management process.

Understandability of a framework

Frameworks are great. I’ve written a few and I’m proud of them.

The first rule of frameworks is don’t write a framework.

Writing a framework to solve a problem you haven’t solve more simplistically before is a gateway to a huge amount of over-engineering and premature generalisation. However, let’s assume you’ve gone through that (on this project, or in general) and are now trying to generalise by adopting a framework.

The main pain of a framework is that it comes with a high barrier to entry. Before someone can use it, they need to learn it. Depending on how home-made the framework is, and how obscure the techniques are, the learning curve may be high.

If you were, as a team, adopting something like Spring or ReactJS then you would be able to say that it’s ok to adopt the framework because there are countless examples on the internet, training courses, pages of documentation and so on.

A home made framework is hard to teach.

Even if you write all the documentation you can think of, people will generally not understand a new technology/technique you’ve invented

With all this in mind, it seems like nobody should write or use frameworks unless they absolutely have to. I don’t agree with that statement. I think the entry criteria for writing a framework has to be correct.

There are huge advantages of creating/adopting frameworks and templates. They amount to keeping the developers operating at the right level of abstraction, and allowing code to be more malleable. However, the risks of doing this are also high and can be very impactful.

Conclusion

There’s a difficult line to draw. If you go too extreme, you obfuscate your code and spend most of your time fighting weird edge cases preventing apparently simple things from being possible. If you go too extreme the other way, you’re doomed to type your fingers to the bone and get eye strain in code reviews.

Here’s a suggestion.

If the framework is simple to medium complexity, and the size of the framework is less than or equal to the code it replaces, and it allows the nuance of usage to be put to the front, rather than have lots of details lost in the boilerplate, then it’s probably worthwhile.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s