Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

'The Code Has Already Been Written'

timothy posted more than 3 years ago | from the is-that-how-you-see-things dept.

Programming 253

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.'"

Sorry! There are no comments related to the filter you selected.

yes I can (1)

Anonymous Coward | more than 3 years ago | (#36864496)

yes I can, at least 5 times more than it took to wright the first time. Thats why I will use it myself to do research, not try to make it usable to others, I do not have that long between needing to publish. It is just not worth doing and with the joys of specialization it probably would not be worth it for someone else anyway.

Re:yes I can (0)

Anonymous Coward | more than 3 years ago | (#36864752)

that explains why your climate model is useless.

Re:yes I can (0)

Anonymous Coward | more than 3 years ago | (#36864810)

What, "wright"?

This is so true (1, Informative)

Anonymous Coward | more than 3 years ago | (#36864510)

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.

Re:This is so true (3, Insightful)

milkmage (795746) | more than 3 years ago | (#36864860)

"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 (3, Funny)

Frosty Piss (770223) | more than 3 years ago | (#36864890)

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 (3, Interesting)

tnk1 (899206) | more than 3 years ago | (#36865034)

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.

Re:This is so true (2)

Frosty Piss (770223) | more than 3 years ago | (#36865550)

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...

Re:This is so true (0)

Anonymous Coward | more than 3 years ago | (#36865086)

So the troll thinks his post is generally complete.. The responder thinks that there is still a tonne
of work to do before it is a flame-ready slashdot-grade troll...

Isnt it ironic......

I concur (4, Interesting)

goombah99 (560566) | more than 3 years ago | (#36865266)

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 (1, Insightful)

RKBA (622932) | more than 3 years ago | (#36865570)

You seem to overlook the fact that computer programmers usually have tight schedule and budget constraints enforced by their supervisor or other management they report to, instead of by the customer (the scientist in this case). Get a computer programmer a gig as sweet as a scientist who can take his or her sweet time to do their research and give the programmer that same open ended time frame with decent equipment and no schedule constraints and you would have a much happier, involved, and more responsive computer programmer.

Re:I concur (2)

SageMusings (463344) | more than 3 years ago | (#36865666)

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:This is so true (1)

elsurexiste (1758620) | more than 3 years ago | (#36865804)

Agreed, when I wrote HPC code for physicists, I was appalled when I saw the programs those people wrote. They wasted precious cycles doing pointless iterations and recalculating stuff. Don't bring a scientist to an engineer fight.

I expected more (3, Insightful)

kikito (971480) | more than 3 years ago | (#36864520)

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 (-1)

Anonymous Coward | more than 3 years ago | (#36864550)

                                              Version 3, 29 June 2007

  Copyright (C) 2007 Free Software Foundation, Inc. <>
  Everyone is permitted to copy and distribute verbatim copies
  of this license document, but changing it is not allowed.


    The GNU General Public License is a free, copyleft license for
software and other kinds of works.

    The licenses for most software and other practical works are designed
to take away your freedom to share and change the works. By contrast,
the GNU General Public License is intended to guarantee your freedom to
share and change all versions of a program--to make sure it remains free
software for all its users. We, the Free Software Foundation, use the
GNU General Public License for most of our software; it applies also to
any other work released this way by its authors. You can apply it to
your programs, too.

    When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
them if you wish), that you receive source code or can get it if you
want it, that you can change the software or use pieces of it in new
free programs, and that you know you can do these things.

    To protect your rights, we need to prevent others from denying you
these rights or asking you to surrender the rights. Therefore, you have
certain responsibilities if you distribute copies of the software, or if
you modify it: responsibilities to respect the freedom of others.

    For example, if you distribute copies of such a program, whether
gratis or for a fee, you must pass on to the recipients the same
freedoms that you received. You must make sure that they, too, receive
or can get the source code. And you must show them these terms so they
know their rights.

    Developers that use the GNU GPL protect your rights with two steps:
(1) assert copyright on the software, and (2) offer you this License
giving you legal permission to copy, distribute and/or modify it.

    For the developers' and authors' protection, the GPL clearly explains
that there is no warranty for this free software. For both users' and
authors' sake, the GPL requires that modified versions be marked as
changed, so that their problems will not be attributed erroneously to
authors of previous versions.

    Some devices are designed to deny users access to install or run
modified versions of the software inside them, although the manufacturer
can do so. This is fundamentally incompatible with the aim of
protecting users' freedom to change the software. The systematic
pattern of such abuse occurs in the area of products for individuals to
use, which is precisely where it is most unacceptable. Therefore, we
have designed this version of the GPL to prohibit the practice for those
products. If such problems arise substantially in other domains, we
stand ready to extend this provision to those domains in future versions
of the GPL, as needed to protect the freedom of users.

    Finally, every program is threatened constantly by software patents.
States should not allow patents to restrict development and use of
software on general-purpose computers, but in those that do, we wish to
avoid the special danger that patents applied to a free program could
make it effectively proprietary. To prevent this, the GPL assures that
patents cannot be used to render the program non-free.

    The precise terms and conditions for copying, distribution and
modification follow.

                                              TERMS AND CONDITIONS

    0. Definitions.

    "This License" refers to version 3 of the GNU General Public License.

    "Copyright" also means copyright-like laws that apply to other kinds of
works, such as semiconductor masks.

    "The Program" refers to any copyrightable work licensed under this
License. Each licensee is addressed as "you". "Licensees" and
"recipients" may be individuals or organizations.

    To "modify" a work means to copy from or adapt all or part of the work
in a fashion requiring copyright permission, other than the making of an
exact copy. The resulting work is called a "modified version" of the
earlier work or a work "based on" the earlier work.

    A "covered work" means either the unmodified Program or a work based
on the Program.

    To "propagate" a work means to do anything with it that, without
permission, would make you directly or secondarily liable for
infringement under applicable copyright law, except executing it on a
computer or modifying a private copy. Propagation includes copying,
distribution (with or without modification), making available to the
public, and in some countries other activities as well.

    To "convey" a work means any kind of propagation that enables other
parties to make or receive copies. Mere interaction with a user through
a computer network, with no transfer of a copy, is not conveying.

    An interactive user interface displays "Appropriate Legal Notices"
to the extent that it includes a convenient and prominently visible
feature that (1) displays an appropriate copyright notice, and (2)
tells the user that there is no warranty for the work (except to the
extent that warranties are provided), that licensees may convey the
work under this License, and how to view a copy of this License. If
the interface presents a list of user commands or options, such as a
menu, a prominent item in the list meets this criterion.

    1. Source Code.

    The "source code" for a work means the preferred form of the work
for making modifications to it. "Object code" means any non-source
form of a work.

    A "Standard Interface" means an interface that either is an official
standard defined by a recognized standards body, or, in the case of
interfaces specified for a particular programming language, one that
is widely used among developers working in that language.

    The "System Libraries" of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form of
packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an
implementation is available to the public in source code form. A
"Major Component", in this context, means a major essential component
(kernel, window system, and so on) of the specific operating system
(if any) on which the executable work runs, or a compiler used to
produce the work, or an object code interpreter used to run it.

    The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities. However, it does not include the work's
System Libraries, or general-purpose tools or generally available free
programs which are used unmodified in performing those activities but
which are not part of the work. For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those
subprograms and other parts of the work.

    The Corresponding Source need not include anything that users
can regenerate automatically from other parts of the Corresponding

    The Corresponding Source for a work in source code form is that
same work.

    2. Basic Permissions.

    All rights granted under this License are granted for the term of
copyright on the Program, and are irrevocable provided the stated
conditions are met. This License explicitly affirms your unlimited
permission to run the unmodified Program. The output from running a
covered work is covered by this License only if the output, given its
content, constitutes a covered work. This License acknowledges your
rights of fair use or other equivalent, as provided by copyright law.

    You may make, run and propagate covered works that you do not
convey, without conditions so long as your license otherwise remains
in force. You may convey covered works to others for the sole purpose
of having them make modifications exclusively for you, or provide you
with facilities for running those works, provided that you comply with
the terms of this License in conveying all material for which you do
not control copyright. Those thus making or running the covered works
for you must do so exclusively on your behalf, under your direction
and control, on terms that prohibit them from making any copies of
your copyrighted material outside their relationship with you.

    Conveying under any other circumstances is permitted solely under
the conditions stated below. Sublicensing is not allowed; section 10
makes it unnecessary.

    3. Protecting Users' Legal Rights From Anti-Circumvention Law.

    No covered work shall be deemed part of an effective technological
measure under any applicable law fulfilling obligations under article
11 of the WIPO copyright treaty adopted on 20 December 1996, or
similar laws prohibiting or restricting circumvention of such

    When you convey a covered work, you waive any legal power to forbid
circumvention of technological measures to the extent such circumvention
is effected by exercising rights under this License with respect to
the covered work, and you disclaim any intention to limit operation or
modification of the work as a means of enforcing, against the work's
users, your or third parties' legal rights to forbid circumvention of
technological measures.

    4. Conveying Verbatim Copies.

    You may convey verbatim copies of the Program's source code as you
receive it, in any medium, provided that you conspicuously and
appropriately publish on each copy an appropriate copyright notice;
keep intact all notices stating that this License and any
non-permissive terms added in accord with section 7 apply to the code;
keep intact all notices of the absence of any warranty; and give all
recipients a copy of this License along with the Program.

    You may charge any price or no price for each copy that you convey,
and you may offer support or warranty protection for a fee.

    5. Conveying Modified Source Versions.

    You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:

        a) The work must carry prominent notices stating that you modified
        it, and giving a relevant date.

        b) The work must carry prominent notices stating that it is
        released under this License and any conditions added under section
        7. This requirement modifies the requirement in section 4 to
        "keep intact all notices".

        c) You must license the entire work, as a whole, under this
        License to anyone who comes into possession of a copy. This
        License will therefore apply, along with any applicable section 7
        additional terms, to the whole of the work, and all its parts,
        regardless of how they are packaged. This License gives no
        permission to license the work in any other way, but it does not
        invalidate such permission if you have separately received it.

        d) If the work has interactive user interfaces, each must display
        Appropriate Legal Notices; however, if the Program has interactive
        interfaces that do not display Appropriate Legal Notices, your
        work need not make them do so.

    A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called an
"aggregate" if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users
beyond what the individual works permit. Inclusion of a covered work
in an aggregate does not cause this License to apply to the other
parts of the aggregate.

    6. Conveying Non-Source Forms.

    You may convey a covered work in object code form under the terms
of sections 4 and 5, provided that you also convey the
machine-readable Corresponding Source under the terms of this License,
in one of these ways:

        a) Convey the object code in, or embodied in, a physical product
        (including a physical distribution medium), accompanied by the
        Corresponding Source fixed on a durable physical medium
        customarily used for software interchange.

        b) Convey the object code in, or embodied in, a physical product
        (including a physical distribution medium), accompanied by a
        written offer, valid for at least three years and valid for as
        long as you offer spare parts or customer support for that product
        model, to give anyone who possesses the object code either (1) a
        copy of the Corresponding Source for all the software in the
        product that is covered by this License, on a durable physical
        medium customarily used for software interchange, for a price no
        more than your reasonable cost of physically performing this
        conveying of source, or (2) access to copy the
        Corresponding Source from a network server at no charge.

        c) Convey individual copies of the object code with a copy of the
        written offer to provide the Corresponding Source. This
        alternative is allowed only occasionally and noncommercially, and
        only if you received the object code with such an offer, in accord
        with subsection 6b.

        d) Convey the object code by offering access from a designated
        place (gratis or for a charge), and offer equivalent access to the
        Corresponding Source in the same way through the same place at no
        further charge. You need not require recipients to copy the
        Corresponding Source along with the object code. If the place to
        copy the object code is a network server, the Corresponding Source
        may be on a different server (operated by you or a third party)
        that supports equivalent copying facilities, provided you maintain
        clear directions next to the object code saying where to find the
        Corresponding Source. Regardless of what server hosts the
        Corresponding Source, you remain obligated to ensure that it is
        available for as long as needed to satisfy these requirements.

        e) Convey the object code using peer-to-peer transmission, provided
        you inform other peers where the object code and Corresponding
        Source of the work are being offered to the general public at no
        charge under subsection 6d.

    A separable portion of the object code, whose source code is excluded
from the Corresponding Source as a System Library, need not be
included in conveying the object code work.

    A "User Product" is either (1) a "consumer product", which means any
tangible personal property which is normally used for personal, family,
or household purposes, or (2) anything designed or sold for incorporation
into a dwelling. In determining whether a product is a consumer product,
doubtful cases shall be resolved in favor of coverage. For a particular
product received by a particular user, "normally used" refers to a
typical or common use of that class of product, regardless of the status
of the particular user or of the way in which the particular user
actually uses, or expects or is expected to use, the product. A product
is a consumer product regardless of whether the product has substantial
commercial, industrial or non-consumer uses, unless such uses represent
the only significant mode of use of the product.

    "Installation Information" for a User Product means any methods,
procedures, authorization keys, or other information required to install
and execute modified versions of a covered work in that User Product from
a modified version of its Corresponding Source. The information must
suffice to ensure that the continued functioning of the modified object
code is in no case prevented or interfered with solely because
modification has been made.

    If you convey an object code work under this section in, or with, or
specifically for use in, a User Product, and the conveying occurs as
part of a transaction in which the right of possession and use of the
User Product is transferred to the recipient in perpetuity or for a
fixed term (regardless of how the transaction is characterized), the
Corresponding Source conveyed under this section must be accompanied
by the Installation Information. But this requirement does not apply
if neither you nor any third party retains the ability to install
modified object code on the User Product (for example, the work has
been installed in ROM).

    The requirement to provide Installation Information does not include a
requirement to continue to provide support service, warranty, or updates
for a work that has been modified or installed by the recipient, or for
the User Product in which it has been modified or installed. Access to a
network may be denied when the modification itself materially and
adversely affects the operation of the network or violates the rules and
protocols for communication across the network.

    Corresponding Source conveyed, and Installation Information provided,
in accord with this section must be in a format that is publicly
documented (and with an implementation available to the public in
source code form), and must require no special password or key for
unpacking, reading or copying.

    7. Additional Terms.

    "Additional permissions" are terms that supplement the terms of this
License by making exceptions from one or more of its conditions.
Additional permissions that are applicable to the entire Program shall
be treated as though they were included in this License, to the extent
that they are valid under applicable law. If additional permissions
apply only to part of the Program, that part may be used separately
under those permissions, but the entire Program remains governed by
this License without regard to the additional permissions.

    When you convey a copy of a covered work, you may at your option
remove any additional permissions from that copy, or from any part of
it. (Additional permissions may be written to require their own
removal in certain cases when you modify the work.) You may place
additional permissions on material, added by you to a covered work,
for which you have or can give appropriate copyright permission.

    Notwithstanding any other provision of this License, for material you
add to a covered work, you may (if authorized by the copyright holders of
that material) supplement the terms of this License with terms:

        a) Disclaiming warranty or limiting liability differently from the
        terms of sections 15 and 16 of this License; or

        b) Requiring preservation of specified reasonable legal notices or
        author attributions in that material or in the Appropriate Legal
        Notices displayed by works containing it; or

        c) Prohibiting misrepresentation of the origin of that material, or
        requiring that modified versions of such material be marked in
        reasonable ways as different from the original version; or

        d) Limiting the use for publicity purposes of names of licensors or
        authors of the material; or

        e) Declining to grant rights under trademark law for use of some
        trade names, trademarks, or service marks; or

        f) Requiring indemnification of licensors and authors of that
        material by anyone who conveys the material (or modified versions of
        it) with contractual assumptions of liability to the recipient, for
        any liability that these contractual assumptions directly impose on
        those licensors and authors.

    All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10. If the Program as you
