5 ms·

I've gone down this rabbitole before, and yes, there are things that take two hours, and there are things that take a lot more. The problem is the scope - ie. a

I've gone down this rabbitole before, and yes, there are things that take two hours, and there are things that take a lot more. The problem is the scope - ie. are you trying to do what you said you'll do (miniature software to log urls), or are you adding 100s of requirements to the scope (gui, filters, privacy,...). We had a bunch of .xml files containing some data, and someone wanted a .csv file... sure, an hour max, and it's done. Fire up some perl, loop, xml->hash, take the data needed, print line by line, done... less than an hour. "Hey, can you add just this and that, and separate folders for this and a total and rolling sum?" ...yeah sure... hour or two. "and this and that?" ...sure, another hour... "Can this be made for that department to use.. just add a simple gui" ...and we've gone from an hour or two, to weeks or months of work. Nobody wanted a gui application made for "normal users", with all the checks and verifications and documentation and everything when you made a request... the scope was a simple one-off script, and that actually took an hour or two. This is like requesting a bicycle, than wanting to add a hitch for a boat trailer and making it higway-legal. And the added problem is, that your script never intended to do "all of this", and you either have to rewrite it from scratch, or you software looks like "the Burrow" (from harry potter).

jiggawatts 5y ago
I vaguely remember a rant some famous Linux developer went on about how setting up printing in Linux requires a dozen parameters, half of which are arcane nonsense that the printer manufacturer themselves probably doesn't know how to set up correctly. Meanwhile, on an Apple or Windows computer it can be literally just plug and print. The difference is that hiding those arcane input parameters takes work, and a lot of it. There was a quote that it takes 10x as much effort to remove an input parameter than simply leaving it in there and letting the user fill it out. A lot of people don't get this, and think the simpler-looking software is simple, when under the hood it is probably doing model auto-detection, driver downloads, protocol negotiation, and even firmware updates on the fly! I face this all the time at work. "Can't you just make a single button to run this task so I don't have to figure out how to use this complicated script?" "I can, but not with this budget..."
- jdefelice 5y ago
  When you make one part simpler, you move that complexity to another part.
- Akronymus 5y ago
  Yeah it takes a LOT of work to hide it [1] Also: For some stuff I want to be able to use the "arcane" parameters for some really obscure task where it is just the right flag or something. [1] https://www.youtube.com/watch?v=HllUoT_WE7Y https://www.youtube.com/watch?v=HllUoT_WE7Y
- selbstgebrannt 5y ago
  I believe you’re referring to ESR’s essay http://www.catb.org/~esr/writings/cups-horror.html http://www.catb.org/~esr/writings/cups-horror.html
  - jiggawatts 5y ago
    That's the one!
- erikstarck 5y ago
  “All user input is error.” - Elon Musk
  - svrourke 5y ago
    [flagged]
    - CharlesW 5y ago
      For those who also weren't sure, I learned that this is an actual quote from Mr. Musk to a U.S. Senator and Senate Finance Chairman. https://twitter.com/elonmusk/status/1457497438474981384 https://twitter.com/elonmusk/status/1457497438474981384 I infer the point to be that Mr. Musk trolls so frequently and thoughtlessly that it's impossible to tell whether he believes the things he's saying, which is why quotes from him are mostly worthless as guiding principles.
chiefalchemist 5y ago
> "...just add..." "It's just..." are the two words you never want to hear :)
- OneTimePetes 5y ago
  Simply just add now.. each word increases the difficulty level by one increment.
OneTimePetes 5y ago
In a ideal world- adding a simple user-gui, would be simple. As in- all edge cases and special cases, will not be handled, but just result in a error - that comes along with a suggested fix googled on stackoverflow. The "simple" program, teaches the users to program. Teaches them to leave an-alphabetism behind.
- Hackbraten 5y ago
  I don’t agree. Users can be in a hurry because they have to catch the train. They can have only one hand free because they’re holding a baby. They can be mentally handicapped so they’re cognitively unable to google stuff. They can be depressed and find themselves unable to accomplish even small tasks. Or they’re blind and there’s no accessible website that explains the error. I think all those people have the right to use your app. There’s a point in drawing a line somewhere. But please, don’t make your app hard to use /on purpose/, not even with good intentions in mind.
  - OneTimePetes 5y ago
    Those that have no train to catch, that have no babies to hold, that are not mentally handicapped are not depressed can fix stuff and share it with those who cant. And at work the "users" often have plenty of time. And even more, once they learn and automate half there job away. The world is not obliged to carry anyone along.
