algorithms – survival of the fittest

Posted on by
1

I’ve been volunteering with a FIRST robotics high school team as a programming mentor. Due to a “series of unfortunate events”, we didn’t get to test our logic to drive straight in autonomous mode until the night the robot went into the crate.

We wound up using an interesting approach. First we brainstormed options and prioritized them. If the programmers got the robot early, we would test in that order. Alas, we did not get the robot early. We got it for 45 minutes about an hour before packing time.

Since it takes time to load code changes to the robot, we parallelized as much as possible. The students had time to test the competing approaches before we got our turn with the robot. So we tried them all by flipping a switch and then tuned the most promising one. It was a great use of time and available resources. And we wound up with an approach that wasn’t in our initial brainstorm.

The lesson applies to us all. Be aware of your primary constraint; in this case time; and optimize to that. Punch card programmers certainly knew this and optimized per run at the machine.

I was very impressed. Good luck in the regional competition team 694!

Subscriber Accounts Now Available

Posted on by
Reply

For those who visit this blog regularly, you can now create a subscriber account. The primary advantage is that your comments no longer need to be anonymous. Creating a subscriber account takes only a minute and after logging in, all your account information and contact information will be available for you to post new comments. In addition, comment authors can now subscribe to instant update notifications for those comments via e-mail, with or without an account. In this manner, Jeanne and I hope to foster greater community interaction and discussions with our articles.

another reason % of time writing tests is meaningless

Posted on by
5

Earlier in the month, I blogged a response to – “What would you say is the average percentage of development time devoted to creating the unit test scripts?”.  As I was telling a friend about it, I realized that I missed an important point!

The question also implies that development time is constant.  Or maybe not.   But if I tell you that I spend X% of my time on creating unit tests and your project currently spends Y time on development, I imagine you are considering the development time with unit testing takes Y + Y*X.

However, this isn’t the case.  The real time is Y + Y*X – Z where Z is the time saved in finding the defects in the code faster.  The benefits span past the current project, but this factor matters even if one just measures within the current project.

Or another way of expressing this is that “your Y is different than my Y.”  My time on development has been adjusted by creating software in a different way.

This seems like a convoluted way of expressing it.  Has anyone come across a better explanation?