3 ms·

You can measure productivity by measuring the success, but that's kinda useless for day to day software engineering management.

Trasmatta 2y ago
How do you define success? If a product bombs, is that because of the engineering or the product design?
- throw5959 2y ago
  I don't think it's possible to answer generally. Track what matters for your business.
- skeeter2020 2y ago
  if it's successful, it's because of sales. If it fails, engineering didn't build the right thing / was too slow - it really doesn't matter.
ChrisMarshallNY 2y ago
I tend to go by results, and for me, "results" means shipped* code that is used and accepted by end users**, can be maintained and extended***, and doesn't generate trouble tickets. * MVP doesn't count. ** Can include users inside the organization. *** It's OK if it requires senior-level ongoing support. I think expecting it to be maintained by monkeys is a bad idea.
- pinkmuffinere 2y ago
  To me, "MVP doesn't count" feels like a crazy take -- in many roles, the _only_ ask is to produce a series of different MVP's. I guess maybe the definition of "MVP" is a bit squishy, and these people-who-ship-MVPs themselves make MVP-MVP's, which shouldn't count as shipped?
  - ChrisMarshallNY 2y ago
    I spent most of my career, shipping finished product, which, in many cases, probably could have benefitted from an MVP-like "tuning phase," but we called that "beta." I think MVP generates more useful feedback, but I really don't like thinking of an MVP as "shipping software." I also worked for hardware companies, where shipping stuff had some pretty serious stakes, and learned how to make sure we got it as good as possible, before getting it out the door. I like the idea of evolutionary design, and "tuning," but I think it's a bad idea (for me) to deliberately ship bad software as an end-product. (Also, MVP, by definition, generates lots of trouble tickets. I am allergic to trouble tickets. It's totally a personal thing, but I live by it).
- skeeter2020 2y ago
  saying "MVP doesn't count" implies that you throw it away and then right "the perfect system" at some point. If you've ever had an MVP land you know that's not how it happens.
  - ChrisMarshallNY 2y ago
    I write "as close to perfect" as I can get. I know that "The Perfect is the enemy of the good" is a popular meme, but I have found that "The perfect is something to strive for" has been useful, for me. In fact, my way has been working for me, for decades. I'm quite aware that many folks do it differently, and that's one reason that I try to "keep it in the I," and write about how I do it, and talk about the bar that I set, for myself. Most of the software I write, is free software that Serves a pretty small demographic. It can have a fairly outsize influence on the lives of the people that use my software, and I really care about the end-users of my work, so I tend to set a pretty high personal bar. I'm quite aware that I don't have many of the stressors that beset commercial software houses, so I sincerely don't feel "snooty." In fact, I feel profoundly grateful to be in a position, where I can follow my muse. I really would like it if folks wrote better stuff, but I am also aware of the culture, and how that's next to impossible, these days.

Trasmatta 2y ago

How do you define success? If a product bombs, is that because of the engineering or the product design?

throw5959 2y ago
I don't think it's possible to answer generally. Track what matters for your business.
skeeter2020 2y ago
if it's successful, it's because of sales. If it fails, engineering didn't build the right thing / was too slow - it really doesn't matter.

ChrisMarshallNY 2y ago

I tend to go by results, and for me, "results" means shipped* code that is used and accepted by end users**, can be maintained and extended***, and doesn't generate trouble tickets. * MVP doesn't count. ** Can include users inside the organization. *** It's OK if it requires senior-level ongoing support. I think expecting it to be maintained by monkeys is a bad idea.

pinkmuffinere 2y ago
To me, "MVP doesn't count" feels like a crazy take -- in many roles, the _only_ ask is to produce a series of different MVP's. I guess maybe the definition of "MVP" is a bit squishy, and these people-who-ship-MVPs themselves make MVP-MVP's, which shouldn't count as shipped?
- ChrisMarshallNY 2y ago
  I spent most of my career, shipping finished product, which, in many cases, probably could have benefitted from an MVP-like "tuning phase," but we called that "beta." I think MVP generates more useful feedback, but I really don't like thinking of an MVP as "shipping software." I also worked for hardware companies, where shipping stuff had some pretty serious stakes, and learned how to make sure we got it as good as possible, before getting it out the door. I like the idea of evolutionary design, and "tuning," but I think it's a bad idea (for me) to deliberately ship bad software as an end-product. (Also, MVP, by definition, generates lots of trouble tickets. I am allergic to trouble tickets. It's totally a personal thing, but I live by it).
skeeter2020 2y ago
saying "MVP doesn't count" implies that you throw it away and then right "the perfect system" at some point. If you've ever had an MVP land you know that's not how it happens.
- ChrisMarshallNY 2y ago
  I write "as close to perfect" as I can get. I know that "The Perfect is the enemy of the good" is a popular meme, but I have found that "The perfect is something to strive for" has been useful, for me. In fact, my way has been working for me, for decades. I'm quite aware that many folks do it differently, and that's one reason that I try to "keep it in the I," and write about how I do it, and talk about the bar that I set, for myself. Most of the software I write, is free software that Serves a pretty small demographic. It can have a fairly outsize influence on the lives of the people that use my software, and I really care about the end-users of my work, so I tend to set a pretty high personal bar. I'm quite aware that I don't have many of the stressors that beset commercial software houses, so I sincerely don't feel "snooty." In fact, I feel profoundly grateful to be in a position, where I can follow my muse. I really would like it if folks wrote better stuff, but I am also aware of the culture, and how that's next to impossible, these days.