'The Code Has Already Been Written'

theodp writes "John D. Cook points out there's a major divide between the way scientists and programmers view the software they write. Scientists see their software as a kind of exoskeleton, an extension of themselves. Programmers, on the other hand, see their software as something they will hand over to someone else, more like building a robot. To a scientist, the software soup's done when they get what they want out of it, while professional programmers give more thought to reproducibility, maintainability, and correctness. So what happens when the twain meet? 'The real tension,' says Cook, 'comes when a piece of research software is suddenly expected to be ready for production. The scientist will say 'the code has already been written' and can't imagine it would take much work, if any, to prepare the software for its new responsibilities. They don't understand how hard it is for an engineer to turn an exoskeleton into a self-sufficient robot.'"

Comments

I expected more

[kikito]

The abstract in Slashdot is pretty much the whole text in the linked post. The other 3 paragraphs repeat the same idea.

Re:I expected more

[rubycodez]

The whole premise is stupid anyway. I've worked with plenty of scientists in national labs that turn out production grade, maintainable code; and programmers who didn't. The core issue is getting people who write code for reuse by others to follow guidelines, regardless of title or profession.

Re:I expected more

[NoNonAlphaCharsHere]

It isn't stupid at all. Lots and lots of scientific software is written by grad students worried about the results, and don't care about the quality of the code itself. Their idea of what is "good code" has no relation to what a programmer who's worked in a production environment would call "good code". And invariably they decide to include libraries from other grad students at other institutions of equal or lesser value. And don't even get me started about documentation...

Re:I expected more

[Nyeerrmm]

The problem with that is recognizing what code is going to be reused by others and what isn't.

I'm an aerospace engineer who writes a lot of code (and does so on the taxpayer's dime), and it is a struggle to find the right balance between getting something functional for the immediate task, and recognizing what will be useful for others later. Since its much more difficult to write the second variety (particularly if it needs to be generalized for as-yet unknown tasks,) its just as important to perform some tasks the quick way as it is to do others the right way. Otherwise I am wasting precious resources.

Re:I expected more

[icebike]

The whole premise is stupid anyway. I've worked with plenty of scientists in national labs that turn out production grade, maintainable code; and programmers who didn't. The core issue is getting people who write code for reuse by others to follow guidelines, regardless of title or profession.

Because you can point to a few (very few) exceptions does not make the story untrue in the vast majority of cases.

Scientist code is usually a giant JUST-SO story, sufficient to derive the results they need for the task at hand.
They either don't have, or avoid putting in data that will crash the program so limit checking is not necessary.
Crashes are fine if they do nothing more than leave a trail of breadcrumbs sufficient to find the offending line of code.
Output need not be in final form, and any number of repetitive hand manipulations of either the input or the output are fine as long as the researcher does not need to spend more time writing any more elaborate code.

This is perfectly fine. The cabinet maker makes jigs. They are designed for their own shop and no one else has exactly the same saw and exactly the same gluing clamps. When the cabinet maker sells his shop, these jigs become useless. Nobody else knows how to use them.

The scientist who takes the time to do a full fledged, fully documented, maintainable, fail-soft package for analysis of data that is unique to their project and their apparatus is probably not doing very much science, and probably not doing their intended job. That budgets force them into this situation is not unusual.

It happens every day in industry, academics, and research. To hand waive it away by saying you know someone who delivers the full package merely calls into question your own understanding of the meaning of a complete, fully documented, maintainable, transferable, and robust software package.

Re:I expected more

[Fnord666]

The problem with that is recognizing what code is going to be reused by others and what isn't.

One way to tell is to ask if this a temporary quick fix for something. If they say yes, assume it will be in production forever.

Re:I expected more

[rubycodez]

grad students != scientists

Code by students who are actually learning to code professionally will have the same issues.

Re:I expected more

[gmueckl]

