{ |one, step, back| }

How did you get started in software development.

Tagged

Looks like Joe O’Brien tagged me for answers to the following questions. He, in turn, was tagged by Josh Holmes, who in turn was tagged by Jeff Blankenburg. It looks like Sarah Dutkiewicz and Micheal Eaton started this.

OK, sounds like fun. Here goes.

How old were you when you started programming?

I was introduced to programming in high school by reading a book on the topic. The book taught me how to write machine code for a strange decimal-based machine. Unfortunately, there was no actual computer involved in the process. Shoot, who had computers back then? Certainly not our high school (the personal computers? not invented yet!)

In college, I learned a smattering of FORTRAN. Just enough to drive a Calcomp plotter to plot data from my undergraduate physics courses. But didn’t really get into programming until my junior year in college. (Story continued in next question)

How did you get started in programming?

So, I was planning out the courses for my junior year in college and I had a hole in my math courses. The math class I needed was not offered that semester, so my adviser suggested taking a computer programming course. He said it would be useful and, who knows, I might enjoy it.

So I signed up for an introduction to FORTRAN course, figuring it would be easy because I already knew a little bit of FORTRAN. I show up on the first day of class and after a few preliminaries the instructor jumps right into some code, that looked like this:

  (de member (pip deck) (cond
    ((null deck) nil)
    ((eq pip (car deck)) t)
    (t (member pip (cdr deck)))))

I remember scratching my head and thinking this was the strangest FORTRAN I had ever seen. I was totally confused for about three days, then something clicked on the third day of class. I suddenly “got” what the instructor was trying to get across and it all made perfect sense.

If you haven’t figured it out yet, the instructor taught us Lisp as part of an introduction to FORTRAN. The instructor turned out to be Daniel Friedman, the author of The Little Lisper, and was well known in the Lisp community. That small exposure to Lisp hooked me on programming from that point on. I took as many CompSci courses as I could in my remaining year and a half in college. I eventually graudated with a BS in Physics, but had a strong background in Computer Science as well.

What was your first language?

Technically, FORTRAN was my first language. But Lisp is the language I fell in love with and is what got me hooked on programming.

What was the first real program you wrote?

I have a very clear memory of the very first program I wrote professionally. The reason it is so clear is that this was the first program I wrote that was intended for actual use by someone who wanted it. Everything else up to that time was done for my own personal enjoyment or to satisfy some course requirement.

The program calculated the “critical angles” of “pieces”. I was given the requirements by Anne Exline, a senior programmer, and proceeded to write the program to spec. It took a few days, but when I was done I showed the result to Anne and she was pleased with the result.

The funny thing is that I had no idea what a “piece” was nor what was so critical about the angles I was calculating. I was so excited about writing an actual program that I did not ask until the software was done. When asked, Anne just looked at me funny and said “Rocket Pieces”. When Cape Canaveral lauches a rocket, they track it very carefully to make sure it stays on course. If it strays, the range safety officer is required to activate the self destruct. The critical angles are those angles that would cause the “rocket pieces” to land outside the safety area of the flight path.

So, my very first professional program was not only useful, it might actually save lives.

What languages have you used since you started programming?

Languages I have used as part of my professional career (in roughly chronological order) include FORTRAN, various assembly languages, FORTH, C, PL/M, C++, Java, Ruby.

Languages I have used in addition to those mentioned above: Pascal, Perl, Eiffel, and Lisp/Scheme.

Languages I can read, but never wrote anything significant in them: Ada, Python, Erlang, Smalltalk, SNOBOL, Algol, Pascal.

What was your first professional programming gig?

I was hired by the RCA Missile Test project in Cape Canaveral, Florida as a Near Real Time Analyst. Duties included programming various launch related software (e.g. the critical angle program mentioned above) and working launch support.

The launch support was the “Near Real Time” part of the job description. From the moment a rocket is launched until it reaches orbital velocity, any malfunction could cause it to fall back to earth. During this initial portion of the launch, the launch is monitored in “real-time” so that we know exactly where it would land if the engines were to cut off NOW. Trajectory calculations had to be done in fractions of a second and updated constantly in real time.

After the rocket reaches oribital velocity (usually somewhere between 8 and 14 minutes into its flight), it won’t fall back to earth. At this point the real time trajectory program is shut down and the near real time program is started. The near real time program can take a few minutes to calculate a more exact orbital prediction and then send that prediction to downrange radars (e.g. the the Ascension Island station) that won’t see the rocket until about 20 minutes after launch. It was the job of the Near Real Time analyst to run that program and provide oribital predictions for downrange station.

