This content has moved permanently to:
https://blog.jonm.dev/posts/measure-your-improvements/
Tuesday, September 2, 2008
Subscribe to:
Post Comments (Atom)
The Art of Writing Software
This content has moved permanently to:
https://blog.jonm.dev/posts/measure-your-improvements/
All articles Copyright © 2007-2019 by Jon Moore. All rights reserved.
4 comments:
JMo,
All good points and well put, but it seems to me that the things you list as causal metrics are to a certain extent well outside the control of the development team insofar as they reflect of the accretive success of marketing and branding, which can be helped by a strong app but not controlled by it. So they aren't really good metrics for any development effort. You could say that the longitudinal TCO of an app would be a causal metric for it, but even there external teams like communications, training, and IT infrastructure factor in. So I'm not seeing pure causal metrics for an SDLC.
Hi Grouse,
Thanks for the input. I struggled a bit with the terms "causal" and "symptomatic", apparently with good reason. I was searching for something to distinguish, for example, "outstanding bug count" from "software quality." Here, we probably really care about the latter, but can only easily wrap a number around the former, which is only a secondary/derived indicator.
I'd definitely welcome suggestions for alternate terms here.
It is true that the development team is not in direct control of the product's profitability; that certainly requires holistic management (should we hire more engineers to enhance the product, or just spend more on advertising?). As you indicate, though, how the development team performs is certainly an influencer on overall product profitability; I'm suggesting collecting trending data over time.
For a given feature that brings in a fixed incremental amount of revenue, for example, spending 2 vs. 3 weeks in QA may be the difference between a positive and a negative ROI for that feature. Having information at this level of detail is the holy grail, and the article here is probably just a small step in that direction.
I think this article needs a rewrite, in general, because it "rohms [too] friely" across a couple of different topics. I'd like to get some more feedback about what the valuable bits are here so I can focus on them during the rewrite.
Jon
Great reading your bloog post
Thoughtful blog you have here
Post a Comment