After discussion from [[2022-10-17]] # Pragmatic technology, not boring technology In [Dan McKinley :: Choose Boring Technology](https://mcfunley.com/choose-boring-technology), Dan mentions [[Python]], [[PHP]] being boring technology, and that they should often be chosen over newer technology with a smaller adoption base. He makes the equivalent of chosing a newer technology as "spending an innovation token". Links: - [Dan McKinley :: Choose Boring Technology](https://mcfunley.com/choose-boring-technology) - https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-here-syndrome/ ## Boring tech is not necessarily a great choice [[ZK - 2022-10-21 - Old technology is not better, often new technology is better]] - boring old tech can be quite bad - failure modes of old technology can be just as obscure as new tech - python performance - "old" boring tech has new releases as well, and reintroduces exactly the same issues - [[ZK - 2022-10-21 - Longing for "boring" tech is often nostalgia for the days when dependency chains were simple]] [[ZK - 2022-10-21 - Insisting on using "proven" technology closes you off to things outside your comfort zone]] - using "boring" tech indiscriminately closes you off to the things going on outside your comfort zone, and the incredible new improvements being made out there (either languages, DBs, tooling, development patterns) - for example, often following influencer tutorials to learn about new tools and gizmos - learnt about chromatic, storybook, vite, descript, bubbletea, vercel, next.js, replay.io - new experimental tech can be great if the engineers are fluent with it / know how to fix its internals [[ZK - 2022-10-21 - Deployment possibilities have changed significantly in 2010 to 2022 - cloud, storage, memory, edge]] - new technology can have a huge adoption base / installation base, even if it just came up on your radar - we are now moving at the speed of github and millions of programmers world wide - new tech with 500 maintainers and 200k hyped users will quickly overtake an old tech with 3 maintainers and 2M users, plus they already have a map of the things not to do / things that work - deployment environment of tech has significantly changed compared to when the "boring" tech was written. - autoscaling, hardware costs, edge computing, spot instance of huge clusters, etc... [[ZK - 2022-10-21 - There are many exciting problems as a software engineer besides... software and technology problems]] - using proven, pragmatic tech is exciting, not boring. It means you can focus your attention on solving the important, innovative problems. This means equally: - not solving obscure performance problems in a new DB - not having to wrestle with 20 year old tooling with an old language - technology paradigms / fundamentals are cyclical, and reasonably stable. Recognizing those can help chose new tech replacements for old tech parts and replace them properly [[ZK - 2022-10-21 - The best technology is usually the one that is already being used]] - the best technology is always the one already in use for which employees are available - align the technology choice on the teams and people you want to hire - pragmatic technology can be chosen for its tooling - there are lots of new technologies with great tools - lots of old technologies with abysmal tooling - Just the tooling itself can redeem a full innovation token ## Why do devs chase shiny in the first place? [[ZK - 2022-10-21 - Boring technology choices can be gatekeeping and alienating to developers]] - boring technology, especially "gatekept", is alienating. - "software architecture astronauts" of old is a thing - self-actualization: - learning is fun and exciting - we are creative, and want to solve new problems - new technology is a new problem - Maybe: [[Learning]] [[BOOK - Mindstorms - Seymour A Papert]] [[Convivial Tools]] - but there are many new problems that are exciting to solve with the current stack - focus from "creating a problem with technology" to "solving business problems / workflow problems / tooling problems" - learning is valuable not just for the company, but for the developer themselves - we play with shiny in our own rooms - don't encounter the pain of: - real life deployment and requirements - dealing with colleagues and communication - we chose the one that we like, so of course we like it - New technology is often encountered in the context of hype talks and success stories ## Why boring/pragmatic is better - less technology is usually better - when introducing something new, write a full plan on how to completely replace what it is supposed to replace, and don't stop before it is fully through. - full cleanup hard to pass by management, so be very careful about introducing new tech, because even with the best laid plan, you probably will be stuck with now 2 technologies - exciting is different for every person - pragmatic is ... more factual - chose how you can best achieve something without adding new tech - stability trumps elegance and speed - iteration speed trumps implementation speed > Having a good team that takes twice as long to build X because the tech is twice as bad, but has tooling and process to deliver and maintain quality solutions trumps a dysfunctional, hard to hire for team writing X in half the time, but proves to be brittle and problematic to run in production. > For example, a team of run of the mill react developers that use prettier, eslint, storybook, chromatic, redux, know how to work with a product manager and a design team, are probably a much better choice than a solo elm developer, as brilliant as she might be. On the other hand, building a webpage in Common Lisp with a rust microservice with my two old buddies with whom I can communicate at the speed of eye contact, might be exactly the right choice for that side- project we got hired for. ## What can we do [[ZK - 2022-10-21 - Discussions around technology choice should be reframed as technical strategy discussions]] - Transform the discussion from "technology choice" to "technology strategy." A choice is not permanent, is fluid and context dependent, and the real engineering happens in making and revisiting and improving on these choices. - A push for shiny usually means that there is friction somewhere, and this is the problem that needs to be solved - This can be, junior developers feel bored and alienated - Make the things that make people happy and excited about new technology happen with the existing technology. - Give back ownership and autonomy - [[Agile]] - [[Lean Manufacturing]] - make that happen with boring tech: - focus on making solving problems with the current stack exciting - better tooling for example? - involving developers more in the decision process - shift the focus from boring to "what are the problems we are solving" - lay open the fundamentals under the boring tech, because these are timeless - reactive programming - functional patterns - event driven architectures - concurrency patterns - learn new practices - faster feedback loops while developing - tools are crucial for new practices - gitops, chromatic, RFC process, etc... - introduce engineers to more holistic thinking: - how does a technology choice impact teams, product, deployment - can lessons and patterns be learnt from shiny tech and then applied ot the current stack - no harm in playing with prototypes in a different language and translate the lessons learnt - -> very valuable skill - hackathons - communication on improvements is key - RFC process - understanding why certain people are excited about a certain technology / what their motivations are, to see if they can be met in a different manner - Lots of new "patterns" can be actually applied to older tech - FRP, event driven, microservices, etc...