06 November 2010

Technical Debt - NSF wants to know.

'Every time a new piece of software is added to the code base, Baker said, an addition is made to its technical debt. Code is the principal, and software maintenance is the interest payment, "so the more code we have out there, the bigger our debt, hence the more maintenance, hence the more interest payments." '
- Push To Measure Technical Debt.

28 October 2010

Agreeable Quotes!

Quotes from Nature's

Computational Science ... Error ... why scientific programming does not compute. By Zeeya Merali.

"There are terrifying statistics showing that almost all of what scientists know about coding is self-taught," says Wilson. "They just don't know how bad they are."

"In the long term, though, Barnes says that there needs to be a change in the way that science students are trained."

"Science administrators also need to value programming skills more highly, says David Gavaghan, a computational biologist at the University of Oxford, UK."

"Gavaghan now uses the software industry's 'master–apprentice' approach to train graduate students in his lab."

And this one is really fitting if you work at a national laboratory:

"To all scientists out there, ask yourselves what you would do if, tomorrow, some Republican senator trains the spotlight on you and decides to turn you into a political football. Could your code stand up to attack?"



I couldn't agree with some of these quotes more .... see Where Is Software Development Really Learned?

Nature Article: Publish Your Scientific Code! Really?

Recently, Nick Barnes wrote a one page article in Nature encouraging scientist to publish their code pretty much as-is. He makes many good points especially ... if the results from your code are good enough to publish, then your code should be good enough to publish too.

My main concern is the possible unintended consequences that scientists will think they never need to improve their software developing skills since what they do is "good enough." When in reality, often, their skills are not good enough and that many scientists are publishing results that are not good enough due to the poor software they have developed. We do not want scientists to lose the sense of urgency to do a better job in writing good software that is a real scientific tool and that produces good science. Yes, I could see where once they publish their code and if peer review deems it flawed, or the like, that they might be embarrassed and want to do better.... but highly unlikely. Besides scientific software should be peered reviewed with code reviews and/or pair-programming just like any other type of software before results are published from it or the code is released to begin with.

Again, "Be a better scientific software developer today than yesterday!"

25 July 2010

Every wonder how to get started with TDD?

Recently, Brett Schuchert has started to put together a series of videos called C++ and TDD. Here is the first in the series called C++ and TDD, Getting Started. Follow the other links to see his follow-on videos.

I found these to be pretty much how it feels to do TDD with C++. He uses Eclipse with the CDT plugin for C++ and CppUnit for a unit test framework. The development environment looks very similar to how we do development on the MCATK team.

The only exception is that CppUnit has been integrated into Eclipse so that Eclipse is aware of the CppUnit. Whereas on the MCATK, we use UnitTest++ and Eclipse is unaware of the unit test framework though our build system is aware of it.

These videos are pretty straight forward and the example project he is working on is easy to follow. If you have been curious about TDD and how it is done then have at look at Brett's videos.

14 January 2010

Academic Earth - University Lectures

Recently, I found a link to an Introduction to Solid State Chemistry course that is OpenCourse. The lecture I listened to was on Diffusion and the professor showed the connection between mass transport by diffusion, Fourier's first Law, and Ohm's Law which Fick, himself, reported on about 150 years ago. Cool.

This is provided at Academic Earth and there are many subjects and many lectures from physics to the bible. Pretty impressive. Have a look.

05 January 2010

Scientific Software Developer Mantra


"Care enough to be a better scientific software developer today than yesterday."



For several months now, I have been trying to word a personal mantra for a scientific software developer (SSD). There has been about half a dozen mantras that I have been tossing around without settling on anyone mantra. They all were similar and the basic idea started with was, "Get better each day." Which in life is a good mantra.

So I decided to settle on the one above and to use it until a more polished one emerges (refactoring for emergent design.) It may seem too wordy for a mantra but it conveys how I want to behave as a SSD. Of course, if I was doing other parts of computational physics then computational physicist could be inserted easily.

Recently, Dan Pink posted a video called "Two Questions" about two questions that could change your life in 2010. I thought question #2 was coincidentally appropriate for this post.

Follow-up To Where Is Software Development Really Learned?: Stroustrup's Article

A few months ago I pondered Where Is Software Development Really Learned? And my thoughts were, "We learn on-the-job and by professional development but not often in school. Even for many CS majors."

Recently, Bjarne Stroustrup wrote on a similar topic in What Should We Teach New Software Developers? Why?

Again, what jumps out at me in Stroustrup's article (especially in The Problem section) is where is software development really learned? One of his conclusions was similar to mine (internships and mentoring in industry along with formal education) in that academia and industry need to bridge this gap.

Interesting article.

03 January 2010

Simulation Model: Stage Four - Verification

Thinking about Pople's Quantum Chemistry Models (or in more general Simulation Models), where five stages may be distinguished as:

1) Target
2) Formulation
3) Implementation
4) Verification
5) Prediction

I got to thinking about the fourth stage:

4) Verification
The next step is to test the model against known chemical facts to determine whether the target has been achieved. If quantitative accuracy is being sought, this can be done by various statistical criteria such as the root-mean-square difference between the results of the theoretical model and experimental data. In selecting such a dataset, it is important to make it as broad as possible, while limiting it to experimental facts known to be of high quality. If the results of such a comparison do meet the target requirements, the model may be said to
be validated.

and how this applies to almost any other type of scientific endeavor.

Can stage four be skipped? In doing so how do we know stage five (Prediction) results are correct? How do we start problem solving if stage five results are incorrect? If stage five results are correct then how do we know that several wrongs did not make a right?

There are many unanswered questions and there could be even more depending on the situation.

Without stage four, I would not be confident in the results of stage five for doing predictive science. Could one start from scratch and reproduce my results without stage four? Perhaps but most likely it would be fortuitous and if several persons tried to reproduce the results then most likely my results would be found out to not be very reliable. Without each stage where is my accountability?

Interestingly enough, these five stages could be associated (or at least have direct analogies) with doing experiment too. To take it even a step farther, these five stages could be said to be the outline of the scientific method.

Science is built in steps and with each step confidence and reliability is built. Without stage four are we really doing science or are we just playing around wasting time and money?