Oh my poor business logic
rednafi.com
Oh my poor business logic
1–10 of 154 posts
Re: Oh my poor business logic
#2There 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.
Re: Oh my poor business logic
#3There 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-…
> So far, I've failed to verbalise exactly how I achieve that in my org
This is where I struggle as well.
Re: Oh my poor business logic
#4It 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.
Re: Oh my poor business logic
#5It 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…
[deleted]
Re: Oh my poor business logic
#6It 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…
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.
Re: Oh my poor business logic
#7There 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-…
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".
Re: Oh my poor business logic
#8It 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…
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 th…
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.
Re: Oh my poor business logic
#9There 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-…
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…
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.
Re: Oh my poor business logic
#10> 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_int...