Large software projects have many vital concerns, such as authentication and authorization. Despite the wealth of available libraries in the Java ecosystem we seem to be re-inventing the wheel far too often. Keep the focus on the core business of your application and don’t think you can code quicker and cheaper yourself than what you can buy off the shelf.
Some ten years ago the consultancy company in Rotterdam I was working for at the time was in the process of migrating their physical servers (JBoss/Oracle) to the cloud. Two modest server racks hogging an air-conditioned room didn’t make good business sense. I can remember a verbal scuffle between our then head of IT and a few more traditional forces in the development team who kept harping on that “these machines are our core business”. Of course they weren’t. In the end nothing much changed for the devs. The care for the now virtualized machines – that were indeed vital to the running of the company – was outsourced and no disasters ever happened.
Don’t grind your own flour
If you’re a travelling sales rep your car is vital, but talking to customers is your core business.
If you’re headmaster of a school you need heating and running water in the building, but your core business is with managing your teaching staff and talking to parents.
As to myself, I can’t do my job without my MacBook Pro, but… You get the point. Most of what is indispensable to completing a job or running a business can be bought, hired or downloaded. Adding value is what drives the economy. We even have a tax for it.
In the not-so good old days providing food and shelter to keep you and your family from starving and freezing to death was pretty much everybody’s core business. It is specialised job descriptions like feelgood manager that separate us from these ancestors. Just as the baker doesn’t grind his own flour to bake a cake, I don’t write my own device drivers or hashing algorithms (more on that later). Mind you, some do, just for the fun of it.
Re-inventing the wheel is a counter-intuitive practice, but we see it all the time. There’s the not-invented-here syndrome: unlikely to be included in the DSM manual of mental disorders but a disease nonetheless. Let’s be fair: to do an incomplete buggy rewrite under the mistaken idea that you can do it better or quicker is wilfully squandering your employer’s money. These people shouldn’t be allowed to make strategic decisions without adult supervision.
Do you sometimes find yourself coding a specific problem, feeling certain that you’re not the first one grappling with this particular problem and wonder if there might not be something you could pull off the shelf? You are probably right and there very likely is something on the shelf.
DDIY: Don’t do it yourself
Every networked multi-user application needs some form of authentication (who are you?) and authorisation (what are you allowed to do). Let me coin the phrase commodity concern here. Secure authentication is non-trivial to implement from scratch and it has dire consequences if you get it wrong. It’s also a necessary evil keeping you from coding the added value of your product that (hopefully) nobody else is writing at the same time. Now of course you don’t write all this from scratch. Spring security has libraries for all your authentication needs. Which is exactly the problem: it’s a DIY kit. There are live wires sticking out for you to connect. While creating and storing password hashes I was prompted to “choose a sufficiently large number of log rounds” for the BCrypt library (apparently too much can fry your CPU). How am I expected to know? Does the anaesthesiologist ask the patient how many milligrams of propofol they would like?
If only I had known keycloak, an open source identity and access management server. Our colleague Jannik Hüls gave a fascinating talk recently at our Breda office.
Instead of cobbling together your authentication solution out of library components and layers of configuration glue, you delegate everything to keycloak and configure multiple realms for multiple apps for any number of protocols through its admin portal. Yes, there’s some unavoidable glue code required to hook it up to your app, but considering the wealth of features it offers out of the box (user registration and admin, email validation), this is minimal.
Cheer up: the hard stuff is already done
In a language like Java most of the hard and challenging commodity stuff has already been done by people smarter than yourself. If you like implementing sort algorithms you can always choose a hip new language with a still embryonic ecosystem. A savvy Java developer should know when not to code. Some might bemoan that this degrades the art of building software to glueing together components, but I disagree. The necessary ‘forgot your password?’ page may be a valid use case, but it’s a commodity concern. It’s vital but repetitious and hence dull.
In one of my previous posts I stressed that you cannot explore enough. There is so much great stuff out there that can save you time if only you took the time to find it. It won’t always be love at first sight. Sometimes you absorb it just enough to realise it’s not your cup of tea. Other times you recognise the value, but don’t have a use for it in a present project. Maybe later, that’s fine. But you have to know it exists in the first place.