April 7th, 2007


A "real world" software development course.

Start - Students are divided up into groups of 3-4, given a loose specification and told to implement solution in technology X by date Y (12 weeks away).

1 week in – No changes. Any requirements clarification requests by students are answered vaguely.

2 weeks in – Students are told they need to have a working prototype ready in 2 weeks.

4 weeks in – Prototypes are evaluated. Students are told to scrap prototype as second big functional change is introduced ("it has to be integrated into outlook", or "it cannot use any client-side script"). Teams are re-organized.

6 weeks in – Students are told the system must use data from a legacy system, which will be made available to them in coming weeks. A "representative sample" (laughs sadistically) will be provided to them (tell them in week 8). Representative sample is small, and structured in a very different way to the way the problem domain is currently understood.

10 weeks in – Legacy data is delivered. Some fundamental information is missing, and shows major discrepancy in way requirements are defined vs. data present to support requirements.

11 weeks in – Minor but annoying change to the environment the software has to run on. Possibly some left-field performance requirements thrown in.

12 weeks in – Project completion.

At any time students could negotiate to deliver less, deliver later, or "spend" more resources - although they would not be explicitly told they could do so. Push-back on requirements changes and schedule re-negotiation (based on said changes) would also be allowed, but also not explicitly stated. Although this sounds somewhat sadistic I think it would go some way to prepare students for "real-world" development.


If there's one thing you can count on about programming in the real world, it's that your customers will never truly understand their problem. If they truly understood their problem in all particulars, then they wouldn't be hiring someone else to solve it. Hence, they'll always be asking for changes - from hour 1 to hour 11. This is why the waterfall method of project management doesn't usually work in the real world. It's also why a signed piece of paper with all deliverables is so important in a flat-rate contract situation. Clueless management ("Week 4: Teams are re-organized.") is not as universal, but it is encountered often.

Can someone please tell me what I'm doing wrong. Please.

What is wrong when you spend two weeks and two interviews, doing everything right as far as you can tell, and you still don't get hired? And it's not like someone else got the job, either - the position is still open. The HR person says "We just didn't feel it was quite the right match" or something to that effect. Which to my ears is that old refrain "it's not you, it's me." Which of course means: "it's you."

So someone tell me. Please. Tell me what the fuck I'm doing wrong. Why can't I get a job? Hm? Hm??

I want to know. What is it I'm doing wrong?
  • Current Mood
    really annoyed with this crap