[stcredzero]

I think I did, hmm, three labs like this? None of them produced anything close to a real software product.

The devil is in the details! Stuff you think isn't a big deal As an undergrad CS student might well be a freaking big deal! Example: in my current project, we've found that in the new system version, the vendor's "type and the list selects the matching prefix" functionality kinda works, but slowly. (As in, over 3 keystrokes a second is too fast and the system loses track of the full prefix.) To our users, it doesn't work at all. Their accustomed workflow is disrupted across the whole app, so I have to go and patch it.

In academia, stuff like this is considered a triviality. In the real world, it matters a lot!

[troutwine]

Interesting. I'm nearly ready to graduate from Portland State University and I know, beyond a doubt, that had I turned in a project with a flaw that glaring I would have failed the project, for "general unsuitability".

Different schools, different methods, I suppose.

[stcredzero]

had I turned in a project with a flaw that glaring I would have failed the project, for "general unsuitability"

I think you miss my point. The problem is over perception of what is "a flaw that glaring." This differs in academic culture and business culture. As you point out, it can even vary from school to school or company to company.

I think you aren't being entirely self-honest about what is glaringly "obvious." My point is actually that what is "glaringly obvious" in one context to one set of people isn't at all so to another set of people in a different context. Awareness of this should not only be taught in some sort of course but also adopted as a core ability for those in the software field. It's pretty fundamental to a whole host of sticky problems we all face with regard to understanding requirements, design, documentation, and fixing bugs.