deleted 5y ago
[deleted]
jrochkind1 5y ago
You seem to be complaining that users/stakeholders have actual needs that may not be captured by their initial naive statement of the problem/solution/requirements. Indeed, they almost always do. Most users/stakeholders aren't good at technical specification of a solution that will meet their problem. It's part of our job to elucidate that in interaction with them. And then, even when you are good at technical specification, sometimes it's hard even for domain-expert developers to fully understand the problem up front, without iterating. This is one of the useful observations attributed to "agile" (but of course not unique to it). These are some of the reasons that projects often take longer than initially estimated, sure. You can complain about them, or complain about users being bad at specifying their problem/solution, but it's just a fact of reality, complaining about these facts won't make them go away, and part of doing a professional job is dealing with them. Which means being very careful about assuming a feature/task is "easy", and remembering to do more investigation of the problem/domain/requirements than just taking a naive "easy" mission from stakeholders at face value -- which is what OP is about.
- ajsnigrutin 5y ago
  To copy from my other comment: My exact case was some reporting for some project (15 people, 36 months, 1 xml per person per month), to throw into excell and draw one graph, for one PPT, a one time deal, for one project manager to show the numbers on the report. The end project, if I didn't stop the idea, would be a black box, where you would put any number of random xmls, and get exactly what the accountant wanted with one button... so an impossible task.
ivyirwin 5y ago
Yes, scope creep can significantly change the time requirements or even the entire, shall we say "scope". But I think it's just as important for us as developers to be aware of that on the initial request, in order to suss out the actual requirements. What does the process look like when we ask back, "are you going to need to have a total and rolling sum? should we think about making a gui so other people can use it too?" Engaging the requests early on not only helps our planning, it helps the "client" figure that out sooner than later. I think I've been successful in my career because I've been able to listen to a client's request and then help them figure out what they are actually asking for instead of taking it at face value. That can be easier said than done on an internal team, but it changes the quality of the product and dynamic of the team significantly.
- ajsnigrutin 5y ago
  My exact case was some reporting for some project (15 people, 36 months, 1 xml per person per month), to throw into excell and draw one graph, for one PPT, a one time deal, for one project manager to show the numbers on the report. The end project, if I didn't stop the idea, would be a black box, where you would put any number of random xmls, and get exactly what the accountant wanted with one button... so an impossible task.
- growse 5y ago
  Indeed. Much of the time, "scope creep" is actually just discovering what the requirements actually are. It's not that the requirements change, the requirement likely existed all along - it's just that no-body realised it. Iterating through feedback loops where you build something that meets the original ask, only to refine/change/add/remove things as everybody discovers that what they wanted is not in fact what they wanted is not an unreasable approach. > I think I've been successful in my career because I've been able to listen to a client's request and then help them figure out what they are actually asking for instead of taking it at face value. That can be easier said than done on an internal team, but it changes the quality of the product and dynamic of the team significantly. Sometimes you can explore the actual scope by skillfully working with the client before you build anything. Sometimes, however, you can only learn what the actual requirement is by building the wrong thing first.
da_chicken 5y ago
See, I read the article's problem description and think, "Okay, a proof of concept is going to take 2-4 hours. A shippable product is probably going to take 5 to 10 times that long." IMX, it's not even necessarily feature creep. It's failure to stop and adequately understand what constitutes a minimum viable product. Not viable to sell on the marketplace. Merely viable to deliver to another user. There's a huge mistake in software development to think that the hard or complicated part is making the algorithm or understanding how your program will interact with it's own data or external data or hardware. That's seldom the actual hard part. The hard part is making it useful to a human being using the system. If it's just for me, I can use a proof of concept that I wrote in perpetuity. I can deal with how janky it is or the obtuse error messages it spits out. If anybody else has to use it, though, there needs to be a mental model for interacting with the software that is intuitive and comprehensible to the user that doesn't require them to have a comprehensive understanding of the underlying code, clases, and interfaces. This is the actual hard part of software development, and the bad part is that it's typically the part that nobody likes to do. That's the lesson the professor is trying to teach here. It's not how to write a program. Nearly any fool can do that. The lesson is: how to author deliverable software.
- derefr 5y ago
  With scripting, often you don't have to deliver it to another user; you just have to get the data from them, run your script on it, and give them back the result. It only has to work on your machine, because that's the only place it'll ever be run, and only once.
jareklupinski 5y ago
> making it higway-legal this is the crux imo; an experienced engineer can hack together a compelling MVP of almost anything technical in a reasonable amount of time, but getting that same code in line with regulatory frameworks and the expectations of the end user is what separates a weekend script from a scalable business
mrslave 5y ago
As long as the client is accepting of time-T-for-feature-F, I quite like this mode of development. Whatever is built shows value at every step. As long as a suitable programming language is used to allow for the changing executing environment (in your example: a GUI).
redhale 5y ago
I often think about this XKCD from years ago: https://xkcd.com/1425/ https://xkcd.com/1425/ "When a user takes a photo, the app should check whether they're in a national park..." "Sure, easy GIS lookup. Gimme a few hours." "... and check whether the photo is of a bird." "I'll need a research team and five years."
Lord_Zero 5y ago
This is hilarious to me because this is exactly what I get from my clients and I would expect nothing less from a college professor. "Just build me a URL logger". And then after saying "sure, we can knock that out quick" they ask for pause ability, title fetching (which is not as trivial as the author makes it sound if you want to handle edge cases)https://stackoverflow.com/questions/64051968/retrieving-title-of-a-page-with-url-in-nodejs https://stackoverflow.com/questions/64051968/retrieving-titl..., rich logs, log management (deleting records), GUI for logs, cloud sync.