If there is one thing you learned along the way that you would tell new developers, what would it be?

Find something that you enjoy and do that. Life is too short to work in a job that you dislike.

What’s the most fun you’ve ever had … programming?

Oh, the fun I have had. This story still makes me smile.

My first computer was a single board Z80 microcomputer with 4 KB of memory. I wrote a small FORTH-like interpreter for it and hacked a version of the animal game in FORTH. The animal game is a program that plays 20 questions to figure out what animal you are thinking of. It constructs a binary tree where each node is a question and the subtrees are the yes and no answers to the question. To play the game, all the program does is walk the tree, ask the question at the current node and follow either the YES branch or the NO branch as appropriate.

If the program guesses wrong, it will ask you for your animal and a question that will distinguish your animal from the one it guessed. It then adds your question to the tree. By this extremely simple mechanism, it is able to expand its knowledge base. (see Ruby Quiz #15 for more details).

I had just finished the program and had seeded it with a single animal, a mouse. I turned to my wife and asked her to play the game. She thinks of an animal and starts the program, which immediately asked her “Is it a mouse?”. She turned to me with surprise and said “How did it know?”. Of course, the animal she picked was a mouse.

I don’t think I have ever impressed anyone with my programming skills as much as she was impressed with that game.

Who’s up next?

I’m tagging the following people. Remember, this is entirely voluntary so don’t feel obligated to answer. But I’m betting the answers are interesting:

On my wall ...

(from here)

Color Blind

Presented a talk on Test First Design today at work.

I did a Lunch & Learn presentation today at work on the topic of unit testing and Test First Design, included a discussion of the Red / Green / Refactor technique. Unfortunately the red gun on the video projector was bad, ruining all the careful color coding I put in to my slides. So the technique will now be officially called Black / Yellow / Refactor.

Tuning Performance

Uncle Bob has a couple examples of why performance tuning almost always has surprises in store for you.

Not What You Expect!

Bob Martin (Uncle Bob) relates a couple of stories on performance tuning and why your expectations are nearly always wrong.

The moral of the story … measure, measure, measure whenever you have a performance problem. The root cause is prabably not where you expect it to be.

Dependency Injection Gone Bad

It always bothers me to see mock objects creating and returning other mock objects.

David Chelimsky on Dependencies

David Chelimsky of Object Mentor notes that dependency injection eases the pain of dependencies so much that we sometimes don’t bother to root out the bad dependencies. Read the article and pay close attention to the dependencies in the original and final versions (I drew a couple UML diagrams to keep it clear in my head).

Plus its got a great Princess Bride reference!

Coding Standards -- Keep It Simple

The last several clients I have worked for loved to publish huge coding standards documents. A recent one was only 20 pages long (and that was one of the shorter ones).

While browsing the new Rails 1.0 web site 1, I stumbled upon the Rails coding standard. Here it is in full (link):

Two spaces, no tabs
MyClass.my_method(my_arg)—not my_method( my_arg ) or my_method my_arg
Follow the conventions you see used in the source already

¹ You did know that Rails 1.0 was released today, right?

Thinking of no one in particular ...

Via Elizabeth Keogh ...

If an Agile Evangelist falls in the forest and there’s no one to hear him, does he still go on, and on, and on about it?

(link)

Test VS Behavior

This article was sparked by a some conversations and discussions at RubyConf 2005.

Test VS Behavior

It seems fashionable these days to say that Test Driven Development is not about testing at all, but rather about (fill in the blank), where the blank can be filled with “design”, “behavior” or “specification”. At RubyConf this year, one of the “informal” discussion sessions around the pool area drew a large crowd of people to discuss this very topic.

The RSpec ruby library (from Steven Baker, Dave Astels and Aslak Hellesoy) is a replacement for Test::Unit. Its main focus is to change the terminology surrounding the whole TDD approach to software development. I think this is key … it is not changing anything fundamental about the processes, it is focused upon the words we use in describing the process. But don’t be fooled into thinking this is a matter of semantics only, for the very words we use to describe something shapes our thought processes about the thing we are describing.

BDD, or Behavior Driven Development, is an attempt to improve TDD (Test Drive Development) by emphasizing the behavior specification nature of traditional TDD. By freeing TDD from its test bound terminology, we avoid some of the preconceptions (e.g. “Tests? Yuck!”) that developers bring to the table when discussing TDD.

So What’s Different

So, what’s the real different between RSpec and Test::Unit? Compare these two code snippets. First the “test” version:

  class TestEmptyMovieList < Test::Unit::TestCase
    def setup
      @list = MovieList.new
    end
    def test_size_is_zero
      assert_equal 0, @list.size
    end
  end

And now the specification version:

  class EmptyMovieList < Spec::Context
    def setup
      @list = MovieList.new
    end
    def should_have_size_of_0
      @list.size.should_equal 0
    end
  end

Note: This is from RSpec version 0.2.0 available as a gem from RubyForge. The RSpec guys are currently thinking about using domain specific language for specification. So expect RSpec to change in the future.

We can see that the structure between the tests and the specifications is very similar. Actually, more than similar, they are virtually identical. We just use Context instead of TestCase, use methods with any name rather than those that start with test_, and use object based assertions rather than specific assert methods.

The result is something that reads rather naturally in ruby-accented English. But the functionally is essentially that of Test::Unit, just in different clothing.

Just Semantics!

I hear you saying “But it’s just semantics!” Of course it is. But leave out the word “just”. When conveying meaning, semantics is everything. And one of the important features of Agile developement is to convey the meaning of the code, in the code itself.

Semantics are important!

Is it worth it?

Ok, semantics are important. But is it worth converting all our unit tests into specifications?

Maybe.

I do find the terminology attractive. But I have a large investment in Test::Unit style tests at the moment. And RSpec is still a bit rough around the edges (for example, the error reporting is not quite as mature as Test::Unit’s). And RSpec is going through some major changes at the moment (I mentioned the specification DSL they are playing with).

What would I like to see? One area of specification that current TDD practices tend to be weak in is the specification of preconditions. Preconditions define under what circumstances it is valid to call a method. For example, it may be invalid to call a square root function with a negative argument. Looking at a list of tests (umm … specs), I can’t be sure if negative inputs are not allowed, or if the spec writer just forgot the cover that case.

I’m not ready to switch over to RSpec yet, but it certainly is moving in interesting directions.

What I didn’t talk about

Those of you who were present at the poolside conversation at RubyConf may wonder why I didn’t mention mock objects, since mock objects were a major part of that debate. I see the Behavior VS Test debate to be completely orthogonal to the Mock VS not-Mock discussion. I’ll pick up the mock object debate in another posting, so don’t worry.

When Clocks Go Bad

Message ruby-talk:103140 on the ruby talk mailing list mentioned problems with the sleep command interacting in strange ways with setting the clock. That reminded me of this story.

Way back when, I used to work on a data acquisition system that used an IRIG clock reader to timestamp our data samples. An IRIG clock works by reading a signal that sends the time once every second. Between the second ticks, the clock reader would interpolate the time down to the millisecnod level. This allows you to have several clocks on different systems all synchronized to the same clock signal.

Our system had to take a sample every 20 milliseconds, so every cycle we would calculate the time of the next cycle. When the current data cycle was done, we would just wait until that next scheduled time arrived to start the next cycle.

An IRIG clock reader is an interesting device. Normally it works really well, but occasionally (especially if there is noise on the clock signal line) it will misread the time signal. One particular reader we were using tended to misread a couple of bits in the minutes data with the result that for one second, the clock reader would add 30 minutes to the real time. When the next clock signal arrived a second later, the reader would start reporting the correct time again.

Jumping ahead was no problem. Our software just used the reported time and continued to schedule data cycles. However, when the clock jumped backwards, the next data cycle was suddenly scheduled for 30 minutes in the future. The result was that our system mysteriously stopped dead for 30 minutes and then just as mysteriously restarted as if nothing happened.

Time is a strange concept in computer programs. It is difficult to know what the exact time is while executing. Consider the following lines of code …

   t = Time.now                      # Line 1
   puts "The Current Time is: #{t}"  # Line 2

One would think that line 2 will print the current time. And most of the time we would be correct. But suppose I pressed the suspend button on my laptop between line 1 and line 2. It might be hours (or days) before line 2 prints out its now "out-of-date" time message.

When you are dealing with times in the millisecond range, there are all kinds of things that will pause your program from one line to the next. Interrupts, page faults, and time slicing all interact in interesting ways to make the concept of "time" in a program something of a challenge.

It wasn’t hard to fix our cycle scheduler to be well behaved, even in the face of uncertain time. And I learned a new respect for time in the process.

Miller on Mock Objects

Charles Miller reminds us that there are two reasons for using mock objects.

To create an environment where the object under test can live.
To test that the object under test correctly modifies the environment.

Each use requires a slightly different API (#1 sytle APIs tend to be more flexible than style #2). I’ve used both styles of APIs in the past (and had been frustrated trying to use a style #2 API in a style #1 situation), but I hadn’t connected the differences with the reason for the differences before.