Blog #7 – IEEE Hack-a-home
My Experience at Stevens Hack-a-home
Over this weekend, Stevens IEEE hosted its first hack-a-home where teams of four Stevens undergraduate students would modify home appliances to become smart appliances. The team I was a part of was given a coffee maker, a CanaKit Raspberry Pi 2 starter kit, a two-channel relay module, and an Arduino UNO. My initial thoughts coming into this competition was mainly fear because I was entering an engineering competition as a computer scientist. I had minimal knowledge on circuits and experience with hardware programming, so I felt that I would make my team lag behind. The other teams who entered the hack-a-home consisted of engineers who knew what they were doing with years of hardware experience. It was intimidating seeing other teams already building circuit boards that were populated with a bunch of intertwined wires connected to sensors and LED’s. However, with the assistance of my team members as well as the vast resources on Python and the Twitter API, I was able to take up the responsibility of programming the entire software to allow the Raspberry Pi communicate with the buzzer as well as the relay module that controlled the electricity flow to the coffee maker. In the end, our design of the smart coffee maker allows the user to tweet to the coffee maker to request the appliance to make coffee at a certain time for a certain amount of cups. The raspberry pi sets an alarm for set time and 5 seconds before the designated time will set off the alarm for 5 seconds. After, the relay module allows electricity to flow through the coffee maker and make coffee. Then, a tweet is sent back to the user to notify that the coffee has finished brewing.
In my opinion, I would prefer working alongside engineers over programmers. I have participated in past software development projects with other Stevens computer science students, but all of my experiences have failed. Every time I have worked with programmers, they always wanted jump into the code without investing time into the design process. As a result, we always became desynchronized where one guy would write code that only worked for his part of the project but not for everyone else’s. This ultimately led to hours spent afterwards editing the code so one part of the program would still function when augmented in the whole program. My partner would start programming without allowing me to catch up, so I would start coding my own program. I never felt like there was a feeling of teamwork when I worked with other programmers. However, my experience this weekend was completely different. Because my partners were all engineers, they know the importance of the design process before beginning the actual implementation of the design. When the competition officially began, we invested the first hour and a half on solely discussing and drawing out different design propositions, and when we finally decided on a design, we discussed the different components needed to make the idea work. I liked this more because there were fewer faults later down the implementation process. When I was lost in how the pin on the Raspberry Pi would send logical bits to the relay module to allow voltage to flow, my engineering friends would always stop and prioritize the team over the work. My friends care more that everyone was the same level and no one was confused about any components of the project. As a result, the team becomes more efficient because no one person will lag behind the others and slow down the design process. I like this more because there is more communication in the team. With programmers, there is no communication because everyone would start coding and wanting to solve the problem his, or her, own way.