received it, or any part of it, contains a notice stating that it is
governed by this License along with a term that is a further
restriction, you may remove that term. If a license document contains
a further restriction but permits relicensing or conveying under this
License, you may add to a covered work material governed by the terms
of that license document, provided that the further restriction does
not survive such relicensing or conveying.

    If you add terms to a covered work in accord with this section, you
must place, in the relevant source files, a statement of the
additional terms that apply to those files, or a notice indicating
where to find the applicable terms.

    Additional terms, permissive or non-permissive, may be stated in the
form of a separately written license, or stated as exceptions;
the above requirements apply either way.

    8. Termination.

    You may not propagate or modify a covered work except as expressly
provided under this License. Any attempt otherwise to propagate or
modify it is void, and will automatically terminate your rights under
this License (including any patent licenses granted under the third
paragraph of section 11).

    However, if you cease all violation of this License, then your
license from a particular copyright holder is reinstated (a)
provisionally, unless and until the copyright holder explicitly and
finally terminates your license, and (b) permanently, if the copyright
holder fails to notify you of the violation by some reasonable means
prior to 60 days after the cessation.

    Moreover, your license from a particular copyright holder is
reinstated permanently if the copyright holder notifies you of the
violation by some reasonable means, this is the first time you have
received notice of violation of this License (for any work) from that
copyright holder, and you cure the violation prior to 30 days after
your receipt of the notice.

    Termination of your rights under this section does not terminate the
