12 ms·

Oh my poor business logic

258 points by nalgeon 3y ago

necovek 3y ago
There is no "perfect balance", but you need tech leads and PMs to understand that you are aiming for a balance where your tech debt is under control and you are continuously and consistently delivering business value. 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.
- ecfi 3y ago
  > So far, I've failed to verbalise exactly how I achieve that in my org This is where I struggle as well.
  - NAHWheatCracker 3y ago
    It's often not a matter of verbalizing if the decision makers don't want to believe what you're saying. 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.
- simonw 3y ago
  An interesting challenge I've found with the term "technical debt" is that engineers can use it as an excuse to work on all kinds of things that might not genuinely be paying down technical debt, taking advantage of situations where the people making the prioritization decisions don't have the hands-on technical experience of the codebase to evaluate if the proposed "improvement" is a good investment of effort or not. AKA someone needs to be able to push back against "we'll rewrite it in Rust to reduce our technical debt".
  - NAHWheatCracker 3y ago
    I've been quite frustrated that the term "technical debt" is so misused. It feels like project managers immediately assume technical debt means "the developer wants to play around". I only use it when it means "the features you want can't be implemented, correctly, and under the time constraints". 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.
    - swatcoder 3y ago
      Some of this is a product of job-hopping culture and of having boom-time teams (technical and management) with too many early-career members. Some of it is also just the perpetual back and forth of competing interests. 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.
      - NAHWheatCracker 3y ago
        > When you’re having to pitch the work to someone, you’ve often already failed the pitch. 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.
swatcoder 3y ago
It never bodes well when an essay opens with a strawman. 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.
- deleted 3y ago
  [deleted]
- chefandy 3y ago
  I think the author was using hyperbole to illustrate two problematic organizational tendencies. I could say something like "I see two kinds of drivers in the northeast: ones that drive like they're fleeing a bank robbery in a stolen police car and others driving like they're piloting a parade float carrying a human pyramid." I think it's obvious I'm not saying literally all drivers in the northeast fit into one of those two categories, rather, I'm setting up the scene to talk about two extremes in a common premise.
  - swatcoder 3y ago
    I’m sure that’s what they were trying to do, but their argument only carries weight in the context of those hyperboles. 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.
    - dasil003 3y ago
latchkey 3y ago
> There must be a middle ground where developers can focus on the core business logic that yields the most value without incurring technical debt and making the development process a nightmare. I don’t have an answer for that, nor have I worked at a company that found the perfect balance. 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_intro/ https://www.pivotaltracker.com/help/articles/gettingmore_int...
- NAHWheatCracker 3y ago
  I worked at a health insurance company 6 years ago where they brought in a group from Pivotal for a week and we worked with them to see how they ran a Scrum team. 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.
  - latchkey 3y ago
    The way Pivotal Labs works is that people who don't buy into the whole culture tend to migrate out pretty quickly. The ones that do buy in, stay around for a long time, learn things inside and out, and end up getting farmed out to places like yours. So you generally get the best of the best on consulting agreements like that. 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.
bruce511 3y ago
>> There must be a middle ground where developers can focus on the core business logic that yields the most value without incurring technical debt and making the development process a nightmare. I don’t have an answer for that, nor have I worked at a company that found the perfect balance. Plus, I’m not a technical lead, manager, or business owner. So if you are one of them, I’d love to hear how you or your organization plans to tackle this 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.
- safety1st 3y ago
  As a dev turned entrepreneur one thing I will do when selling projects is talk to clients about software as a depreciating asset. While there are some limitations to the comparison this framing makes sense to business people in general, especially well with finance or operations departments, and can work with internal stakeholders too. 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.
cavisne 3y ago
There is a new paper out from Google which seems like an interesting approach to get out of microservice hell https://sigops.org/s/conferences/hotos/2023/papers/ghemawat.pdf https://sigops.org/s/conferences/hotos/2023/papers/ghemawat....
- yeswecatan 3y ago
  This is an interesting paper and one I would never have found on my own. How did you come across it?
  - cavisne 3y ago
    Twitter, I think it is pretty new. The lead author is a very well known engineer.
