21–30 of 154 posts
I'm forced to sit back and admire a sentence that's as well wrought, funny, and true as this.
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.
Durable systems are gone. Longterm support is 12-18 months. Iterate or die is how it works now, I guess.
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-…
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…
Theoretically someone who understood both the business and the technical side of things ought to be able to weigh up individual tasks from both sides and figure out which was higher priority. But in practice that seems very hard - you'd need both intimate knowledge of both domains and immunity to organisational politics. Explicitly adjusting that high-level dial (so maybe the 25% becomes 50% when it's a codebase you want to publish/reuse, or 0% when it's an EOL project that you're just running until it falls apart) might be the best you can do in practice.
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…
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…
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.
> 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 Clo…
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. P…
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.