Exactly this! It is not about the education of the people writing the code. It's about the purpose for which it is written. I've done it all.

As a scientist most software that I write is geared to solving the problem at hand, nothing more. Sometimes this can be 10.000 lines of C++ code, at other times a short python script or 10. Each time, the code serves as a sort of automation for something that needs to be done anyway (I could attempt to compute the simulation result myself, by hand on pen and paper, you know... if I don't die of old age first ;) ). Often, not a single thought goes into how to make this stuff reusable, robust or more generic. It works on the one machine it is ever going to run on and very likely nowhere else, because it does not matter. What matters is the program output, not the program itself.

As a software developer I have to think differently. Software gets compiled, packaged and deployed elsewhere. It must run out of the box, never crash, give useful error message and recover cleanly if something bad happened. And amidst all this effort, there's a tiny bit of code hidden somewhere doing the actual work. All that matters is that the program behaves correctly, no matter what the concrete output is. I might not even be expected to understand what the output actually means - it's not my primary concern.

See the difference?

Re:I expected more

[16384]

The bulk of scientific research is done by grad students (or others like them with various kinds of scholarships). The professors whose name is at the end of paper's author list guide and oversee what is done, but don't have time for the daily grind of research. Their main job is to teach and get funding.

Re:I expected more

[calmofthestorm]

PhD students at tier 1 and 2 research universities are basically bottom-rung scientists-in-training (sometimes with UGs below them). For our first year or two we'll take a class or two a term, but the bulk of our time is spent doing research, writing and reading scientific papers, and presenting at conferences. For the last 3-4 years we typically take no classes and spend all our time doing research and teaching. We're professionals who make $20-$30k/yr depending on the location, plus full benefits and tuition waivers for any classes we do take. Expectations of workload are typically higher than entry level positions in industry (50-80 hours/wk, depending on the field and PI), and pay is obviously worse. The postdocs and professors do do some of the research themselves (especially when younger), but for the most part their time is spent directing the general direction of the research and applying for grants to fund it, doing the work (for free) to review and organize journals, and of course teaching. Most of us are aware we won't be going on in academia after the PhD, and I at least am okay with that.

It's nothing like a masters or a undergraduate degree at all. We really aren't students in any meaningful sense of the word given the modern sense of college, aside from the fact that we'll get a degree in time. In Europe there are post-graduate degrees awarded after the PhD, so I guess you could call their postdocs "students" as well.

It's completely different outside STEM, however, with PhD students typically earning little to nothing and sometimes having to pay tuition.

Re:I expected more

[jasomill]

Scientist code is usually a giant JUST-SO story, sufficient to derive the results they need for the task at hand.
They either don't have, or avoid putting in data that will crash the program so limit checking is not necessary.
Crashes are fine if they do nothing more than leave a trail of breadcrumbs sufficient to find the offending line of code.

Funny — this could as easily describe how physicists often write mathematics.

In this paper (the paper itself is here), Feynman notes that

The mathematics is not completely satisfactory. No attempt has been made to maintain mathematical rigor. The excuse is not that it is expected that rigorous demonstrations can be easily supplied. Quite the contrary, it is believed that to put the present methods on a rigorous basis may be quite a difficult task, beyond the abilities of the author.

Feynman's "exoskeleton" nevertheless led him to some reasonably well-respected work in quantum electrodynamics. But my point is simply that the problem isn't with "scientists," it's with intelligent people confusing 'ability, in principle to understand X' with 'actually understanding X in practice' —a fallacy that is very common in IT, and one Feynman quite consciously worked to avoid. Life is short, "all one surveys," quite long. Besides, it cuts both ways: it's not at all clear that developers who don't understand the underlying science would do a better job with scrupulous documentation, because even if they bothered to RTFM, they wouldn't have the necessary background to understand it. The net result might be a loss stemming from a "false sense of comprehension."

Finally, it is not unusual for engineers to "understand how hard it [will be] to turn [a given] exoskeleton into [the required] self-sufficient robot" only in retrospect, thus it seems quite silly to expect anyone else to understand this at the outset —here I did not say "believe one understands."

For "turning an exoskeleton into a robot," write "double-entry bookkeeping," "plumbing," "formal mathematical proof," "horseback archery," or "dating," and nothing much changes— it's hard to have a good working knowledge of something one has no experience doing.

Re:I expected more

[tombeard]

To the scientist the program is a tool, to the programmer it is a product.

Re:I expected more

[backwardMechanic]

A lot of scientific software is run less than 10 times, often only once. It generates the result, end of story (well, go away and understand what you got). There really is no point in extensively recoding for reuse, checking all the consts are const, etc. Documentation of the form 'does X using method Y (numerical recipes page P)' is often enough - i.e. a couple of lines of comments at the top of the file. It doesn't have to look nice, it just has to be correct. And don't even get me started on optimization (spending three weeks to cut a 12 hour runtime in half is not worth the effort).

Re:I expected more

[chrb]

Scientist code is usually a giant JUST-SO story, sufficient to derive the results they need for the task at hand. They either don't have, or avoid putting in data that will crash the program so limit checking is not necessary.

Welcome to the worlds of in-house, bespoke and embedded software engineering. This issue is not limited to scientists - in every company I have ever worked at, "getting it done" was more important to management than "code quality".

One-off vs. Product

[gomerbud]

To a scientist, their software is simply a tool, a means to an end. Their results and discoveries are what they really care about. When it comes to reproducing scientific results for verification, it is actually advantageous that another group not use existing software. Another research group using the same faulty software, with the same hidden bugs, will likely come to the same incorrect result.

Productization of software is a completely different exercise. You have to make your software work for a larger crowd on a plethora of devices. You actually have to consider how your software fits into the larger product lifecycle. The key difference here is that you have customers that you need to keep happy.

Re:One-off vs. Product

[swillden]

There's a nice concept devised by Ward Cunningham which captures this issue nicely: "Technical debt".

Failing to put in the effort that makes code maintainable during its construction incurs a notional "debt" which the software carries with it. Future developers working on the code "pay interest" on this debt in the form of time wasted on understanding and modifying the crappy, undocumented code, or on fixing bugs that wouldn't have been present if the code were better. Sometimes, those future developers may decide to spend time refactoring, building tests or documenting, and those cleanups pay down the "principal" on the "debt". After their cleanup work is done, future work has smaller interest payments (less effort for the same results).

Startups often deliberately decide to incur great amounts of technical debt on the theory that if the revenue starts flowing in they'll have the money to fund paying it down, but if they don't start getting some money the whole company will evaporate.

For scientific research, it's pretty clear that it also makes sense to incur lots of technical debt in most cases, because there's little expectation that the code will be used at all once the research is complete. Even when that's not the case, I think few scientists really know how to create maintainable software, because it normally is the case. I don't see a lot of scientists spending time reading about code craftsmanship, or test-driven design, or patterns and anti-patterns, or... lots of things that at least a sizable minority of full-time software engineers care a lot about.

I guess the bottom line, to me, is that this article is blindingly obvious, and exactly what I'd expect to see, based on rational analyses of the degree of technical debt it makes sense for different organizations to incur.

Physicist Speaking Here

[digitrev]

I work with Monte Carlo code and statistical analysis software. I use CERN's ROOT package for the stats analysis, CERN's GEANT4 for the MC code, and *nix scripting when I need to handle multiple files. Every single piece of code I write is written for a purpose. That purpose is generally to generate data and then analyze it. The only other people who are going to see it? Maybe my supervisor, and, if I'm just in on a contract, maybe the guy who has to work on my code later. But to be blunt, that doesn't matter. All that matters is that I know what's going on.

That being said, sometimes I write software for my own personal use. There, I tend to write more robust code, trying to follow various programming standards. Because I figure, if I write something for myself that turns out to be fairly useful, someone might want to use it, or adapt it. But professionally, all my code needs to do is get out that table or prepare that figure. Is it sloppy? Yes. Does it get the job done? Also yes. Fortunately, not only is my field esoteric, it's also government work, so it's practically a guarantee that my code will never have commercial release.

This is so true

[LordNacho]

You can often tell whether someone is "programming as a means to an end (of your own)" versus "programming to build a tool for someone else". For instance, I have experience in the financial industry. Quite a lot of traders see coding as a means to implement their cool new model. Looking at their code, you can often tell. It's as if everything was built to just exactly fulfil the requirement, with no thought to the fact that those requirements might change. But of course, they do change. So you get hacks and workarounds, and cut'n'paste cargo cult code. Kinda like what those Orks in Warhammer 40K might make. And of course the problem with spaghetti code is that if you write it, nobody can ever help you solve problems/improve it. It's the coding equivalent of painting yourself into a corner. There's loads of smart traders out there with an excel spreadsheet that actually is an extension of their personalities (In fact it's their Magnum Opus. Everywhere they go, they try to take this quirky little file with them). Every little hack is something only they can explain (comments, yeah right. Do your body parts have explanatory comments?) and only they can fix if wrong.

