Joel Spolsky on UCOSP
Posted by Greg Wilson on 2009/10/27
Three pieces of news:
- Joel Spolsky has blogged about UCOSP.
- He’s going to help sponsor us next term, and one of his employees will lead a Mercurial project.
- Being mentioned in “Joel on Software” has a noticeable impact on readership figures:
UCOSP 
eleni said
WoW! This is great news indeed! Great Job Greg!
Eric Burnett said
Slightly off topic, but there was an interesting (if a bit inflammatory) response to Joel’s article posted earlier today defending the general CS teaching process, with associated comments on Hacker News.
Greg Bray said
I would be one of those new readers 😛 Sounds like a great program! Getting undergrads involved with large open source projects should definitely help them be more prepared for the real world. The school that I graduated from has a similar program for both CS and CE/EE degrees to get students involved with industry sponsored projects. I wrote a bit about it here:
http://blog.theg2.net/2009/10/computer-science-at-university-of-utah.html
Keep up the great work!
Theory AND Practice « UCOSP said
[…] by Greg Wilson on 2009/10/29 There’s nothing like a bit of controversy to push up readership—and blood pressure. I inadvertently started it by describing UCOSP to Joel Spolsky at DevDays […]
Mark said
This project looks like an excellent way to teach team skills.
When I was doing my CSE degree back in the early 90’s, we had one colaborative project in our final year. The whole class was split into pairs of teams of three people, half of the teams doing a back end server, with each one paired with another team doing a user interface front end.
The team I was on made a real hash of our half of project, we just didn’t devote enough time early enough to get the debugging completed on time. We suffered many of the problems Joel mentions in his blog, but we worked well as a team to write up a good end of project report, explain our difficulties and say what we learnt from the experience.
Our companion team, writing the UI, completed and debugged their code each persons part of the code was working their test harnesses, but they hardly communicated with us or each each other at all. As such, their final report was an unstructured mess which suggested that they had no problems whatsoever and the reason the system as a whole didn’t work was entirely our fault.
As you can probably guess, we got a 1st on the project, while the other team barely scraped a pass. The important thing from our tutors point of view was that we had learnt what it meant to work as a team, while the other team only saw the code, not the wider context.
This is what I often see as the difference between a programmer and a software engineer. As has been said many times before, there is more to programming than just bashing out code.
Incidentally, if you are going to show a graph like the one above, it is well worth while using a logarithmic scale. As long as it is obvious that the scale is log, it would provides much more information about the scale of the increase in traffic.