Posted by Saulius Grigaitis 21/11/2011 at 13h58
Few years ago I started delivering course Agile Development with Ruby at the Faculty of Mathematics and Informatics of Vilnius University . It is one semester course containing one weekly theory lecture and one weekly practice lecture for BS and MS students. It’s optional course, so I expected only very motivated students will pick it. So original intention was to prepare deep course about BDD with Ruby with few other topics like advanced Ruby chapters (for example meta-programming) and Ruby on Rails web framework. I delivered and tuned this course for 4 semesters so far, but I think there are still unsolved issues and plenty space for improvements, so I’ll write problems I faced teaching students in this series of posts and I would like get your feedback.
I’ll dedicate this post for one of most problematic thing – practice tasks. Initially I decided to use common scheme that is used in our faculty – final student’s mark contains of 40% of practice results and 60% of exam at the end of course. Couple of guys that produce best apps during practice lectures gets 10 without exam. I was very serious about practice tasks, because there is no way to learn BDD without practicing it. Unfortunately it turned out that I was too serious about it…
Initially I decided to give 3 tasks:
- Ruby application (for example “Car rental software”) – 2 points
- Porting Ruby application to ActiveRecord – 1 point
- Porting entire application to Ruby on Rails – 1 point
Tasks had defined quality (not all requirements, but some like OOP, full test coverage etc.) and quantity requirements (for example – at least 50 specs). But actually it’s really hard to clearly measure code quality, so mark mainly was written based on quantity requirements. So if some student had low code quality, then I just gave him my suggestions how to improve code and if there were spare time, then he/she improved the code. But if student do not show interested in improving code, then I just focus on quantity requirements. Seems that it’s not bad approach, because then I can spend more time with motivated students instead of wasting time with unmotivated students.
- Tasks are really suitable for learning BDD.
- Scope is good for very motivated students.
- Too big scope for average student. Even experienced Rails developer spent at least 50 hours to complete it, so for fresh guys it can take 3x or even more. Usually students don’t have so much time for optional courses.
- Ruby on Rails learning curve is long. Convention over Configuration means a lot of learning time.
- Not all students were comfortable writting application, because they mostly wrote algorithms previously.
So overall I was happy with results from motivated students, but very unhappy with results from unmotivated students.
Later I introduced simpler version of practice tasks. So there were two options – Rockstars and Mainstream. Rockstarts was exactly same as Approach #1, Mainstream was 3 tasks too, but instead of application students needed to implement algorithm. Students needed to pick algorithm that is not trivial and processes not trivial data structure, so it’s possible to implement second task that loads or stores algorithm data using ActiveRecord. Third task was just simple frontend for that algorithm. It thought I solved unmotivated students problem. I was wrong. So what Mainstream students did – they tried to pick simplest possible algorithm with simplest possible data structures, so usually it ended up with single method algorithm implementation using trivial Ruby data structures (like arrays).
- Different level tasks, so great students can learn a lot and implement great app, while unmotivated can complete tasks still learn something.
- Too easy to cheat Mainstream task and turn it into too simple implementation and completely not suitable for learning BDD.
- Algorithm implementation isn’t good project to learn BDD, application is much better.
So I think it probably was even bigger fail then Approach #1
I got rid of Mainstream, so there were only Rockstars task, but instead of 4 points for practice tasks, I decided to give 6 points for practice and 4 for exam. I think that practice tasks are much more important than exam in this course. So task #1 – 3 points, task #2 – 1.5 point and task #3 – 1.5 point.
- Virtually it’s still two different level tasks – motivated students can implement all three tasks, while unmotivated students can implement only first task and get 3 points.
- Student don’t need to decide which task set (harder or easier) he/she is going to take, because everyone starts with same task #1 and then motivated students can proceed on other tasks.
- First task is too big chunk, it definitely needs to be split in smaller tasks.
This approach was best one so far, but I’m going to proceed improvements in upcoming semesters.
Approach #4 (Upcoming)
I hope to get feedback on this one from you, maybe you will find improvements until I start to use it next semester. So basically I’m going to use Approach #3, but I’ll split first task in to 3 smaller tasks, so 1 point per each task. Main problem is how to split the task. So far best way I think about would be simply split buy quantity. Originally first task had few quantity requirements:
- at least 50 rspec tests.
- at least 5 entities (in other words Classes).
So then I’ll have three sub-tasks:
- at least 30 tests and 3 entities.
- at least 40 tests and 4 entities.
- at least 50 tests and 5 entities.
Any better idea?