On the other hand, you sometimes hire a guy who is a programmer, but knows nothing about the domain. Very good with OO models and that kind, but you have to teach them everything about finance. What's a settlement date, what kinds of options exist, etc. You get what you ask for, because they know how to turn problems into object models, but you have to ask VERY carefully. And teach. Unfortunately, not everyone has time for that, and so you end up with something that still doesn't quite do what it's supposed to.

So you often end up gettings guys who understand the problems, but can't program, programming. And guys who can program, writing the wrong program.

This is a real problem

[smcdow]

The issues surrounding transitioning research S/W written by scientists into honest-to-goodness production systems are ones I'm very familiar with.

At my company, a lot of energy has been put into bridging the gap over the years with varying results. I believe that the root cause of the problem is that research S/W is not an end-product; typically for scientists the end-product is a research paper, white paper, proposal paper, etc., for which the S/W is only a tool for getting to the end-product. As soon as the experimental (or proof-of-concept) S/W returns the desired results, the software is considered "done".

In contrast, production S/W is often THE end-product for developers, so a lot more attention is given to robustness, re-usability, etc. All the standard thinking that you want to go into your production S/W.

One big issue for us is that the research S/W is almost always written in Matlab, while the production code is written in C++ and Java. The single largest source of bugs in our systems is porting S/W from Matlab to C++ or Java. (As an aside, please let's not talk about the Matlab 'compiler', nor Octave. -- we've already tried them both, and they're both performance hogs and also create SCM and CM nightmares).

We experimented with requiring that the research S/W be written in C++, but it was a disaster. The scientists couldn't get anything done, and the code was just awful. So, back to Matlab it was.

And, my experience is that people who I have a great deal of respect for, who I consider brilliant in their fields, holding PhD's, etc., have produced the crappiest Matlab code I've ever had the sorrow to read. My favorite instance was the use of these local variable names within a single function of research S/W that was considered "done" (true story):

i
ii
iii
iiii
iiiii
iiiiii

And, of course, little documentation as to the mechanics of the code. And believe me, it gets worse from there. Bear in mind that the code does indeed work for its particular purpose, and may well be ground-breaking in that particular research domain. But "done"? Ready for production? Not without a major porting effort (which is really a re-writing effort). The most mysterious thing to me, though, is that the scientists, for all their intellectual firepower, don't understand that it's a problem.

The solution we've converged on is to require our bizdev to be responsible for funding efforts to rewrite the research code and get it integrated into the product baseline. And, the bizdev types can't proclaim a particular capability "done" (eg., sell it to customers) until they've funded and executed those efforts. It took years of education to get to this point, but things are moving along much better then before.

Re:This is a real problem

[WizzardX]

I've worked with maths/science types before to integrate their formulas into linux-compatible production code.

It's usually been pretty small formulas (a couple of screens full of code at most), and I don't understand most of it, being a programmer and not a maths guy. Also, we're a pretty small business, and these haven't been under any major deadlines (it fell more under R&D), so I had time to do this properly.

Anyway, what I've done in the past is these steps:

1. When their matlab version is done, ask them to make a representative table of expected inputs and outputs.

2. Port their matlab version to Octave, so I can run it under linux on my workstation. Usually only minor changes are needed.

3. Check my Octave results against their tables, and also confirm that version with the maths person.

4. Port that over to the final version (Python+numpy in this case. Performance isn't a major issue, and I can always use something like Cython to get C-like performance if needed for this type of code), and do a lot of testing and checking with the maths person. The testing part also includes writing automated tests cases against the "known good" inputs and outputs.

And in other cases, the maths guy knows a fair amount of C (an embedded/maths/hardware guy, but not an experienced coder), so they've worked directly with me to port their code over from algorithm to Python, fix issues and test it (where I again don't understand most of the formula), and I've made it more maintainable (added a lot of comments, error checking, etc), and forwarded a very tidied-up version to other coders in my team to work with.

Re:This is so true

[milkmage]

"It definitely is functional but hardly has any of the features consumers demand."

isn't this expected (or at least not surprising). if I were a NASA engineer, I'd see the program as a tool to help me accomplish the larger task. the more time I spend on tools, the less time I spend on progress to the larger objective. I'd write the program as quickly as I could.. would not care about UI, functionality, usability or anything else, I built it for me to use - as long as the output satisfies my needs, i'd consider the task done and move on.

Re:This is so true

[Frosty Piss]

I'm working on commercializing NASA software and this couldn't be more true. When talking to the inventor they inevitably say "Oh yea the software is done, anyone can write code for this, should be easy to sell." even if it's coded in Fortran,, has no Gui or documentation of any sort. It definitely is functional but hardly has any of the features consumers demand.

You know, php / ruby / scripting-language-du-jur might solve many "Web 2.0" problems (Jquery, MooTools, and all the other JS libraries are seriously cool stuff), but there is a reason there is "still" a lot of scientific coding being done with Fortran (which continues to be developed like most modern programming languages), and other "niche" languages. This is not the forum to educate you on that little but notable fact...

But really, I can't quite decide if your post is a troll or not, with lines like "even if it's coded in Fortran" and "has no Gui" and "hardly has any of the features consumers demand"...

I mean, is NASA really writing software that might readily apeal to "consumer demand"?

I'm leaning in the direction that your AC post is a troll, so I'll give you a few points for being able to get me to respond, but I have to subtract points for the lameness and general poor lay-up.

You show potential for developing a good troll shtick / persona but you've got a long way to go. 2 out of 10. Work on it.

Re:This is so true

[tnk1]

We're discussing the ability to commercialize that software, not to simply use it.

Yes, it works. It may even work quite well. It's another thing to be able to use it outside the original group that created it and another thing entirely to turn it into something that can be used by someone who wants to use the functionality for a completely different task.

I've written code that is for a task that I need to get done for myself. This means I can use any arcane method of entering data that I feel like in any format I feel like. If I know exactly what I will be entering and in what format I will enter it, I don't need to do data validation steps in the code. If I know that it won't hurt something to just control-C out of the script, I won't bother creating a "Quit/Exit" functionality. All those things are not needed if you know your code and what it can and it cannot do. The problem is that if you want to commercialize it, you will be selling it to people who do not know what it can do.

And yes, NASA can write code that can have commercial applications. Of course, perhaps not for the "consumer" that you are thinking of, but businesses and even other research groups can be consumers of a product. They are going to be made up of people who are not going to want to spend their time learning your arcane methods of doing things to make the program work for them. They will want an interface that can allow them to make use of the powerful capabilities of your software without having to either write it themselves or spend a huge amount of time learning it and its quirks.

FORTRAN is great, and I have used it myself for things. I think perhaps that it is off-base to have used that as a slur against these programs. However, FORTRAN is a bit of a niche skill in this day and age. You're not going to be able to leverage the great majority of coder resources today if you insist on using it for the code base, and it will make some things more difficult to manage, like perhaps not a slick GUI, but something that is functional and makes the software easier to learn and work with.

I concur

[goombah99]

I always like the Numerical recipes quote: Scientists solve next years problem on last years computer. Computer programmers solve last years problem on next years computer.

I've lived on both sides of this divide but mainly on the scientific side. I become apoplectic with software engineers who just don't vest themselves in the science. The perpetually want a set of requirements. And they get upset if a new requirement is added later. I see software as a way to explore a space. Model it. Determine what more modeling is needed. You are constantly trying to do something that usually is beyond what is computationally possible so you have to figure out what approximation is going to work. What has to be done at full scale and what can be done at lower resolution. Mock up stuff.

The engineers who don't see it as a process just are impediments. Scientists want lots of simple things fast then see what is working and add new simple extensions. They don't want to wait 4 months for some delivered code based on specs it took 2 months to write.

Hence scientist tend to write their own code.

Re:I concur

[SageMusings]

The [sic] perpetually want a set of requirements. And they get upset if a new requirement is added later.

Yeah, pretty much. I think that sums it up quite nicely. I'm guessing you have not written much commercial software.

Re:I concur

[jmac880n]

The perpetually want a set of requirements. And they get upset if a new requirement is added later.

I agree that this is a good, if terse, summation of the basic conflict.

Poorly named, most "Computer Scientists" are NOT scientists. There is no application of the Scientific Method to solve unknown problems. Instead, they are Software Engineers trying to adapt known problems to solution by a versatile tool (the computer). No Science. Just Engineering.

I see software as a way to explore a space. Model it. Determine what more modeling is needed. You are constantly trying to do something that usually is beyond what is computationally possible so you have to figure out what approximation is going to work. What has to be done at full scale and what can be done at lower resolution. Mock up stuff.

This sounds like Science. Very indeterminate. And, not easily estimated. Business managers that employ Software Engineers demand estimates. And schedules. And progress reports.

Also, users of developed software often have - shall we say - hazy views of what is really needed. This can lead to disappointment when the software does not meet expectations.

Thus, to avoid being placed in a bad position, Software Engineers demand detailed requirements, so that they can make accurate estimates and avoid end user disappointment.

You live in a different world, pal... Not necessarily better or worse, but different.

Re:My dear abacus

[swillden]

If I'm getting this right, scientists view software as nothing more than a specialized calculator.

I can certainly confirm that as an engineer, that's certainly how I view it. Almost literally in most cases.

But I have never deluded myself that our really complicated calculator programs would be appropriate for some sort of deliverable product for general use. In fact I repeatedly try to make that point and people still don't get it. And usually "Software engineers" expect a bunch of their absurd rituals to be followed anyway, even if it's never going to go anywhere or be used by anyone but me. So I would contend that the professional programmers and particularly the software process types are the ones who don't grasp the concept.

Brett

Brett

Here's a tool that may be helpful to you in explaining the issue to various people: "Technical Debt". Your quick-n-dirty code that does what you need it to do carries a great deal of technical debt, but the nature of its limited use means the interest payments are small, so there's no value in paying down the debt. Start trying to turn it into a product to be used by many people, however, and you'll quickly find that the interest payments are unbearable, and that it costs a great deal of effort to pay off the technical debt, to turn the code into something that is maintainable.

You can thank the software engineers for that elegant and powerful notion :-)

