Seabase I Case Study

Module K

On Oct. 27, Joann attends the team leaders meeting:

Minutes of Oct. 27 Team Leaders meeting

She learns that, contrary to her assumptions, the project is about more than just "porting" the existing C code to Matlab. "There IS DESIGN in what CS team have to do". She remarks that the team "really should run the simulation Hank sent early in the term" and "really should do empty prototype in simulink as our next objective". She includes these as goals to complete by the next Team Leaders meeting, Nov. 3.

She reports on what she learned in the following email:

Dear Ken, Bob, Arnie, and Dave;

I learned some interesting stuff today. Not only did I almost follow Hank's math
he did for Jon, but matlab is about code, you can't click and drop as I thought.
Check out the attached minutes!

See you in class tomorrow.

--JoAnn

(Listen to some "interesting stuff"!)

  1. Follow JoAnn's request to "Check out the attached minutes!"
    • Do Hank's suggestions sound familiar?
    • Why was a laptop required for their project?
    • When was it first promised?
    • #6 under details. Good idea? Why?
    • What are the "design issues" for the CS team?
    • How are they different from the ME team?
  2. The best information seems to come out of the Team Leader meetings.
    • Evaluate JoAnn's efforts at passing along that information.
    • Yet there also seems to be a lack of clarity; the same questions are asked over and over again. In terms of project management, develop some suggestions that might help avoid the confusion.

A requirement of the project was that any solution must be implemented in Matlab. JoAnn finally comes to the realization that Hank was right all along about the need to learn Matlab, and agrees to follow his program.

Consider (or listen to) this exchange between JoAnn and Hank, from the meeting transcript:

47:20

Hank: We talked a little bit in the beginning about the computer part. 
JoAnn: laughing
Hank: There was some concern, I think, that there wasn't any design aspects, but
it isn't true.
JoAnn: It isn't?
Hank: No, it isn't.
JoAnn: Shoot, we're back at space one if there isn't any design...
Hank: Well, you've just got to jump in there. You'll find out what I'm talking
about.
JoAnn: You mean jump into the Matlab part...
Hank: Right. The S-functions. You'll find more than you bargained for...
48:01

JoAnn: Well, we were thinking about the design in other ways; more like software
engineering, but once we get into Matlab we'll see what they are.
Hank: Tell me more about software Engineering
JoAnn: It's more like analyzing the domain, and all the systems that are coming
into play, and setting up what it's going to be like, and setting activity states,
whatever
Hank: You can do that, can't you?
JoAnn: Well, that's what we were doing, then last week it suddenly hit us that it's
not something that's getting changed, it's just something that's getting taken into
Matlab, and then it will be done.
Hank: Well, Yeah. But I'm not convinced that that code that exists is perfectly
correct. 
JoAnn: Oh shit
Hank: So to do a little analysis on it would be a good thing.
JoAnn: Well that's where we had started, but it could have been a little more clear.
So put a fire under ... analyzing systems, and meanwhile maybe putting fire under me
to get me going on Matlab, cause I need structure, or I'm just going to lay on the
couch...
Hank: Seriously, as I understand it was written in ten days, and it worked, but
I'm not convinced it's bulletproof, or that it does what you want it to do at all
times.
49:28

JoAnn: We figured what part goes where in the s-functions, that's something that
has to be dealt with.
Hank: Yeah. It's all how you divvy it up.
JoAnn: So we have a general idea...Start learning Matlab, that's a big step into
it. Cause then it will make sense.
Hank: We talked about making a skeleton of it...
JoAnn: Right, I loved that, an empty prototype.
Hank: then you've got something you can point to and say "we've done that". That
would be a nice, concrete objective.
JoAnn: A Goal. OK. Thanks. 

Consider JoAnn's comment "then last week it suddenly hit us that it's not something that's getting changed, it's just something that's getting taken into Matlab, and then it will be done".

What does this mean for the CS students self-esteem? We teach them to be creative, analyze and solve problems. But here JoAnn thinks the CS part is just "plug and chug": just port the code into Matlab and all will be complete. How successful is Hank at ameliorating this feeling (see his "ten day" comment)?

The CS team flounders because of a lack of consistent, clear goals. One solution is to follow a meeting with a quick e-mail to "superiors" summarizing what was discussed, and what is expected (and when). Creates a paper trail, good documentation technique.

Would cc'ing minutes to Hank and Dave have done this?
Would it have helped resolve the rider block problem, for instance?
The laptop finally appears to be on its way. How did the delay in its arrival affect the CS team's progress? What could they have accomplished with the laptop if they had had it at the beginning of the semester?

Why couldn't Hank's teams get CS the info they requested?