licenses of parties who have received copies or rights from you under
this License. If your rights have been terminated and not permanently
reinstated, you do not qualify to receive new licenses for the same
material under section 10.

    9. Acceptance Not Required for Having Copies.

    You are not required to accept this License in order to receive or
run a copy of the Program. Ancillary propagation of a covered work
occurring solely as a consequence of using peer-to-peer transmission
to receive a copy likewise does not require acceptance. However,
nothing other than this License grants you permission to propagate or
modify any covered work. These actions infringe copyright if you do
not accept this License. Therefore, by modifying or propagating a
covered work, you indicate your acceptance of this License to do so.

    10. Automatic Licensing of Downstream Recipients.

    Each time you convey a covered work, the recipient automatically
receives a license from the original licensors, to run, modify and
propagate that work, subject to this License. You are not responsible
for enforcing compliance by third parties with this License.

    An "entity transaction" is a transaction transferring control of an
organization, or substantially all assets of one, or subdividing an
organization, or merging organizations. If propagation of a covered
work results from an entity transaction, each party to that
transaction who receives a copy of the work also receives whatever
licenses to the work the party's predecessor in interest had or could
give under the previous paragraph, plus a right to possession of the
Corresponding Source of the work from the predecessor in interest, if
the predecessor has it or can get it with reasonable efforts.

    You may not impose any further restrictions on the exercise of the
rights granted or affirmed under this License. For example, you may
not impose a license fee, royalty, or other charge for exercise of
rights granted under this License, and you may not initiate litigation
(including a cross-claim or counterclaim in a lawsuit) alleging that
any patent claim is infringed by making, using, selling, offering for
sale, or importing the Program or any portion of it.

    11. Patents.

    A "contributor" is a copyright holder who authorizes use under this
License of the Program or a work on which the Program is based. The
work thus licensed is called the contributor's "contributor version".

    A contributor's "essential patent claims" are all patent claims
owned or controlled by the contributor, whether already acquired or
hereafter acquired, that would be infringed by some manner, permitted
by this License, of making, using, or selling its contributor version,
but do not include claims that would be infringed only as a
consequence of further modification of the contributor version. For
purposes of this definition, "control" includes the right to grant
patent sublicenses in a manner consistent with the requirements of
this License.

    Each contributor grants you a non-exclusive, worldwide, royalty-free
patent license under the contributor's essential patent claims, to
make, use, sell, offer for sale, import and otherwise run, modify and
propagate the contents of its contributor version.

    In the following three paragraphs, a "patent license" is any express
agreement or commitment, however denominated, not to enforce a patent
(such as an express permission to practice a patent or covenant not to
sue for patent infringement). To "grant" such a patent license to a
party means to make such an agreement or commitment not to enforce a
patent against the party.

    If you convey a covered work, knowingly relying on a patent license,
and the Corresponding Source of the work is not available for anyone
to copy, free of charge and under the terms of this License, through a
publicly available network server or other readily accessible means,
then you must either (1) cause the Corresponding Source to be so
available, or (2) arrange to deprive yourself of the benefit of the
patent license for this particular work, or (3) arrange, in a manner
consistent with the requirements of this License, to extend the patent
license to downstream recipients. "Knowingly relying" means you have
actual knowledge that, but for the patent license, your conveying the
covered work in a country, or your recipient's use of the covered work
in a country, would infringe one or more identifiable patents in that
country that you have reason to believe are valid.

    If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of, a
covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate, modify
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.

    A patent license is "discriminatory" if it does not include within
the scope of its coverage, prohibits the exercise of, or is
conditioned on the non-exercise of one or more of the rights that are
specifically granted under this License. You may not convey a covered
work if you are a party to an arrangement with a third party that is
in the business of distributing software, under which you make payment
to the third party based on the extent of your activity of conveying
the work, and under which the third party grants, to any of the
parties who would receive the covered work from you, a discriminatory
patent license (a) in connection with copies of the covered work
conveyed by you (or copies made from those copies), or (b) primarily
for and in connection with specific products or compilations that
contain the covered work, unless you entered into that arrangement,
or that patent license was granted, prior to 28 March 2007.

    Nothing in this License shall be construed as excluding or limiting
any implied license or other defenses to infringement that may
otherwise be available to you under applicable patent law.

    12. No Surrender of Others' Freedom.

    If conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot convey a
covered work so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you may
not convey it at all. For example, if you agree to terms that obligate you
to collect a royalty for further conveying from those to whom you convey
the Program, the only way you could satisfy both those terms and this
License would be to refrain entirely from conveying the Program.

    13. Use with the GNU Affero General Public License.

    Notwithstanding any other provision of this License, you have
permission to link or combine any covered work with a work licensed
under version 3 of the GNU Affero General Public License into a single
combined work, and to convey the resulting work. The terms of this
License will continue to apply to the part which is the covered work,
but the special requirements of the GNU Affero General Public License,
section 13, concerning interaction through a network will apply to the
combination as such.

    14. Revised Versions of this License.

    The Free Software Foundation may publish revised and/or new versions of