Re:This is so true

[Frosty Piss]

However, FORTRAN is a bit of a niche skill in this day and age.

I disagree. I think you miss the point: FORTRAN was and *IS* widely used for the tasks that it excels at. Other languages are *NOT* widely used for the tasks that FORTRAN excels at.

"In this day and age"?

This leads me to believe that you really don't know what type of things FORTRAN (and perhaps other "niche" languages) are used for, and why it makes sense to use them. As well, you seem to be under the impression that development on the language itself stopped years ago. In fact, work on new versions of FORTRAN has never stopped, continues to this day, and is not carried out by dirty hippies in their mom's basement someplace.

FORTRAN is not a Web scripting language, perhaps that's why you are having trouble wrapping your mind around it...

leverage debt

[epine]

That's a great post, of the kind that saves me a lot of typing. You covered the first-order considerations brilliantly.

What you missed was technical debt blindness, which has been around since forever. Books I read around the time of the Mythical Man Month talked a lot about maintenance syndrome: that the original development team would be regarded as brilliant for producing working functionality at tremendous speed (undocumented, with no error handling for edge cases), then the first maintenance team would all be fired as underachievers for adding hardly any new functionality in the first year or two.

Turns out it's hard to erect a machine shop over top of adobe mud brick construction without adding some reinforcement to the structure, which usually takes a lot longer than the entire original edifice.

