Magic. The software kind of magic.

It’s a kind of magic!

Hey y’all!

It’s that time of the month again, time for another blog post! We’ve been writing a longer post and had intended to post it this month, but unfortunately it isn’t quite ready; fortunately something else has been bugging us enough to get it’s own blog post.

Magic.

Magic, you say?

Yes, magic.

What magic?

Software magic.

Oh right. I’m still confused…

Well, then, you have every right to be!

Here at 23Sqaured we use the term ‘Magic’ or ‘Software Magic’ to describe the situation we frequently encounter when using frameworks. The situation when the framework or library does something very helpful for you but you aren’t quite sure how or what it’s doing.

That’s great though, right? Well yes, yes it is. It’s the reason that people use frameworks; so you don’t have to write all that boilerplate code, you can just focus on getting the system built and working and worry about your business specific code needs.

Take the favoured Spring framework, in particular Spring Boot. It’s great, one can create a web service with a minimal amount of code by letting Spring do the heavy lifting. When combined with Jackson for example, one has an awesomely powerful set of annotations and functionality available, making complex systems, well, pretty darn straightforward.

The problem is, if you were to ask the average Spring Boot developer how their system worked, like, what actually happens from when you receive that GET/POST/Whatever request to your system processing it and responding, would they be able to tell you? No, they probably wouldn’t. The problem we have with this is that when something goes wrong (trust us, it always does…) it’s much more difficult to fix, chasing down bugs through decompiled byte code (if you happen to be using Java) isn’t the most pleasant experience – it can be frustrating and, more importantly, time consuming.

Let us be clear here, we aren’t against frameworks. We’re against too much magic. Too many frameworks bolted together to build a system. When you’re system is using frameworks in double figures you should really be questioning your design. Frameworks are there to make life easier and speed up development but there still needs to be some development. When most of the code in the project codebase belongs to another product it’s going to be pretty tricky to debug errors and issues. Further, you’re entirely at the mercy of the other development teams to fix bugs and add features that your project might need.

The final thoughts to take away from this in a little brown knowledge bag for tomorrow’s lunch is that whilst frameworks are great and useful there’s a balance to be had. The sweet spot is where you’ve got enough framework usage to speed up development and provide all the boilerplate code whilst still giving you the ability to understand how your code is actually working! Of course, this might be 1 framework for some projects and 10 for another; it all depends on what you’re doing.

We’re sorry this is more of a thoughts rather than actions blog; it’s just something we’ve been thinking about lately here at 23Squared HQ. In the meantime, you’ve been great…we’ve been…

~23Squared