At 23:15 -0600 02/16/2004, Greg McKaskle wrote: >Of course this is one of those >topics that is difficult to discuss in writing, so please don't use your >whiney voice when reading it. I'm simply trying to give insight into >our process.
This process is not unique. One can substitute any large software software project. I think the process NI uses is the same as almost anyone selling/maintaining software. I don't particularly like the model/existing practice. Maybe I should clarify that the sound track is NOT a whiney voice, but the distant sound of tilting at windmills! >LV is a very complicated piece of software. Like most complicated >systems, changes can be characterized by cost, risk, and benefit. These >are the what the LV team members use to decide what bugs get fixed and >when. Of course bug fixes are also weighed against the development of >additional features. But what metric is used on the space of cost/risk/benefit? Of course, ultimate responsibility of the corporation to its owners means that cost/risk/benefit are all judged in terms of fiscal income. The argument that this is bad or good is irrelevant, but this is the standard against which those terms are judged. The point of the interview I posted was that bug-fixing is low benefit, high cost using that metric. For me, the high cost is mistakes controlling equipment which for one of the long standing bugs (which is high cost, low return) is that valves get modified on actual equipment at times the operator did not intend to actuate things. This involved a rather kludgy chunk of code to get around, and then it is high cost (to me) to maintain, since explaining this obscure code takes time/effort/cost. This end user cost needs to be translated to cost to NI. >When triage is performed, these bugs frequently find their way at the >end of the list. That isn't to say they won't ever be fixed, but these >are usually batched together and dealt with when a specific feature is >reworked. Well, actually for some bugs, they will be permanently on the low end of the scale and never fixed unless that whiney voice implies that there is a cost! The Squeaky Wheel concept is certainly something that is considered during "triage". Again, maybe the squeaky wheel factor shouldn't be considered but it is. >As an example, units in LV is a unique experiment unlike what I've seen >in other programming languages or engineering tools. This is where bugs are actually a design defect and not fixable without a major rewrite/overhaul. Units are somewhat unique in the way LV handles them. Again, NI will sell more copies of LV by adding express nodes than by fixing the units problems until the users start to complain a lot. In some respects the model rewards that whiney voice. I don't like it either. >Units and charts are still on the list of things that could stand to be >improved, and my advice to you is to make sure that bug reports give the >engineer good information so they can make good estimates on the cost, >risk, and benefit. In particular, they can judge the risk of changes to >a particular area, and estimate the time to make the changes, but it is >sometimes hard for them to estimate how much time and how many LV users >are bothered by a bug. Maybe a more complete description on how to report a bug and what to do, to debug the bug. So that the information is as complete as possible. The standard report merely asks a few simple questions about hardware/software configuration. Maybe some suggestions for testing when and where the problem does or does not occur. In most cases this is an artI think I have gotten good after 20 years of beta testing various hardware/software solutions but we could all use guidance above the simple level that is posted on NI's web site. I admit, that sometimes I get sloppy and do a bad bug report as well. > Of course if you are honest, you may have just >relegated your bug to the back of the line And occasionally we get to whine about it! There was a nice article in Tech Review journal about "Why is Software So Bad". This was a nice rundown of the drivers for software development and some of the attempts to fix it. In a more perfect world with educated consumers and producers all would be fine, until then I will keep tilting at those dang windmills. They might be giants! -Scott