You can instead take a wrecking ball to the first iteration, but this rarely works out as well as hoped. You end up with far more ambitious adobe mud construction built with a whole new generation of unproven tools. At some point you have to bite the bullet and ferment what you began with.

People hide debt blindness behind widely divergent construals of simplicity, where "simple" usually turns out to be a euphemism for any decision that sidesteps paying down debt in the short term.

For professional software engineers, there is one true simplicity to rule them all: generativity and compositionality. Can you build the next layer on top with any hope of having it work and able to support an ongoing stack? For us, it's a long term game of pass the baton. For everyone else (management, scientists) the endgame is to cash out, and take credit elsewhere (e.g. publication biography).

Unfortunately, a citation is not a formal linkage that the compiler either accepts or rejects. By the standards of compositionality, citation is payment in dubious coin. Citation is not falsifiable. Scientists still count their citations even when they come from papers that are full of crap, peer review notwithstanding. For a professional software engineer, when you start instantiating objects from one library inside an abstract expression template library, you come face to face with compositionality in a way that few scientists can even imagine, having weened at the outrage of being improperly cited.

Technical debt blindness on the part of management quickly turns a software engineering shop into a highly non-linear fiasco. We've all seen this.

Somehow this game works out better (for the participants) when played by bankers with leverage debt. But now it's my turn to pass the baton, since that deserves a whole lot more typing and I've done my bit.

