Yes, I said it. And yes, I insulted the vast majority of the Software industry (probably including You). The fact is, it is an everyday thing to hear: “I have this great idea for a React App/Android App/iOS App.” Yeah, but what does it do? Why is it so great? Does it have to be based on that framework to be so awesome? If you don’t know the answers of the first two, you’re already in trouble. If the answer of the last question is “Yes”, then do you think it will work as you expect it? I doubt it.
What people want
Here’s the thing. Unlike with cars, in software, people don’t care what’s under the hood. People use software to save time, frustration and money. They don’t use it because it is built with React. They don’t care if it is an iOS app, as long as they can use it on whichever smartphone they have. So why do you care so much?
I get it that we, as developers, are on the tech side of the industry, where all we care about is ifs and fors and bugs and code. We hate javascript and we love python. But once you’re ready with your app, all the user sees is the GUI.
And if this app does not do what she needs, she’ll go and find another one. Because the value in the app is not in what technology was used, but in the time saved, the easy use, the security of the user data.
Stop choosing technology stacks too early
Like Uncle Bob Martin said in this video: “Framework authors are out to screw you”. He explains there how to prevent this from a technical point of view. I argue, that if you do this, it will make your product better!
Creating a product is hard. Even more so when you haven’t been taught how. How do you know, what feature to include in it? How do you know what your users want? What would bring more users to it? I need to think about them quite hard, before I decide what’s the next thing I need to implement.
So why should I bother with even more questions, like: “Is this feature easy to implement with Angular?”, “Can I run a database on an iPhone?” Why not concentrate on the essence of the application, before facing the hard questions?
Create value first
So there it is, you decided to leave the framework choice for later. And Uncle Bob Martin helped with that. Then what’s left to do? Business logic! All the stuff the user pays for.
The business logic is the thing that saves your users time. It gives them ways to save money or to have fun, if you’re building a game. So focus on it. Make it work. Make it fast. Yeah, it will be hard to make a decent UI without a framework. But who cares? There’s time for that.
Besides, your first users will definitely be nerds for what your app does. Or relatives. Just die-hard fans of you or your app. So they’d deal with it. They can wait a little bit for fancy design and other perks. But even they wouldn’t bother if there is a better value somewhere else.
Choose your tools for what you do
Ok, now you have an awesome application with some crude UI. It probably still doesn’t even use a database, because “Ain’t nobody got time for this!” Now what?
Great! Now you know what you’re doing already. It’s ready for use and it works exactly as you want it to. Now you have the freedom to choose what type of application it would be! Would it be a web application? Would it be desktop app? Or perhaps an iOS app accessing the logic in a client-server configuration.
Or all of the above! Since your business logic was developed in a framework vacuum, there is no reason you can run your code anywhere (provided it compiles for that platform, of course), in any way. It is encapsulated. It does not need to be changed at all.
All you need to do now is choose the way it is going to be distributed. And then package it appropriately. Is it a web app? Use React! Is it going to be a desktop application? Qt it is! Android? Not a problem, put it on a server and write your UI in Kotlin.
What if I choose the wrong framework?
So you chose this fancy UI library, but it does not want to cooperate. You have to perform satanic rituals to make it do what you want and you’re almost out of goats! Tough. You know this is bad and the closer the deadline comes, it only gets worse.
No worries, your business logic still works. All your problems are on the outside of it. They are isolated just on the top of your application.
So why not just wipe out the entire UI and write it all over with the right tools? It’s only a few files after all! Or even better! Leave this UI where it is. If all hell breaks loose, at least you have something. Start all over, use the right tools and avoid the mistakes from your previous try.
Even if the UI is not fully operational by the deadline, whoever already uses your app has to deal with that rudimentary UI you’ve built for testing. So the new UI would always be better. And that’s a positive!
Minimal Viable Products don’t need magic
And there are benefits from a technical point of view too! Already 15 years since I started programming, I hear from everywhere, that magic is bad. This is a metaphor people use to say that if you don’t understand what’s happening in your code, you’re doing something wrong.
Well, turns out, if you write everything from scratch, you need to know what you’re doing. Therefore, by definition there is no magic in your code. Yay!
From that, you can easily extrapolate, that most magic is in the frameworks. This is generally true, because when you decide to use one, usually there isn’t enough time to look into it in detail. Besides, that’s what frameworks are for, right? It is invented to save time.
Well, yes, but the last thing you really need is to inject more bugs into your core codebase. And of course the frameworks have bugs. All software has bugs.
The thing is, calculating a final sum of an order does not need to have any UI. And it is usually as simple as adding some numbers together. So why use framework for that?
Get rid of your frameworks
Well, after all these arguments I had above, do you think it is a good idea to keep using frameworks in your business logic?
Maybe…
But it is worth the time to look into it and see what actually happens. Do you have an injection framework? Or even more than one injection framework? Do you think you need more than one?
If you have an old project which you started with a bunch of magic from the start, it won’t be easy to do that. But be brave and try!
Cheers!
If you liked this article, perhaps you’d like what I have to say about testing.