Any chance we can agree that you're both right, up to a point? There's no point the programmers spending time fixing something the customers haven't noticed isn't perfect -- working but not as well as the programmers would like. (Re-arranging those deck chairs.)
The customers might want X fixed first while the programmers want to fix MNO first because the flaw in MNO is what's making X not-work as expected. Unless someone has reverse-engineered and de-constructed the code, they'll never know that. Which makes both of you right, at different points along the path. Cheryl Alex MacPhee wrote: > > I'm sure we can agree to disagree. But at the risk of > causing an outbreak of chuckling with you, I am a former IT > professional, with a lot of experience, and I led several of > the teams developing the largest non-defence computer > project in Europe in the field of telecommunications. The > programmers may "work for the developer", but the developer > has nothing to develop without customers who pay, unless > that is it is a mere hobby. The real priorities here are > business priorities. There is absolutely no point in > assigning a high priority to fixing a trivial fault when > there's a major problem that risks driving the customer to > another product. It may be a cliche, but don't re-arrange > the deckchairs on the Titanic. > > Without customers, the developer has nothing but time on his > hands. When the customers move to another product because > the competition is addressing the customer's priorities and > not the programmer's, the programmer will have plenty of > time to assign a high priority to twiddling his thumbs > because the revenue stream is drying up. > > > Alex > > > > > ------------------------------------------------------------ > From: [email protected] > Date: Sat, 15 Feb 2014 08:33:36 -0500 > Subject: Re: [LegacyUG] Endnotes > To: [email protected] > > Sorry, > > We will have to agree to disagree. The programmers work for > the developer. The customer purchases a license to use the > program. If the customer has an issues, they can contact the > developer/software owner. The customer absolutely does not > contact the programmer nor does the customer have the right > or knowledge to dictate to the programmer what priorities > should be set. I always chuckle when someone contacts this > list and says I am a former programmer or I am an IT > professional therefore I know what the best business model > is for a company I have never worked for. > > There are many many users on this list that barely know how > to turn a computer on (no insults intended to anyone). How > can those same people possibly know what priorities should > be set for correcting perceived issues which in many cases > is not an issue, but user misunderstanding. > > As I said, we will have to agree to disagree - setting > priorities belongs with the programmers - not the users. > > > On Sat, Feb 15, 2014 at 8:04 AM, Alex MacPhee > <[email protected] <mailto:[email protected]>> > wrote: > > In the real and commercial world, not the land of La La, > it's the customers who pay the programmers, not the > programmers who pay the customers. The function of a > program suite is to solve a problem that the customer > has, not a problem the programmer has, and it's the > customer's priorities therefore that count. There is a > maxim well understood in the commercial world, that if > you don't listen to your customers, somebody else will. > Legacy User Group guidelines: http://www.LegacyFamilyTree.com/Etiquette.asp Archived messages after Nov. 21 2009: http://www.mail-archive.com/[email protected]/ Archived messages from old mail server - before Nov. 21 2009: http://www.mail-archive.com/[email protected]/ Online technical support: http://www.LegacyFamilyTree.com/Help.asp Follow Legacy on Facebook (http://www.facebook.com/LegacyFamilyTree) and on our blog (http://news.LegacyFamilyTree.com). To unsubscribe: http://www.LegacyFamilyTree.com/LegacyLists.asp
