Programming

Enterprise programming 2023 edition

Back in the Naughties there were Enterprise Java Beans, Java Server Pages, Enterprise Edition clustered servers, Oracle databases and shortly thereafter the Spring framework with its dependency injection wiring. It was all complicated, expensive and to be honest not much fun to work with. One of the appeals of Ruby on Rails was that you could just get on an start writing a web application rather than staring at initialisation messages.

During this period I feel there was a big gap between the code that you wrote for living and the code you wrote for fun. Even if you were writing on the JVM you might be fooling around with Jython or Groovy rather than a full Enterprise Java Bean. After this period, and in particular post-Spring in everything, I feel the gap between hobby and work languages collapsed. Python, Ruby, Scala, Clojure, all of these languages were fun and were equally applicable to work and small-scale home projects. Then with Node gaining traction in the server space then gap between the two worlds collapsed pretty dramatically. There was a spectrum that started with an inline script in a HTML page that ran through to a server-side API framework with pretty good performance characteristics.

Recently though I feel the pendulum has been swinging back towards a more enterprisey setup that doesn’t have a lot of appeal for small project work. It often feels that a software delivery team can’t even begin to create a web application without deploying on a Kubernates cluster with Go microservices being orchestrated with a self-signing certificate system and a log shipping system with Prometheus and Grafana on top.

On the frontend we need an automatically finger-printing statically deployed React single-page app, ideally with some kind of complex state management system like sagas or maybe everything written using time-travelable reactive streams.

Of course on top of that we’ll need a design system with every component described in Storybook and using a modular class-based CSS system like Tailwind or otherwise a heavyweight styled component library based on Material design. Bonus points for adding React Native into this and a CI/CD system that is ideally mixes a task server with a small but passionate community with a home-grown pipeline system. We should also probably use a generic build tool like Bazel.

And naturally our laptop of choice will be Apple’s OSX with a dependency on XCode and Homebrew. We may use Github but we’ll probably use a monorepo along with a tool to make it workable like Lerna.

All of this isn’t much fun to work on unless you’re being paid for it and it is a lot of effort that only really pays off if you hit the growth jackpot. Most of the time this massive investment in complex development procedures and tooling simply throws grit into the gears of producing software.

I hope that soon the wheel turns again and a new generation of simplicity is discovered and adopted and that working on software commercially can be fun again.

Standard
Software, Work

Generating corporate welfare through enterprise software

It is always good to have someone on the inside and therefore service software companies often go to great lengths to woo potential champions within large organisations. That’s the way things are but there is an interesting phenomena that takes this too far and I call it “corporate welfare”.

Companies often like to tote how configurable and adaptable their software is. By using just a few web screens or maybe a set of configuration files you can make the software do whatever you want. How convenient! Or rather how convenient for the suppliers. How many of you have ever had a burning desire to tinker with your email system setup, or your bug tracker’s workflow or the permissions of your project management software.

Probably no-one except the product champion who argued for the software to be introduced in the first place. In fact the champion’s role in the company is now predicated on their expertise with the existing solution. What incentive do they have to replace or review “their” section of infrastructure? Their salary is now based on how effective their relationship is with their supplier.

In fact I don’t think it is uncommon for people changes to precede changes in software providers. Someone has to take over the champion’s job of massaging the product and without the massive personal commitment to it finds the job cumbersome and undesirable, sparking the search for solutions.

My argument would be that if you cannot primarily use a solution out of the box then you are better off not using it. If you have a business process that requires a lot of gnarly configuration and bespoke software work then the greater value is in simplifying the business process rather than recreating in software.

In my view complex or whitebox products are more about capturing customers than serving them and that goes from SAP down to JIRA.

Standard