How software development contributed to my design process
On the first day of our class for engineering design, we were asked to write up a portfolio of some of the past design work we've done. It rather surprised me when I realized that I have design experience from creating software. I didn't at the time perceive them to be work of engineering, and did not follow a concrete design philosophy, but the process I used for developing software contributed to my design process.
The goal of app development is to develop a solution to a problem, which agrees with my definition for engineering design. The difference in the tools and resources available and the nature of the final product results in the use of different design approaches, but the process is recognizable as a design workflow.
One apparent difference between programming and the development of other types of solutions is that there often is a "right" answer available. When I was looking for a way to cover the Android navigation bar at the bottom of the screen, I pulled up the source code to Android's Window Manager, looked at the ordering of the layers, and found a layer that worked. In my mental image of a "designer", the problems he/she/it solves are less clear-cut. The problems given as examples of engineering design, such as figuring out the shape of a laptop holder, or choosing the shape of a computer mouse, do not have a single "right" solution. Yet upon further inspection, I noted that developers and designers actually work with both types of problems. When I was working on the Detailed Design Report, I found myself looking for information on the temperature inside a dishwasher, and the types of plastic that can withstand the temperature: both questions are factual, not creative, and have "correct" answers - just like the aforementioned programming problem. When I'm working on my applications, I also need to answer questions that are not clear-cut, such as how to organize the program (object relationships, activities, etc), which requires thinking and analysis, like the stereotypical design problem.
Another area where I was able to use a software-inspired approach for design is in my reliance on reference designs. When I developed my first Android application, PocketInvEditor, I would code with an Android tutorial book on my desk, and source code to Android's built-in programs open on a browser tab. I consulted them to gain insight into how common tasks are accomplished by people who understand the platform better than I did. In the detailed design report, where I needed to find a suitable material for a ketchup bottle cap, I remembered my usage of reference designs, and began the research by checking recycling websites to find the types of materials that existing caps are made from.
The detailed design report shared one further attribute with my software development work: it was an individual project. Previously, when I worked on applications, I relied on reference designs or even library code (code written by other people that can be included in a project), but overall I worked alone. Often, in design, people would work as part of a team, as I did during the creation of the conceptual design report. In software, there is, of course, much collaboration as well. One company that helps programmers work together is GitHub, and its corporate culture's beliefs echos the design philosophy of a creative studio. Their approach to collaboration involves the use of pull requests, which are basically threads of conversation, to let fellow programmers critique and offer possible improvements to each other's work. Sounds familiar? Yes: in our Conceptual Design Team, we also offered constructive criticism to each other as we prepared our candidate solutions for presentation.
GitHub's design philosophy also values rapid iteration. Their co-founder's outline of GitHub's development principles highlights their approach of releasing new features: "deploy at will". By simplifying the process to deploy (release new features), iteration through the design process becomes easy: with every deploy, feedback can be gathered from consumers. When I started creating applications, I discovered that rapid iteration is efficient: I wasn't brave enough to push out multiple releases a day, but only used the strategy when testing locally. Even then, I appreciated the ability to make incremental tweaks, hit "install", and getting feedback. It embodies the "jump forward" phase of the design process: the tweaks allows me to improve a low-fidelity prototype into the shipping product extremely quickly. Problems can be quickly spotted, and nuisances can be quickly fixed. I ended up designing some of my software for rapid iteration: for BlockLauncher, I created a script that would build the software, install it, and then launch it on my tablet, so I can quickly make changes. In the engineering design course, I found that this ability to iterate is not as accessible: it took us multiple hours to create a rough physical prototype of our splashproof pot design. Instead of relying on high-fidelity prototypes, I adapted my strategy to use simple prototypes: when designing one candidate solution for the pot, I drew a rough picture of the parts in Inkscape, a vector art program, and used the rotate tool to visualize the movement of the metal plates, a key component in the solution. In the future, I expect rapid prototyping of physical solutions to become just as easy as software prototypes, due (in part) to the rise of 3D printing. A Windows developer noted that it was "easy to practice iterative design" when 3D-printing, as examplified by his trial-and-error process for tweaking the dimensions of his SD card holder so the cards would fit snugly. Even NASA realized that rapid feedback on designs can aid in achieving "a clear, simple, understandable vision", and to that end has organized teams under the philosophy of quick prototyping.
In the end, though software development and engineering design looks very different at the surface, they actually share many core concepts, and I was able to adapt some strategies I learned during programming for use in design projects.