It’s hard to believe, but already the summer term is about half over. We are closer to the exams than to the first term day, and that’s a scary thought because I feel I haven’t done anything useful, yet, preparing for these exams. In fact this term feels like it’s over before I had really noticed it had begun. Maybe I have already been here too long. When time starts passing quickly doing something, it’s usually a sign you are getting used to doing it. It probably also means you are rather busy.
Our software engineering project, the urban transport simulation, is taking shape. We are going to have our second meeting with the professor this afternoon, and these meetings, which take the place of the normal practicum meetings, are supposed to be ‘milestones’, in software development parlance, at which we show something deliverable, or at least present significant progress. In fact the thing still doesn’t do anything, although we have been working frantically on it for more than seven weeks. Or let’s be precise: two of us have been working frantically. In my project leading capacity, last week I tallied the lines of code written by the four of us since term start, and the results were revealing: Between the two of us, my programming partner and I have written almost 95 percent of the code, in roughly equal shares. In particular, he is responsible for almost three-quarters of the nasty Angular code in the frontend, and I have written two-thirds of the Java backend, including the entire core simulation logic and the map editor, or almost exactly 50 percent of the entire project. The other two guys have together contributed all of 5.5 percent.
That’s not to say I didn’t have fun doing this, and I’m sure the same goes for my programming partner. But time is a scarce commodity, and so far I alone have sunk over 180 hours of work in this single project for a single course. In addition, I have all alone done the first two out of four practicum assignments for the intelligent systems course, for our group of four, simply because I am the only one of us who can find his way around programming in Prolog. My programming partner at least tried, and the other two guys were content letting me do it.
And moreover, I have also done the programming for the first assignment in the computer networks practicum, where we work in groups of two. As you may recall, I had successfully suggested that we experimentally swap partners for this practicum, mainly because I wanted to have a chance to work without the constant slightly condescending activism of my programming partner. I am really having second thoughts now, because whereas the first assignment (the SMTP mail client) for computer networks was a few hours of work, the second (a chat room server and client) was quite involved. My new partner and I started working on this together for a couple of hours, but then he got sick, and a week before the practicum we had exactly six classes and nothing in them. So when we met to (hopefully) complete this project by way of pair-programming, I was under severe pressure because I wanted this done quickly, preferably on the same day (and my working days are limited by having to pick up the children at school at 4 p.m.). But in the evening we had a code ruin that did nothing.
It was quite a revelation for me. Working with my former programming partner was high stress for me, but at least we got things done. Working with my new partner was completely relaxed. We never got into an argument, we were friendly and polite, he was respectful of my contributions, but we didn’t get anywhere, particularly since this assignment required thread programming, and my new partner had missed the operating systems course in the winter term, so the whole burden of designing the nuts and bolts of this thing was plainly on me. In the end I spent the evening and the entire next day, missing two whole lectures entirely even though I was physically there, getting this stupid chat server to work, and even then I needed an additional half day finding a workaround for a nasty bug. Not a problem, really, expect before I had this thing finally working I was really sort of scared of not having anything to show in the practicum next (this) week. And that tought me something I hadn’t really considered before: That working with my former programming partner had the one big advantage that I always had a safety net. I may often have cursed him inwardly for putting pressure on me by always rushing ahead, but never, not even once, were we in any danger of not completing the assignment. In fact, it was most unusual for us not to be done one to two weeks before the due date. Not having a solution less than a week before the practicum is a new one for me, and I can’t say I like it.
So a week ago in the project meeting I faced the group with my findings regarding our respective contributions. The message was clear: I have done a lot more than my share, already; moreover, I have also done the same in two other courses; and now it’s time the two of you get your arses in gear, and you had better do so all over the board. Particularly with respect to the fourth guy in our group, who has a very relaxed attitude to say the least (and he still gets good grades!), and who has used most of his time so far for surging ahead with his project for adaptive systems, where I, on the other hand, haven’t done anything except read and think, so far. (I am getting to that.)
It was no use, and somehow I knew it wouldn’t be. My new programming partner is a very nice guy and I like him a lot, but with respect to the study program he is always in over his head. He simply doesn’t have any time to spare to do more. And the other guy has certain isolated activity peaks, but other than that he likes to take it easy. So in the week since, these two have continued to sit on the single ticket (work assignment) they have already been sitting on for the previous two weeks, not getting anything done, while my programming partner and I completed each another ticket in the same time, bringing our combined total to nine for this milestone, as compared to exactly none for the other two. Small wonder then that our presentation this afternoon will not present a workable simulation, as it easily could have if just all of us had been roughly pulling their weight. I am fighting the temptation to view this as project management failure on my part. It’s a study project, and there is neither any external pressure (we have no customers) nor any internal pressure (I can’t fire those who aren’t contributing). We only have our intrinsic motivation to push us, and clearly for the two of them that’s not enough.
Oh well. I guess in the end that’s the whole point of this project–we ought to learn about the problems of organizing work in a team, and I am learning. That we are also producing a software product is simply a way to an end.
In any case, willy-nilly I have to reduce my involvement in this project so I can catch up with the three other courses, and if that means it will progress at a snail’s pace from here, so be it. Even though it still lacks the keystone, we have produced quite a large edifice, both in terms of complexity and of size (5,400 lines of code so far).
For the last couple of days, I have finally returned to my adaptive systems project (the Maze) and I have now the rudiments of a working game, including a graphical representation using the GUI library Tk (already somewhat familiar from our first-term Ruby programming, but also available for Python). Moreover, after many days of banging my head against the wall, I have finally had my aha moment regarding temporal difference learning. It’s usually that way with me: I get stuck on understanding the most basic thing about something. In this case it was the idea of updating my estimate of the value of a situation without knowing the final outcome. The value of a state (e.g. a situation in a game) with respect to a final reward (e.g. winning the game) is a key principle in reinforcement learning. Classically you compute that value for earlier situations only after you know the final outcome. That algorithm is called, for reasons unclear to me, Monte Carlo, and it’s comparatively easy to fathom. In temporal difference learning, however, you adjust your estimate of the situation as you go, and that was beyond me for a long time. But in fact it’s simple: You use your estimate of the next situation from an earlier iteration to adjust your estimate for this situation. The old estimate for the next state plus the observed reward for the present state is your new value. And in the first iteration, you use random values so you have something to start with.
It’s funny that I should have had such problems getting something so basic, but I have that talent. A lot of my co-students are much quicker on the uptake, at least initially. But once the penny drops for me on the basic things, everything that follows from them becomes suddenly ridiculously obvious for me, and then I start catching up. So that problem is out of the way and I can start programming.
And of course at the same time I am doing my flashcards for computer networks, a course that is becoming successively less entertaining and more demanding the closer we get to the wire. True to the top-down approach used by the professor, we have passed from the application layer to the transport layer, and are now concerned with how the TCP protocol works. We are calculating round-trip times and juggling packets to and fro, trading acknowledgements that have a tendency to get lost, a problem for which fortunately different good solutions have been developed by people who are a lot more knowledgeable about these things than I really want to be. But just as with operating systems last term, unfortunately we can’t let it rest at that. Equally, I again have flashcards for the software engineering (part II) oral exam, on topics such as testing strategies, continuous integration, quality management, risk management, organizing review and meetings, and so on. It’s going to be alright, but I find it harder to get a grip on all this vague project management vocabulary than on the more concrete contents of the first part last term. In the end, it’s all more or less common sense, but of course the professor wants to hear the exact terminology. For instance, reviews, inspections, and walkthroughs are all ways of discussing code with other people, and I suppose in real life they overlap, or people even use the terms interchangeably. But for the exam we have to know the difference.
I still haven’t even started working seriously on preparing for the intelligent systems exam. As I said, the lecture is proceeding at a snail’s pace, and mostly my attention wanders. But there will be an exam, certainly not a nasty one, but it will involve some algorithms, some Prolog, some logic, and so on. I should prepare my crib, but I am again crippled by the professor’s insistence on its being hand-written. Can’t really do that in advance, or how would you manage your space? I tried to discuss this with the professor, but she cut me off before I could even start. I suspect she considers demanding a hand-written crib particularly pedagogic, but in face it simply means you can’t prepare at all before the end of the term. I wonder if this was her intention, or whether she has just resigned herself to the fact that almost all students would in any case start preparing late. Well, not me, but I suppose that’s my private problem, then.
So yes, I feel I should stop wasting my time and get my own arse in gear. It’s time to concentrate on the things that will make a difference in the end. The state of our software engineering project won’t, but the adaptive systems project and exam preparation will.