Some time around 09/05/2004 09:42:17, I think I heard Marck D Pearlstone say:
DJ>> as they are functional deficiencies, which impede use at the most,
DJ>> and annoy and frustrate users at the least.
> Incorrect.
> Bugs are functional deficiencies that impede at worst, yes, but the
> least effect of a bug is to not even affect the majority of users.
> Such a bug is a low priority bug.
Which is paraphrasing what I said. I do agree with you that bugs which do not affect
a majority of users have a lower priority, but the fact still remains there are plenty
of core-functionality issues that have been reported for years, which have not been
addressed.
> You have a very mistaken view of the software market. The only
> bug-free software is very small and very limited in functionality.
> I've only been working in this field for 30 years - this is a fact,
> believe it!
I have been working in the software industry for about 15 years; I am a software
developer myself. I am not talking about "bug-free software"; I am talking about
addressing known core-functionality bugs and other issues which have been outstanding
for some time now. *And* communicating to your existing customers, in a diligent and
honest manner, your development plans and the future of the product.
DJ>> But again, focusing on this and the addition of new non-core
DJ>> features to the detrement of the quality and functionality of the
DJ>> product itself,
> Who said that was what happened? It isn't. This has been explained
> over and over.
But this is *exactly* what happened. By your own admission later in your comments,
this was a pure marketing decision, which ignored the wishes and needs of the current
(rather large) user base. What has been explained over and over is that RitLabs made
a poor marketing decision, not that their software development process is following
the right path. And this is what frustrates me and many others.
> While the responsible programmers who were familiar
> with the code focused on the buggy functionality, what would *you*
> have paid the idle staff to do? Go home? Take a holiday? They don't
> know the code behind the bugs and it is not cost effective to force
> them to work on it while the responsible programmers were doing so. If
> anything, such a procedure could slow down the bug-fixing effort while
> the new programmers received on-the-job training.
I see your point; keep adding chrome in order to keep the idle staff busy. Do you
really believe this is a sound development philosophy for a software company?
> Instead, the new programmers were effectively employed on the equally
> essential face lift. It just happened that the face-lift code was
> finished before all the bug fix code was in. Just because you don't
> understand the complexities of a multi-person software project, no
> need to waste bandwidth arguing a corner that doesn't make sense, is
> there?
As a software developer, I do understand the complexities of a multi-person software
project. This was a big assumption on your part. And employing new programmers to
add chrome, bells and whistles is the sort of direction that me and others believe is
wrong; Current programming efforts should be concentrated in "fixing what's broken"
first, adding chrome later. If "what's broken" is so much, and if efforts directed
towards correcting them would drive the company away from a competing position in the
market, then the problem is not the feature set or the lack of programmers, but a
fundamental flaw in the original scope and mission. That is what I and others see,
which tells us that RitLabs is scrambling to grasp at straws with a product that might
have lost its steam. TB! is a great product, no doubt about that; but part of its
appeal was its promise of all good things that would come from the tight, purist, and
focused approach the developers initially took on it. It is my feeling, as well as
others, that this has been lost. What's left is a buggy application with a new shiny
chrome and some useless bells and whistles, with some powerful features to be sure,
but with a lack of future in the face of intense competition from new comers like the
Mozilla Foundation, Opera, et al.
DJ>> not to mention the promises made when v2.x was introduced, is just
DJ>> plain wrong.
> That's another issue.
> Yes, promises have been broken. That's bad marketing. RIT's marketing
> department need to take a long hard look at that as a matter of
> policy. Do you know what I think the outcome will be? No more feature
> promises. Marketing rules in the sales-centric universe that our
> flawed western society has created. I'm not happy about that and it
> doesn't speak well to ethics. But it is where we live.
And behold, your admission to my point above; a marketing move -- and a bad one at
that -- does not correspond to a proper software development process. I'm sure you
understand that both are different; I am complaining about the latter, while you are
responding about the former. Besides this is not "another issue", this just compounds
the new popular view that the company has no real or trustworthy direction.
DJ>> Specially when history shows that it is very probable that the
DJ>> introduction of new features can introduce its own legion of bugs,
DJ>> and increase the complexity of the application.
> ... and while this is true, the product cannot stand still because of
> competition and new market demands. Every review of TB ever published
> has slammed it for its outdated interface. I know what I'd do if I
> were its publisher. Exactly what they have done!
And again I reiterate that if the application is so broken that the correction of
known core-functionality issues will cause RitLabs to lose its market position, then
the problem is not with the interface, nor the bells and whistles, but with the
original concept and design. Maybe RitLabs is not well suited to build a good e-mail
client capable of competing in todays market. But understand that I am not saying
they aren't, just exploring the possibilities.
>>> You are one of those 100, so apparently you don't like the
>>> decision, but that doesn't make Ritlabs priorities wrong, only
>>> different from yours.
DJ>> RitLabs priorities are wrong, whether you want to agree with
DJ>> my comments or not.
> ... only in your (and a couple of other equally ill-informed and
> unsympathetic individuals). In my opinion, the programmers have it
> right and the marketing department have made an error. Then again,
> with the huge facelift, I can see why too. It's not press-worthy to
> launch "Shiny new The Bat! Version 2.13.0x announced - look at the
> shiny new XP front end / enhanced IMAP / blah blah". Press release
> about the all-new look for version 3 and you break into markets you
> couldn't touch before.
Adhering to an artificial release dateline which corresponds to a yearly marketing
cycle and not with the natural development process is not a sound corporate
philosophy. Hence mine and other's complaints.
> So the only error is in the treatment of the existing user base.
Not the only error, but a big one indeed. Ignoring your existing user base, specially
in an application that competes mostly because of user satisfaction spread through
word of mouth, might be considered corporate suicide by some.
> ... <snip>
DJ>> ... plenty of old bugs that have not even been addressed in the
DJ>> least, which shows a poor development process and a lack of
DJ>> commitment to quality.
> And yet, the fixing of bugs is an ongoing process. They continue to
> work on them.
Point taken. But I venture to argue that some bugs have been ignored. And if they
are so difficult to correct after some years, then the problem might be the original
design.
> Some bugs take longer to fix than others and, at some
> point, you have to replace a bug-ridden release with a less bug-ridden
> release.
I agree strongly with this, as I mentioned a few paragraphs above, but this is not
what happened. What happened was that new features were added on top of the current
faulty ones, increasing code complexity. This does not help correct known issues.
The new version 3.0 was rushed to publication because of an artificial marketing
deadline, and the TB-beta discussion list, and the almost daily maintenance releases,
show that the product was not ready for market. Again, this shows a lack of
commitment to quality. And furthermore, ignoring your users' reaction, shows a lack
of respect towards you loyal customers.
> It's ridiculous to say that a software company can leave
> bug-ridden versions on sale just because they didn't fix *all* the
> bugs. And that's what you're saying.
That's not what I am saying at all. I agree with you, but RitLabs did not take that
path. An increase in version number due to marketing decisions does not a new
code-base make. I do not expect RitLabs to stop all product advancement in order to
"fix *all* the bugs", but I do expect from any company whose products I purchased to
show a commitment to their customers. A pattern of lack of communication, haphazard
development cycles, and bad marketing decisions, frustrates me and a lot of other
users. And since this is no way, in our opinion, to run a successful business, the
lack of direction and policies dilutes our faith in the future of the company.
And to go back to the original point against Allie's comment, *THIS* is what bothers
us, not the fact that there is a new pretty interface.
-dZ.
--
Powered by The Bat! v.2.12.00,
Hindered by MS Windows 2000 v.5.0 build 2195 Service Pack 4
________________________________________________
Current version is 3.00.00 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html
