+972 52-548-6969
Project lifetime perspectives
I’m teaching a course in university, which gives me some interesting perspective into the mind of new people who join our profession.
One of the biggest differences that I noticed was with the approach to software architecture and maintenance concerns. Frankly, some of the the exercises that I had to review made my eyes bleed a little (the students got full marks, because the point was getting things done, not code quality). I talked with the students about the topic and I realized that I have a very different perspective on software development and architecture than they have.
The codebase that I work with the most is RavenDB, I have been working on the project for the past 12 years, with some pieces of code going back closer to two decades. In contrast, my rule for giving tasks for students is that I can complete the task in under two hours from an empty slate.
Part and parcel of the way that I’m thinking about software is the realization that any piece of code that I’ll write is going to be maintained for a long period of time. A student writing code for a course doesn’t have that approach, in fact, it is rare that they use the same code across semesters. That lead to seeing a lot of practices as unnecessary or superfluous. Even some of the things that I consider as the very basic (source control, tests, build scripts) are things that the students didn’t even encounter up to this point (years 2 and 3 for most of the people I interact with) and they may very well get a degree with no real exposure for those concerns.
Most tasks in university are well scoped, clear and they are known to be feasible within the given time frame. Most of the tasks outside of university are anything but.
That got me thinking about how you can get a student to realize the value inherent in industry best practices, and the only real way to do that is to immerse them in a big project, something that has been around for at least 3 – 5 years. Ideally, you could have some project that the students will do throughout the degree, but that requires a massive amount of coordination upfront. It is likely not feasible outside of specific fields. If you are learning to be a programmer in the gaming industry, maybe you can do something like produce a game throughout the degree, but my guess is that this is still not possible.
A better alternative would be to give students the chance to work with a large project, maybe even contributing code to it. The problem there is that having a whole class start randomly sending pull requests to a project is likely to cause some heartburn to the maintenance staff.
What was your experience when moving from single use, transient projects to projects that are expected to run for decades? Not as a single running instance, just a project that is going to be kept alive for a long while…
Comments
I discussed this years ago with a few colleagues. One of them was pushing local universities to consider a distinct degree in “software engineering”, which focused on maintenance and testability. Another argued that a bachelors in computer science didn’t mean you were prepared to dive head-first into the field, but that it showed you were trainable.
One thing that could work for teaching about long-term concerns is having a dummy project (eg forked from a current, large open-source project), where the students have to build features on top of their own code over the years. They can compare their results to the implementations that were actually made in the open source project, which helps them see alternate ways of achieving the same solutions.
What about semester projects that students have to complete in order to get a pass? Moderate size/difficulty so one person can complete it throughout the course, but big enough to encourage some engineering and use of proper tools. Gives students a thing they can own and show their creativity and knowledge, but also requires them to approach the project in some planned way and think about the product as a whole. I think (just my opinion, maybe i'm just inventing a non-existent problem here) there are too many programmers out there who have never written a complete application - somehow completed the education just by solving tests and doing simple tasks, then went to work in some big IT departments where they only did external-fed simple tasks, but never ever had an occasion to think how to make a complete product and what is required to do so. So i think it would be valuable to get such experience while still at school.
Rafal,
A key issue here is that a semester project (~3 months) is really nothing compared to the amount of time you keep a project alive.
To compare to RavenDB - you have ~30 full time developers working on that, and that goes on for over a decade. So we are talking about centuries of man hours vs. 3 months + the amount of time a student can devote to a single course, which is likely significantly less than a full time job.
I think the skills that you want to have covered here is 1. to grasp and adapt somebody else's code and 2. write code that is easily grasped and adapted by somebody else. Together they allow for code that will survive decades.
'Somebody else' of course includes a time-shifted you :)
Part 1. and 2. go hand-in-hand: part 1. tells you what information you need when doing 2. So I can imagine a semester where X teams start X different projects, and the teams rotate their repositories after every few weeks ('sprints').
The hard part is in grading and keeping things 'fair' as you go along; in a school setting that probably means a lot of preset intermediate measurable goals for each sprint and accepting that you may inherit subpar work (now there's a valuable lesson! :) )
Hello, I think this is a huge opportunity for the university and the student to collaborate. Maybe the U can have a pool of internal projects or maybe someones related to investigations. This will give the chance to go deep into some subject. For example, I saw in CMU ( Carnegie Mellon University) they have a project to build their own DB engine. This it's an excuse to teach internal things like b-trees, join algorithms, concurrency (there is also a public repo for it https://github.com/cmu-db/bustub). This way of approach will add that extra knowledge that it's so needed in the future CS toolbelt.
In my personal experience, I did a lot of code reuse during my degree (but I started when I had more than 9 year in the IT business)
Hello. You can also have a single project that evolve each year with 3rd years student, that means each year different students work on the same project. That also means you'll not only teach the maintainability (maintain what previous students did), but also prepare them to work on an existing project (which is almost always the case when you start the job)
Fabrice,
Having them start over from some random project done by a previous year's student is interesting (evil, as well).
Comment preview