We're so obsessed with novelty in our industry:
- front-end folks want to work only with the latest frameworks, and 'jQuery' is one of the worst insults
- somehow the biggest problem with all the APIs is that they are RESTful, not GraphQL
- the traffic from all the 20 users per minute that use your platform in peak has to run on containers deployed by auto-scaling, massively scalable container scheduler with dynamic server-side discovery
- even the work planning and tracking has to happen via sleek, lightweight 'visual collaboration space', because you know - Jira is so 90s
And well, that's OK.
New tools are cool. We like learning new stuff. New toys sometimes reshape an approach to old problems in an interesting way, providing new perspectives. Besides, this new stuff has already worked for someone - a successful startup or even a hundred of them. Learn from the best and use what they use, right?
No, this is not a post about cargo cults. I have something else on my mind — money.
Where's the money?
You're all probably familiar with the concept of technology adoption life cycle. If you're not, I strongly recommend you to read "Crossing the Chasm" by Geoffrey A. Moore - you'll thank me later (btw. that book was written in 1991! oldie, but goldie!). But if you need a quick primer, feel free to check my old blog post here.
Done? Brilliant, let's go on.
While definitely there's a lot of exciting things going on in the 'innovators' sector, there's a massive, money-stuffed potential in the thickest part of the bell curve - early majority and late majority. Why so? These companies may not be the galloping startup unicorns, but stable, grazing enterprise rhinos - however, they are also the ones who:
- have massive code-bases they have to live with
- have made a lot of technical/architectural decisions that are not easy to revert or even evolve
- had time to scale - tech-wise but also product-wise and org-wise, hereby gaining a lot of inertia
- well, they have succeeded - they survived, so they are profitable (have money!), instead of burning through investors' money
Their (rhinos') problem is that the world doesn't care about their specific (rhino-ish) needs. The community tells them to be like startups (who are 1% of their size and 1000% of their velocity) - i.e., use tools/practices/methods invented and optimized for startups. That obviously can't work because of zillion reasons (that may take years to fix OR be not fixable at all - practically speaking): tech debt, process debt, org structure, etc.
Do you see that? It's actually a bit crazy:
- the development of modern-day tools is driven in 99% by building NEW STUFF (instead of maintaining what's already existing)
- new tools, methods, approaches are tailored for the needs of small, rapidly moving organizations but only until they grow because of their own success ;D
- and there's a relatively little focus on effectively working with whatever's already running (and presumably - brings proven value, and money $$$)
Rhino-oriented development
Frankly, if I were to start building tools for other developers - frameworks, libraries, services, dev tools, etc., I'd definitely target 'the rhino zone'. Examples? Here you go:
- Task tracking tool? Totally, but instead of a single board aimed to work with trunk-based development: nested hierarchy of programs and projects, with stakeholder 'point' budgets, quarterly scope committees, and other such abominations (justified by the complexity and scale of those orgs).
- Front-end? Hell-yes. 'Pimp my jQuery' bundle: modern styling (support for various customization mechanisms), state management, even some jQuery app skeleton, e.g., compatible with React's router (to make the transition possible in future).
- Back-end? Purpose-build static+dynamic analysis. Instead of useless metrics and messed-up graphs, visualizations and hints aimed to dissect, carve, separate, and decompose (into coherent modules, not microservices). Obviously, it'd have to be language/platform-specific, but (as we're speaking about rhinos), JVM and .NET sound like good picks.
Maybe, just maybe, there are plenty of tools like that already available, but the information about them doesn't get into my 'info bubble'. That's entirely possible - feel free to let me know if that's the case. Because I can't help the impression that we've got used to building 'append-only' software with the re-write as an only way to fix problems.
It's scary, but this madness also sounds like an ample opportunity. The world is running on software (more and more of it) that also grows old - all the feasible ways to simplify its modernization, or at least decrease its maintenance cost, can be turned into billions-worth businesses.