- nvella 3y ago
  I've only read the abstract, but hasn't this been achievable for at-least the last twenty years with dependency injection? I've seen time and time again developers conflate microservices with the general concept of service abstraction and separation-of-concerns. These things have existed before microservices, and will continue to exist. 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.
  - ajkjk 3y ago
    This isn't really DI. From skimming, it is sort of.. cross-machine DI.
EdwardDiego 3y ago
> while juniors want to ditch Celery for Kafka because the latter is hip. 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.
- rednafi 3y ago
  Kafka is great. Problem is that the celery system is working just fine and there are higher priority tasks rotting in the backlog.
john-radio 3y ago
> Raking in absurd sums to tweak linters or buttons may not be the worst thing in the world, if it also didn’t lead these bored people to dream of becoming architecture astronauts by introducing absurdly complex tools to solve imaginary problems. I'm forced to sit back and admire a sentence that's as well wrought, funny, and true as this.
lmm 3y ago
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.
- captainkrtek 3y ago
  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.
- gymbeaux 3y ago
  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.
  - ehnto 3y ago
    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.
giantg2 3y ago
I hate both types of organizations. I think I hate the rapid tech switching even more than the business focused one. There's a lot to hate about languages like COBOL, but honestly it looks awesome create neat code with actual documentation and design documents, that will just work for decades with minor upgrades and changes. Durable systems are gone. Longterm support is 12-18 months. Iterate or die is how it works now, I guess.
- al_borland 3y ago
  I see no point in automating anything if I'm expected to re-write it every year. If they are going to pay me to do that, they might as well just pay someone to do the work manually. It would probably be faster and cheaper than the illusion of time savings we're getting from reimplementing the same solutions year after years against our will. 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.
gymbeaux 3y ago
I’m on a sabbatical because I find myself very jaded by the industry, more or less for the reasons stated in this article. What I tell people is something like “I LOVE building stuff with code, but lithe EVERYTHING ELSE.” Writing code may be better suited as a hobby for me… after all, I have the most fun with side projects… but then, as most of you can probably empathize with, how will I make the sweet, sweet six figures? I’ve looked into being an AWS Solutions Architect, but they want someone with more sales experience (???). You’d think it would be the other way around, that’s certainly what we wished for when interacting with them as “customers.” It was always “hmmm, good question, let me get back to you on that” with the equivalent of LMGTFY in my inbox days later like that wasn’t the first article I read on the topic. Anything else so far feels like a waste of my talent (“talent” - I mean I don’t want to be installing Microsoft Office on people’s computers or replacing ink cartridges). 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.
- granshaw 3y ago
  Sounds like freelancing/consulting might be right up your alley. Maybe building mvps or working on relatively new products or codebases. Charge for your time and no pretend work. 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
  - gymbeaux 3y ago
    Yep, I’ve done some freelancing over the last few years. I like it, but it’s hard to do that and a full-time job at the same time. Obviously the issue is getting enough work when you’re not normally employed, and when you are normally employed, the issue is not getting too much work. Clients like stuff ASAP and telling them an MVP will take 3 months because you’ll only be working on it 8 hours/week doesn’t go over well. The clients I’ve had are understanding but they all eventually want me to quit my job and come work for them, either as FTE or still a freelancer.
jonathanlydall 3y ago
The startup (bootstrapped, non-US based) I work for creates a developer productivity tool which gives you high quality architecture “for free”, allowing you to instead focus on those bespoke un-automatable business rules. We essentially aim to solve the author’s stated issue here.
- klysm 3y ago
  I'm very skeptical that's high quality for all use cases. Architecture is a huge trade off space and what's right for a particular product is most certainly wrong for another.
  - jonathanlydall 3y ago
    Absolutely, you choose or create the architecture or architectural components which make sense for your particular situation/requirements. After all, there is no one size fits all architecture, there is instead a choice of trade-offs.
