41–50 of 279 posts
This sounds more like a problem of scope creep than unexpected complexity
This is only true if you believe software development to be the practice of slavishly implementing ill-defined requirements regardless of what the user actually wants.
Earlier quoted context omitted.
This was supposed to be a student hobby project, not a company product release. You are thinking of this problem from the perspective of an enterprise programmer, not of a hobbyist enthusiast.
I’m baffled by the level of offence you’re taking at the idea that this is all part of a programmer’s job. Nobody needs to go to college to become a hobbyist programmer, it serves students very poorly to treat them that way. It’s the same reason we teach algorithms instead of just how to google. Code doesn’t exist in a vacuum.
This is a strawman, I never said these things aren't a part of a programmer's job.
> Nobody needs to go to college to become a hobbyist programmer
Nobody needs to do enterprise programming on hobby projects, you learn that on the job. For a hobby project it is more important that the project is fun, and very few find enterprise coding fun.
Earlier quoted context omitted.
This was supposed to be a student hobby project, not a company product release. You are thinking of this problem from the perspective of an enterprise programmer, not of a hobbyist enthusiast.
They are studying to become professional programmers. I think the enterprise perspective is correct, you don't want grad students with a hobbyist mindset.
> A few students came to me asking if I had any ideas for a software project that they could work on outside of class. > I explained an idea for a utility that I had been wanting: A desktop program that monitors my clipboard for URLs and logs them automatically. I think this person misunderstood the students, the student wanted a project to practice programming, not a project to practice project management. The progr…
Was curious if I could pull this off, and managed to get a Mac version "working" at an "acceptable" (there isn't even a quit button yet) level to serve as a starting place. Was embarrassed by the quality, since it's just 5-6 snippets (of various style) pasted together...but I might as well share it anyway to prove the point: https://github.com/owenfi/clipboardcopies The article does strike me as "scope creep" or miss…
I think interpreting the intention of the author and the students should take into account that the author's research is in human-computer interaction and that the students most likely are aware of that fact as well.
>The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. - Tom Cargill, Bell Labs
Some things are important to plan since they are hard to change, like user data or API boundaries, but other than that simple is usually the best to start with.
Earlier quoted context omitted.
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.
Right, but was that what the students asked for? I doubt they thought that they could launch a successful product in 2 hours worth of work.
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.
Earlier quoted context omitted.
I think interpreting the intention of the author and the students should take into account that the author's research is in human-computer interaction and that the students most likely are aware of that fact as well.
that's fair, and maybe if they wanted a "project" then project management was the right thing to look at.
Earlier quoted context omitted.
> The programming parts of this would take 2-4 hours This is, literally, the error that the entire article works on dispelling. Anyone can write a rough command line tool that monitors the clipboard and prints to stdout. Writing a usable GUI application is a lot more work. That’s not project management, that’s coding work. The ratio of project management work to coding isn’t 10:1 or even 100:1 like you’re suggesting.
> Anyone can write a rough command line tool that monitors the clipboard and prints to stdout. There's a good chance that this will solve 95% of all needs. Most of the features suggested in the article beyond the original premise are unnecessary.
The teacher is the client. The client is the one who will better estimate what is necessary or not.
If you own a company and someone wants to contract you for work, you start explaining how what the client says it needs is not necessary and how he can manage with less than he demands?
Earlier quoted context omitted.
Right, but was that what the students asked for? I doubt they thought that they could launch a successful product in 2 hours worth of work.
I'm sorry but I gotta call this out; this is just peak HN arrogance. All we have is an article relating an anecdote and the reaction to it is to second-guess the author's actions/interpretation of events. Surely, the author has more context of what was actually happening, what was actually being asked for? The actual words used were already vague enough ("ideas for a software project"). The answer to that would alway…
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.