Re:This is so true

[turbidostato]

"I'm working on commercializing NASA software and this couldn't be more true."

I don't think is just NASA. Wasn't an IBM engineer the one that said: X time for a valid prototype; 10*X for an in-house product; 100*X for a commercial packaged application?

Given that what a scientist does for her calculations is in the "valid prototype" stage (why the hell would she be interested in anything else?) you can do the math about how much it will cost to put it on a shelf, so to say.

The license has already been written

[j_f_chamblee]

This is a really common problem in the academy. So common in fact, that one particular academician has come up with a special license, the Community Research Academic Programming License (aka, the CRAPL). It's worth a look and good for a chuckle:

http://matt.might.net/articles/crapl/

Re:My dear abacus

[swillden]

You seem to forget that the basic tenet on "technical debt" is "debt". There's not debt if there's no expectancy of having to repay it.

I didn't forget it, I explicitly stated it.

However, you're certainly right that this is an area where the analogy with financial debt breaks down. Another is the fact that quick-n-dirty code in the hands of the original author often appears to have no "interest" cost -- that person can use, modify and enhance the code with great speed and effectiveness.

I think it's worth looking under the covers of the analogy to see why it breaks down. The reason is that technical debt is really just an artifact of obscurity. Well-designed and well-written code is easy to understand because it's transparent and complete, and accompanied by documentation that provides the knowledge necessary to work with it, and tests that enable modification-introduced bugs to be quickly identified and corrected. Bad code has all sorts of edge cases that simply aren't written (or are but don't work), the code is convoluted and hard to understand and the documentation and tests are missing, deficient or -- in the worst cases -- actively misleading.