the GNU General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.

    Each version is given a distinguishing version number. If the
Program specifies that a certain numbered version of the GNU General
Public License "or any later version" applies to it, you have the
option of following the terms and conditions either of that numbered
version or of any later version published by the Free Software
Foundation. If the Program does not specify a version number of the
GNU General Public License, you may choose any version ever published
by the Free Software Foundation.

    If the Program specifies that a proxy can decide which future
versions of the GNU General Public License can be used, that proxy's
public statement of acceptance of a version permanently authorizes you
to choose that version for the Program.

    Later license versions may give you additional or different
permissions. However, no additional obligations are imposed on any
author or copyright holder as a result of your choosing to follow a
later version.

    15. Disclaimer of Warranty.


    16. Limitation of Liability.


    17. Interpretation of Sections 15 and 16.

    If the disclaimer of warranty and limitation of liability provided
above cannot be given local legal effect according to their terms,
reviewing courts shall apply local law that most closely approximates
an absolute waiver of all civil liability in connection with the
Program, unless a warranty or assumption of liability accompanies a
copy of the Program in return for a fee.

                                          END OF TERMS AND CONDITIONS

                        How to Apply These Terms to Your New Programs

    If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.

    To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
state the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.

        <one line to give the program's name and a brief idea of what it does.>
        Copyright (C) <year> <name of author>

        This program is free software: you can redistribute it and/or modify
        it under the terms of the GNU General Public License as published by
        the Free Software Foundation, either version 3 of the License, or
        (at your option) any later version.

        This program is distributed in the hope that it will be useful,
        but WITHOUT ANY WARRANTY; without even the implied warranty of
        GNU General Public License for more details.

        You should have received a copy of the GNU General Public License
        along with this program. If not, see <>.

Also add information on how to contact you by electronic and paper mail.

    If the program does terminal interaction, make it output a short