koliber 3y ago
There is no perfect balance. If you have the awareness of the extremes you can adjust course. A little goes a long way. 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.
robocat 3y ago
SoA = service-oriented architecture (acronym not expanded in article). https://wikipedia.org/wiki/Service-oriented_architecture https://wikipedia.org/wiki/Service-oriented_architecture
deleted 3y ago
[deleted]
langsoul-com 3y ago
Resume driven development is a pretty good reason explanation of why people go for new and hip. Old tech won't pass automated scanners.
closeparen 3y ago
DLQ and retry are complementary strategies. DLQ is where the message goes after retries are exhausted. Whether you need one depends on your SLA, whether the message is still relevant later, whether the data is going to be reconciled through some other channel, etc. It's not an aesthetic preference.
quickthrower2 3y ago
A good balance comes when both employees care about business decisions e.g. "is it worth spending 3 months of the teams time on X?" and vice versa non-engineers are aware of technical debt and why teams are trying to 'pay it down'. The ideal situation is when there is someone or a group of people who can take in all the information and make decent business decisions. After all - the codebase and it's maintainability is a part of the business (just like a well maintained oil rig vs. a bad maintained one impacts the business). It is just not as visible as managers can't walk around and eye up the code as easily as see cracks and rust in the building work.
goimonkeen 3y ago
[flagged]
danbruc 3y ago
In principle, at least for business applications, the middle ground is something like low code - data access, UI, user management, authentication, logging, auditing, ... all taken care of already, you make the data model and business logic. In practice this works up to a point, when you have requirements that do not fit the model or capabilities that the creators of the platform had in mind, when you have to start fighting the platform, then you are right back in wtf code land. When you decided which platform to use, you of course evaluated this and made a good choice, building the first version worked nicely. Now you have a running system and want to extend it, now you are getting the more unusual requirements that were not important for version one and therefore not taken into account when making the platform choice, now your nightmare starts.
- j-a-a-p 3y ago
  Yes, reminds me of about 25/30 years ago when low code was at its high. Back then there were strict guidelines where to put business logic (client, server or both), how to name them. Everything had to originate from the model (model driven development). Since then the developers took over and killed waterfall and 4GL in the process.
  - CPLX 3y ago
    Genuine question, what were the low code frameworks that were popular in the late 90’s that you’re referencing here?
    - j-a-a-p 3y ago
      Forgot most of that, I consider this 'enterprise period' in my life as pretty boring. 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).
d--b 3y ago
Well the middle ground does exist and it is mostly just a blend of the two problems. 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.
- rednafi 3y ago
  This is far better than picking one extreme and sticking with it until the product dies!
Tade0 3y ago
I've found that small, focused teams are generally better at this, especially when they're close to the stakeholders and can arrange a metting to get some feedback if need be. 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.
discreteevent 3y ago
"Domain work is messy and demands a lot of complicated new knowledge that doesn’t seem to add to a computer scientist’s capabilities. Instead, the technical talent goes to work on elaborate frameworks, trying to solve domain problems with technology. Learning about and modeling the domain is left to others. Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance." - Eric Evans
liampulles 3y ago
I've found that really inquisitive, good devs tend to get bored if stuck with the same stack for a while. This in my experience is what often drives adopting shiny new things which are not needed and cause progress to grind to a halt. 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.
_glass 3y ago
One thing I noticed when consulting SAP or Salesforce implementations, where the tech stack is a given, the focus switches only to the business logic, people are forgetting how important tech is. Reporting starts to be included, millions of validations are running, bringing the system down. As the tech is a simple given, limitations are not to be overcome, but rather accepted. Which often turns out funny, because it has all real-world consequences of some obscure limitations.
wazoox 3y ago
There are several level of relationships in a company: technical, business and social. Often, management hires consultants to push for organisational changes, and most of the time social relationships are ignored because in contrast with the other two, they're mostly unwritten and implicit. 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.
adrianfanaca 3y ago
The whole software development industry has all of a sudden been relegated to what it has always been: just a tool. Like the hammer. Those who promoted the hammer as the holy grail have been reading this article and commenting some shit their alcohol imbued sick brain has been capable of producing in their zero thought process. If you get huge sums to work on linter for years and you use that money to fuck up your brain instead of developing you end up a cripple. Just like the software development industry has become. A cripple that no one wants to meet, touch, see
brainzap 3y ago
Whats wrong with writing RFC?
- rednafi 3y ago
  RFCs are great if they incur discussion but not so if no one reads them at all. The latter happens more often than I'd like to admit.
