[sldev] Just askin': How are we doing?
Able Whitman
able.whitman at gmail.com
Mon Jun 25 12:53:02 PDT 2007
>
>
> The other (big) thing, and I think the comments on the blog for
> the 1.17.1 and 1.18 release announcements support that, would be to
> make the 3rd quarter the quarter of "bug fixing". This is probably
> something King Philip would need to do (like Bill Gates at one point
> just announced the "year of security" or something like that), but
> a quarter of letting the dust settle, where everybody would just
> work on fixing and cleaning up stuff, would do the whole viewer a
> lot of good.
>
>
I have to disagree, actually. While I do think it's vitally important to try
and stay on top of the bugs which cause the biggest pain points, I don't
think it's reasonable to focus only on big fixes. First, at least, is the
fact that sometimes the line between bug fix and new feature is blurry.
Modifying the internal browser to support cookies was certainly a new
feature, but it also fixed the bug that sites using cookies didn't work in
the internal browser, to pick just one example. :)
Also, I think trying to get a team focused 100% on fixing defects has a
deleterious effect on morale. It's good to guide your team's efforts so that
they are properly prioritizing between testing, bug fixing, and new feature
work. But when you're doing nothing but bug fixing, it quickly becomes an
environment where people feel like they're stuck in a rut and not making an
real progress. That's not conducive to keeping folks happy, and happiness is
more important than just helping people feel good: Happy devs write better
code, and happy testers find better bugs.
Don't let Billg fool you -- even during the year-long security push, there
was plenty of new feature working going on. Sure, a lot of those new
features were security-related, but you can't just stop working on software
for a year (or even a quarter). The only time I saw an entire team go
heads-down into code reviews and bug fixing was when the COM folks went dark
after the remotely-exploitable DCOM flaws a few years back. That effort was
disasterous for morale, and I saw a bunch of people leave for another team,
or another company, or burnout entirely.
Again, it's a matter of prioritization and communication (both internal and
external), and finding the right balance between bugs and features.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070625/804a5600/attachment-0001.htm
More information about the SLDev
mailing list