Underestimating "Enterprise" development
Always remind yourself that enterprise or corporate development is not boring and stodgy, rather impressively tough to do well.
A topic that is consistently running across my mind is that my resume is chock full with “enterprise” development. And in some of my experience, including now, that enterprise development was ingrained into a SaaS product. I can confidently say, if you’re interested in real, long-lived, profitably sustainable products, it is in the enterprise you’ll find them. And what is more important - they’re harder to build and require deeper skills than most.
You might be painfully aware, the tech industry is going through some tough times. However if you really pay close attention, most of this drought is in very specific kinds of software companies, and they’re not enterprise.
So it’s fair to see the current state of tech as a drought. But I think this is misguided for anyone who’s impacted by layoffs, looking for work. Enterprise is not cutting back as hard as most, generally speaking, and is a domain ripe for a fresh perspective.
Healthcare, Education, Finance, and Insurance industries all have software development going on in both customer facing and internal employee facing ways. And more importantly for these industries, their software is not simply required, but if not done well has impact to more than just revenue and profit. (for the moment I’ll skip the democracy killing potential of other industries)
Therein is the additional complexity that a software developer will experience in the enterprise. Building the product, delivering it to the intended audience, and then pass the SOC2 audits, tight security protocols, and approved and validated business continuity plans, with clear and infallible data resiliency plans.
All that to say: Enterprise development is not a stodgy, boring, and insufferable job to have. Rather it’s where your skills can be honed and challenged. Do you feel you have the skills and experience to handle all of the possible ways software can go bad, and have the business quite literally be dependent on “going bad” is not an option? Do you have the constitution to contribute to a product that has thousands of components, handling billions of transactions a month, in which if there are just a few hundred errors, you are capable of monitoring and tracking all of them to some form of reconcilation. All in the name of “5 nines up-time”?
There’s the rub
Enterprise development is polluted with ineffective process. Have no doubt, some of the process is required in order to achieve those qualities listed above. Some companies have rigorous change management process, and that’s directly related to the data resiliency and business continuity goals. Other companies have business demands that limit feature changes, such as reporting, billing, and storage compliance, where if anything to the software changes, even in the slightest ways, it could have calamitous effect to the business for regulatory reasons.
Take this very small example: SEC updates WORM compliance for broker-dealers.
Seriously, go read that article. Did you notice it said that since 1997 broker-dealers were required to maintain all their data in a “write once, read many” way and that it was immutably stored? When you read the article did you giggle and hold a bit of mockery in your thoughts? Fair enough. It is 2023 now and … wow … if we’re still dealing with CD-ROM storage of our data, then we’ve got a long way to go. But seriously, in your current job do you have to worry about this complexity, and the standards in which you save your data? Or are you currently fighting over the state of JavaScript?
Tooling
The enterprise development environment is littered with tooling that purports to improve the process for building software but quite literally doesn’t. And this in my observations is what prevents most developers from entertaining the idea of working for an enterprise company. It’s come to be a stereotype, for a while now, and I believe that should change.
So in order to avoid under-estimating the enterprise development demographic, Attainable will be working to build a new tool for software development, intended on fixing all of the things wrong with the tooling that exists today - but also more importantly the stereotype that has existed for so long.
Here is the pitch:
Don’t measure developer productivity, measure the product’s productivity.
Attainable believes there is a way to incorporate all of the industry leading practices into a new software development tracking tool that doesn’t make life miserable for everyone involved. There is a new fleet of tools coming to the market and the future is bright. Enterprise software is dense with interesting, challenging, and mission-critical problems, so why not make it more approachable? Attainable is starting to work on a new tool for Enterprise development that will help improve developer experience. Stay tuned.