A junior faculty member emailed me recently with the following question:
Do you have any advice on best practices for training students who are new to programming, and at the same time building a usable product? I do a lot of programming myself, but I’ve usually run as a solo operator, and I haven’t used any formal methodology — I just get an idea of the problem and gradually build up and test the pieces needed to solve it. But this project is well beyond the students’ current skill level, and we also need a way to coordinate work by a number of students. So I’m thinking I should use some (semi-?)formalized approach to break the work down into manageable pieces.
After a few minutes of scribbling, I had listed almost 20 practices employed by my research group, which is way too many to implement all at once. So here are my top five recommendations for bootstrapping a student and research-oriented software development team.
Last summer, I had the idea of teaching in an athletic style, and last fall, I tried it out in my software engineering course. My experience teaching this way led to a new idea: using GitHub, Jekyll, and Twitter Bootstrap to: (a) make it easier for teachers to develop course materials and (b) provide a higher quality experience for students. I started this project in January and the resulting Morea Framework has achieved its 1.0 release.
Last week I had the opportunity to participate in the Energy Excelerator‘s 2014 Seed Week program. Representatives from nine energy-related startups attended an 8 day immersive experience at the Energy Excelerator offices in downtown Honolulu. This week kicked off a year-long process of mentorship to help the startups become viable businesses that create a more positive energy future in Hawaii and across the world. Along with Justin Carland, I attended as a co-founder of Open Power Quality, a commercial offshoot of an open source research project that began in my laboratory a year ago.
Last summer, I speculated about an “athletic” approach to teaching software engineering, including:
- A “flipped” classroom: lectures are online, freeing up class time for other activities.
- A primary focus on skill acquisition, and a secondary focus on concept acquisition. For example, rather than assess the ability of students to explain the difference between white box and black box testing, the approach assesses their ability to implement white box (or black box) testing.
- An emphasis on fluency, as measured by the time to complete tasks correctly. For example, given the task of writing a test case to verify that a system exhibits a specific behavior, students are evaluated on their ability to implement it quickly, as well as their ability to implement it correctly. This elevation of speed to a first class component of the pedagogy gives the class its “athletic” feeling.
How startup weekend, outrigger canoe racing, and Crossfit inspires a new approach to software engineering education
I have a confession to make. For over 20 years, I’ve been teaching “cubicle” software engineering. This does not mean that I teach students to use punch cards, COBOL, and the waterfall lifecycle model. To the contrary, my curriculum appears quite modern: agile development processes, a “flipped” classroom, and modern tools and technologies including GitHub, CloudBees, Bootstrap, and the like.
Users of Git, particularly with cloud-based services such as GitHub, CloudBees, and Heroku, must have a very basic understanding of public key authentication and encryption. This article provides a minimal introduction along with a few use cases.
For the past 20 years, the State of Hawaii has pursued the development of a high tech industry to counterbalance our economic dependence on tourism, with mixed results. Proponents of software-based companies note that these products are environmentally friendly, can be developed in any location, and bring in highly-skilled, highly paid jobs to the State.
These advantages are all true, and there are some notable high tech success stories. Unfortunately, while Hawaii is well-suited to high tech, high tech may not be well suited to Hawaii. The location-independence of software development means that it is just as easy to migrate high tech jobs out of Hawaii as it is to move them here, as is demonstrated by the frequent relocation of locally started high tech companies to California.