gspencley 3y ago
I would like to start by teaching developers what business logic IS, and how to separate it from the other "layers" of software design. 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.
- pas 3y ago
  it's clear there's no budget for maintaining that disciplined layering ... (see #3 on the list from https://news.ycombinator.com/item?id=38188689 https://news.ycombinator.com/item?id=38188689 ) 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 ... "
- default-kramer 3y ago
  I mostly agree with you. But I'd guess that at least 10 of those 100 developers might say something like "business logic belongs in framework-agnostic pure functions, unless you have a good reason not to." And many of the remaining developers would say "what is a pure function?" 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.
  - rednafi 3y ago
    I love FP; at least some aspect of it. But it’s not popular because it’s not the panacea that the evangelists want you to believe. Also, the community loves getting engaged into pseudo-intellectual ramblings that most people find useless.
javier_e06 3y ago
A business is a group of ferrets. Other than eating and inviting mischief, no much logic there.
- rednafi 3y ago
  I fed this to midjourney and it gave me a few great illustrations :p
Aqueous 3y ago
High level architects should focus primarily on creating a system architecture that is designed to incrementally and composably add functionality. 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.
- Tainnor 3y ago
  > 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.
Michelangelo11 3y ago
I agree with this, but the article feels like it's talking about a world that no longer exists (or is rapidly ceasing to exist). Questions like "should salaried engineers focus on code quality at the expense of business goals" are a ZIRP phenomenon, i.e. relevant at a time when companies were hiring engineers just to prevent competitors from hiring them and when graduating from a boot camp was all it took to land a junior SWE role. Now that the engineering job market is, alas, looking a lot like other job markets, this feels like it's from a different reality.
- rednafi 3y ago
  You’ll be amazed at what goes on in some of these multi billion dollar companies. Why do you think the mass tech layoff happened? There are still a ton of coasters in large companies that didn’t get affected by the last layoff spree but are responsible for the next one.
joelthelion 3y ago
I'm a manager who tries to take this middle road. But it's frustrating to see other teams on either side of the spectrum celebrated, and hard to get recognition for your small team that just gets the job done, while trying to keep an acceptable level of quality.
flowinghorse 3y ago
Just note that any organization is quite complex, and surely at different times different people in an organization have different purposes, and they may have different understandings if they share the same purposes. So it is pretty common that everybody's actions, understanding, and purposes are not coordinated. 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
pjmlp 3y ago
> Now that microservices are no longer in vogue... They certainly never heard of MACH Architecture and headless CMS.

258 points by nalgeon 3y ago

There is no "perfect balance", but you need tech leads and PMs to understand that you are aiming for a balance where your tech debt is under control and you are continuously and consistently delivering business value. 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.

ecfi 3y ago
> So far, I've failed to verbalise exactly how I achieve that in my org This is where I struggle as well.
- NAHWheatCracker 3y ago
  It's often not a matter of verbalizing if the decision makers don't want to believe what you're saying. 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.
simonw 3y ago
An interesting challenge I've found with the term "technical debt" is that engineers can use it as an excuse to work on all kinds of things that might not genuinely be paying down technical debt, taking advantage of situations where the people making the prioritization decisions don't have the hands-on technical experience of the codebase to evaluate if the proposed "improvement" is a good investment of effort or not. AKA someone needs to be able to push back against "we'll rewrite it in Rust to reduce our technical debt".
- NAHWheatCracker 3y ago
  I've been quite frustrated that the term "technical debt" is so misused. It feels like project managers immediately assume technical debt means "the developer wants to play around". I only use it when it means "the features you want can't be implemented, correctly, and under the time constraints". 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.
  - swatcoder 3y ago
    Some of this is a product of job-hopping culture and of having boom-time teams (technical and management) with too many early-career members. Some of it is also just the perpetual back and forth of competing interests. 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.
    - NAHWheatCracker 3y ago
      > When you’re having to pitch the work to someone, you’ve often already failed the pitch. 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.

swatcoder 3y ago

It never bodes well when an essay opens with a strawman. 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.

deleted 3y ago
[deleted]
chefandy 3y ago
I think the author was using hyperbole to illustrate two problematic organizational tendencies. I could say something like "I see two kinds of drivers in the northeast: ones that drive like they're fleeing a bank robbery in a stolen police car and others driving like they're piloting a parade float carrying a human pyramid." I think it's obvious I'm not saying literally all drivers in the northeast fit into one of those two categories, rather, I'm setting up the scene to talk about two extremes in a common premise.
- swatcoder 3y ago
  I’m sure that’s what they were trying to do, but their argument only carries weight in the context of those hyperboles. 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.
  - dasil003 3y ago

latchkey 3y ago

> There must be a middle ground where developers can focus on the core business logic that yields the most value without incurring technical debt and making the development process a nightmare. I don’t have an answer for that, nor have I worked at a company that found the perfect balance. 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_intro/ https://www.pivotaltracker.com/help/articles/gettingmore_int...

NAHWheatCracker 3y ago
I worked at a health insurance company 6 years ago where they brought in a group from Pivotal for a week and we worked with them to see how they ran a Scrum team. 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.
- latchkey 3y ago
  The way Pivotal Labs works is that people who don't buy into the whole culture tend to migrate out pretty quickly. The ones that do buy in, stay around for a long time, learn things inside and out, and end up getting farmed out to places like yours. So you generally get the best of the best on consulting agreements like that. 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.

bruce511 3y ago

>> There must be a middle ground where developers can focus on the core business logic that yields the most value without incurring technical debt and making the development process a nightmare. I don’t have an answer for that, nor have I worked at a company that found the perfect balance. Plus, I’m not a technical lead, manager, or business owner. So if you are one of them, I’d love to hear how you or your organization plans to tackle this 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.

safety1st 3y ago
As a dev turned entrepreneur one thing I will do when selling projects is talk to clients about software as a depreciating asset. While there are some limitations to the comparison this framing makes sense to business people in general, especially well with finance or operations departments, and can work with internal stakeholders too. 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.

cavisne 3y ago

There is a new paper out from Google which seems like an interesting approach to get out of microservice hell https://sigops.org/s/conferences/hotos/2023/papers/ghemawat.pdf https://sigops.org/s/conferences/hotos/2023/papers/ghemawat....

yeswecatan 3y ago
This is an interesting paper and one I would never have found on my own. How did you come across it?
- cavisne 3y ago
  Twitter, I think it is pretty new. The lead author is a very well known engineer.
nvella 3y ago
I've only read the abstract, but hasn't this been achievable for at-least the last twenty years with dependency injection? I've seen time and time again developers conflate microservices with the general concept of service abstraction and separation-of-concerns. These things have existed before microservices, and will continue to exist. 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.
- ajkjk 3y ago
  This isn't really DI. From skimming, it is sort of.. cross-machine DI.

EdwardDiego 3y ago

> while juniors want to ditch Celery for Kafka because the latter is hip. 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.

rednafi 3y ago
Kafka is great. Problem is that the celery system is working just fine and there are higher priority tasks rotting in the backlog.

john-radio 3y ago

> Raking in absurd sums to tweak linters or buttons may not be the worst thing in the world, if it also didn’t lead these bored people to dream of becoming architecture astronauts by introducing absurdly complex tools to solve imaginary problems. I'm forced to sit back and admire a sentence that's as well wrought, funny, and true as this.

lmm 3y ago

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.

captainkrtek 3y ago
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.
gymbeaux 3y ago
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.
- ehnto 3y ago
  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.

giantg2 3y ago

I hate both types of organizations. I think I hate the rapid tech switching even more than the business focused one. There's a lot to hate about languages like COBOL, but honestly it looks awesome create neat code with actual documentation and design documents, that will just work for decades with minor upgrades and changes. Durable systems are gone. Longterm support is 12-18 months. Iterate or die is how it works now, I guess.

al_borland 3y ago
I see no point in automating anything if I'm expected to re-write it every year. If they are going to pay me to do that, they might as well just pay someone to do the work manually. It would probably be faster and cheaper than the illusion of time savings we're getting from reimplementing the same solutions year after years against our will. 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.

gymbeaux 3y ago

I’m on a sabbatical because I find myself very jaded by the industry, more or less for the reasons stated in this article. What I tell people is something like “I LOVE building stuff with code, but lithe EVERYTHING ELSE.” Writing code may be better suited as a hobby for me… after all, I have the most fun with side projects… but then, as most of you can probably empathize with, how will I make the sweet, sweet six figures? I’ve looked into being an AWS Solutions Architect, but they want someone with more sales experience (???). You’d think it would be the other way around, that’s certainly what we wished for when interacting with them as “customers.” It was always “hmmm, good question, let me get back to you on that” with the equivalent of LMGTFY in my inbox days later like that wasn’t the first article I read on the topic. Anything else so far feels like a waste of my talent (“talent” - I mean I don’t want to be installing Microsoft Office on people’s computers or replacing ink cartridges). 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.

granshaw 3y ago
Sounds like freelancing/consulting might be right up your alley. Maybe building mvps or working on relatively new products or codebases. Charge for your time and no pretend work. 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
- gymbeaux 3y ago
  Yep, I’ve done some freelancing over the last few years. I like it, but it’s hard to do that and a full-time job at the same time. Obviously the issue is getting enough work when you’re not normally employed, and when you are normally employed, the issue is not getting too much work. Clients like stuff ASAP and telling them an MVP will take 3 months because you’ll only be working on it 8 hours/week doesn’t go over well. The clients I’ve had are understanding but they all eventually want me to quit my job and come work for them, either as FTE or still a freelancer.

jonathanlydall 3y ago

The startup (bootstrapped, non-US based) I work for creates a developer productivity tool which gives you high quality architecture “for free”, allowing you to instead focus on those bespoke un-automatable business rules. We essentially aim to solve the author’s stated issue here.

klysm 3y ago
I'm very skeptical that's high quality for all use cases. Architecture is a huge trade off space and what's right for a particular product is most certainly wrong for another.
- jonathanlydall 3y ago
  Absolutely, you choose or create the architecture or architectural components which make sense for your particular situation/requirements. After all, there is no one size fits all architecture, there is instead a choice of trade-offs.

koliber 3y ago

There is no perfect balance. If you have the awareness of the extremes you can adjust course. A little goes a long way. 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.

robocat 3y ago

SoA = service-oriented architecture (acronym not expanded in article). https://wikipedia.org/wiki/Service-oriented_architecture https://wikipedia.org/wiki/Service-oriented_architecture

deleted 3y ago

[deleted]

langsoul-com 3y ago

Resume driven development is a pretty good reason explanation of why people go for new and hip. Old tech won't pass automated scanners.

closeparen 3y ago

DLQ and retry are complementary strategies. DLQ is where the message goes after retries are exhausted. Whether you need one depends on your SLA, whether the message is still relevant later, whether the data is going to be reconciled through some other channel, etc. It's not an aesthetic preference.

quickthrower2 3y ago

A good balance comes when both employees care about business decisions e.g. "is it worth spending 3 months of the teams time on X?" and vice versa non-engineers are aware of technical debt and why teams are trying to 'pay it down'. The ideal situation is when there is someone or a group of people who can take in all the information and make decent business decisions. After all - the codebase and it's maintainability is a part of the business (just like a well maintained oil rig vs. a bad maintained one impacts the business). It is just not as visible as managers can't walk around and eye up the code as easily as see cracks and rust in the building work.

goimonkeen 3y ago

[flagged]

danbruc 3y ago

In principle, at least for business applications, the middle ground is something like low code - data access, UI, user management, authentication, logging, auditing, ... all taken care of already, you make the data model and business logic. In practice this works up to a point, when you have requirements that do not fit the model or capabilities that the creators of the platform had in mind, when you have to start fighting the platform, then you are right back in wtf code land. When you decided which platform to use, you of course evaluated this and made a good choice, building the first version worked nicely. Now you have a running system and want to extend it, now you are getting the more unusual requirements that were not important for version one and therefore not taken into account when making the platform choice, now your nightmare starts.

j-a-a-p 3y ago
Yes, reminds me of about 25/30 years ago when low code was at its high. Back then there were strict guidelines where to put business logic (client, server or both), how to name them. Everything had to originate from the model (model driven development). Since then the developers took over and killed waterfall and 4GL in the process.
- CPLX 3y ago
  Genuine question, what were the low code frameworks that were popular in the late 90’s that you’re referencing here?
  - j-a-a-p 3y ago
    Forgot most of that, I consider this 'enterprise period' in my life as pretty boring. 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).