jiggawatts 5y ago

I vaguely remember a rant some famous Linux developer went on about how setting up printing in Linux requires a dozen parameters, half of which are arcane nonsense that the printer manufacturer themselves probably doesn't know how to set up correctly. Meanwhile, on an Apple or Windows computer it can be literally just plug and print. The difference is that hiding those arcane input parameters takes work, and a lot of it. There was a quote that it takes 10x as much effort to remove an input parameter than simply leaving it in there and letting the user fill it out. A lot of people don't get this, and think the simpler-looking software is simple, when under the hood it is probably doing model auto-detection, driver downloads, protocol negotiation, and even firmware updates on the fly! I face this all the time at work. "Can't you just make a single button to run this task so I don't have to figure out how to use this complicated script?" "I can, but not with this budget..."

jdefelice 5y ago
When you make one part simpler, you move that complexity to another part.
Akronymus 5y ago
Yeah it takes a LOT of work to hide it [1] Also: For some stuff I want to be able to use the "arcane" parameters for some really obscure task where it is just the right flag or something. [1] https://www.youtube.com/watch?v=HllUoT_WE7Y https://www.youtube.com/watch?v=HllUoT_WE7Y
selbstgebrannt 5y ago
I believe you’re referring to ESR’s essay http://www.catb.org/~esr/writings/cups-horror.html http://www.catb.org/~esr/writings/cups-horror.html
- jiggawatts 5y ago
  That's the one!
erikstarck 5y ago
“All user input is error.” - Elon Musk
- svrourke 5y ago
  [flagged]
  - CharlesW 5y ago
    For those who also weren't sure, I learned that this is an actual quote from Mr. Musk to a U.S. Senator and Senate Finance Chairman. https://twitter.com/elonmusk/status/1457497438474981384 https://twitter.com/elonmusk/status/1457497438474981384 I infer the point to be that Mr. Musk trolls so frequently and thoughtlessly that it's impossible to tell whether he believes the things he's saying, which is why quotes from him are mostly worthless as guiding principles.

chiefalchemist 5y ago

> "...just add..." "It's just..." are the two words you never want to hear :)

OneTimePetes 5y ago
Simply just add now.. each word increases the difficulty level by one increment.

OneTimePetes 5y ago

In a ideal world- adding a simple user-gui, would be simple. As in- all edge cases and special cases, will not be handled, but just result in a error - that comes along with a suggested fix googled on stackoverflow. The "simple" program, teaches the users to program. Teaches them to leave an-alphabetism behind.

Hackbraten 5y ago
I don’t agree. Users can be in a hurry because they have to catch the train. They can have only one hand free because they’re holding a baby. They can be mentally handicapped so they’re cognitively unable to google stuff. They can be depressed and find themselves unable to accomplish even small tasks. Or they’re blind and there’s no accessible website that explains the error. I think all those people have the right to use your app. There’s a point in drawing a line somewhere. But please, don’t make your app hard to use /on purpose/, not even with good intentions in mind.
- OneTimePetes 5y ago
  Those that have no train to catch, that have no babies to hold, that are not mentally handicapped are not depressed can fix stuff and share it with those who cant. And at work the "users" often have plenty of time. And even more, once they learn and automate half there job away. The world is not obliged to carry anyone along.

deleted 5y ago

[deleted]

jrochkind1 5y ago

You seem to be complaining that users/stakeholders have actual needs that may not be captured by their initial naive statement of the problem/solution/requirements. Indeed, they almost always do. Most users/stakeholders aren't good at technical specification of a solution that will meet their problem. It's part of our job to elucidate that in interaction with them. And then, even when you are good at technical specification, sometimes it's hard even for domain-expert developers to fully understand the problem up front, without iterating. This is one of the useful observations attributed to "agile" (but of course not unique to it). These are some of the reasons that projects often take longer than initially estimated, sure. You can complain about them, or complain about users being bad at specifying their problem/solution, but it's just a fact of reality, complaining about these facts won't make them go away, and part of doing a professional job is dealing with them. Which means being very careful about assuming a feature/task is "easy", and remembering to do more investigation of the problem/domain/requirements than just taking a naive "easy" mission from stakeholders at face value -- which is what OP is about.

