Liz wrote:
As a developer I do know how hard it is to write something to suit
everyone, however, if you broke something that used to work, rather
than add new stuff, its much better for the confidence of your
userbase to fix the broke stuff, before adding new. We all understand
breakages, stuff happens, but when it remains broken, and ignored..
quite often people report bugs because they used that feature, and
now their usage is hampered.
I did not want to add to this already rather thick soup, but... my
fingers itched :-)
There is a detail here that we must not forget. RL indicated that they
were doing a major code re-write (which sounds very much like a
re-design: you only re-write major parts of your product if you decide
you reached a limit, and a re-design is warranted).
Usually, when a product reaches a milestone -- like a new version,
re-design, whatever -- you branch on your source management tool. This
means you create a new subtree, separate from the currently-available
source code base. At this point in time work will then go on two
radically different fronts: maintenance and support on the production
(soon to be old) source code base, and development action on the new
source code branch.
As such, issues that have been discovered on the current support version
*may* *not* be seen on the development version. Even more, if the
development process gets to re-write major portions of the code, then
the issue found on "production" code may not even be reproducible on
development code.
Also, usually development is left alone until a point in time when new
(since the code branch) product issues are verified against the
development, and the code bases are then "synchronised". Obviously, as I
pointed out earlier, sometimes you just cannot do it. And, of course,
there are those that say development people live in a different world...
having been on both sides of the fence (development and support), I have
to say I agree with it.
Also, every product issue is given a priority, and high-priority issues
are worked on first. One way to give an issue higher priority is by
showing the issue impacts negatively a large portion of the customer
base. Issues that do not impact many customers, or that do not cause
catastrophic failure of the product are, by consequence, left for later
work. Take your own conclusions on how you can influence, folks.
I am not saying, or even implying, this is what RL did, or does. I am
just pointing out how this usually works on large development shops. I
personally guess this is the *only* way this type of work can be done,
in general...
--
..hggdh..
"developers do not need rockets to reach the moon. I know. I have been
there"
________________________________________________________
Current beta is 3.5.33 | 'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html
IMPORTANT: To register as a Beta tester, use this link first -
http://www.ritlabs.com/en/partners/testers/
