Comment by ajsnigrutin | Hacker News Reader

Comment by ajsnigrutin | Hacker News Reader

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).

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..."

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

I believe you’re referring to ESR’s essay http://www.catb.org/~esr/writings/cups-horror.html

That's the one!

“All user input is error.” - Elon Musk

When you make one part simpler, you move that complexity to another part.

I have not experience this fool-proof plug and play on windows or mac os. I just last year replaced a printer because it wasn't working with my wife's Macbook Pro, it worked one day and just dropped of the face of the earth the next (was able to print over USB from my linux laptop still). The printers were I work constantly have issues working with the windows PCs.

Moral of the story, printers are a necessary evil and what is wrong with the world.

EDIT: For future readers if you don't see the responses. The home printer was a Brother.

Also, this is not a statement that Linux is better. Think of it as the experience of using printers in general is pretty shitty regardless what your computer is running.

Printers were the bane of my existence when I was responsible for maintaining a small business's computer stuff. They all ran shitty Windows PCs with varying versions. One day one of the accountant's computers started crashing on boot, and after a hell of a long time, I found that some Epson printer driver had set a registry key that didn't revert upon uninstallation, and that crippled the machine.

I wonder if in your case, your old printer relied on either 32-bit kernel extensions (I don't know if that's a thing), or if it relied on one of the deprecated Kernel Programming Interfaces such as IOUSBFamily. I also wonder if a printer driver falls into a category of deprecated extensions that are silently reported by the OS, because most do pop up an alert of some kind.

https://developer.apple.com/support/kernel-extensions/

Was it a HP printer?

HP last year managed to accidentally revoke their macOS code signing certificate. I'm not sure how much software was affected, but as far as I know all HP software for Mac, including printer drivers, was broken (CRLs are updated automatically even if you have automatic software update disabled)

Nah, it was a Brother printer, I replace it with a cheap HP printer. The Wireless on that one stopped working, I've just given up and my wife uses the cable to print. Well luckily the HP is still playing nice over a USB cable.

If you still have the Brother printer, try disabling IPv6 on the Brother printer.

I remember this issue from a while back. Some update happened, and then wireless printing stopped working on some iOS devices. It happened to a colleague's macbook, and disabling IPv6 on the Brother printer fixed it for us. I can't remember where I found the initial advice, but here's someone else mentioning it: https://discussions.apple.com/thread/250584298

Any sufficiently large discussion of software complexity will spawn a large sub-thread about printers.

Any sufficiently large discussion of printers will beget a number of ad-hoc support sub-threads.

Printers used to rum much better on Windows back in the day when the manufacturers developed drivers with the intention to make them run well. I've never seen any one doing the just "plug, install driver, run", except for shared printers maintained by a contractor. But they used to run better than Linux.

Nowadays the main advantage of Linux is that it won't install the manufacturer's driver. Anyway, the arcane settings aren't required anymore.

The single most problem-reducing maneuver I've tried with home network printers is getting the printer off plain DHCP and make it consistent (set a static IP manually [outside your DHCP range] or by DHCP reservation).

After sorting this out in the router, then add the printer to the various desktops/laptops/tablets/phones.

Maybe I'm imagining the improvement, but I don't think so (and it can't hurt).

> The difference is that hiding those arcane input parameters takes work, and a lot of it.

One of the things I say often, too often, is, "Making it look easy is very very hard."

Early on as a dev, I made the mistake of doing exactly what I was asked. Basically I learned that user control was better than automation in some cases. I had to write a script to select batches of files from a larger number for translation/annotation with certain proportions of various characteristics. There was some amount of self balancing involved, and I wrote a cli program that did this well. I took a process that previously took days (often communication lag) dozens of times per year and brought it down to milliseconds.

The problem was that the humans involved didn't really want what they asked for. They wanted control. They wanted to select a batch with certain characteristics, then another batch with others. They wanted to pass a list of files that must be included, a list that must not. They wanted audit functionality, they wanted multi-step selection, to mark files for auditing, translation, and different annotations types, to select a batch from one annotations type for another.

At the end of the day, this ever evolving script worked out very well and took away the need for a programmer doing complex sql and filesystem queries. There was still a human involved, but that was because the human wanted to be involved. The process taught me about users wanting something other than what they ask for, scope creep, and also showed me the value that could be generated via a fairly simple script created in collaboration with the user.

Printers are plug and play on Windows? That's not my experience. I have constant problems at work. Settings resetting, stupid printer driver GUIs nagging about ink, prints coming out wrong and making me go into the detailed settings to fix it. Rare are the days where I can just print the stuff I need with no fuss. I'm fortunate enough to be able to solve problems on my own. Coworkers are forced to call support and waste hours and hours of their time because of these printers. The scanning situation is even worse.

I do a little tech support for my neighbors after hours. Printer issues (on Windows) are an extremely common complaint. All kinds of random things can and do fail.

I've been working with printers for 35 years and they still find ways to destroy my soul.

This week I discovered my Canon printer has some way to detect "plain [white] paper" and absolutely refuses to print on the high quality "cream" coloured paper instead. No matter what tricks I tried in swapping the paper, as soon as I put the better paper in the tray it would freak out.

Some printers use an infrared sensor to detect paper width. Those tend to freak out on weird paper colors, though I've never had the issue with cream before. Only darkish colors like purple and the like.

Printers are plug-and-play on Windows, macOS, and especially iOS (AirPrint) if 1. you're always printing PDFs at 100% scale, single-sided, black-and-white, and 2. you're printing against a printer where that particular configuration is its wheelhouse (i.e. a laser printer.)

Ha! Printers!!

I worked on an OS called CTOS back in the day. It was difficult to set up printing, because there was no feedback. It worked or it didn't, and there were queues to configure and services to install and network connections...

Somebody in a trade rag wrote "Its easy to print on an Apple, difficult on an IBM PC and impossible on CTOS". That smarted.

So a guy named Tom Ball (later the Java Swing guy) wrote a Prolog script that somehow could just tell you if printing was working or not, and what to do about it. Never figured out how he did that. BUt our trouble tickets went from something like 60% printer-related, to noise. Just like that.

I remember after all these years, and try to make software foolproof. For the customer service folk, because they matter.

> The difference is that hiding those arcane input parameters takes work,

I'm reminded of the first time I tried to get wifi going from a CLI-only NetBSD install. wpa_supplicant something something.. I eventually got it working but it was sort of a nightmare compared to how you connect wifi in an OS UI.

> 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?"

"Just" is a four-letter word and its use is forbidden. Replace it with "in addition" and change how everyone thinks about the request.

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.

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.

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.

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.

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.

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.

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.

> "...just add..."

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

Simply just add now.. each word increases the difficulty level by one increment.

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-titl..., rich logs, log management (deleting records), GUI for logs, cloud sync.

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.

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.

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.

> 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

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).

I often think about this XKCD from years ago: 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."

Reply on news.ycombinator.com