ajsnigrutin 5y ago
To copy from my other comment: My exact case was some reporting for some project (15 people, 36 months, 1 xml per person per month), to throw into excell and draw one graph, for one PPT, a one time deal, for one project manager to show the numbers on the report. The end project, if I didn't stop the idea, would be a black box, where you would put any number of random xmls, and get exactly what the accountant wanted with one button... so an impossible task.

ivyirwin 5y ago

Yes, scope creep can significantly change the time requirements or even the entire, shall we say "scope". But I think it's just as important for us as developers to be aware of that on the initial request, in order to suss out the actual requirements. What does the process look like when we ask back, "are you going to need to have a total and rolling sum? should we think about making a gui so other people can use it too?" Engaging the requests early on not only helps our planning, it helps the "client" figure that out sooner than later. I think I've been successful in my career because I've been able to listen to a client's request and then help them figure out what they are actually asking for instead of taking it at face value. That can be easier said than done on an internal team, but it changes the quality of the product and dynamic of the team significantly.

ajsnigrutin 5y ago
My exact case was some reporting for some project (15 people, 36 months, 1 xml per person per month), to throw into excell and draw one graph, for one PPT, a one time deal, for one project manager to show the numbers on the report. The end project, if I didn't stop the idea, would be a black box, where you would put any number of random xmls, and get exactly what the accountant wanted with one button... so an impossible task.
growse 5y ago
Indeed. Much of the time, "scope creep" is actually just discovering what the requirements actually are. It's not that the requirements change, the requirement likely existed all along - it's just that no-body realised it. Iterating through feedback loops where you build something that meets the original ask, only to refine/change/add/remove things as everybody discovers that what they wanted is not in fact what they wanted is not an unreasable approach. > I think I've been successful in my career because I've been able to listen to a client's request and then help them figure out what they are actually asking for instead of taking it at face value. That can be easier said than done on an internal team, but it changes the quality of the product and dynamic of the team significantly. Sometimes you can explore the actual scope by skillfully working with the client before you build anything. Sometimes, however, you can only learn what the actual requirement is by building the wrong thing first.

da_chicken 5y ago

See, I read the article's problem description and think, "Okay, a proof of concept is going to take 2-4 hours. A shippable product is probably going to take 5 to 10 times that long." IMX, it's not even necessarily feature creep. It's failure to stop and adequately understand what constitutes a minimum viable product. Not viable to sell on the marketplace. Merely viable to deliver to another user. There's a huge mistake in software development to think that the hard or complicated part is making the algorithm or understanding how your program will interact with it's own data or external data or hardware. That's seldom the actual hard part. The hard part is making it useful to a human being using the system. If it's just for me, I can use a proof of concept that I wrote in perpetuity. I can deal with how janky it is or the obtuse error messages it spits out. If anybody else has to use it, though, there needs to be a mental model for interacting with the software that is intuitive and comprehensible to the user that doesn't require them to have a comprehensive understanding of the underlying code, clases, and interfaces. This is the actual hard part of software development, and the bad part is that it's typically the part that nobody likes to do. That's the lesson the professor is trying to teach here. It's not how to write a program. Nearly any fool can do that. The lesson is: how to author deliverable software.

derefr 5y ago
With scripting, often you don't have to deliver it to another user; you just have to get the data from them, run your script on it, and give them back the result. It only has to work on your machine, because that's the only place it'll ever be run, and only once.

jareklupinski 5y ago

> making it higway-legal this is the crux imo; an experienced engineer can hack together a compelling MVP of almost anything technical in a reasonable amount of time, but getting that same code in line with regulatory frameworks and the expectations of the end user is what separates a weekend script from a scalable business

mrslave 5y ago

As long as the client is accepting of time-T-for-feature-F, I quite like this mode of development. Whatever is built shows value at every step. As long as a suitable programming language is used to allow for the changing executing environment (in your example: a GUI).

redhale 5y ago

I often think about this XKCD from years ago: https://xkcd.com/1425/ https://xkcd.com/1425/ "When a user takes a photo, the app should check whether they're in a national park..." "Sure, easy GIS lookup. Gimme a few hours." "... and check whether the photo is of a bird." "I'll need a research team and five years."

Lord_Zero 5y ago

This is hilarious to me because this is exactly what I get from my clients and I would expect nothing less from a college professor. "Just build me a URL logger". And then after saying "sure, we can knock that out quick" they ask for pause ability, title fetching (which is not as trivial as the author makes it sound if you want to handle edge cases)https://stackoverflow.com/questions/64051968/retrieving-title-of-a-page-with-url-in-nodejs https://stackoverflow.com/questions/64051968/retrieving-titl..., rich logs, log management (deleting records), GUI for logs, cloud sync.