You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Harmony Lab

One of the nice things about my job is being able to take credit for interesting student projects. We’ve got an awesome pool of kids that are always doing stuff. They have cool ideas, write up a sloppy implementation and don’t want to maintain it. So it comes to us and we have the opportunity to polish it and expand it for use to a broader audience.

The most recent of these projects to come along is the newly named “Harmony Lab”. (Formerly GoFigure / Piano Lab) This is a nice application that allows you to hook up a midi keyboard to your computer and get information about music theory stuffs (and by “music theory stuffs” I mean I haven’t yet wrapped my head around everything the application does).

Currently it is an application that uses an applet to get the midi data from the keyboard and a ton of javascript for visualizing the key/chord. And a ton of javascript is never a pretty thing.

We are giving it a backend for some authentication, cleaning up the javascript where we can, and adding some extra functionality — hopefully not too much extra. This is a cool project, but it’s usefulness is limited to one or two classes.

What’s cool about this is it’s a (potentially) simple application so it lets us play with (learn) something new (to us). So we went for python Django.

It’s available on github from the start.

Posted in ATG, Harmony Lab. Tags: , , , . Comments Off on Harmony Lab »

The Code Monkey – Devaluing Software Developers

Code Monkey

Note: Opinion. This is something I’ve noticed/perceived in all positions I’ve held.

Of course no one is paid enough money. Boo hoo, we all want more money. Although that is a nicely objective way to value employees, that’s not what this is about.

This is about how software developers are perceived by (most) management. If a manager has a software developer and a project manager under them and they get conflicting reports/opinions from the two people, they will always go with the project manager. Management typically looks at a developer as an overly technical person, unable to understand client and business needs. So when a developer goes for a management position, they are shot down because they are “too technical”. (When someone gets turned down for a position in an IT organization because they are too technical, something is clearly wrong.) The perception of management is clear. PMs get the attention and typically the praise. PM ideas are seen as coming from a position that’s higher level because a developer works in the nitty gritty and doesn’t think in terms of high level.

A software developer ideally understands the client and business needs just as well as the PM. Given that’s an ideal, but that’s what makes a good developer good. Often the reason a project turns out bad is the developer wasn’t made aware of why they’re doing what they’re doing. (Sometimes that’s because it hasn’t been thought about on a high level — no one really knows why.)

The truth of it is software developers come in good and bad the same as project managers. Some are really good and some are totally not. The problem is most management don’t bother to get to know their employees, so they don’t know who is good and who is bad so they make generalizations based on role. That’s bad.

Of course you can now say I’m making a generalization about management in the same way. And you’re right.

Posted in Development. Comments Off on The Code Monkey – Devaluing Software Developers »

More MOOCs in the News

Massive Open Online Classrooms (MOOCs) made headlines in the New York Times again. Harvard University’s own venture into MOOC-space, edX, is mentioned, along with the usual suspects, Coursesara and Udacity.

A couple highlights from the article:

  • The challenges inherit in widening a traditional classroom to a global audience are breathing new life into the art of teaching and learning. Professors are finding that they need to reshape and rethink their instructional approach when teaching tens of thousands of virtual students.
  • These challenges will be overcome with the help of the students themselves. For example, the crowd-sourcing of moderating discussion forums and of grading via peer-to-peer evaluation is becoming critical to running a MOOC.
  • Peer-to-peer evaluation of assignments, such as essays, is permitting the MOOC to go beyond computer science and engineering, which were suited to automated, computer grading. Humanities courses are starting to jump aboard.
  • There is, of course, still much to learn, especially about how well students learn in a MOOC. MOOC-space is young, wild, and untamed.
Posted in MOOCs. Tags: , , , . Comments Off on More MOOCs in the News »

Gamification in Software Development

Gamification has been on my mind a lot lately.

I was just doing some of my sprint planning and found myself filling out borderline excessive github issues for my project. I put all of the issues for the current sprint into aptly named milestones. So as I finish the issues in the milestone, the milestone progress bar gets filled up. I recently realized I enjoy doing this because it’s very game-like.

I’ve turned work into a game and I think it has increased productivity and general happiness with employment. Maybe that sounds lame, but it seems true in my case, I would recommend it for most people who are finding their current work stale and are looking for some self motivation.

Posted in ATG, Development, Gamification. Tags: , , , , , . Comments Off on Gamification in Software Development »

Badgered about badges: Will higher ed be shook up by alternative credentials?

Harvard badgesOne of the big buzzwords circulating through the halls of academia has been “gamification,” the concept of introducing game-like elements into the higher ed environment. The NMC Horizon Report of both 2011 and 2012 indicated that game-based learning is a growing trend in the classroom, and just within the past month, articles in the New York Times and The Chronicle of Higher Education highlight an element of gamification that may very well disrupt the entire paradigm of attending a school to earn a degree. This new element is the digital “badge,” a possible foundation for what might be called the “alternative credentialing” movement.

This movement is serious business.  The Mozilla Foundation has established the Open Badges project, which, with support from the MacArthur Foundation, is defining the Open Badge Infrastructure, a technology suite that can be used to build an ecosystem of badges.  The Digital Media and Learning Competition, sponsored by the MacArthur Foundation and the Bill and Melinda Gates Foundation, awarded several grants to institutions such as Disney-Pixar and NASA to explore the concept of badges in life-long learning. Prominent Universities, including Duke, Purdue, and Carnegie-Mellon, are also experimenting with badges. And badges will probably play a significant role in the credentialing process of the now ubiquitous MOOCs.

The question remains, of course, as to whether badges will ever be considered as valuable as a regular degree. The jury is out on that one, and probably will continue to deliberate on this issue for years, if not decades, to come. But should the time come when a collection of badges on your resume is equivalent to a degree from a major University, prepare to witness a revolution in higher education.

Agile Documentation and Research Stories

A few months into our switch to a more agile process, it became apparent that we still weren’t able to find a place for documentation in our sprints.

At first we had the idea that we would add a task to each story that would cover documentation. We found that we would end up writing docblocks and general code documentation but actual user documentation never got written. But we did that before so we really weren’t getting done what we were trying to get done.

Our next attempt was to set aside a day at the end of the sprint where we would write documentation or finish up stories that were not done yet. But I’m not sure how other people are doing point allocation in sprint planning but I think the ideal is to try to go just a little over the to of what you’re capable of. That keeps you working hard. At least for me, if I know I can do 50 points in a sprint and I schedule 40, I will get 40 done. Work expands to fill time. My point is there is always work to get done on the last day of a sprint. Scheduling documentation within the sprint separate from story points just doesn’t work.

That brings us to documentation stories.
As a developer
I need to document this functionality
So I can easily refer back when there is a problem in the future

This would be great, if during sprint planning, these stories actually got priority. The client wants a cool app, they don’t care about user documentation when you could instead be giving them a bell or a whistle.

What we have had are research stories. These are stories where we investigate options. i.e.
As a developer
I want to figure out if X is doable
So I know if this technology is the right way to go

These stories come up often in our process. We typically have been simply making some notes and reporting back at the retrospective / next planning. This was fine for our purposes but then we realized we could be creating a slightly more professional looking set of notes and pass them off as user documentation.

This doesn’t cover every aspect of user documentation, but it can get a lot of useful documentation done. How did we do our ldap data? We have documentation of our options and our final choice and why.

Currently we have been writing all of these in google docs so they can be easily collaborated on. We then paste them into the project wiki. It appears to be working.

Posted in Agile, ATG, Design & Modeling, Development, Uncategorized. Tags: , . Comments Off on Agile Documentation and Research Stories »