4 ms·

I've been brainstorming this with colleagues at my job and tossed out the idea of including both an immediate development cost as well as a "long term cost mult

I've been brainstorming this with colleagues at my job and tossed out the idea of including both an immediate development cost as well as a "long term cost multiplier" for every requested feature. So far, no one has the like the idea or phrase. I can't really blame them. But there must be some quantity or term, with a nice memorable ring to it, that could get this across and at least let business people make decisions with full information at hand. Granted, any such numbers delivered in that guise would be wild guesses. But still, better than nothing. Edit: However, I've since realized that the notion of "story points" and "velocity" already sort of provides a way to get this across if used carefully.

m_mueller 7y ago
How can story points be used for that? To me that's only relevant in the short term. Can management be made to understand that velocity can be too high? Edit: Expanding with my previous thoughts on this - as a software architect I've explained my role to management by saying it's like I work in an agile team, but the waterfall is in my head - someone needs to keep the architecture together and drive it towards green pastures where it keeps great flexibility for developing future anticipated features without giving up stability.
- deleted 7y ago
  [deleted]
- sopooneo 7y ago
  My thought was that story points can be used once they are turned into velocity by dividing by time. And you can say that adding this feature half baked now in short time, will inevitably drop our velocity by 10% in the future.
  - m_mueller 7y ago
    Like a huge afterburner that is a dead weight after 3 seconds...
mindvirus 7y ago
We need to quantify it though. Thinking about long term implications and talking about it is good, but that doesn't break us out of the bubble of communicating it to the business. After all, they don't know what a story point is (heck I don't really, and I've been doing this for a while). As the article points out, management can be short sighted- they want to deliver on their roadmap this quarter or half (because that is what they are paid for). I don't know what the answer is, I struggle with this. Testing has some promise here: if we can deliver (failing) tests early on that demonstrate progress toward the roadmap, and use those to show progress to the business and help them hedge risk, we can use tests as a forcing function for quality - testable code, especially for business processes, is usually good code.
- kqr 7y ago
  I sometimes give two estimations in one: up-front cost of development and long term consequences. Could be something like, "8 points + three support cases per week" for making a new feature without fully thinking it through. Or "32 points + misconfigurations every other month" for including a complicated feature that can more easily be abused. Or "We can go with our current best guess, and the effort of that is maybe 2 points + potentially 12 points later if it turns out we were wrong. Contrast this with 6 points to be certain of doing the right thing now." In my experience, this is highly appreciated in environments that take you seriously, listen to you, and understand what "estimation" means,
  - gvjddbnvdrbv 7y ago
    Your competition gave an estimate of 2 points, did the work, got paid and moved on. Now you are supporting the feature...
    - kqr 7y ago
      If that was the right call, then great! If not, hopefully someone learned from their mistake. If nobody did, I'm probably not interested in that business anyway; it sounds like it is a recurring source of friction.
the_gipsy 7y ago
"Growth". That is one word that makes managers look like deers in headlights. At least the first time you tell them. Maybe the issue is much bigger than just communication. Perhaps they also realize that they don't work for, or will get rewarded for, far future profits and benefits.
buster 7y ago
Isn't that what tech debt is about? You write code that works right now, but you know it should be refactored because of long term costs. Keep track of it, put it on a wall, quantify it (days, story points, whatever) and talk to your manager about what tech debts need immediate resolving, what are the nice to haves. The worst thing you can do is to build up tech debt and be silent about it. Tech debt needs to be handled, or else your software won't be maintainable in the long term and new features will cost much more and put the system in risk even more. And there is a nice slide about it: https://www.slideshare.net/cairolali/resolving-technical-debt-in-software-architecture/3 https://www.slideshare.net/cairolali/resolving-technical-deb... (In case you are wondering, the circle means, you're past any maintainability. Go to start, rewrite. If your client or manager wants to avoid it, he/she should plan for refactoring).
- sopooneo 7y ago
  I hear you on tech debt, but in my conception, it is just one portion of "long term cost multiplier". Because even a perfectly coded and tested feature adds weight to a system and slows future development.
