3 ms·

> “Software is never 'finished' but must be constantly updated to maintain capability, address ongoing security issues and potentially add or increase performan

> “Software is never 'finished' but must be constantly updated to maintain capability, address ongoing security issues and potentially add or increase performance.” Something that people really need to understand when they are asking if something is done. “Done enough for now” is the best, simple phrase I’ve learned to convey the sense of what was quoted above. It can easily segway into that conversation, if handled delicately, and teachable moments for management. How do you convey doneness in your projects?

streetcat1 7y ago
1) You slice your project into use cases. 2) You "do" every use case end to end (including the pieces of infra needed for that use case and the user interface parts). 3) You add regression tests (unit / func) for the use case. 4) Every new such use case is a new release. This way you are always done.
- rumanator 7y ago
  Then there's the fact that requirements do change, and do change often, and of course there are bugs and emergent design issues.
  - streetcat1 7y ago
    Absolutely. But this is just another use case. The real risk of working UC by UC, is that you might get locked into bad architecture. The way to mitigate that is by using microservices.
cbanek 7y ago
At one previous job I was at, people were saying things are done when they weren't. Then the PM started going, is it done-done? Oh sure. I think that mostly meant "is it actually checked in and running?" Then when we had bugs, they would come around and ask, is it done-done-done (said quickly, with a sense of doom)? I love the "done enough for now.," although I do find some use in breaking down doneness. My levels of done: 1) I've got a prototype or POC that works. I've cracked the hardest issues and gotten it to work, at least in some way. 2) Code is buttoned up, checked in, and running in the build (probably in a branch), maybe even reviewed. 3) Code is tested, and tests pass 4) Code is integrated and working functionally as part of a system. People are able to call it and rely on it. Proves code does what it needs to. So I really try not to say "it's done," but more where it is at in this SDL.
- qznc 7y ago
  This is why I like the Scrum idea of having an official "definition of done". It is valuable to have a shared understanding about it. https://www.scruminc.com/definition-of-done/ https://www.scruminc.com/definition-of-done/
kthejoker2 7y ago
Scrun has a definition of done, it usually is some form of * code checked in * tested * documented * deployed * accepted For each user story. So performance, capabilities, and other enhancements or fixes are their own user story and follow the same path.
- closeparen 7y ago
  "When I pass a series of inputs to the classifier, they are tagged with at least 65% precision and at least 65% recall." It could be that the available data and current approach yield only 63%, in which case the user story is being worked on indefinitely for months. Or it could be that 65% is achieved, but the threshold chosen was a wild guess; business value is actually linear all the way up to perfect, so it's worth iterating indefinitely. The scrum & user story format work well for small and unambiguous units of customer-facing behavior, but some software is made of more than that.

streetcat1 7y ago

1) You slice your project into use cases. 2) You "do" every use case end to end (including the pieces of infra needed for that use case and the user interface parts). 3) You add regression tests (unit / func) for the use case. 4) Every new such use case is a new release. This way you are always done.

rumanator 7y ago
Then there's the fact that requirements do change, and do change often, and of course there are bugs and emergent design issues.
- streetcat1 7y ago
  Absolutely. But this is just another use case. The real risk of working UC by UC, is that you might get locked into bad architecture. The way to mitigate that is by using microservices.

cbanek 7y ago

At one previous job I was at, people were saying things are done when they weren't. Then the PM started going, is it done-done? Oh sure. I think that mostly meant "is it actually checked in and running?" Then when we had bugs, they would come around and ask, is it done-done-done (said quickly, with a sense of doom)? I love the "done enough for now.," although I do find some use in breaking down doneness. My levels of done: 1) I've got a prototype or POC that works. I've cracked the hardest issues and gotten it to work, at least in some way. 2) Code is buttoned up, checked in, and running in the build (probably in a branch), maybe even reviewed. 3) Code is tested, and tests pass 4) Code is integrated and working functionally as part of a system. People are able to call it and rely on it. Proves code does what it needs to. So I really try not to say "it's done," but more where it is at in this SDL.

qznc 7y ago
This is why I like the Scrum idea of having an official "definition of done". It is valuable to have a shared understanding about it. https://www.scruminc.com/definition-of-done/ https://www.scruminc.com/definition-of-done/

kthejoker2 7y ago

Scrun has a definition of done, it usually is some form of * code checked in * tested * documented * deployed * accepted For each user story. So performance, capabilities, and other enhancements or fixes are their own user story and follow the same path.

closeparen 7y ago
"When I pass a series of inputs to the classifier, they are tagged with at least 65% precision and at least 65% recall." It could be that the available data and current approach yield only 63%, in which case the user story is being worked on indefinitely for months. Or it could be that 65% is achieved, but the threshold chosen was a wild guess; business value is actually linear all the way up to perfect, so it's worth iterating indefinitely. The scrum & user story format work well for small and unambiguous units of customer-facing behavior, but some software is made of more than that.