Mario

If we are not using "improvements" (as you just said), and
we are tracking effort related to bug fixes in PMCS (per
Jeff via the dmlt list), it makes perfect sense to me!

Thanks
Jacek



On 09/15/2014 02:02 AM, Mario Juric wrote:
> On 9/11/14 21:33 , Jacek Becla wrote:
>> Mario, K-T
>>
>> I understand the logic, and it does make sense from the EV
>> and PMCS perspective. What I am saying is that
>>
>> a) a lot of things we are doing can be seen as either
>>     "new feature" or "improvement". As an example, say
>>     we have a working version of qserv that supports
>>     a join expressed like this:
>>     "select whatever from A, B where A.id=B.id."
>>     Later, we add support for a better join:
>>     "select whatever from A join B using (id)"
>>     It feels more like an improvement to what we
>>     already have working, right? But I don't think we
>>     want to do this work under the overhead umbrella.
>>     So, I just want the team to be sensitive to that
>>
>
> We don't distinguish between "new features" and "improvements", if
> that's what's confusing you. They both add value.
>
> We only differentiate between work that adds value (Story), and work
> that's expended on fixing the value we already thought we had (Bug).
>
> A bug is when you discover that the capability you *thought* you had,
> you really don't (because -- you have a bug). For example, a bug would
> be if "select whatever from A, B where A.id=B.id" didn't correctly join
> the table table *** under conditions where its implementation (as
> specified in the original Story) should have worked correctly ***.
>
>> b) we are just starting the construction, and theoretically,
>>     we should be starting writing from scratch, right?
>>     We shouldn't be starting with discovering bugs, we
>>     should first implement things, earn story points, and
>>     then we can talk about bugs (in the code we already
>>     earned points for)
>>
>
> Depends on how you developed the plan for going forward; I think LDM-240
> assumes we're building on top of existing code.
>
>> I am also saying that when doing the estimates I didn't
>> really considered bugs as overheads. I guess I will need
>> to change my perspective when doing future estimates...
>>
>
> I'm not sure if you did or didn't -- verify that your definition of bug
> is consistent with mine. A bug doesn't mean that an implementation isn't
> complete; it means that the code you *thought* worked within the limits
> of what it implements, really doesn't (because of a programmer error --
> a bug, in the everyday sense of the word).
>
> Hope this helps,
>

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1