To a person that knows the code, these defects are basically irrelevant, so the debt is invisible and "interest free". Once the codebase grows to a point that no one can know it all, or gets passed onto others, then the debt raises its head.

This is why debt isn't a perfect analogy for the original developer or (small) development team. But it is a great analogy in the common case, which is a large codebase passed down through many "generations" of developers. Well, the common case for most product and company-internal code, anyway. Not for most research code, as you pointed out.

"It works for me" syndrome

[alispguru]

I work for a group at NASA. One of our group's tasks is to take scientist-written code and wrap it for distribution to hundreds of remote sites around the world. We try our damnedest to run the code as-is, but fairly often have to modify it to remove stuff like:

* Hard-coded input and output file and directory names
* Small and arbitrary length limitations on file pathnames - I've run into buffers that were declared as 53 characters in length, probably because that was what they needed on their system
* Large arrays being allocated on the stack - Linux distros have different default stack sizes

Most of the problems stem from the picky crap that C makes users go through for simple stuff like string manipulation. Both the scientists and the downstream developers like me would be MUCH happier if the scientists worked in something more forgiving (Matlab/IDL/Mathematica, or a flexible scripting language with a decent interface to heavy duty math libraries).

Re:This is so true

[anubi]

As much as I hate to speak not-so-glowingly about the first high-level language I learned, I must admit once I dabbled in Borland C++, I was hooked big-time.