notice like this when it starts in an interactive mode:

        <program> Copyright (C) <year> <name of author>
        This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
        This is free software, and you are welcome to redistribute it
        under certain conditions; type `show c' for details.

The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, your program's commands
might be different; for a GUI interface, you would use an "about box".

    You should also get your employer (if you work as a programmer) or school,
if any, to sign a "copyright disclaimer" for the program, if necessary.
For more information on this, and how to apply and follow the GNU GPL, see

    The GNU General Public License does not permit incorporating your program
into proprietary programs. If your program is a subroutine library, you
may consider it more useful to permit linking proprietary applications with
the library. If this is what you want to do, use the GNU Lesser General
Public License instead of this License. But first, please read

Re:I expected more (4, Insightful)

rubycodez (864176) | more than 3 years ago | (#36864554)

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 (5, Insightful)

NoNonAlphaCharsHere (2201864) | more than 3 years ago | (#36864628)

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 (2)

rubycodez (864176) | more than 3 years ago | (#36864742)

grad students != scientists

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

Re:I expected more (4, Informative)

16384 (21672) | more than 3 years ago | (#36864840)

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 (3, Informative)

calmofthestorm (1344385) | more than 3 years ago | (#36865412)

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 (0)

Anonymous Coward | more than 3 years ago | (#36864780)

Its no different then any other experimental environment. When you are experimenting the only thing that matter is getting the result you want. When you get the result you want, you then go back and figure out how to make it work in the real world. Thats the standard workflow for any kind of experiment to production. Isnt that what engineers are for? Someone who bridges the gap between scientist and production? Either way i only mention it point out that this entire article is about perspective, nothing more.

Re:I expected more (4, Informative)

gmueckl (950314) | more than 3 years ago | (#36864804)

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 (1)

Oligonicella (659917) | more than 3 years ago | (#36865000)

Frankly, no. Your software is used to determine conclusions. It should be as available and legible as any other portion of the output or your conclusions are suspect.

Else wise, you wind up with "Oops! Can't find it or don't know what that part does."

Re:I expected more (2)

Nyeerrmm (940927) | more than 3 years ago | (#36864630)

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 (4, Funny)

Fnord666 (889225) | more than 3 years ago | (#36864724)

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 (0)

Anonymous Coward | more than 3 years ago | (#36864808)

You don't need to write repurposable software, just maintainable and testable software.

Re:I expected more (4, Insightful)

icebike (68054) | more than 3 years ago | (#36864704)

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 (1)

rubycodez (864176) | more than 3 years ago | (#36864736)

The other half of my career dealt with in-house code writers. I can assure you they have the same problem, by and large, and worse code

Re:I expected more (1)

mjwalshe (1680392) | more than 3 years ago | (#36864790)

yes at my first job (at a world class rnd organization) we built our of fluid dynamics software to model fluid flow and we did a ton of work back checking our code against real life.

Re:I expected more (1)

ceoyoyo (59147) | more than 3 years ago | (#36865242)

Research code should be written with good practices if possible but it should ALWAYS be rewritten when it becomes something more than research code.

Research is trying things out to see if they work. The code will always be messy, confusing and convoluted to some extent. Taking that as a package and turning it into some sort of product is silly.

I have a degree in CS and just recently helped commercialize something that came out of my PhD. The tech transfer company blew their budget hiring a development house to clean up and modify my research code for release. After six months they ran out of money without a working product. I rewrote it in a week from scratch, much faster, smaller, simpler and more maintainable than the research chicken scratch ever could have been.

Re:I expected more (0)

Anonymous Coward | more than 3 years ago | (#36864702)

This is not just these two groups. I have seen the same thing come out of management meetings. "Oh that demo you have looks good lets ship it". Or my personal favorite
"its just one button that should be easy",
"It will be 3 weeks worth of work",
"How can that be its just one button"
"you want that button to do 20 things the code doesnt do yet so 3 weeks".

Not Just Scientists.... (0)

Anonymous Coward | more than 3 years ago | (#36864546)

Most managers think the prototype is the product.

Re:Not Just Scientists.... (0)

Anonymous Coward | more than 3 years ago | (#36864626)

I've encountered code written by plenty of programmers that think this way too. This is a general gripe and OP is simply singling out "scientists" due to some personal prejudice.

Re:Not Just Scientists.... (0)

Anonymous Coward | more than 3 years ago | (#36864670)

I would actually gripe that it is the programmers who think that prototype is the end product. They got the bits moving in the right order from place to place and they think that it has some use. Meanwhile the underlying data doesn't function in the way it's handled and any tiniest modification to the code to handle the actual data which needs to be handled involves changing code in 5-10 different places. Because, hey, the data is already moving through the "code path", so it getting the numbers aligned "should be easy."

Re:Not Just Scientists.... (1)

John Bresnahan (638668) | more than 3 years ago | (#36864866)

Hell, I've had managers who thought the PowerPoint mockup was the product!

One-off vs. Product (4, Insightful)

gomerbud (117904) | more than 3 years ago | (#36864566)

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 (1)

petes_PoV (912422) | more than 3 years ago | (#36865022)

This tells us that academics view of software is incompatible with the commercial world. So all that teaching CS in universities does is train CS graduates to think the same way - that the code is the product. This goes a long way towards explaining why there's so much poorly documented, badly explained and crappily designed stuff out there. Because the people who write it have never been educated in the importance of productising it.

While that shortcoming can be overcome in a commercial organisation, with lots of ancillary staff to write manuals., design UIs and even correct the spelling in the user interactions, there's little chance that freeware authors would have those skills, or even care about the lack of those qualities - it explains a lot.

Re:One-off vs. Product (5, Insightful)

swillden (191260) | more than 3 years ago | (#36865236)

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.

Re:One-off vs. Product (0)

Anonymous Coward | more than 3 years ago | (#36865458)

I agree.. this is similar to what I call an execution debt with .NET, java and other 'managed' runtimes.. the programmer takes less time developing, but the longer execution times add up for the customer..

My dear abacus (0)

DigiShaman (671371) | more than 3 years ago | (#36864572)

If I'm getting this right, scientists view software as nothing more than a specialized calculator. They don't want a program that spoon-feeds them information let alone set the premise for how data should be calculated and organized.

Programmers on the other hand feel the opposite and think their users should do nothing more than input data and record the results. The research being already incorporated into the software and all that.

Re:My dear abacus (1)

Brett Buck (811747) | more than 3 years ago | (#36864764)

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.



Re:My dear abacus (1)

DigiShaman (671371) | more than 3 years ago | (#36865062)

I though so. At least in the field of geo-science, it's the geologists who use full software suites to prepare interpretation data. However, it's the geo-science engineers whom use a half dozen obscure tiny programs specifically to crunch the numbers. If I had to make a wild guess, I'm thinking the same hold true for aerospace, automotive, and architectural design.

Re:My dear abacus (2)

swillden (191260) | more than 3 years ago | (#36865304)

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.



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:My dear abacus (0)

Anonymous Coward | more than 3 years ago | (#36865670)

You can thank hackers & researchers for having computers.

The notion of "technical debt" is entirely centered around the idea that code should be reused. In my experience, the transition from research to production should always, invariably, absolutely be a complete rewrite.

The main reason is not that of convenience; research includes, by its nature, blind alleys, suboptimal approaches and mistaken assumptions. Those all will leave their trace in the program, which becomes more complex as a result. The way forward is to distill the essential mathematical beauty of the final algorithm, and use it as a spec for writing the new version of the software. And since you have a spec, you can employ all the best software engineering practices in the world - and they will deliver a great, maintainable product.

Black & White (1)

Zaphod The 42nd (1205578) | more than 3 years ago | (#36864586)

This assumes people are very clearly an engineer/programmer OR a scientist. But I would consider most software engineers to be computer scientists as well. Its a fairly nonsense distinction. The analogy to spiderman and doc ock is fun, but ultimately metaphor don't prove anything.

"Programmers need to understand that sometimes a program really only needs to run once, on one set of input, with expert supervision. Scientists need to understand that prototype code may need a complete rewrite before it can be used in production."

This is just an extreme generalization, to the point of stereotyping.

Re:Black & White (1)

ETEQ (519425) | more than 3 years ago | (#36864676)

No, this is a very strong distinction in *some* fields. For example, in observational astrophysics, most scientists spend much of their actual working time writing code... but they clearly think of themselves as "scientists" and not at all as programmers, with the mindset the article notes. Occasionally people get hired to be "software support" that are clearly supposed to be engineers/programmers, and they think in very different ways.

The end result is that despite programming as much as, if not more than, the "programmers", many of these scientists don't follow any of the rules about software readability and reuse that programmers have learned the hard way over decades. You can immediately look at code and tell who was trained to program by/as a scientist and who actually learned as a programmer: the algorithms often work just as well, but the former are impossible to understand and build on, while the latter are much more readable.

Re:Black & White (1)

Zaphod The 42nd (1205578) | more than 3 years ago | (#36864712)

Then these are still just tips that EVERYONE who writes programs should be aware of. Don't over engineer, don't worry too much about efficiency at first, premature optimization is the root of all evil. On the other hand, be aware that readability and maintainability can be very important in code if it is going to be used more than as a one-off, or if it is going to be used by a team.

Re:Black & White (1)

plover (150551) | more than 3 years ago | (#36864776)

The point is that it's a one way street. Software engineering is a specialization of engineering science, but most scientists aren't software engineers. A scientist can create the embodiment of an algorithm representing a solution to their problem, but don't think of it in terms of the qualities of reusability, modularity, interface, coupling, cohesion, exception handling, security, data integrity, etc. And they aren't supposed to: they're trained to understand biology, botany, physics, or whatever their field of expertise is, and never studied software engineering.

Think of it in terms of chemistry. A research scientist may create a test tube of a unique compound in the lab, and she would say she's solved the problem. But she would turn it over to a chemical engineer to figure out how to make the stuff in tanker truck quantities. The engineer would understand the performance and limitations of the pumps, mixing tanks, heaters, and catalysts needed to scale the problem up to a factory environment. It's a different job, requiring different knowledge.

All the software engineers I know are perfectly capable of emitting a dense chunk of spaghetti code to solve one task one time, the same as the scientists, but they generally don't because they know spaghetti code is difficult to prove that it will behave correctly, even just the one time it's needed. Unlike non-computer-field-related scientists, they also know better than to call such code "production ready."

Re:Black & White (0)

Anonymous Coward | more than 3 years ago | (#36864842)

I wouldn't consider most software engineers computer scientists. You don't think a mechanical engineer is a scientist, so why a software engineer?

Computer scientists are those that design the programming languages we use, the compilers and the hardware they run on.

Disclaimer: I'm a software engineer, not a computer scientist.

So everybody starts out as a scientist? (1)

Anonymous Coward | more than 3 years ago | (#36864588)

When I learned to program, my programs would only run for me. Every program would only do something useful if the user (me) adhered to one "obvious" way of interacting with the program. Then I observed that other people would not understand the obvious way of using my programs. I believe that over time, experience teaches programmers to avoid this problem - first by retrofitting existing programmers, then by looking for ways of writing less personal programs from the start. Eventually this leads to an appreciation for design guidelines, standards and generally programming in the large concepts.

This is a new idea? (0)

Anonymous Coward | more than 3 years ago | (#36864592)

Most "software engineers" in the comercial world are exactly the same. As soon as its written and minimally functional its off to production. The idea that software in the comercial environment is engineered is a pipe dream.

Re:This is a new idea? (1)

Kenneth Stephen (1950) | more than 3 years ago | (#36864828)

Maybe this is your experience, having come from working on applications that serve mom and pop shops, but don't assume that your experience is the same as everyone else's. Mine is the opposite of yours. Most applications are engineered for maintainability and very often, when compromises are made in shipping things out the door, it is often the function points that are left on the floor, rather than shipping function points backed by unmaintainable code.

The only exceptions to this that I have seen have been in shops which are so small that the development team lacks an architect who can enforce this discipline, and you have a team consisting of prima donnas. I'm not saying that small teams can't deliver good code. Just that most of the screwups that I've seen come from small teams operating without any discipline (and they typically lack the discipline because they think they are small enough to operate in that mode).

Dealing with that now (1)

Anonymous Coward | more than 3 years ago | (#36864594)

Posting anonymously for a reason... The software we use to manage data flows from a certain big experiment in Switzerland (Globus, Bestman) are excruciatingly bad. Software gets promoted from version N to N+1, not because they have made major bug fixes or functionality upgrades, but because it's grant-writing time again and they need to show progress.

Software written by scientists often barely works, and heaps misery upon misery upon the hapless admins who have to maintain the service. Exposure to Grid software, in particular, should be regulated by OSHA.

Physicist Speaking Here (4, Interesting)

digitrev (989335) | more than 3 years ago | (#36864600)

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.

Re:Physicist Speaking Here (0)

Anonymous Coward | more than 3 years ago | (#36864708)

Every single piece of code I write is written for a purpose.

I should certainly hope so. Otherwise, it would just be a complete waste of time.

[...] so it's practically a guarantee that my code will never have commercial release.

This is exactly how unmaintainable code gets foisted on someone. Sure, statistically speaking, it's completely true and these pieces of code don't need to be maintainable or modular. But someone later decides that a one off program that was never meant to be maintained is useful and needs to be maintained, improved, and expanded. Nobody ever sits down and says, "I'm going to write a piece of commercial software, only I'm going to make the code base an complete mess so that nobody can ever understand it."

Re:Physicist Speaking Here (0)

Anonymous Coward | more than 3 years ago | (#36864836)

Nobody ever sits down and says, "I'm going to write a piece of commercial software, only I'm going to make the code base an complete mess so that nobody can ever understand it."

Hmm, you never had to deal with somebody who was in job-protection mode?

Re:Physicist Speaking Here (1)

ETEQ (519425) | more than 3 years ago | (#36864722)

This is exactly the attitude I encounter very often when I talk to other physicists and astrophysicists (I'm the latter). But I think this actually is partly a self-fulfilling prophecy. While it's true that many of the codes we write will never be re-examined by anyone, a few of them will. But many scientists write totally inscrutable code, so no one bothers trying to re-use code in that way, because it's easier to just start over from scratch. Thus, no wonder everyone thinks no one is going to look at their code - if they wrote more readable code, perhaps someone would!

That being said, I certainly have had to take code from someone and build upon it or make it work properly for a slightly different instrument or something like that, and I can definitely say that I'm biased, because those experiences are invariably the most frustrating work I find myself doing! Part of it is that a lot of scientists seem to say "if I add comments everywhere, that's all that's needed to make it easy/readable," but they then don't follow indentation rules, or consider their code structure before they implement, or consider possible extensions of their code when they are writing it. So it wouldn't take that much more work, but some scientists just don't realize that in fact it probably is worth the effort for the sake of future work.

Re:Physicist Speaking Here (0)

Anonymous Coward | more than 3 years ago | (#36865722)

Many of the codes? You sound like one of those people that bug forums asking for the "codez" to do things way beyond their capability. It is "much of the code we write". I'm not being a grammar nazi. It just sounds stupid.

Re:Physicist Speaking Here (0)

Anonymous Coward | more than 3 years ago | (#36865408)

With that kind of attitude to the differences in programming, it's no wonder people question climate models generated by 400 year old tree rings.

Re:Physicist Speaking Here (1)

zrbyte (1666979) | more than 3 years ago | (#36865532)

Based on my experience, the amount of work that I put into creating quality code is dependent on the task at hand. When I know that the script, software will only be used once or twice (prepare the graph, etc.) it's not worth it to put a great amount of work into it to make it usable. In these circumstances I mostly adhere to the Klingon coding rules [] : "A TRUE Klingon warrior does not comment his code!"
Now, it should be noted that, sloppy code means: usability is utter shit and should not be confused with errors in the algorithms, maths and implementation of these.

In general, the more scientific value a piece of code will have, the further it will be developed [] (not necessarily by scientists).

Re:Physicist Speaking Here (1)

burgundy (53979) | more than 3 years ago | (#36865632)

Yes, but if you work in a large collaboration then your analysis ought to past muster with a larger audience than just your supervisor. And don't dismiss "the guy who has to work on my code later" so blithely. It depends where your code sits in the analysis chain, but it might have quite a long life ahead of it. I've seen (and had to deal with) plenty of code written by long-gone graduate students.

This is so true (5, Insightful)

LordNacho (1909280) | more than 3 years ago | (#36864612)

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.

Re:This is so true (1)

MacTO (1161105) | more than 3 years ago | (#36864898)

Many of those people who "can't program" actually can program. They simply understand the program's requirements. Maintainable code is not always a requirement since a lot of software written in research labs is intended to be written once and run a handful of times.

It's also worth noting that properly structured code from a programmer's perspective is not always the same as properly structured code from a scientist's perspective. "Turn(ing) problems into object models," may be the last thing that scientific code needs because most problems are procedural in nature (particularly for data analysis, and even for modelling).

Re:This is so true (1)

Chris Mattern (191822) | more than 3 years ago | (#36865326)

Maintainable code is not always a requirement since a lot of software written in research labs is intended to be written once and run a handful of times.

While those of us who write programs on a regular basis know that often there's nothing more permanent than temporary code.

Re:This is so true (1)

quietwalker (969769) | more than 3 years ago | (#36864936)

You get what you ask for, because they know how to turn problems into object models, but you have to ask VERY carefully.

As a developer (and one in the financial industry at that), if there was one single thing I could suggest that would have the biggest impact on software development, it would be this:

              Enforce a 'Good Requirements' only policy.

This may require a lot of training, and a great deal of rejected requirements for not meeting the standard, and cause great grief to those who think their 15 second explanation of an 80+ man hour feature implementation is sufficient. It certainly requires that the programming team be empowered to reject bad requests.

I think I have yet to work at a company that has not effectively told me that they would not meet their deadline if they took the time to spell out what they actually want. When I point this out, the universal response is something along the lines of a shrug and a smirk. Often followed by a "well, it's 5 o'clock, I gotta run ... let me know how that turns out tomorrow morning."

In all honesty, I have to say that I feel it's pure laziness. When I give lessons, use SDLC software, etc, the thrill goes from "We're doing it right," to "Oh no! I have to do work!". Then they try to work around the system or believe that desk drive-bys are still okay, and then complain when someone is laid off or quits and no one can pick up their work.

I don't know what's so hard about it. The idea is simple and applies to so many things; hard work now results in less work later, when it's more expensive and time-critical. Isn't this taught in business college, PMP certification, etc? What the heck?!?

Re:This is so true (1)

dcollins (135727) | more than 3 years ago | (#36865536)

Isn't this short-term thinking endemic to the financial industry in the first place? I mean, programmers joke about unmaintainable code as personal job security -- but hard-charging finance guys would actually act on that.

I assume they understand the incentives of their job, and have the training and/or personality to ruthlessly focus on that. They have bonuses and commissions to collect, yes? They get no additional income from well-written code, or something that assists their replacement next quarter or next year. They don't really give a crap if the next guy's job is feasible or not -- then he can serve as a scapegoat in the political throw-under-the-bus game. That's my impression (not involved in finance except for stories from a friend in insurance IT).

Hardly surprising (1)

Inf0phreak (627499) | more than 3 years ago | (#36864624)

This is hardly unexpected. The code needed to process data from science experiments can be years in the making by one or few persons sculpting it to do the job they need done. It might be a bit much to say that it's throw-away code, but once the paper is out the door it probably won't see much use again.

All of this combined with the fact that the coders are scientists and thus aren't concerned with UI issues and whatnot make it so it may take a lot of manual intervention at various steps to use the software, but in the end the science gets done... and you make a neat gun for the people who are still alive </portalroll>.

Re:Hardly surprising (1)

maxwell demon (590494) | more than 3 years ago | (#36865090)

More importantly: As scientist, you expect to be able to change the code at any time if needed. Therefore if some branch of your code isn't entered by your problem at hand, it's absolutely acceptable to not put any effort into it, and just make sure that you don't run it unknowingly (e.g. by adding a message and an abort). Then, if a future problem happens to get into that code path, you still can work on that part of the code. But in the mean time, you have produced useful results which you might not have produced if you had spent your time on that not yet used code. And not being able to publish those results timely might in the end render your whole work useless because someone else was faster, published the results you would have gotten, and for lack of genuine results your grant wasn't renewed.

The point is: For the scientist, the program is a tool. It's not the end product. The difference is similar to the one between doing an analytic calculation to get a result, and writing down the same calculation for a text book. The calculation you do for a result has just enough written down to get at the result and convince yourself that you didn't calculate wrong. It's almost certainly not ready to be published in a text book.

I've been in that position, more or less (1)

93 Escort Wagon (326346) | more than 3 years ago | (#36864634)

And I gotta say - the linked blog post makes me think the author just got in an argument with his scientist boss, and he lost.

Re:I've been in that position, more or less (1)

calmofthestorm (1344385) | more than 3 years ago | (#36864692)

*shrug* different tools for different purposes. I'm a graduate student, and writing good, scaleable, maintainable code would take far more time than I have, and is not what I'm paid to do. I'm paid to produce results. I've worked in industry before building huge infrastructure systems with many other people, and it calls for a completely different product. I'd go so far as to argue different skill sets. But speaking as someone who knows how to write "good" code, it's a waste of time for most academic applications, particularly outside CS.

If the software is the product, write it well, if not, get it done fast and right.

Not so true (1)

giuseppemag (1100721) | more than 3 years ago | (#36864642)

As a university researcher in applied game development I pretty much work on abstracting and generalizing *finished* software.

I usually do this: I spend between six months and a year building a game according to some technique, framework or new language I am researching. The game is then finished, published and even sold. Then a paper is written describing the technique and its inpact. Lather, rinse, repeat.

This is just anecdotical experience, but in this day and age of shrinking research budgets it is not uncommon to find scientists who also package and sell their research.

So this whole "programmers are cool, they develop finished stuff while the other a-hole scientists quit halfway" is just a stupid generalization based on a superficial stereotype of academia. Also, THIS IS NOT NEWS, and even if it were it wouldn't matter.

Re:Not so true (1)

prefec2 (875483) | more than 3 years ago | (#36864824)

With scientists they do not mean engineers. They mean only mathematics, physics and its derivatives.

Re:Not so true (1)

giuseppemag (1100721) | more than 3 years ago | (#36864900)

Computer scientists? I'm a programming languages guy, type systems and declarative/functional programming. I hardly see myself as an engineer and I've never published at an engineering conference...

Computer Science and Engineering (1)

prefec2 (875483) | more than 3 years ago | (#36865112)

In software development things become more and more planned and predicted and tested over the last decades. Something which was more or less an art is becoming a set of established techniques. So software development becomes more and more and engineering task. On the other hand. Software developers and designers are always trying to use new stuff because the problems of today cannot be solved with the technology from 10 years ago.

I was on an software engineering workshop on modeling and domain specific languages. After my presentation I said that I think we are not engineers. As of the above situation. However, we use engineering methods/techniques to handle complexity and to get the information we need to model, write and deploy software.

Some truth to this (0)

Anonymous Coward | more than 3 years ago | (#36864662)

I recently worked with two software companies on the same project. One wrote software for any old client, the other was a specialised scientific software house.

The scientific software house wrote some really appalling code, but boy, did they care that they understood what the software was supposed to do, and that it delivered the right results.

The generic software house wrote clean, maintainable code using industry best practices... and wrote code that was almost useless, as they gave no thought to what it really needed to do. They billed us for a huge number of changes just to get it to functional (as opposed to well written) status.

Does it matter? (1)

Chemisor (97276) | more than 3 years ago | (#36864698)

The days of long-lived software are pretty much gone. There are a handful of companies that still maintain the programs they've written a long time ago, but most programs written today are written quickly and dirtily, to spring up one day and fall into oblivion the next. "Apps" are little more than short fads that come and go, easy to implement due to having little functionality, and just as easy to discard for the next one.

Re:Does it matter? (0)

Anonymous Coward | more than 3 years ago | (#36864802)

Industrial programs are a very strong counter point - if there's money in it then there will be support for it. The socftware required to communicate with and configure 10, 20 or even 30 year old hardware exists (I work with some of it) and will continue to exist while the companies that use these systems need it.

If we say "We don't support that any more, buy something new." they say "Okay, do you have 's phone number?", and buy our machines again. Naturally there's a limit, but in the oil and gas industry if equipment is working then it tends to get left alone - very much a case of "If it is not broken then there is no need to repair it.".

Re:Does it matter? (0)

swalve (1980968) | more than 3 years ago | (#36864830)

Only because software has been so universally bad for so long that people no longer respect it. If the delicate geniuses currently writing software had any pride, they would do it right the first time, and then it wouldn't have to be so commoditized. Every time I see someone call programming an art, it makes me want to shit. Art??!

If programmers want their product to be taken seriously, start having some damned standards. When I read the lists of outstanding issues and bugfixes in various releases, my mind boggles at the ridiculousness of it. How did someone write code that's supposed to do that thing, but it doesn't?

Re:Does it matter? (1)

sjames (1099) | more than 3 years ago | (#36864912)

I have dealt with a number of HPC programs on a regular basis that are old enough that they still refer to the input data as a "deck". They will never be completely rewritten and even small changes are few and far between because of the nightmare of re-validation. Unfortunately, because they started life as one-off research code, they are also fantastically sensitive to changes in the compiler due to accidentally depending on implementation quirks rather than the standards.

Re:Does it matter? (1)

rubycodez (864176) | more than 3 years ago | (#36864946)

Maybe you overlook the longer lived stuff because it's everywhere and we're used to seeing it. What about the operating systems, languages and utilities your computer are using? your office applications? the major database management systems? What about the webserver software? what about commerce, banking, healthcare, MRP, ERP systems?

No duh (1)

Anonymous Coward | more than 3 years ago | (#36864714)

Scientists write software to do science. Programmers write software because they've spent their lives learning how to perfect the art..

Re:No duh (1)

agm (467017) | more than 3 years ago | (#36865744)

Programming *is* a science - one that deals with the abstract. The scientists referred to in the article deal with the physical. I'm a software engineer. When people ask me what I do, I say that I design, architect and build things that are not real. The sad thing is that most of it is for companies to find better ways of extracting money from people.

Excellence takes teamwork (1)

yesterdaystomorrow (1766850) | more than 3 years ago | (#36864728)

It is indeed true that code written by scientists often needs polish. But the other truth is that it's often necessary for a scientist to write the code. Too many programmers think that all they have to do is write code to spec. But when you're writing code that supports the needs of a subject that takes a decade to master, only someone with that mastery can understand what the specs mean.

Often, the best results emerge when a scientist writes the code, and a programmer reviews and polishes. But that can cause a lot of friction: scientists don't like criticism, and programmers would rather program than review and polish. It's a challenge for project management.

This isn't true for just scientists. (1)

BitterOak (537666) | more than 3 years ago | (#36864732)

This has nothing to do specifically with scientists, this is more about the difference between code you write for your own use versus code you write for others to use. Scientists aren't the only people who write code for their own use!

Conversely, scientists often do write code that needs to be shared, sometimes among large groups. I used to work in the field of experimental high energy physics, which typically have collaborations of hundreds or even thousands of people. Some of the software I worked on was to be used by the wider collaboration, and there were many coding practices we were expected to adhere to, in order to ensure the code worked properly on all the different systems in use. (We supported about 6 different OS's: VMS and several flavors of Unix.) Other software was written for my own personal analysis, and it wasn't meant to be shared, although it was expected that I at least run some consistency checks to ensure the code was giving reasonable results.

On the other extreme are general purpose tools, written by scientists for use by scientists on many different collaborations, such as CERNLIB, Root, Minuit, GEANT, etc. And lets not forget, the World Wide Web was created at a high energy physics lab (CERN) to facilitate online collaboration! It seems to have proven robust enough for a somewhat wider use!

This is a real problem (4, Insightful)

smcdow (114828) | more than 3 years ago | (#36864746)

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):


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 (1)

JazzHarper (745403) | more than 3 years ago | (#36865044)

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.

A couple of thorough re-orgs should be sufficient undo all that.

Re:This is a real problem (1)

Titoxd (1116095) | more than 3 years ago | (#36865308)

Have you considered using Fortran? Matlab is much closer to Fortran than C (arrays start at 1 instead of 0, to pick a rather annoying bug), has plenty of libraries available (just like C) and the newer versions of the language standard are not the spaghetti-laden soup they used to be.

No wonder (1)

prefec2 (875483) | more than 3 years ago | (#36864816)

Most scientists (e.g. physicists, chemists, mathematicians, geo-*) solve their problems with formulas. Then they code these formulas in a coding language which is most likely C, Fortran, Algol68 (not really) or Mathlab. While programmers often also only code, software engineers try to design software and have to incorporate different aspects. This is even true when writing software for the sciences. However, the same apply to all the other fields we write software for.

People constantly misuse the word 'Programmer' (1)

Assmasher (456699) | more than 3 years ago | (#36865028)

There are programmers and there are Software Engineers.

The two things are different, and people who don't know any better equate them.

There's nothing wrong with being a programmer at all, but programming is a subset of Software Engineering.

It's akin to the difference, imho, between a construction worker and an architect. One can be a hack or a craftsmen, but tends to have a smaller overall picture of the where/what/when/why behind decisions that often seem unimportant or superfluous. The other can be incompetent or a good engineer and tends to have (or is supposed) the background of understanding to know why things are or should be done a certain way - at the very least being able to understand the impact of short term decisions on the long term.

There are, of course, exceptions to everything.

Exception handling is the challenge (1)

SpaghettiPattern (609814) | more than 3 years ago | (#36865168)

Punching down the logic was the easy and fun part. Exception handling is the main challenge. Then come middleware issues.

It's easy to disassociate yourself and to become a patronising git and to claim to have done the hard work. Making software maintainable, supportable and well performing is never a matter of course.

Generally speaking it is hard for a non-programmer to imagine a programmer's job. The tedious thing is that scientists will always have significant influence and may not appreciate the hard programming work. This is even more so with clueless manager.

Code unnecessarily reengineered (1)

amightywind (691887) | more than 3 years ago | (#36865272)

Yes, I have seen some bad code come from scientists and engineers. I have also seen simple but ugly code, unnecessarily reengineered by OO design zealots and broken and ruined with complexity. It depends on who did the writing and the rewriting. The best policy is for software engineers to give scientists simple interfaces to write to and then stay out of their way.

Mhmm Weird Scientist, (1)

Maxhrk (680390) | more than 3 years ago | (#36865300)

"The Code Has Already Been Written" sound like Scientists don't believe in evolutionary while Programmers do. Really?

This is also true in medical devices and in biolog (0)

Anonymous Coward | more than 3 years ago | (#36865320)

This is also true in medical devices and in biologics (medicines) - i.e., with respect to scientific and engineering knowledge, not just computer programs.

As an engineer and manager in product development and tech transfer roles, I'm continually amazed at how little R&D biologists know or care about tech transfer, manufacturing, marketing, logistics, etc.

I started in R&D, and was guilty of that once, but still ...

meyers briggs.. (0)

Anonymous Coward | more than 3 years ago | (#36865356)

the old INTJ vs INTP battleground...

Optimism (1)

dcollins (135727) | more than 3 years ago | (#36865442)

"All programmers are optimists. Perhaps this modern sorcery especially attracts those who believe in happy endings and fairy godmothers... But however the selection process works, the result is indisputable: 'This time it will surely run,' or 'I just found the last bug.' So the first false assumption that underlies the scheduling of systems programming is that all will go well, i.e., that each task will take only as long as it 'ought' to take. The pervasiveness of optimism among programmers deserves more than a flip analysis..." [Fred Brooks, Mythical Man-Month, p. 14-15]

So really this observation is really just a slightly-different flavor of something that is characteristic of all programmers.

I had one job where I was assigned a particular game feature. So I took a week and I did it. My technical manager took it and played with it and came back to me completely shocked: I couldn't find any bugs! he says. (Also: I was continually being chastised for long schedules, and having my estimates arbitrarily cut in half by the manager.) That job convinced me I had to get out of the industry.

"Software Carpentry" (1)

bgoffe (1501287) | more than 3 years ago | (#36865476)

The site Software Carpentry [] aims to teach scientists and engineers key programming tools and approaches to write better code. There are many, many resources to help non-programmers write better code. The fellow who runs it, Greg Wilson, has done yeoman work in this regard. I was so impressed that I invited him to an academic conference and we were really pleased.

My entry into this problem is "Where's the Real Bottleneck in Scientific Computing?" [] (from the American Scientist). It says everything that the article here does and much more. Highly recommended.

gui-y it up gui-y it down (1)

smoothnorman (1670542) | more than 3 years ago | (#36865506)

In all the (big-pharma) shops i worked at, i'd write and test the command-line number cruncher inside (until my boss could get a paper or two out of it) then hand it to "two guys" that would slap on a stunningly restrictive (in terms of functionality) GUI (itself a third party tool set based on Qt) and it'd sell just fine sweat [shrug]

I always write for someone else (1)

Anonymous Coward | more than 3 years ago | (#36865558)

I write all my code for someone else: me a year from now.

I'm proud to say I can pick up something I wrote ten years ago and be quickly up to speed. The basic principle is this: something that is obvious now will not be so a month from now. Writing robust software now will save a whole pile of misery later. It isn't just a case of having to re-write a piece of software; when it comes time to write a paper, you have to go back through your software and figure out precisely what you have done.

The other thing is that, these days, you may face an FOI request. You really don't want crap programming exposed for public ridicule.

But things are getting better (0)

Anonymous Coward | more than 3 years ago | (#36865592)

This issue is actually getting less bad in some cases. In my area of biology, there is a strong trend towards journals requiring that analysis code be archived along with data, as a condition for a paper being accepted. Also, grant proposals are looked upon more favorably when they promise to develop, document, release, maintain, and support software that implements their new ideas. These requirements make me plan more for future use and clean up my code so that it's not an embarrassment when others see it. I think this is all contributing to a healthier scientific and software-ific environment.

Is it really news? (1)

140Mandak262Jamuna (970587) | more than 3 years ago | (#36865700)

It is like saying:

"DIY fixers do a hack job of wiring their routers in their home basements to their computers in second floor bedroom. They drill a hole and take the cable clearly marked "indoor use only" outside the home hanging in a lazy lopsided catenary curve up to the bedroom window, take it through the window into the house. The window sash does not close properly and allows bugs to get inside.

Professional electricians on the other hand use flexible drills to make nice access holes, wire the cables, patch up the dry wall, clean up all the debris, and charge you 90$ an hour. "

P.S: Exercise to the reader: Make it a car analogy.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?