The Third Bit

The list looks good to me! I might add a few things:

Different ways to integrate your work – see http://toolsmiths.blogspot.com/2007/06/some-different-approaches-to.html
for what I’m referring to.

Test Harnesses

The Build is Broken – so what?

Time Zone issues (hey. some students work like they’re on another continent)

and maybe mention that products get worked on in parallel.

~Matt

Hi Greg,

I have found in the past, that if you forget everything else, then documenting the process is the most important general rule. I don’t mean documentation for the software etc. More documenting what has happened, decisions etc… via the wiki, email archive, subversion history, etc… To be honest people hardly ever go back through these to find something. The real value is the fact that you could if you wanted to, and thus it makes people act more responsible, productive and motivated. Everyone wants to be the loudest mouth on the mailing list, the one with the most commits, etc… it just gets people moving.

Cheers.
Jonathan.

Great Idea.

A key section is project type:

Project Type:
Motivation:
The Product Upgrade
The Legacy Port
The Technology Port – The Great Ruby Re-Write
The Change of Owner Port – My Dept. My Stack
The (V Rare) Blue Sky – Pure Research Dev
The (Rare) Green Feild – Research Driven Dev
The (Common) Brown Feild – Basic New Features Dev
The (V Common) ‘Sale Critical’ Feature
The (Rare) Pure Refactor – Samurai!
The Contractor Relay – When did this project start?
The Death March – When will this project end?

Target:
Multi Platform Behemoth
Single Platform Behemoth
The GUI re-skin
The Middle Tier Flush
The Back End clusterization
The Cluster consolidation
The Mold Breaker
The Phases:
1: Boundless Promise
2: Grand Proclamation
3: Enthusiastic start
4: Teathing Issues
5: Disillusionment
6: Despair
7: Panic
8: Distancing of Management
9: Praise of the uninvolved

The last section is some-what tongue in cheek.

But this type of taxonomy is always missing from books on how to develop software products and yet the impact of the ‘Motivation’ is massive.

Being able to take a step back and see what type of beast you’re trying to tackle is very helpful in answering the judgement call questions like speed/quality/cost, sturdy/agile/hybrid, who will want to help, who should help, who has most experience?

There must be a site somewhere where we could pull together a group of people to write this text book of experience based rant/guidance/theory…

That’s a terrific idea, and I look forward to reading it!

The list looks pretty comprehensive to me. I don’t know if it fits with 301 but maybe you can also talk about these other points:

- The guide, to me at least, assumes the students are starting a project from scratch, start to finish. I think it’d be good to give an eye opener about jumping on board an ongoing project since that is pretty much the reality for new entry developers, i.e. they should get use to reading other people’s code, try to figure out what it does, then make changes. It’s probably counterintuitive to how CS students have been taught soft dev in first and second yr programming courses.

- Put more emphasis on testing (I don’t see it up there!). Unit testing, regression, etc.

Here are some things I think are important in a university team project:

- Version control.
- Regular meetings.
- Most important of all are the people. If at all you can, try to work with people whose goals are similar to your own. If you intend to get a 95 but you work with people who are shooting for a 60, it’s not going to be a pleasant experience. Although, maybe it will be a realistic experience? I don’t know. Anyway, if the teams are pre-selected then there’s nothing you can do about this.

I think everything above is obvious and I have no idea how (whether) it could be worked into a book, but it’s just my very limited perspective.

Have you seen _Manage It!_ (http://www.pragmaticprogrammer.com/titles/jrpm/index.html) ?

It looks like a very comprehensive guide.

The Pragmatic Programmers have other good references on software development.

Cheers
Chris

Maybe it’s good to go in the detail on how to estimate the work (time & effort) in the Planning and Scheduling section, and how to use the estimation to make project plan. Although you already have “What To Do When Things Go Wrong”, I think you can also focus on what to do when running late on schedule.

For the teamwork section, I find it hard to compare between school and real world. In school, it’s hard to have a real leader / manager; hard to deal with people in your team that you don’t like or have conflict with.

How to have an Arugment

- Don’t take it personal
- Challenge everything
- If everyone agrees then asign a devils advocate

Only one thing comes to mind that isn’t explicitly mentioned, and that’s
something along the lines of “Where to find answers”. You hit a problem
you don’t know the answer to (how do I do X in Python?) — what now?

In reply to Wayne’s third point (devil’s advocate), see also Gloria’s “Let’s All Evolve Past This” post [1], which she says:

Many tech men envision a technical debate as a battle, and celebrate the supposed victory, exhibiting classic ‘Alpha Male’ behavior. I have personally seen it so many times in my profession that I brace myself for it when discussing tech issues with new groups of men. So many of them arm themselves with weapons of aggression, demeaning comments, and behavior which encourage more of a filibuster than a healthy debate. The supposed tech discussion becomes a test of verbal and emotional endurance, where whomever can argue the hardest and last the longest wins.

They can shake hands afterwards and congratulate each other over a ‘good fight’ after a technical debate. “I like the challenge of a good argument, which is why I do that”, one male colleague explained to me. “I like a good technical debate too, but I don’t want to feel verbally or emotionally abused afterward. Women don’t fight for fun, they fight for personal issues.” I explained to my male colleague.

[1] http://www.devchix.com/2007/06/09/let%E2%80%99s-all-evolve-past-this-the-barriers-women-face-in-tech-communities/

One thing that I think is missing is material about testing: regression/unit test harnesses (which don’t need to be complicated – a shell script that ran through tests saved groups that I was involved with on multiple occasions) and design for testability.

Even if you have known your group members for a while, you may not know how well they work in a group, especially if this is your first group project. Some people may not be able to handle their share of the work (lack of technial ability, feeling overwhelmed by the group/project, demands from other courses, etc) so it might be good to talk about ways of dealing with such scenarios so that everybody can feel like they’re pulling their weight.

Will this be an actual colouring book? the best textbook that I ever had was my grade 10 science text – it was written by my teacher in the form of a comic book – it had a cast of characters – the teacher, a bunch of students, scientists etc. and students could colour the panels. A similar style for software projects might be good as it would likely be a lot more interesting than just another text filled with page after page of words. The format and the characters (eg. prof, a group or two, people from industry/ex-students) might give students something to relate to.

Greg, if you can expand on Gloria’s post, call it “how to have a healthy technical debate”, then you’d solve (or at least show how to solve) roughly 60% of the problems I face on courses that require teamwork.

Learning how to release software can be important if the students expect someone else will use it. “Release it!” by Michael T. Nygard is probably the best thing I’ve read in the past couple of years, though it may have limited value for undergrads.