Oh my poor business logic
rednafi.com
rednafi.com
The more organisational layers you have between you and the customers - architects, business analysts, and the like - the more disconnected your work will be from the business value.
Incidental complexity it can be called. Problems outside of the core business domain or problem you are solving. Like, you can't get the data in the right format because your version of a DB library doesn't support it, something like that. I want the tools to get out of the way so I can focus on the problems.
I bring that up because I find certain ecosystems respect that a lot more than others. Some people are busy building Jenga towers of abstractions because coding is fun, but many of us are knee deep in the business domain and just want the tools be clear and easy.
Been there... never again. If I can't speak to the people that use the software, I'm out, period.
In some ways I respect their devotion to pure technical craft. Personally, I'm not talented enough at the technical aspect to make up for ignoring business needs.
Codemonkey doesn't want to be involved with all that shit.
What's that? We're three years into this six months project and you just realized again that you don't understand your own job, don't understand the legal requirements placed on you, nor your position in the overall organizational architecture? Of course we can rewrite everything from scratch for you, again. What do you mean there's no budget and it has to just work?
The Agile style user stories that often lack technical details because the author doesn't know enough about the technical details means the developer is the one actually writing the requirements (usually as they are doing the work).
It's much better to just talk to users and watch them work. A same-day feedback loop beats any improved study quality.
Totally agree. However be aware that there is a tradeoff. I have seen too many projects where business logic was informally embedded throughout the codebase. Such that only the original developer could make sense of it.
In every company I have worked for in the last 10 years, the layer in between business experts and software engineers has been always: the manager (either product manager or eng. manager). It's a bottleneck. The flow usually goes like this:
business expert -> manager -> engineers -> manager -> business expert -> manager -> engineers -> ...
Whenever the manager comes with "requests" from the business side, we end up with tons of questions because everything is half-baked. Manager goes back to business with our questions and comes back with some answers, but usually that just generates even more questions. In this way managers feel empowered. There's no way they can let the engineers just talk with business (otherwise the managers would feel like they are not contributing in anything... which is kinda right if the engineers are more or less professionals).
Ideally having a competent person acting as the middle man for most daily operations is desirable though
Outside of those managers, managers have been worse than useless. They’ve been an impediment to both me and the business (from what I can see).
So, in my experience, a good manager is worth every penny. All other managers are a net negative.
Reminds me of the "if apple built every feature requested" meme.
https://twitter.com/blader/status/1698369360581337399/photo/...
We would make one map from the info the managers told us and one map of the actual processes by talking to every single employee involved.
We frequently found critical processes no manager knew about and also that some random secretary was the focal point for entire departments (mundane processes no one else wanted)
I'd love to read a tutorial of how mapping every business process is done in practice. Do you have any pointers?
Other sources are any existing ERP or other business process system.
Paperwork of any kind (invoices, quotes, POs, accounting) can also be used.
Even if a business thinks they are a flat org and have few processes, I guarantee there are ad hoc managers/leaders along with shadow processes.
As opposed to saying, "Steve from Sales was on the call to a customer and they have this specific problem".
But what about software middle managers? What's going to happen to them??? Honestly, for over a decade that is how I worked on professional software project. I never saw the need of manager. And software development works better when there are NO middle manger just customer and developers. Of course I'm aware most developers don't care about the business logic.
Seem like management stuff in software is just for show. Corps are just trying to impose their process on software developers, which don't really work.
Medical software, for example, is ripe with examples of how programmers are completely clueless about clinical applications and implications of whatever they are doing. There's probably no other field where programming was misapplied as often and failed in such hilarious (and devastating) ways. For example, there's a lot of programming happening around various imaging modalities. Often you'd hear about programs that do X better than a radiologist. Only to discover that the programmers who wrote the program had no idea what radiologist was even doing.
Just at the start of COVID pandemic there were countless programs written to identify the virus in chest X-rays. A lot claimed success... while the clinical truth is that X-rays on their own cannot tell you if a patient has COVID, it's indistinguishable form pneumonia or a bunch of other things. The diagnosis must be made using labwork. Sometimes it's possible to be moderately confident relying on both X-ray and presentation, but not judging by X-ray alone.
Similarly, I had a chance to work on complicated budgeting and banking software. It was a joke how nobody knew what the hell the program was supposed to do and how the QA were driven up the wall by not being able to get reliable information from the partners about how certain aspects of the program should perform. Forget the developers, who'd at best got a written spec for their tiny fraction of the product and had no idea how it fits into the larger picture or what exactly it's supposed to do.
Sadly, a lot of programmers have this unwarranted confidence that they just need to read the problem description and they'll be able to program a solution for it. For complex problems that require a lot of expertise this, at best, results in solutions that are extremely convoluted and painful to use for the end user.
The pay is bad and developers are treated like commodities by the upper management. You are expected to understand all the context around building products and at the same time, chase deadlines in every sprint. This usually happens because the business people have no idea how to run a tech company.
Also, the products are usually fraught with technical debt and no one wants to work with the codebase because working on that crap for a longer period of time will just make them unemployable. Healthcare tech is garbage for a reason.
There’s a disconnect between product owners and the engineers working on the product. Smaller teams can usually avoid it if less cross team communication is required to build and maintain the product.
I'm a technical lead, business owner, and ex-manager. So I guess I qualify to answer :)
The short answer is that we have only ever had a very (very) small development team. Typically around 3 or 4 people.
Secondly we're using "old" tech, nut with up-to-date tooling. Our product contains code written in 1996 and iterated on since.
I'm lazy, and I'm not interested in writing it all again in some new language. So we haven't done that. I'm lazy, so I'm not interested in re-architecting it every 5 minutes. I'm lazy so i prefer simple, maintainable, easy to read, code over cleverness.
Most of all, as a startup (boot strapped) I didn't get paid in we didn't make sales. (That happened a lot in the early years.) So shipping is a priority. Business is a priority. But since I'm lazy I avoid solutions that'll break things, that'll cause unnecessary work in the future.
I have enough autonomy to dictate pace of delivery. I have enough incentive to move the business forward (in the short and long term.) I don't need to resume pad (this is the first ,and last, job I'll ever have.)
Alas none of this advice is transferable. What works for me likely won't work for you. Our context is likely too different.
So yeah, there are businesses in between the extremes. Ones with competent developers. Ones either competant managers. Ones where all the business interests are kept in balance. They are not easy to find. Good luck.
The sources of the depreciation are tech debt and general turnover/churn in the method and process within an industry/vertical (like if you built a web app in 2002 based on ASP.NET, it's pretty tough for that to be a lively project today).
We know there are systems out there that have been running well and doing their job for 30 years, and there are systems that need to be replaced/rewritten from scratch every couple of years. Which one do you want to buy/fund/budget for?
If the customer or stakeholder only cares about a two year horizon you approach the project one way. If they say they want this thing to be firing on all cylinders 10 years from now then we approach it and price or budget for it differently. When you talk like this it doesn't sound too weird to introduce the idea that we should do an annual tune-up to a system that they don't want to have to replace until 2035. The tune-up is how you get 15 years of life out of your intellectual property instead of 10, this is how you sell time to pay down tech debt. The eventual rebuild is also part of the discussion (not if it will happen, because it will. But when it will happen is something we can influence, so the framing can be, would you rather do an expensive rebuild every 10 years, or do it in 15-20 because you paid for a regular maintenance along the way?).
Boom now in their head this software you're writing is like a car. Everyone understands cars. A car has a lifespan. If you didn't go to the mechanic and do your annual scheduled maintenance and the car breaks down, that's what you get for being cheap. Like I said big ops and finance departments actually really like the idea of a tuneup that prevents the car from breaking down. They're used to thinking about that with lots of physical assets anyway. A marketing department at a startup maybe not so much but their time horizon is usually short anyway.
* 15 years ago no one expected their website to work well on a phone, or serve up much in the way of streaming video.
* 10 years ago no one was expecting that a server should respond in under a second, aka Lighthouse's TTFB, and the concept of say a "Largest Contentful Paint" did not exist.
We can go on forever, so what has happened is that all the practices and expectations within the industry have been redefined (occasionally even for good reason!). To stick with the car analogy, you don't expect much in the way of self-driving features from an older car... hell power windows didn't even become ubiquitous until the 1990s.
So maybe we just can't get a great TTFB and LCP out of our old dependency stack which existed before those concepts were really a thing, and there you have an example of why a rebuild will probably continue to be a "when" rather than an "if" for years to come.
Now we can frame the discussion as "let's partner up to ensure we make the best use out of this system and extend its life as much as is reasonable," which doesn't have to be an adversarial discussion.
He talked about how the whole thing relies on "boring" tech, like PHP.
Probably second only to Google, for hits per second. Uptime, robustness, and ease of maintenance were a really big deal. Very mercenary, and very practical.
Love this.
Personally speaking, the best place that I've worked at that mostly solved that balance, was Pivotal Labs. Technically, it was Cloud Foundry, but same people. The way they use Pivotal Tracker and the process around it was mind blowing. Unfortunately, it is really one of those things that you can't just read about and understand. You really had to be part of their culture. It was a cross between cultish and military precision. You can google around and read up on many blog posts. The PT documentation [0] spells a bit of it out too. It was intense, but I really enjoyed my time there.
[0] https://www.pivotaltracker.com/help/articles/gettingmore_int...
I was amazed. The Scrum master wasn't just some busy body manager who only ran stand-ups, he was constantly floating around throughout the day helping people out. We had 4 developers and 4 consultants, so we mostly paired up and that was super productive. Pivotal tracker was better than Jira. They had a strong focus on getting something working and collaborating. It was eye-opening.
Unfortunately, the company was picking 4 random employee developers from across the organization each week. Most of the organization was contractors, including everyone on my team aside from me. My team used Jira and had no option to use something else. Back on my team, the contractor Scrum master and contractor product owner continued to run the team incredibly ineffectively.
I can't tell if those few consultants I worked with were representative of Pivotal as a whole, but I will say that that week was a bright spot in an otherwise dismal part of my career.
I've heard some horror stories about Pivotal as well. Not everyone or every project was perfect. Their pricing is also insane. I'm sure your company paid through the roof for what you got.
But overall, the general education that I got there for how to run projects and build products is hands down the best thing I've ever learned in software engineering. It is funny, they don't teach that sort of stuff in schools as much as they focus on just teaching you how to code.
Oh and PT is hands down better than Jira, but that is a low bar since Jira is really shit. That said, it isn't necessarily about the tool, but how you use it. PT can be used for good as well as evil and knowing how to write stories, point them properly and manage them, is a learned skill.
I unironically love being distracted by other peoples problems. Usually the person giving me the work I'm really supposed to be doing gets annoyed at me for it, I'd love it to be my actual job.
In the End they couldn't change much of my company's approach to software development. Managers mostly want to be fast like a Silicon Valley startup only if it does not mean they need to change anything in the organisation. Anyway, years of semi-successful software projects are more likely to bring a change...
I've also tried to 'change' companies towards Pivotal process. It never really works. People are more than willing to listen, but when it comes down to the practice of things, it just doesn't happen for one reason or another. I think that is why Pivotal Labs works so well... everyone working there is already on the same page and sticks around for many years... and anyone who isn't on page, migrates out relatively quickly.
I think this is also a bit why 'agile' tends to get a lot of hate/fear on HN. You really have to be military and cultish about it from day one, like PL is. Few people are willing to buy into that. Even I was skeptical of it when I first started there and it took me a while to relax into it.
Oh god. I worked at Pivotal, and i saw something like this happen on one project. Four Pivotal Labs devs, four client devs; each client dev was with us for two weeks, so each week, we started with two new people, and two people with one week's experience on the project. Absolute madness. There was some weird politics, and i think the people running the project on the client side wanted it to fail, so this may have been an attempt at sabotage. The client devs were very sharp, and fully cooperative, so we did get some work and some training done despite all that. Common consulting L.
Next step is, of course, to extend the XML validation to make sure it conforms to your application's expectations. And suddenly you have invented a compiler as well.
I most certainly hope so. But I've been involved in extending a system as I described as recently as a few years back. Everything was supposed to be configurable (by no-code customers) and XML was the language of choice, so the XML was... complicated.
Since then the developers took over and killed waterfall and 4GL in the process.
There was one product really popular then, but forgot the name. Sorry.
A product I personally know is Oracle Designer. This could generate fairly complicate applications (like master-detail-detail layouts) based on the ERD.
Another product I also forgot it's name, was considered very good, but used only within the IBM ecosystem. Fun fact, I was the product owner for a project where the IBM team vastly outperformed the web team (think half the size, twice the speed).
This might not catch all the surprise requirements, but it might catch the worst ones.
A sure way to get surprised is to do the opposite:
- don't talk to the people who use your software, but some middle-men
- just take the customers first idea as gospel and assume they disected the problem space themselves
- keep everything constrained and never let anybody get wild or crazy with ideas
- don't anticipate potential future requirements and don't let them influence your decisions ever
Of course those things don't come for free, but it is important to realize that the initial phase of a project is crucial also for the impression your shop will leave behind. If people feel they have been heared and had a chance to come to a shared understanding with you, they are less likely to view your software in an unfairly harsh light later on. They will remember this and will hire you for the next thing.
But if your software managed to survive a decade of good use without any major issues I'd already count that as a job well done.
And for the unreasonable ones you can always say: "The system we originally intended wasn't meant to do this technically. If you want to have this feature we can help you but it will cost $X and this is a entirely new project."
If a graphic designer designs a logo and the customer in the end has the idea that they want that logo as a stamp or in a black and white version ANY graphic designer worth their salt will have anticipated this. If they want a 3D animated video of the whole thing rotating that is a different thing.
In one of the projects I worked on there suddenly came the requirement that they need metrics on how long people were working on different screens, completely unrelated to the actual business. No big deal in general, just put some code in some base class to collect the current time on enter and on leave. But the application framework we used just does not allow this, you can not modify the base classes used for screen, you have to add code for the enter and leave event on each screen individually. It just never occurred to the people that made the framework that you might want to do the same thing on all your screens and nobody expected that we might ever need this either, until we did.
So far, I've failed to verbalise exactly how I achieve that in my org, but it's a combination of strategies and tactics like timeboxing refactorings, setting new tech tryouts as experiments that you re-evaluate, iterative development, and recognizing that you are never getting perfect code, nor a perfect balance.
This is where I struggle as well.
You have to be working with people who are more interested in finding the best outcome for the organization/team/people than the most convenient decision for personal or political reasons.
AKA someone needs to be able to push back against "we'll rewrite it in Rust to reduce our technical debt".
For what it's worth, I shy away from the term and talk more about approaches and outcomes. It's still baffling when I give a project manager the options:
1. Rewrite and have a working prototype in 2 weeks and solid product in two months. We will be able to use better tech, learn some new things, and the product will match the feature needs.
2. Refactor this month and get the feature you want in a couple months after that. We won't learn as much, but we'll have a cleaner technical product and we'll get some features.
3. Try to implement the feature now. It will be late, broken, and other features will break. We will spend all of next quarter patching it. We won't learn anything new. It will slow us down on the next feature.
It's always #3.
That said, for those who do good work and develop long-term trust with long-term colleagues, addressing technical debt is often “poke at this while I sip coffee” work that get chipped away at gradually and without a lot of paperwork, or that gets quietly slipped in alongside other feature work.
When you’re having to pitch the work to someone, you’ve often already failed the pitch. The debt payment is already due.
But if your peers come to trust you, then they learn not to reject a PR that cleaned up this module a little more than strictly necessary or that included a commit that revisited an adjacent abstraction.
To get there, though, you need to work on healthy, stable teams with experienced colleagues rather than in the mad churn that seems to dominate a lot of work cultures these days.
Damn that stings and it's so true.
> But if your peers come to trust you, then they learn not to reject a PR that cleaned up this module a little more than strictly necessary
I've never had an issue where a coworker rejected a PR, even when doing a massive refactor that isn't strictly necessary.
Project managers are the ones that don't see this kind of work and it's benefits. They're the ones that I find it hard to build trust with.
As an engineer, I have rejected massive refactors in unrelated PRs: heck, I have rejected massive PRs period.
They always:
- are hard to review
- bundle a bunch of unrelated changes together
- hard to accept piecemal
- risky to test and deploy
- hard to revert
- hard to pivot according to new learnings along the way
- hard to improve
- have lots of review iterations
- slow down all the other work (conflicts, remerging effort for all the other changes in flight...)
- usually "one way doors" (relates to hard to revert)
When these are done as small incremental steps where we improve one thing at a time, none of the above hold, and coupled with a good CI/CD pipeline, take less time.
I know that many engineers believe there are things that can't be done incrementally like that, but I've always been able to give them a plan for any "impossible-to-split" refactor/rewrite.
Offering #3 is absolutely not a business or management problem, this is something you are doing wrong.
I'm not sure if you could ever see management as the problem.
Obviously, the risk here is that you include non-neccessary refactoring work in it, and then people stop trusting you.
And finally, there is a hack-it-together approach, but I always try to keep that outside the core product to make it clear this is throwaway effort (if you can have another deployment, that's ideal).
But honestly, it is engineers job to find that hard to reach balance: keep improving the code, and keep delivering value.
That's the hard part of software engineering, and we should all embrace it.
Sometimes it's too much work to do ad hoc. Oftentimes people won't go out of their way to refactor. Having the fair discussion can make it real and important.
If the team can't talk about refactoring, it's an unhealthy team. Managers who want to act like maintenance of a project isn't something that should ever be their concern don't deserve a paycheck.
> But honestly, it is engineers job to find that hard to reach balance
This attitude is bullshit. It's everyone's job. High level balance is more of a concern for management. Low level balance is the more of a concern for engineers. High and low level balances can work for or against each other. Management that just pushes their responsibilities down the hierarchy aren't pulling their weight.
Sure, it is everyone's job and they should certainly openly talk about it, but no manager can go and do it for an engineer.
A great engineer can find an incremental value with any refactoring they do: otherwise, they are extremely likely to refactor for the wrong future. I've seen this play out a number of times.
And the root cause is always exactly the same: engineers can't design code for the future that's not here today or at most, tomorrow. When they think they've done it, a new future comes and that code is even harder to refactor because it prematurely catered to cases that never materialized.
But that's exactly why managers need to understand and accept that refactoring is software engineering, and engineers need to do it continuously and keep delivering value while they do it.
And while CTOs, Eng Directors, architects and technical leaders might be "managers" in a sense, to me they are still all engineers, and they are the ones ensuring technical direction enables a healthy project while satisfying business goals.
Non-technical managers are there to bring clarity to business requirements, but they don't need to know exactly how sustainable technical excellence (or at least health) is achieved, the same way engineers don't need to know how user research or user testing that proves something works or not, is performed.
Theoretically someone who understood both the business and the technical side of things ought to be able to weigh up individual tasks from both sides and figure out which was higher priority. But in practice that seems very hard - you'd need both intimate knowledge of both domains and immunity to organisational politics. Explicitly adjusting that high-level dial (so maybe the 25% becomes 50% when it's a codebase you want to publish/reuse, or 0% when it's an EOL project that you're just running until it falls apart) might be the best you can do in practice.
We called it “product health” so it could encompass tech debt but also UX debt, performance, cosmetics, etc.
So in reality, it's not "technical debt" that's the issue, it's that engineers don't have the right incentives from the beginning.
I can't count the number of applications I've seen that have no clearly defined "place" for business logic. So you see it buried in views, state management, persistence, databases (I'm looking at you, Postgres functions and stored procs), services, controllers ... anywhere and everywhere. Impossible to test, impossible to reuse, waiting for someone to extract and isolate it but no one seems capable of even recognizing it for what it is.
I think if you were to ask 100 developers to define "business logic" you would get 100 different answers. That's the first problem to solve.
to have a sacred place for business logic it'd require a nice interface, maintaining that has an overhead compared to "can't we just intercept the request at ... "
I'm not claiming that FP is always the answer, but it's a great technique that somehow is still very under-utilized despite being enshrined in popular frameworks like React (I think). I don't mean to criticize developers who are unaware of FP - I graduated in 2008 but didn't learn FP until 2014, and I still can't believe that I was ignorant of it for so long. And I can't believe how many developers are still ignorant of it. Unless I'm wrong and FP actually sucks, there is an education problem.
Those 10 developers might have a decent answer to the question "Where should business logic live?" (decent depending on other design considerations).
But that does not answer the question I asked them, which was "What is business logic?"
I could probably handle the “bleh” of our industry if I didn’t have to bathe in it. Even 40 hours/week seems like too much, and why do I have to pretend I work 40? Just pay me less and let me go yellow on Teams at 1pm every day.
Yes, you’ll have to find clients. No, there is no perfect alternative to the “sweet six figures”, something’s gotta give, but you gotta start somewhere
Durable systems are gone. Longterm support is 12-18 months. Iterate or die is how it works now, I guess.
The best things I've done are the things I've never told management about. I make something, it works, people use it, and I don't have to touch it again for years. When I do, it's a minor change that takes 5 minutes. Anything coming from management is a multi-year project that requires hundreds of hours of meetings and at least 60 devs across a dozen teams... all to make something that 1 person could do in a few weeks if they were left alone and didn't have to conform to their overly complex frameworks.
This often means adopting some sort of overarching architecture that nudges people towards composable implementations. For write-heavy, highly stateful systems with complex business logic, this means using something like a workflow engine where you can simply declaratively add tasks and conditions to pre-existing DAGs while being confident the existing workflow will not fundamentally change. To create new functionality, it's often enough to use existing functionality as a drop-in template. Duplicate and add / remove - no need to worry about what's there because you're not touching it.
For read heavy systems thinking about composition at the very highest levels is also very important. This allows engineers to easily add functionality without being concerned about breaking what's already there.
Always favor additive models over models where updating existing functionality is the norm. This means junior engineers can "color within the lines" so to speak, and the risk to the rest of the system is low.
Would also emphasize that while unit testing is often useful for the individual developer working on a piece of code, but as far as ROI, end-to-end integration testing has the most bang for the buck. If you have the full endpoint tested, for instance, from end-to-end, including database writes, your confidence level goes up by an order of magnitude when you have to modify that functionality. If you have to choose between investing in extensive unit testing and extensive end-to-end API or contract tests, always choose the latter.
It's not so clear-cut, unfortunately. Extensive end-to-end tests can be very hard to setup, can be flakey, can take forever to run (especially if you do it on every change), etc.
I agree you should have some layer of automated end-to-end testing (and not enough people do), but in the end, I think you have to work towards making the system as compositional as possible, so you can also test things extensively in isolation - the end-to-end tests then serve to make certain that the individual pieces fit together, but don't hit all the edge cases.
Beyond that, you haven't addressed the fact that a comprehensive end-to-end test suite in a complex system is really, really slow.
Our API tests run flawlessly every time because they write against an isolated database with well-defined endpoint and messaging contracts. They also execute all remote operations against a mock API that conforms to those contracts. This is perfectly achievable.
To me it's a classic tradeoff: the more you integrate in your tests, the more meaningful they are - but also the harder to write and maintain.
Most companies I worked tend to oscillate between these two extreme:
- why can’t we get anything done quicker? We need to stop refactoring everything all the time!
6 months later:
- why is everything breaking all the time? Why are engineers complaining that the code is shit? We have to stop and start again on cleaner bases.
6 months later:
- why can’t we get anything done?
One has to realize that this is how it works, and be at peace with it.
If you are see that your organization is too chaotic, you should put some structure and discipline in place to curb the tech debt and chaos. You’d be surprised by how far adding in basic listing and teaching the team to use it will get you. You can add automated testing after that, and move on to other initiatives.
Similarly if you are in a resume-oriented development organization, bring attention to business outcomes through little initiatives. Make your engineers attend at least one sales or support call per month. Explain the company budget. Show the true costs of going with the flavor of the month.
You can foster change bit by bit. Things will get more balanced if you continually do it.
It is tough though. You are fighting a culture battle. Changing peoples mindsets and habits is a long process. You won’t get overt support and you won’t see immediate results. But it’s worth it.
https://sigops.org/s/conferences/hotos/2023/papers/ghemawat....
A good DI implementation allows for one to define these business services as interfaces and implementations within an initial monolith, and then trivially reimplement those interfaces against an API or RPC when it comes time to scale. Interfaces can be separated out into a common library which can be referenced in all parts of the system. I am simply curious as to why this has been so staunchly avoided over the past decade of microservices hype.
The purpose of an organization is never simple. From Hebert Simon's <Administrative Behavior>:
> The survival and success of organizations depend on their providing sufficient incentives to their members to secure the contributions that are needed to carry out the organizations' tasks
Unfortunately companies tend to throw people at the problem, so you get 10+ sized teams where 30% at maximum do any productive work, because the rest is either too caught up in their personal lives or too junior to pull their own weight.
I've been both part of that 30% and the rest in different projects and I've managed to flip one dev to the better side once, so it's not typically an inherent feature of a person.
I'm not sure when Kafka was last considered hip. Probably 2015?
Also, Celery is arse to maintain, so if you're already using Kafka, make the change.
If you're not, then don't.
It's sort of sad and funny to see people pushing for organisational change through new internal applications deployment or new procedures and workflows, without ever tackling the human interaction factor.
I was one of these developers until I saw how my shiny decisions to failure. But it's a tricky problem with good devs who have not learned that lesson, as you don't want to lose them.
I'm forced to sit back and admire a sentence that's as well wrought, funny, and true as this.
They certainly never heard of MACH Architecture and headless CMS.
In the opening paragraph, the author describes one work style that’s on the verge of seizing up, and sets it against a work style that apparently produces nothing of business value at all?
They then work to criticize the latter as impractical, even though it’s just an imaginary business archetype that couldn’t possibly exist.
The reality is that most operating workplaces are already situated somewhere in the middle, navigating some version of the compromise the author spends the rest of the essay trying to lay out.
If the author is earnest and really worked at places that appeared as paralyzed as their strawman archetype, then either the business was already evaporating as they were hired into it or (more likely) they didn’t really understand what was going on and probably don’t have the insight to be writing about it.
In your example, it’d be like continuing the essay to argue that people should really try driving like they were just in a plain old consumer car. The thing is: that’s essentially what everybody is already doing in the real world, and so you’ve not contributed anything with your argument.
I think this is a bit uncharitable. Yes, nominally everyone is trying to do this, but in practice this comes down to a lot of tradeoffs in terms of timeframes, team sizes, and maintainability/scalability. Even if you have balanced perspectives, what usually ends up happening in larger corporations is some group has a louder voice and more power, and ends up influencing decisions in a way that is globally suboptimal because executives are too busy, and local managers are too focused on their own silos/perf evaluation.
For example, complexity is often built into the product and systems according to the resourcing allocated to a particular problem at a certain point without a full understanding of the implications over time. However, when that complexity is found to have a poor ROI there is then a natural aversion to removing it because at that point it's hard to quantify how exactly the business depends on it. This creates a tax on the entire org, which many can observe, but structuring incentives to fix is fiendishly difficult, especially in comparison to new growth opportunities that get executives, board members and investors excited.
That's only true if you struggle to understand ideas vs expression.