In professional development there is always a trade off between what features to have in a product and when you want to ship the product. Dare Obasanjo @Carnage4Life is a Principal Program Manager Lead at Microsoft and a really smart guy. Last week he tweeted “You can be feature driven or you can be date driven. You can't be both unless you want to ship crap.” which outlines the problem rather succinctly.
In schools we tend to ask students to hit both date and feature requirements. We want students to finish all the requirements of a project by a very specific date. While there are times when project deadlines are extended (which does happen in the professional development work – also rarely) usually the dates are quite firm. For a lot of students this means that the projects turned in are pretty poor. Some students get it all done and done well by the deadline. This is because projects are usually designed with time frames that are reasonable. Usually. For a good student. This doesn’t model well with professional development but then our goals are different. What about the students who don’t have enough time to do it all and do it well? Students generally have two options:
- Turn in buggy programs that attempt all the required features
- Leave out some of the required features.
Option one seems to be quite popular in my experience. I think that students feel that they should attempt it all. In general I think that is the worse of the two. It’s hard to give a fair grade to a program that doesn’t work. A program that works even though it doesn’t meet all the requirements is a lot easier to grade and gives a better indication of how much a student knows.
A big part of the reason for this is that students try to do it all at once. I’ve seen students try to write every bit of code before doing more testing than syntax checks. Of course we try to teach students to take things step by step. We ask them to do unit testing. We ask them to break things down into small manageable easily testable pieces. But somehow too many students try to do everything all at once. Why? I don’t really know.
I suspect that intermediate deadlines might help, especially for larger projects. This would give a chance both to reinforce the need for iterative development testing and check for early difficulties. or perhaps have students create larger projects with sub projects leading up to a conclusion. Some sort of case study type project. It’s something I would like to try.
What do you do to prevent the “all the features are there but none of them work” problem?
I think one way to try to solve this problem would be to take an agile type approach where every week/2 weeks they're expected to turn in a working program with one or two new features that were assigned.
ReplyDeleteIn my experience, students more often hit Option 2 than Option 1. For example, buttons without event handlers in VB, or stubbed methods in Java. (Granted, stubbed methods may give the appearance of buggy code, thus Option 1 ...)
ReplyDeleteI encourage Option 2, to give the students the sense of acccomplishment for having finished "something".
Regarding the Agile approach, couldn't this just be considered taking one large project and breaking it into several smaller ones, thus giving the students multiple chances to "finish features or hit dates"? (Yes, I uderstand how Agile works; I also understand how students "work".)
"Regarding the Agile approach, couldn't this just be considered taking one large project and breaking it into several smaller ones"
ReplyDeleteYes, but, as Alfred said "somehow too many students try to do everything all at once." This would force them to not be allowed to do it all at once. To get out of the waterfall mindset of planning everything out first and building that week's piece so that when the client changes their mind when your midway through the project, it doesn't require starting over. Don't even give them the next week's tasks so they can plan ahead.