CPTTM SDI 2005-001 end of project review

The instructor simply tells the student what to type. The student doesn't want to ask questions because it will slow down the process. As a result, the student may not know what's going on until after a long time.

1. The instructor can briefly describe what they're going to do before telling him what to type.
2. The instructor can ask the student to see if he has any questions after they commit.
3. Similar to (2) but the instructor should ask student whenever he finds a puzzled look.
4. Tell the students by asking questions they won't slow down the progress. It's just the opposite. Only good programmers can go fast.

I think (1) won't work well. My personal experience indicates that students usually don't understand explanations without seeing the code. Usually typing the code first and then explaining later works better.

I'd suggest a solution based on (2): The instructor can ask the student to see if he has questions when running "All Tests". This will make much better use of the idle time waiting for the tests to run.

(3) should provide the fastest feedback to the student but it requires the instructor to be very sensitive. So it may not be practical.

(4) can be done, although I'm not sure if it will change their behavior.

Too many new technologies (Tapestry, Hibernate, OpenWFE and etc.) for the students. The gap is too wide. As a result it takes quite a long time for them to get on track.

1. Give the students a few overview sessions.
2. Use simpler technologies (e.g., Swing).

This raises the question of what can be best learned in a traditional training course and what can be best learned in pairing. I think that pairing excels when teaching a few skills that are so hard to master and that require repetitive uses/practice. Traditional training is better for the rest of the stuff.

(1) seems to be in the right direction. However, should SDI really be positioned to teach all the hot and great technologies that help the students to get a job right away? I think its real mission is to transfer fundamental skills in software development that require repetitive practice to master (OO, customer interation, planning, team work, testing). With these fundamental skills they can learn all the hot new technologies by attending regular training courses to prepare themselves for the job market. New technologies will become old one day, but the fundamental skills last. SDI is not a replacement for regular training, but an important complement.

Therefore (2) seems to be the right way to solve this problem.   

Not all instructors are good at writing unit tests. Due to lack of instructors, it is impractical to require all instructors to be good at this before joining SDI. Instead we may identify a couple of instructors who are better in this aspect and let them inspect unit tests written by others and suggest ways to improve the tests. The ideal timing may be when they're running "All Tests". The resulting tasks must be signed up. The hard part is how to make sure they will do this job. One way is to do a standup meeting every session (or iteration) and ask each person in turn to report his findings on quality problems.

1. Separate data and logic and try to reuse the logic.
2. Extract code into method to show its intention.

As suggested above, we can make good use of the time when running "All Tests" including: seeking questions from the students, looking for quality problems and etc.

In addition, working on fat clients should improve the situation.

This is the most important reason for the slow velocity of our team. If this solution works, it will greatly speed up the velocity. So this is a very attractive proposition.

However, due to the natural sizes of the stories as defined by the acceptance tests, we can only complete one or two stories in each iteration. For this solution to work, two people must be able to implement the story as quickly as 12 people. Not that it's impossible, but I am not sure how likely it is.

What if it can't be done? The worst case is to revert back to the current situation. However, can we plan the stories for say 3 iterations and allow a story to span across iterations? This can blur the velocity as it's difficult to measure how much work is done and how much work is to be done in a story. However, by estimating the relative workload of each task in a story, the velocity can still be measured pretty accurately. Another difficulty is that there may be little to demo to the customer at the end of the iteration as all the stories are only partly done.

1. Strongly suggest (force) the user to do this story at the beginning.
2. Give this user story a high point if it is done later but a low point if it is done at the begining.

We as the developers can't force the user to do which user stories first. So (1) doesn't work. If we try to play this role, we will jeopardize the project as we'll be interfering with user's view on what's important and what's not. We are in no position to do that.

(2) sounds OK in principle, but is very difficult to do in practice as there are too many sequencing combinations.

I think we're mixing two issues together: Implementing login itself is easy to do. What requires a lot of effort is to make sure the Tapestry pages are access protected. This is what the access control for PR user story does. The scope of this user story is semi-fixed (limited to PR pages, but if we add new PR pages or new PR stories, the scope will expand). This is not good. User stories should have fixed scopes.

But a more important issue is that, shouldn't security (including access control) be built-in when the code is being written? Adding security later doesn't sound like a good idea. Security should be part of the architecture.

Therefore, access control should probably be part of each individial user story. But when considering complicated access control issues such as who can read or write a PR in a given tray, the user story will become quite large and involve a lot of domain logic. But let's try.