My programming is definitely the exoskeleton. Not for display. Its for me and me alone.

My latest programs are mostly thermodynamic equation solvers to help me with heat transfer and physical work output estimations. These programs model systems I am working on. They help me estimate heat exchangers, entropy loss, flow rates, pipe sizes, refrigerants (mostly R290 Propane), ice formation rates, heat rejection rates. This kinda stuff is meaningless to anyone else, but its exactly what means anything to me. By the time anyone else understands what I have done, they would have been better off writing their own code as I have done for myself. That way, they know exactly what their computer is doing, and would have a really good sense what's wrong when something peculiar is observed.

When I used to work in Aerospace, I had coded lots of programs that helped me do circuit analysis, SMPS magnetics, and phase-locked-loop design. These were mostly re-iterators which would change one parameter to make some other parameter meet some specified value. I hated running someone else's code because if I didn't know exactly what was going on, I was wide open to some very embarrassing (and usually very expensive) misunderstandings.

Even to this day, my old Borland C++ for DOS, with my assorted libraries which I have coded over the years, is my tool of choice for horsing around with computational techniques. When all is said and done, if I need graphical outputs, I can make bitmaps, and if necessary, animate a series of them as an AVI ( I got the code for that right over at SourceForge as EasyBMP,... Thanks, guys! ).

About the fanciest I get is if I *really* get seriously worked up, I put it up as a web page (in the vein of TCP/IP Lean by Jeremy Bentham) so I can transfer data in our out via the RJ45 jack. I have a drawer of 3-Com 905 boards just in case the machine I'm tinkering on doesn't have one.

I don't enjoy at all spending all that time gussying the code up for GUI presentation. (Neither do I enjoy getting all gussied up myself for formal dinners!). I am at the core a scientist/engineer, not at all a suit-guy. I am firmly of the camp that ranks design quality above packaging, even though I know as well as anyone that its packaging that sells a product.

Re:This is so true

[EsbenMoseHansen]

Non-programmers surely shouldn't be making production code in any case :)