d--b 3y ago

Well the middle ground does exist and it is mostly just a blend of the two problems. 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.

rednafi 3y ago
This is far better than picking one extreme and sticking with it until the product dies!

Tade0 3y ago

I've found that small, focused teams are generally better at this, especially when they're close to the stakeholders and can arrange a metting to get some feedback if need be. 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.

discreteevent 3y ago

"Domain work is messy and demands a lot of complicated new knowledge that doesn’t seem to add to a computer scientist’s capabilities. Instead, the technical talent goes to work on elaborate frameworks, trying to solve domain problems with technology. Learning about and modeling the domain is left to others. Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance." - Eric Evans

liampulles 3y ago

I've found that really inquisitive, good devs tend to get bored if stuck with the same stack for a while. This in my experience is what often drives adopting shiny new things which are not needed and cause progress to grind to a halt. 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.

_glass 3y ago

One thing I noticed when consulting SAP or Salesforce implementations, where the tech stack is a given, the focus switches only to the business logic, people are forgetting how important tech is. Reporting starts to be included, millions of validations are running, bringing the system down. As the tech is a simple given, limitations are not to be overcome, but rather accepted. Which often turns out funny, because it has all real-world consequences of some obscure limitations.

wazoox 3y ago

There are several level of relationships in a company: technical, business and social. Often, management hires consultants to push for organisational changes, and most of the time social relationships are ignored because in contrast with the other two, they're mostly unwritten and implicit. 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.

