A desktop program that monitors my clipboard for URLs and logs them automatically.
All the other concerns are not part of the original ask. I think for someone who knows these APIs, 2 hours to working prototype is totally doable. The biggest question in my mind: why does the author assume all of those extras are necessary before knowing whether or not they’ll even find value in the simplest possible thing?
Don’t go implement every feature idea you come up with from this exercise!
I explicitly said not to go implement all of these features. It is a quick thought experiment to find the design decisions that are important to you/your users before making plans and estimates.
I get that. My problem is that it’s easy to go so off the rails in brainstorming that you miss the fact that the most basic thing is stupid anyway. You can always complicate later, but if you complicate too soon, you might convince yourself it’s not worth it.
if you complicate too soon, you might convince yourself it’s not worth it.
That might be a good thing. You’re assuming the only way to know if you need the complication is to first build the simplest possible thing™. That might be true, and prototypes are often illuminating. But it’s not necessarily true. Often you can think through something and realize that, you know what, this really isn’t worth it unless I also have A, B, and C features, and those are actually harder than I thought.
There are fine lines between and intuitive judgements needed to balance motivation, analysis-paralysis, and coding-without-a-plan. The errors in each direction are real.
There are fine lines between and intuitive judgements needed to balance motivation, analysis-paralysis, and coding-without-a-plan. The errors in each direction are real.
This is very well stated, and I completely agree with your comment.
I disagree as well, I think having your students build a prototype in 2 hours is even more valuable then product-izing the whole thing. You don’t even know your own requirements until after you’ve spent a day or two with the prototype to see if it actually scratches your itch.
You (the customer) could decide that you had an X - Y problem all along (I said I wanted to know all the URLs from my clipboard, but what I actually wanted was the ability to search my chat history).
Any widget can expand into a million development hours of wondiferous UI and integrations, that’s not surprising. If anything I would take this design exercise with the students and then turn it around one more time to teach a lesson about scope creep. (Ok, we did all this, now take 3 hours to build your 2 hour prototype, and don’t paint yourself into a corner).
I’d rather spend 10-20 minutes going through this exercise and asking questions about what features are needed, then building a prototype. It doesn’t have to be one or the other.
This hits on a bugbear of mine where people say “just do X and then just do Y, simple enough”; emphasis on the word “just”. It’s almost never just a matter of “just” and a lot of seemingly trivial tasks end up down rabbit holes where a bulk of the venturing could have been avoided by a slightly lengthier planning process, or “thinking more about it” process if one is averse to the concept of planning.
At some point it occurred to me that whenever I used the word “just” in a code review comment, it was a sign that I wasn’t being as constructive and helpful as possible. Now when I catch myself using that word, I stop and consider whether my comment could come off as condescending or flippant even if that wasn’t my conscious intent. The answer is “yes” often enough to keep me vigilant about the word.
Ha ha ha - had not heard that one. As a marketer, I always roll my eyes when people say (and they often do!) “can’t they just build that in, like, 2 hours?”
As originally stated before scope creep, 2 hours sounds reasonable. Dump urls, line by line, into a file. Urls start with http. Every time.
Written in Python. Uses the pyperclip library. Polls for updates. Take polling frequency as environment variable, default to every 60 seconds. Consider using a notification library like notify-py to share saving those urls with the user. Add a conditional to not save the same url twice in a row.
This design phase took 10 wall clock minutes and I brushed my teeth in the middle.
For students? This could take 2 hours to write.
But all these features and considerations and designs? Do they fit the user’s need or not? If not, don’t mess with it. When the user thinks “gee I wish…” that’s when you add a bell or whistle. Until then, solve the user’s problem.
Unless you don’t care about the user, but want accreditation or investment dollars. In which case, go ahead, take three weeks to do market research on timestamp formats hypothetical users might want in their glossy url recording service.
Sometimes, the user actually just needs something simple.
As originally stated before scope creep, 2 hours sounds reasonable.
“scope creep” in this context seems a little loaded. The question is about the merit of those features.
Do they fit the user’s need or not?
That’s exactly the point. Every request from a user has an implied caveat, being “do whatever you need to do to solve the actual problem, which may not be the literal ask.” It’s fairly clear that dumping URLs to a log without providing a way to access it isn’t that helpful for a user.
Putting myself in the user’s shoes, I wouldn’t want to run something that unconditionally polls, particularly when a notification API is available. But that unravels fast, because something like AddClipboardFormatListener that sends window messages isn’t going to be simple to retrofit using pyperclip.
That goes back to the author’s point: writing code without really understanding what’s in scope to solve the user’s problem is likely to waste a lot of time.
Reminds me of the ol’ ‘This StackOverflow site looks like it could be cloned in a weekend’[1]
The main gist is that we see the overall structure or DB schema as the core of the problem. Especially in open source. When we try to do something similar, we may have that core chunk correct, but it’s not usable by anyone but ourselves. I believe it’s one of the big gate keepers of using open source software.
… Often used ironically by the intended victim when a suggestion for a program is made which seems easy to the suggester, but is obviously (to the victim) a lot of work.
This post struck a nerve with me. I currently have people on Twitter complaining about a problem that “only needs two hours of your time” (a direct quote). At a previous job, people were upset because “the community could knock this out in a day”.
From my limited career experience, there’s a huge time difference between a prototype and a production system. I find that, indeed, many prototypes take a small amount of time. Much of my time comes from “productionizing” the system: handling edge cases, adding logging, dealing with platform-specific inconsistencies, etc.
Perhaps these people are right, and perhaps I should be faster by an order of magnitude. But from my experience, real production software takes a lot of time to get right.
Some of these points should obviously be out of scope. Want to pause clipboard monitoring? Just close the software. Want it encrypted? Come on, even your browser history isn’t.
All the other concerns are not part of the original ask. I think for someone who knows these APIs, 2 hours to working prototype is totally doable. The biggest question in my mind: why does the author assume all of those extras are necessary before knowing whether or not they’ll even find value in the simplest possible thing?
I explicitly said not to go implement all of these features. It is a quick thought experiment to find the design decisions that are important to you/your users before making plans and estimates.
I get that. My problem is that it’s easy to go so off the rails in brainstorming that you miss the fact that the most basic thing is stupid anyway. You can always complicate later, but if you complicate too soon, you might convince yourself it’s not worth it.
That might be a good thing. You’re assuming the only way to know if you need the complication is to first build the simplest possible thing™. That might be true, and prototypes are often illuminating. But it’s not necessarily true. Often you can think through something and realize that, you know what, this really isn’t worth it unless I also have A, B, and C features, and those are actually harder than I thought.
There are fine lines between and intuitive judgements needed to balance motivation, analysis-paralysis, and coding-without-a-plan. The errors in each direction are real.
This is very well stated, and I completely agree with your comment.
I disagree as well, I think having your students build a prototype in 2 hours is even more valuable then product-izing the whole thing. You don’t even know your own requirements until after you’ve spent a day or two with the prototype to see if it actually scratches your itch.
You (the customer) could decide that you had an X - Y problem all along (I said I wanted to know all the URLs from my clipboard, but what I actually wanted was the ability to search my chat history).
Any widget can expand into a million development hours of wondiferous UI and integrations, that’s not surprising. If anything I would take this design exercise with the students and then turn it around one more time to teach a lesson about scope creep. (Ok, we did all this, now take 3 hours to build your 2 hour prototype, and don’t paint yourself into a corner).
I’d rather spend 10-20 minutes going through this exercise and asking questions about what features are needed, then building a prototype. It doesn’t have to be one or the other.
This hits on a bugbear of mine where people say “just do X and then just do Y, simple enough”; emphasis on the word “just”. It’s almost never just a matter of “just” and a lot of seemingly trivial tasks end up down rabbit holes where a bulk of the venturing could have been avoided by a slightly lengthier planning process, or “thinking more about it” process if one is averse to the concept of planning.
Reminds of the (unattributed?) saying:
To be fair, sometimes, hours of coding can save you weeks of planning as well.
Wholly agreed. My own experience has unfortunately gravitated more towards the “just this and just that” mentality.
You’re not alone - I reference this piece often when people overuse “just”. https://alistapart.com/blog/post/the-most-dangerous-word-in-software-development/
At some point it occurred to me that whenever I used the word “just” in a code review comment, it was a sign that I wasn’t being as constructive and helpful as possible. Now when I catch myself using that word, I stop and consider whether my comment could come off as condescending or flippant even if that wasn’t my conscious intent. The answer is “yes” often enough to keep me vigilant about the word.
Ha ha ha - had not heard that one. As a marketer, I always roll my eyes when people say (and they often do!) “can’t they just build that in, like, 2 hours?”
As originally stated before scope creep, 2 hours sounds reasonable. Dump urls, line by line, into a file. Urls start with http. Every time.
Written in Python. Uses the pyperclip library. Polls for updates. Take polling frequency as environment variable, default to every 60 seconds. Consider using a notification library like notify-py to share saving those urls with the user. Add a conditional to not save the same url twice in a row.
This design phase took 10 wall clock minutes and I brushed my teeth in the middle.
For students? This could take 2 hours to write.
But all these features and considerations and designs? Do they fit the user’s need or not? If not, don’t mess with it. When the user thinks “gee I wish…” that’s when you add a bell or whistle. Until then, solve the user’s problem.
Unless you don’t care about the user, but want accreditation or investment dollars. In which case, go ahead, take three weeks to do market research on timestamp formats hypothetical users might want in their glossy url recording service.
Sometimes, the user actually just needs something simple.
“scope creep” in this context seems a little loaded. The question is about the merit of those features.
That’s exactly the point. Every request from a user has an implied caveat, being “do whatever you need to do to solve the actual problem, which may not be the literal ask.” It’s fairly clear that dumping URLs to a log without providing a way to access it isn’t that helpful for a user.
Putting myself in the user’s shoes, I wouldn’t want to run something that unconditionally polls, particularly when a notification API is available. But that unravels fast, because something like AddClipboardFormatListener that sends window messages isn’t going to be simple to retrofit using pyperclip.
That goes back to the author’s point: writing code without really understanding what’s in scope to solve the user’s problem is likely to waste a lot of time.
Designing for one user is much easier than designing for all of them.
Either the need is real and you want a real tool to fit one person’s need, or you want to design something for the sake of the challenge.
That sounds like a terrible approach to outsource design decisions to the user.
“We’ll just make that a setting the user can customize. “
Reminds me of the ol’ ‘This StackOverflow site looks like it could be cloned in a weekend’[1]
The main gist is that we see the overall structure or DB schema as the core of the problem. Especially in open source. When we try to do something similar, we may have that core chunk correct, but it’s not usable by anyone but ourselves. I believe it’s one of the big gate keepers of using open source software.
[1] https://blog.codinghorror.com/code-its-trivial/
I think Codidact took about a year, but it’s open source so now you can work from that instead of scratch.
https://github.com/codidact/
There’s a great answer on meta: https://meta.stackexchange.com/questions/2267/are-there-any-clones-alternatives-for-running-a-stack-exchange-style-qa-site
Perhaps relevant: http://www.catb.org/jargon/html/S/SMOP.html
This post struck a nerve with me. I currently have people on Twitter complaining about a problem that “only needs two hours of your time” (a direct quote). At a previous job, people were upset because “the community could knock this out in a day”.
From my limited career experience, there’s a huge time difference between a prototype and a production system. I find that, indeed, many prototypes take a small amount of time. Much of my time comes from “productionizing” the system: handling edge cases, adding logging, dealing with platform-specific inconsistencies, etc.
Perhaps these people are right, and perhaps I should be faster by an order of magnitude. But from my experience, real production software takes a lot of time to get right.
Why does the first version have to be “production software”?
It doesn’t have to be in all cases, you’re right. In the two personal examples I mentioned above, they were.
Because that’s all the time that product gave you.
Some of these points should obviously be out of scope. Want to pause clipboard monitoring? Just close the software. Want it encrypted? Come on, even your browser history isn’t.