How do I incorporate TDD into my workflow as a scientific programmer / student / researcher? [closed]

Question

I'm busy! Most of my time is spent using analytical techniques, or on course work, and when I switch over to programming mode I need to generate code quickly. Since, the Primary Investigator for the lab I'm in doesn't care if I'm using TDD or an abacus as long as I get results fast.

I've read "TDD by example" and found it quite helpful. I subsequently bought "Refactoring: Improving the Design of Existing Code", "Design Patterns: Elements of Reusable Object-Oriented Software", and "Working Effectively with Legacy Code" but these book are large and the prospects of jumping into them now is daunting!

The conversational style and flow of "TDD by example" made it easy to incorporate into my schedule. But, I don't know how to work in these other books and in which order; it seems that each is just as relevant (I'm in a kind of Dining philosopher deadlock - I'm waiting for each aspect of my programming toolkit to improve but their interdependency has me either gridlocked or loosing time to context switching - sorry for the analogies :) ). e.g. I have legacy code that needs to be refactored and covered with tests, I need to push forward using TDD (but I never do), I need to code with design patterns so I stop reinventing wheels.

Is there a good way to break down these required reads into byte sized chunks and a way to do so while applying their techniques to current projects (personally, I loose the information if I can't apply it right away)? Do I focus on one book and complete it? Do I need TDD first then refactoring and design pattern skills (but 'chicken and the egg' all these unit testing books talk about design patterns and refactoring as if I know them backward and forward)?

I've read the best tutorials for beginners but it doesn't explain how I integrate this into a busy schedule. And, I read programming in a scientific environment but again it misses the mark of how do you add these techniques when you already are behind on time.

Aloysius

Answer 1

Given the description of what you do, I would first start with questioning the assumption. I don't know anything about the complexity of your programs, but if your coding consists strictly of generating calculations and it is kind of "script-level," meaning that for a given piece of code you could just as easily throw it out and rewrite it as keep it, then a lot of these techniques are overkill. I think TDD (perhaps a paired down version that kind of combines in integration testing) will always be valuable, but beyond that, not necessarily.

If however, you are really designing software systems (and at least some of what you might be doing might qualify even if all of it does not, for example database model, input screens, result distribution) then I would say read enough of these books to get started, and don't worry about not doing it right all the time for starters, just make sure you are making measurable progress every week.

By the way, design patterns can be useful to read about how similar problems are addressed, but don't "design using them" instead of something else. Your design may not be good on its own, but patterns come from real-world design, not the other way around. So you can certainly see more object oriented solutions that what you may be doing, but don't worry about if what you are doing fits a design pattern. Make sure that what you are doing is good maintainable design on its own terms, and the patterns will flow from that.

Exocarp

Writing software for a research lab myself, I can def say that it is not a safe assumption that the "get it done quick" attitude is an indication that the scope of the software is small or "script-level". Principle scientific researchers often view the software created for their research as a means to an end and do not care about the quality the software produced, only it's end results. This often results poor software design due to pressure to get things done in the short run as well as duplicated efforts across projects due to a lack of modular implementations. – Mcquillin

+1 @Mark, yes, the code is quite complex and can't easily be accomplished in environments like Matlab or Mathematica. So, I need to start reusing the code (which will require me to refactor) .. – Aloysius

Answer 2

I'd start with the Refactoring book (because you mentioned being swamped in legacy code) and try to read it an hour at a time. Then the next time you are programming, look for ways to apply what you read.

Once you start to feel like you are freeing up some time, look at the other books. I also recommend the book Code Complete for improving your skills.

Mordvin

Answer 3

You can't do it all, all at once (you knew that). Some techniques save you time, and TDD and Refactoring are high on that list. Particularly with TDD - don't fret about when to do it, whether to do it, how to fit it into your schedule; just do it. The sooner you start, the sooner it saves you time. Once you have that skill in hand, then as you approach a task on the legacy code, write tests around it to protect you (no, that's not TDD, but the test-writing skills that you've honed with TDD will apply). When you've got good coverage of the module you need to change, then you can refactor it freely, running your tests frequently. Of the books you mention, in the situation you describe, the next one I would recommend reading is Michael Feathers' Working Effectively with Legacy Code - it will give you the tricks that carry you forward.

For the time being, though: TDD everything. It will save you time sooner that you imagined, and you can put that time into learning more and better techniques.

Slalom