<br><br><div class="gmail_quote">On Wed, Jun 27, 2012 at 8:43 AM, Peter Wang <span dir="ltr"><<a href="mailto:pwang@continuum.io" target="_blank">pwang@continuum.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Jun 27, 2012 at 9:33 AM, Charles R Harris<br>
<<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
> On Wed, Jun 27, 2012 at 7:20 AM, John Hunter <<a href="mailto:jdh2358@gmail.com">jdh2358@gmail.com</a>> wrote:<br>
</div><div class="im">>> because the original developers are gone.  So people are loathe to<br>
>> upgrade.  It is certainly true that deprecations that have lived for a<br>
>> single point release cycle have not been vetted by a large part of the<br>
>> user community.<br>
><br>
> I'd also venture a guess that many of those installations don't have<br>
> adequate test suites.<br>
<br>
</div>Depends how you define "adequate".  If these companies stopped being<br>
able to make money, model science, or serve up web applications due to<br>
the lack of a test suite, then they would immediately put all their<br>
efforts on it.  But for users for whom Numpy (and software in general)<br>
is merely a means to an end, the management of technical debt and<br>
future technology risk is merely one component of all the risk factors<br>
facing the organization.  Every hour spent managing code and technical<br>
debt is an hour of lost business opportunity, and that balance is very<br>
conscientiously weighed and oftentimes the decision is not in the<br>
direction of quality of software process.<br>
<br>
In my experience, it's a toss up.. most people have reasonable unit<br>
tests and small integration tests, but large scale smoke tests can be<br>
very difficult to maintain or to justify to upper management.  Because<br>
Numpy can be both a component of larger software or a direct tool in<br>
its own right, I've found that it makes a big difference whether an<br>
organization sees code as a means to an end, or an ends unto itself.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br>Yep. What I meant by adequate was adequate for safely upgrading/refactoring. My experience is that folks will stay with what they have as long as it gets the job done. Competition can drive changes, but even that can be an unreliable prod as it may take several years before losing an edge begins to hurt. <br>
<br>Chuck <br></div><br></div>