adrianfanaca 3y ago

The whole software development industry has all of a sudden been relegated to what it has always been: just a tool. Like the hammer. Those who promoted the hammer as the holy grail have been reading this article and commenting some shit their alcohol imbued sick brain has been capable of producing in their zero thought process. If you get huge sums to work on linter for years and you use that money to fuck up your brain instead of developing you end up a cripple. Just like the software development industry has become. A cripple that no one wants to meet, touch, see

brainzap 3y ago

Whats wrong with writing RFC?

rednafi 3y ago
RFCs are great if they incur discussion but not so if no one reads them at all. The latter happens more often than I'd like to admit.

gspencley 3y ago

I would like to start by teaching developers what business logic IS, and how to separate it from the other "layers" of software design. 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.

pas 3y ago
it's clear there's no budget for maintaining that disciplined layering ... (see #3 on the list from https://news.ycombinator.com/item?id=38188689 https://news.ycombinator.com/item?id=38188689 ) 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 ... "
default-kramer 3y ago
I mostly agree with you. But I'd guess that at least 10 of those 100 developers might say something like "business logic belongs in framework-agnostic pure functions, unless you have a good reason not to." And many of the remaining developers would say "what is a pure function?" 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.
- rednafi 3y ago
  I love FP; at least some aspect of it. But it’s not popular because it’s not the panacea that the evangelists want you to believe. Also, the community loves getting engaged into pseudo-intellectual ramblings that most people find useless.

javier_e06 3y ago

A business is a group of ferrets. Other than eating and inviting mischief, no much logic there.

rednafi 3y ago
I fed this to midjourney and it gave me a few great illustrations :p

Aqueous 3y ago

High level architects should focus primarily on creating a system architecture that is designed to incrementally and composably add functionality. 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.

Tainnor 3y ago
> 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.

Michelangelo11 3y ago

I agree with this, but the article feels like it's talking about a world that no longer exists (or is rapidly ceasing to exist). Questions like "should salaried engineers focus on code quality at the expense of business goals" are a ZIRP phenomenon, i.e. relevant at a time when companies were hiring engineers just to prevent competitors from hiring them and when graduating from a boot camp was all it took to land a junior SWE role. Now that the engineering job market is, alas, looking a lot like other job markets, this feels like it's from a different reality.

rednafi 3y ago
You’ll be amazed at what goes on in some of these multi billion dollar companies. Why do you think the mass tech layoff happened? There are still a ton of coasters in large companies that didn’t get affected by the last layoff spree but are responsible for the next one.

joelthelion 3y ago

I'm a manager who tries to take this middle road. But it's frustrating to see other teams on either side of the spectrum celebrated, and hard to get recognition for your small team that just gets the job done, while trying to keep an acceptable level of quality.

flowinghorse 3y ago

Just note that any organization is quite complex, and surely at different times different people in an organization have different purposes, and they may have different understandings if they share the same purposes. So it is pretty common that everybody's actions, understanding, and purposes are not coordinated. 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

pjmlp 3y ago

> Now that microservices are no longer in vogue... They certainly never heard of MACH Architecture and headless CMS.