celticmusic 7y ago
> However, I've since realized that the notion of "story points" and "velocity" already sort of provides a way to get this across if used carefully. Not really. What you're missing is called risk. risk with respect to missing the deadline and long term risk when doing a sloppy job. Business people understand risk, yet software developers go through all this effort to talk about story points and velocity.

m_mueller 7y ago

How can story points be used for that? To me that's only relevant in the short term. Can management be made to understand that velocity can be too high? Edit: Expanding with my previous thoughts on this - as a software architect I've explained my role to management by saying it's like I work in an agile team, but the waterfall is in my head - someone needs to keep the architecture together and drive it towards green pastures where it keeps great flexibility for developing future anticipated features without giving up stability.

deleted 7y ago
[deleted]
sopooneo 7y ago
My thought was that story points can be used once they are turned into velocity by dividing by time. And you can say that adding this feature half baked now in short time, will inevitably drop our velocity by 10% in the future.
- m_mueller 7y ago
  Like a huge afterburner that is a dead weight after 3 seconds...

mindvirus 7y ago

We need to quantify it though. Thinking about long term implications and talking about it is good, but that doesn't break us out of the bubble of communicating it to the business. After all, they don't know what a story point is (heck I don't really, and I've been doing this for a while). As the article points out, management can be short sighted- they want to deliver on their roadmap this quarter or half (because that is what they are paid for). I don't know what the answer is, I struggle with this. Testing has some promise here: if we can deliver (failing) tests early on that demonstrate progress toward the roadmap, and use those to show progress to the business and help them hedge risk, we can use tests as a forcing function for quality - testable code, especially for business processes, is usually good code.

kqr 7y ago
I sometimes give two estimations in one: up-front cost of development and long term consequences. Could be something like, "8 points + three support cases per week" for making a new feature without fully thinking it through. Or "32 points + misconfigurations every other month" for including a complicated feature that can more easily be abused. Or "We can go with our current best guess, and the effort of that is maybe 2 points + potentially 12 points later if it turns out we were wrong. Contrast this with 6 points to be certain of doing the right thing now." In my experience, this is highly appreciated in environments that take you seriously, listen to you, and understand what "estimation" means,
- gvjddbnvdrbv 7y ago
  Your competition gave an estimate of 2 points, did the work, got paid and moved on. Now you are supporting the feature...
  - kqr 7y ago
    If that was the right call, then great! If not, hopefully someone learned from their mistake. If nobody did, I'm probably not interested in that business anyway; it sounds like it is a recurring source of friction.

the_gipsy 7y ago

"Growth". That is one word that makes managers look like deers in headlights. At least the first time you tell them. Maybe the issue is much bigger than just communication. Perhaps they also realize that they don't work for, or will get rewarded for, far future profits and benefits.

buster 7y ago

Isn't that what tech debt is about? You write code that works right now, but you know it should be refactored because of long term costs. Keep track of it, put it on a wall, quantify it (days, story points, whatever) and talk to your manager about what tech debts need immediate resolving, what are the nice to haves. The worst thing you can do is to build up tech debt and be silent about it. Tech debt needs to be handled, or else your software won't be maintainable in the long term and new features will cost much more and put the system in risk even more. And there is a nice slide about it: https://www.slideshare.net/cairolali/resolving-technical-debt-in-software-architecture/3 https://www.slideshare.net/cairolali/resolving-technical-deb... (In case you are wondering, the circle means, you're past any maintainability. Go to start, rewrite. If your client or manager wants to avoid it, he/she should plan for refactoring).

sopooneo 7y ago
I hear you on tech debt, but in my conception, it is just one portion of "long term cost multiplier". Because even a perfectly coded and tested feature adds weight to a system and slows future development.

celticmusic 7y ago

> However, I've since realized that the notion of "story points" and "velocity" already sort of provides a way to get this across if used carefully. Not really. What you're missing is called risk. risk with respect to missing the deadline and long term risk when doing a sloppy job. Business people understand risk, yet software developers go through all this effort to talk about story points and velocity.