 |
 |
Carl Grant wrote: > > a. You've got to accept responsibility for helping to test > software. There can be 1000's of pathways through code. We know you > want bug-free code, but the developer/vendor can't > test them all by > themselves or you'd never actually get the code! I don't know about this. There is a thing called "Quality Assurance". Mass market software makers like Microsoft spend quite a bit of effort on QA procedures to try and assure a basic level of _working_ before a product is released. In our market, we very very seldomly get this. There are techniques and methodologies that other software companies have developed to try to assure quality without "never getting the code". What is it about our particular industry that leads to us not being able to expect this? On the other hand, yes, customers should be willing to be beta testers. But the software we are often given to 'beta test' (or even as _release quality software_) is sometimes at a level that wouldn't even be called 'alpha' in other industries. Other times final release software has serious flaws in it that keep the software from doing what it's advertised to do. Customers should not have to themselves perform as unpaid testers for the vendor to achieve a basic level of quality. I guess the question is in what is that 'basic' level of quality. I guess vendors think they are currently delivering it, but customers don't think they are currently getting it. (I guess the various constraints that keep us from _no longer buying_ the software even if we think we aren't getting that basic level of quality is the answer to why we aren't able to expect that basic level of testing before software is released... Many of us are trying to work on those constraints.) Jonathan > b. If you're paying a commercial vendor to support/maintain, > understand that costs should go up to compensate them for supporting > that increasing complexity. > 5. Try to standardize practices, **where possible**, between like > institutions. Use development resources for great ideas, not just > to support local idiosyncrasies... > 6. Understand if you're trying to please everyone, it means lowest > common denominator. If you're trying to lead and develop new ideas, > somebody is going to be upset. It's not the > developer/vendors responsibilities to decide which of these > apply to > your institution or what to do about it when it happens. Decide up > front, are you following, or are you leading? > > Carl > > Carl Grant > President > CARE Affiliates, Inc. > E: [log in to unmask] > M: 540-529-7885 > O: 540-552-2912 > 866-340-9580 x 801 (Toll-Free) > Website: www.care-affiliates.com > Adium: carl_r_grant > Skype: carl_grant > > On Nov 6, 2007, at 1:33 PM, Roy Tennant wrote: > >> On 11/6/07 10:27 AM, "Jonathan Gorman" <[log in to unmask]> wrote: >> >>> How about an equivalent list from the vendor/software developer's >>> perspective? >>> I think that would help balance the picture, but perhaps that's >>> already in >>> your plans ;). >> >> Funny you should ask...I had originally intended to do this, but >> then I was >> wondering if it start to be redundant -- that is, would a number of >> points >> simply be restated from the vendor's viewpoint? But if there are >> unique >> points to make from that perspective it would be worthwhile to >> include them. >> This is an area where I consider myself even more ignorant than >> usual, so if >> those of you who work on that side of the fence would like to chime >> in with >> relevant manifesto points from the perspective of developers and >> vendors, >> I'm all ears. Thanks, >> Roy > -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu