Comments for Greebsnarf's Weblog http://greebsnarf.wordpress.com Just another WordPress.com weblog Thu, 04 Sep 2008 21:43:46 +0000 http://wordpress.com/ hourly 1 Comment on Two-month plan postmortem by slinkp http://greebsnarf.wordpress.com/2008/08/25/two-month-plan-postmortem/#comment-4 slinkp Thu, 04 Sep 2008 21:43:46 +0000 http://greebsnarf.wordpress.com/?p=32#comment-4 Yeah, thanks for the great write-up. Re. "engineering tasks are being completed faster than QA is able to sign off them"... I still feel that this is largely an organizational problem at TOPP: 1) What QA means in our process is entirely ad-hoc and optional. Tim has helpfully pushed us through some very productive testing episodes, and Doug and I are currently pushing hard on a very time consuming code-review (the first I know of here since I joined TOPP); but we as an organization haven't prioritized these things or figured out how much time we need to spend on it. Lately, far as I know, we've been running without any schedule at all, which as Ethan pointed out is problematic. So +1 to being more explicit about scheduling. 2) We have no dedicated QA staff. QA at TOPP means yanking developers and designers away from developing and designing. Which would be OK only if we could learn to accept working at a radically slower pace. Personally I think we should put some dedicated testers in the staff budget ASAP. I think Spolsky's pretty on-target about this: http://www.joelonsoftware.com/articles/fog0000000067.html Tangent: I'm curious why this blog post ended up here rather than on say http://www.openplans.org/projects/operations/blog/ Yeah, thanks for the great write-up.

Re. “engineering tasks are being completed faster than QA is able to sign off them”… I still feel that this is largely an organizational problem at TOPP:

1) What QA means in our process is entirely ad-hoc and optional. Tim has helpfully pushed us through some very productive testing episodes, and Doug and I are currently pushing hard on a very time consuming code-review (the first I know of here since I joined TOPP); but we as an organization haven’t prioritized these things or figured out how much time we need to spend on it. Lately, far as I know, we’ve been running without any schedule at all, which as Ethan pointed out is problematic. So +1 to being more explicit about scheduling.

2) We have no dedicated QA staff. QA at TOPP means yanking developers and designers away from developing and designing. Which would be OK only if we could learn to accept working at a radically slower pace. Personally I think we should put some dedicated testers in the staff budget ASAP. I think Spolsky’s pretty on-target about this: http://www.joelonsoftware.com/articles/fog0000000067.html

Tangent: I’m curious why this blog post ended up here rather than on say http://www.openplans.org/projects/operations/blog/

]]> Comment on Two-month plan postmortem by Rob Miller http://greebsnarf.wordpress.com/2008/08/25/two-month-plan-postmortem/#comment-3 Rob Miller Thu, 04 Sep 2008 19:55:00 +0000 http://greebsnarf.wordpress.com/?p=32#comment-3 Thanks for this debrief, it's very helpful to compare our goals to what we actually accomplished. In addition to what you mention above, I can think of two more issues that set our deployments back a bit. The first is a lack of testing resources. You mention that there was "sensible reluctance on the part of the stakeholders"; I've certainly had some "sensible reluctance" w.r.t. the Plone 3 deployment. This reluctance is informed by the fact that (until very recently, anyway) nobody other than myself has done any significant amount of hammering on the P3-based stack. It does seem to me that engineering tasks are being completed faster than QA is able to sign off them, creating a back-log of items that are close-to-ready but about which the developers may not feel entirely confident. The other issue is a bit more pedestrian, which is that some of this has hit right in the middle of the summer vacation season. While in theory there are a number of folks who can troubleshoot and fix issues in any part of our codebase, in truth it's likely that I'll be able to resolve certain P3-related issues much more quickly than anyone else, and thus it's unnecessarily risky to try to deploy that code to the live site when I'm not around to deal w/ issues as they come up. Neither of these negate your ideas or suggestions, of course, I just wanted to add them to the list of things to consider in our future planning processes. Thanks for this debrief, it’s very helpful to compare our goals to what we actually accomplished. In addition to what you mention above, I can think of two more issues that set our deployments back a bit. The first is a lack of testing resources. You mention that there was “sensible reluctance on the part of the stakeholders”; I’ve certainly had some “sensible reluctance” w.r.t. the Plone 3 deployment. This reluctance is informed by the fact that (until very recently, anyway) nobody other than myself has done any significant amount of hammering on the P3-based stack. It does seem to me that engineering tasks are being completed faster than QA is able to sign off them, creating a back-log of items that are close-to-ready but about which the developers may not feel entirely confident.

The other issue is a bit more pedestrian, which is that some of this has hit right in the middle of the summer vacation season. While in theory there are a number of folks who can troubleshoot and fix issues in any part of our codebase, in truth it’s likely that I’ll be able to resolve certain P3-related issues much more quickly than anyone else, and thus it’s unnecessarily risky to try to deploy that code to the live site when I’m not around to deal w/ issues as they come up.

Neither of these negate your ideas or suggestions, of course, I just wanted to add them to the list of things to consider in our future planning processes.

]]> Comment on str(obj) by Programming by Interface « Greebsnarf’s Weblog http://greebsnarf.wordpress.com/str-obj/#comment-2 Programming by Interface « Greebsnarf’s Weblog Mon, 21 Jul 2008 05:30:32 +0000 http://greebsnarf.wordpress.com/?page_id=17#comment-2 [...] inspect the implementation at all. Period. Good examples: “str(obj)“ (which implicitly assumes that “obj“ implemented IString) and “getComponent(IDesiredInterface).doSomething()“. Bad examples: [...] [...] inspect the implementation at all. Period. Good examples: “str(obj)“ (which implicitly assumes that “obj“ implemented IString) and “getComponent(IDesiredInterface).doSomething()“. Bad examples: [...]

]]>