Reflecting on subtle intricacies of mixing hardware and software
As the title suggests, this is what the majority of my semester involved with regards to this class. While at times it has been a struggle to keep on track I think from an educational point of view, it has been well worthwhile. Having to work in an environment where my group and myself are unfamiliar was not only a challenge because of learning the material, but also integration with something we already know.
I think one of the main issues that was unforeseen was that of time management. I do not believe the issue was because of poor time management in general but because nature of our work. When setting deadlines, for a large majority of hardware, we as a group would know the general idea of what needed to be done. For example, one problem we ran into came from actually driving led strips. Going in, we set the goal of having a raspberry pi be able to run a string of leds. We knew that a raspberry pi had gpio pins that could be used to send data and power to leds, but the exact implementation details were somewhat vague. In the end this became a problem. The leds expected a 5V power supply and the GPIO pins on the raspberry pi would only output 3.3V. Because of this, the leds would not work and we had to order a level shifter to compensate. Even after waiting for shipping the level shifter had to be soldered onto a board that could be used with the raspberry pi. This is just a simple example of unforeseen consequences when working with new systems. Had we known to specifically look at what voltages were expected and output at least one of our expected timeframes could have been more accurate. To me, the takeaway here was to be sure that a problem is thoroughly investigated before assigning timeframes. However, this isn’t always possible, so I feel as though timeframes should always try to overestimate for problems.
In the same vein, facilitating creativity panned out different in the group than I expected. Going into the project we all had a fairly specific idea of what we wanted in the final artifact. However this, in most cases, did not account for real world constraints. A prime example of this was with our original idea to have valves that simply opened to let water, kept under pressure by a pump, turn into somewhat of a fountain. However, in reality, the physics behind the implementation made this not a viable idea. Much like the led problem, this was an unforeseen consequence of working in an unfamiliar field. More so, this had an effect on our overall creative process. I think for the team as a whole, this was the main time we realized that there were actually limitations to what we could do. Now instead of being able to do whatever we wanted, creatively, we had constraints. We couldn’t just think up anything, we realized there were two sides to being creative. We had to come up with ideas that would prove our artifact, but we also had to do it within more specific boundaries.
I not only found that being creative was hard when imposing new constraints, but I also found it hard to tell if our ideas were ‘good’ from a creative perspective; what people like is relative after all. For example, there were times that at a group meeting ideas would get thrown around for some implementation. However, not all of these ideas were implemented. Sometimes ideas would get brought up and while they may have seemed great one member, they were not so great to others. We quickly learned that it wasn’t exactly easy to come up with objectively ‘great’ ideas. Because of this, we made heavy use of other people. When we had an idea to implement, we would go out and ask either our roommates or other friends who like music what they thought. Sometimes this didn’t work and they didn’t like the ideas, but it also served to get useful feedback on if other people actually liked our ideas. Even more, there were times where someone would tell us “It would be cool if…” and say something we hadn’t even thought of. Personally, I learned that when designing an artifact that others use, the user group should be canvassed.
While at first it may have seemed the idea of having these extra constraints of having to make a physical product versus just having it on paper may have been an annoyance, it quickly grew on me. I think the idea of creative computing is at its peak, is one of the most strictly “computer science” things to exist. In reality, computer science is simply about problem solving. When working on this project, we all had an idea of what we wanted to do. But the question was never really ‘what do we want to do’, at least after the first few weeks, but instead we kept having to ask ourselves ‘how do we want to do this’. Not only that, but we had to ask ourselves, how do we want to make our artifact so it’s appealing to the user, and it gives the user creative freedom. I really do this is computer science, solving problems. The more constraints that are added simply add to the problem.
I also think the idea of added constraints really helped the development of our project. Because of this, we had to iterate time after time. So many times we would find something that didn’t work, so we would have to try something different. I also really think the class did a great job of pushing and facilitating this. From day one, we were encouraged to iterate over designs. As well, I think the professor’s willingness to help was very beneficial to the class structure. Getting access to the studio in Moss also played a critical role in how far our project could come.
Over all, this project had more takeaways than I can realistically generalize into a single message. I think the ability to understand your limitations is crucial to the success of an artifact. More so, I think it is important to plan for failure and build buffer time around it, especially when working in unfamiliar areas