Monthly Archives: December 2010

FIRST Lego League Challenges – Against the Odds

Leave a reply

[youtube=http://www.youtube.com/watch?v=UUIZdOk1oTs]

I’ve spent the last 7 or 8 weeks coaching a group of 6th through 8th grade students as they prepared for the Regional and State competitions of FIRST Lego League. FIRST Lego League combines research, technical, and teamwork aspects into a really great contest. I’m going to take a minute to share how my co-coach Dr. Joshua Enszer captured our pretty challenging season. Despite the challenges, the team members have had a great time. Both teams at LaSalle Intermediate Academy had a good showing at State competition, and one of our teams progressed to the state level of competition.

This is how we got to where we are:

“On October 11, I received a phone call from a parent at LaSalle Intermediate Academy. She had been calling people who knew people in search of a coach for their Lego League team. They had one parent, Dan Neumann, committed to coaching, but needed another coach in order for the program to exist with the school’s two teams. Already a month behind in the season, parents were scrambling to fill this void so that the children could participate in Lego League this year.

Two days later I was in contact with Dan, another newcomer coach. We had no idea what we were getting into. LaSalle had historically performed well at competitions, but they’d also had the same successful coach since this program started! I personally had not heard of this program before this year. We read over the coach’s manual and scoured the websites and arranged for our team to meet for the first time on Friday, October 15, with five weeks to regional competition.

That Friday – and the following week of meetings, actually – was spent getting students (some with past experience, but largely not) to know one another and to set up the tables for this year. Veteran Lego League students brought new students up to speed on the aspects of the competition from day one – the research project, the programming challenge, Gracious Professionalism. It took three meetings just to construct the pieces for the programming table and to select a research topic. Four weeks to competition.

With the table ready for practice, students found the school’s NXT kits, evidently untouched since the year prior. It took no time to realize two things: one NXT’s display was no longer functioning, though it still had the capability to run programs; teams had never used light sensors and only one was to be found among the school’s supplies. We put in an order for more sensors and a replacement NXT as soon as we could. The team soldiered on with what equipment was available, and team mentors – previous Lego League participants now in high school – came back to help support the new students with their research with mere weeks left.

The students never gave up. We met three times—seven to eight hours—a week for the duration up to the regional competition. The new equipment came in and functioned perfectly. And then, the day before the regional competition, just an hour before we were to pack up and prepare to leave, the hard drive on the programming computer crashed. A student took it home to his father, who spent the evening retrieving the data, and miraculously, had it for us the next morning. We have doubly backed up everything since.

Harried, but determined more than ever to give a good showing, the team performed as best they could at the regional competition. Things did not go entirely as planned, but the students were not down. As the judges computed final scores, parents watched as our students lead a number of people in some games and dances. And after an interminable wait, the judging was announced, and our team placed in the regional competition.

The team has been imbued with a drive to succeed all season, and this placement only tempered their resolve. With a week to go to the state competition, the repaired computer bit the dust entirely, but files were securely stored elsewhere. Programs have been improved and expanded, the presentation script refined. Regardless of the result at the state tournament, these students have already survived a late start, rookie coaches, faulty and missing equipment, and two computer crashes. They’ve already beaten the odds to get here. Who knows what is next…? I wouldn’t underestimate them.

Josh Enszer ”

Thanks, Dr Enszer, for describing the situation so accurately. I am looking forward to taking this year’s lessons and returning to coach next year, if possible.

Here is a video of the robot trying to solve one of the challenges. We finally get consistent results toward the end:

 

Refactor (Don’t Rejactor) Your Code

Leave a reply

I believe that today’s team retrospective may have contributed a new term to the Agile lexicon: Rejactoring

While “refactoring” is the agile-embraced practice of improving the quality of the system without changing the system’s behavior, a “rejactoring” is a “refactoring” that “jacks up” the object of the refactor.  When a refactoring goes bad, it becomes a “rejactoring.” Rejactoring the code results in systems breaking in unexpected ways and at inconvenient times.

Here are some suggestions on how to avoid rejactoring your code:

  • Improve the code’s structure in a series of small increments, not one big change.
  • Have tests defined that will that give you quick validation that you have not inadvertently broken the current functionality.
  • Separate functional improvements from the refactoring effort. Combining a refactor with functional improvements is simply building new features, not a true refactor. Be careful not to bastardize the practice of “refactoring.”

For further reading on refactoring, check out Martin Fowler‘s book, Refactoring: Improving the Design of Existing Code as well as the site Refactoring.com.