Last week was pretty relaxed, I lectured on doing code reviews — pretty much the standard pitch. This week we spent Tuesday doing a code review, I think it went pretty well. I had chosen a team whose code was strong so that our first code review would be a positive one.
Today I announced that the Huffman compression that the class has been working on has been found by the client to be unsuitable, it does not give a good enough compression ratio for some files of interest: massive PBMs showing mostly text and some graphics. The client decided that its requirements would be better met by first performing run-length compression on the PBM files at the bit level, resulting in 8-bit run-length codes: one bit for the sense of the run, 7 bits for length. Since runs of white are much more common than runs of black, there’s still plenty of redundancy left in the RLE codes, so they should subsequently be Huffman encoded.
The other aspect of today’s assignment is that due to some internal shuffling at our company, the teams have been moved around. Each team must implement RLE compression on top of the Huffman implementation provided by the team whose number is one greater (modulo seven). Teams are forbidden from touching their old code, although I hope they will be willing to answer questions about it. This is an exercise that I’ve been wanting to spring on students for a long time. Hopefully it will be a character-building experience for everyone.
Also in class today we spent some time looking at defect reports on the students’ code from Coverity Scan. This was (for me at least) pretty entertaining. First, the defect reports were of impressively high quality. Second, Coverity’s web interface is quite nice to use
7 responses to “Writing Solid Code Weeks 5 and 6 — The Plot Thickens”
“character-building experience” == cursing instructor behind his back
Is this a graduate-level course? Truly, this course should be a requirement for every CS degree. Good work.
This course sounds like a writing code as a job course instead of the advertised writing solid code. I love the bait and switch. Will you be covering the highly entertaining topic of estimating cost estimation too? I find that’s a skill which just about everyone junior struggles with, and relatively few ever master.
I echo the comment that Coverity Scan is a very good web-based system for solid code bug reporting and triage.
We’ve started using it on a reasonably code-debt riden open source project to great benefit.
dcw, regarding “writing code as a job” I guess that’s fair to say, although I would say that writing code that works on top of someone else’s code is part of writing solid code.
Alas I do not have plans to cover cost estimation, I know zero about that topic…
Hmm, I guess what I was trying to get at is that you’re not just covering writing solid code (which is obviously part of most development jobs), but but you’re covering the sort of interesting activities that happen around coding and development when working on projects that last beyond a single semester. For students their first real experience with that is likely to be after they graduate, and either move on to industry, or into more complex graduate work. The comment on cost estimation was really a hopeful comment that you’d have a good post on how to teach it. When I work with my team, being able to estimate how long something will take is often their weakest skill. The only way I know to learn to estimate well is to do it regularly for years, and be responsible in some way for schedule misses, and frankly that’s a really unpleasant experience with limited success.
It’s outside my area, but does anyone really know how to do cost/schedule estimation very well for many projects? My impression is that it’s very hard, and the models can work but only if you really fit the assumptions. Could be the state of the art has advanced beyond my concepts of “use experience to guess how long, then double that and cross your fingers.”
Hi dcw, I would like to write a post about cost estimation but I’m just wildly unqualified.