Developers can focus on the business logic when they're close to the business. Look for places where you sit close to the business people, talk to them a lot, maybe even talk to customers. Where you're part of a team that has a responsibility of delivering product X to customers rather than a team that has a responsibility of doing things that use technology Y.
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.
> 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.
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).
When I worked disaster recover and continuity, we had to map every business process.
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)
You start with any documentation they already have (usually done for insurance or legal reasons) and start mapping much in the same way you would map data flow in a program.
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.
Well, being the middle man is kinda the manager job. The situation you describe happens when the manager does a poor job and is both submissive to the business requests and unable to comprehend technical issues.
Ideally having a competent person acting as the middle man for most daily operations is desirable though
This is it. I have had a few really good managers in my career. They were game changers. When they came to me, they’d really done their homework and thought about the problem, or they hadn’t done it at all and were handing it off to me and giving me the contacts and support I needed to do my own research and own a thing entirely myself.
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.
In a lot of organisations the business side isn't necessarily incentivised to talk to tech, which causes a lot of issues. In good places, it's different and the development cycles work really well with an engaged business side. You still might want some manager in there to manage demands, conflicts, resources, etc.
Agreed. There is a role for a good manager to filter ideas from the business side and make sure all asks are building towards the products future. If the funnel is "sales people => engineers" you're likely to get a lot of spurious development that doesn't make the product better.
Reminds me of the "if apple built every feature requested" meme.
You'd think this is non-controversial, but have worked at places where product and UX act as gatekeepers and don't want engineers involved with the problem solving. They'll "figure it out for you" and then spoon feed Jira tickets and Figma mockups to devs.
I've experienced this too at a bigco. A well-meaning group of UX people took on the role of conducting all user observation studies. And the studies were high-quality and statistically valid, but it took months to get observations I could have seen directly in minutes. So the recommendations were mostly about things I'd already fixed or changed.
It's much better to just talk to users and watch them work. A same-day feedback loop beats any improved study quality.
I also agree that I prefer to work this way, but it's crazy to see how many developers have an "I just want to code, I don't want to think about business problems" mentality.
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.
Often it's because getting involved on the business side means doing a lot of politics. Is this problem more urgent than that problem? Who will take credit for solving this problem? If I solve this problem, will they fire half the people who currently solve it manually? If I solve that problem, will it empower a certain scumbag VP who's been clamouring for it? Etc etc.
Codemonkey doesn't want to be involved with all that shit.
I don't think GP means getting involved with business side decisions, just understanding the "business logic". Where "business logic" is a generic term for anything, it could also be the rules of a sport, how the competition(s) are structured etc. if you are building a sports website...
Requirements engineering can be extremely draining regardless of it.
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?
My biggest frustration is the people who refuse to get involved with any of the process of defining requirements, but then when the requirements arrive moan about how they're stupid requirements and won't get the job done. You can't have it both ways.
It's because defining requirements is someone else's job, so if you get involved, you will be doing part of their job while you might already be working at your capacity.
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 boggles my mind how someone can think they can build anything useful without having a basic understanding of what the thing they are building will be used for... that's a sure-fire way to software that will be a nightmare to use (and support).
I really like that “X vs Y” example. I was just on a team where we were estranged from the business folk who would supposedly be using our products and it very much felt like a “Y”, where my boss cared much more about the tech stack than the value (if any) we could deliver to the users. Suffice it to say the team was cut in a round of layoffs. I had fun working with things that I normally wouldn’t work with (eg Neo4j) but to me surprise it was very demotivating not feeling any purpose behind what we were building, tech stack be damned.
I have come to not care much about the tech stack, I work with all sorts. But by extension I grow weary of of dealing with technical problems that are only tangential to the business problems.
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.
Well said. Every opportunity I’ve had in my career, as an engineer, where I get facetime with customers has been a good use of time. I usually come away with a better understanding of their needs, new ideas, or take back issues to my team to investigate.
> 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.
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.
Where I've seen this problem to be the most acute, it's not because of organizational disconnect -- it's the lack of domain knowledge on the part of the programmers.
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.
Until very recently, I used to work in the healthcare industry before switching to a different one. I only got into it because it was hip during covid, until it wasn’t.
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 work in consulting and corporate dysfunction is how we make money. The disconnect between "business" and "IT" is at the core of most of these engagements. Because of the relationships between funding and ownership, the relationships often become downright antagonistic. In the latest example, we were working with the IT side of a company trying to get connections to the business side because we know that solving those sorts of issues is the best path for real improvement. During this process the business went out and hired their own consulting company to work on things instead. It's absolutely insane what happens inside of multi-billion dollar companies.
>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.
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.
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.