When to Call a Project Dead Instead of Done

At the beginning of my SCDS fellowship, I sat down and outlined my goals for the year. Realizing that there was some serious skill development that needed to happen in order for me to be able to achieve them, I decided that I would start with some incremental projects that would help me to learn the skills that I would need in order to achieve my bigger goals. The first project that I set out to complete was building a small digital clock for my desk at the SCDS, using an Arduino, a small LCD screen, and a Real Time Clock (RTC) chip. I hoped to learn the basics of Arduino and a little bit of the C/C++ programming language that I would need for projects involving Arduinos.

As I worked on this project, I documented my progress in detail on the wiki that I keep for all of my SCDS projects. Although the project moved slowly, I made steady progress. Once I found an RTC module that worked well, I worked with tutorials in order to put together a program for the Arduino that allowed me to set the date and time on the clock, display the time on the LCD screen, and I had begun to work on adding the necessary code to have all of these features be controlled by buttons when the Arduino was not plugged into a laptop (ie, when the clock was on my desk). I felt like I made tangible progress in my understanding of basic electronics, of C/C++, of libraries, and perhaps most importantly, in finding resources for working with Arduino. One day, I put the perfectly functional project in my bin at Hacklab, where I had last worked on the project.

About eight weeks later, I returned to the project. I plugged the Arduino into my laptop, launched the Arduino application, and hit “Upload” (uploading and running the code that I had put together to the Arduino). Immediately, the code started throwing errors. One of the other members of Hacklab pointed out that there was an update to the Arduino software since I had last worked on the project. I felt like that was pretty valid feedback, so I patiently updated the software, and tried again. This time when I hit “Upload”, all of my previously existing libraries were missing. I was grateful for the detailed notes that I had kept on my wiki. I went back through them, found the sources for the missing libraries, and re-installed them.

The third (and ultimately fateful) time that I hit “Upload,” my code threw hundreds of errors: one for every function in the libraries that I had re-installed. At this point, I asked a few other Hacklab members their thoughts. They scrolled through the errors and (like me) found no obvious easy fix. I sat and looked at my little mess of jumper cables and code and chips, and made a tally in my head of all of the things that I had learned working on that project. The point had never been a finished clock so much as it was about learning, and I spent some time considering whether or not spending the hours it might take to troubleshoot the code for the clock would be worth it.

Eventually, I decided that it probably was not. I put the clock back in my Hacklab bin, moved my notes to the “inactive” section on my blog, and pulled out the next static-proof bag of components for my SCDS project.

Leave a Reply

Your email address will not be published. Required fields are marked *