But I didn’t give the students a programming problem. I gave them a software project to solve a problem I have, which involves UX and PM work along with some coding.
The actual words used were already vague enough ("ideas for a software project"). The answer to that would always be subjective. Why is there no trust in the author that he has a better read of the room? He definitely has more context of what the students were actually asking for. These are also, students; I'd give the author benefit of the doubt that he gave them a problem that would be most productive use of their time given their skill level. Maybe that's why he didn't consider web browsers or bug trackers.
FWIW, I think the article makes a good point but is poorly illustrated, especially for this audience. I've no doubt your average HN commenter has projects/scripts under their belt more complicated than a clipboard logger, maybe even on far tighter time constraints. But c'mon, these are students! If you work in the industry there will definitely be different causes for project under-estimation.
And since the author teaches software engineering classes and not UX classes I assume this would be a software engineering project and not a UX project. Building out a lot of UX features without users is an anti pattern, better write a bare bones implementation first (start from command line, help first users set it up and see how they like it) and then work from there. For a hobby project that would likely be the end of the project, and a good student could get it in a few hours I'm sure.
Most things about software dev are never taught to college students. This is actually an excellent project to teach students beyond programming for computers and building things for humans. Not thinking about UX is what leads to most software projects failing because we are fundamentally different from computers (do I even need to explain this?)
I wish I had teachers teaching me stuff like this in my software dev classes instead of the usual stuff. I wouldn't have had to waste years trying and failing to learn this
I think this would be a great class project with the teacher acting as a fictive user. I think it is a horrible hobby project to suggest.
Most of UNIX literally seems to have been built like this.
> If you do UX then you need users to actually test what you write on.
No offense to azhenley but why do you expect any different? They asked a CS professor for a project idea. How many CS professors have project ideas that come with UX case-studies? How many CS professors have the resources to guide students to coordinate actual UX tests outside of a research grant?
It's an outside-of-class project. It doesn't need a compelling use-case.
> It is a horrible project no matter how you view it.
Too harsh, this has yet pedagogical value. Because, you know, they are students. Bulk (if not all) of the work you typically do at school teaches you things even if they are not portfolio-worthy.
> Building out a lot of UX features without users is an anti pattern, better write a bare bones implementation first and then work from there.
I agree with the thought but, again, this isn't real-world software engineering. I feel I can't emphasize this enough. Maybe these students have been writing from-stdlib-up CLI tools ever since and their teacher thought it's time to expose them to APIs other than stdlib. Who knows.
Might as well raise pitchforks that finding the most valuable customer for Northwind Traders (LLC) is counter-productive because the database is outdated. Better gather data first, why not normalize the schema while you are at it, so you can stream it to the cloud and get a better analysis than plain SQL. (Calm down, Northwind is a sample database for education purposes.)
People who write blog posts on the internet are not exactly immune to poor communication.