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..."
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 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.
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.
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.
"Just" is a four-letter word and its use is forbidden. Replace it with "in addition" and change how everyone thinks about the request.
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.
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.
Nowadays the main advantage of Linux is that it won't install the manufacturer's driver. Anyway, the arcane settings aren't required anymore.
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)
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 printers will beget a number of ad-hoc support sub-threads.
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.
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).
One of the things I say often, too often, is, "Making it look easy is very very hard."
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.
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.
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.
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.
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.
> 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.
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.
"It's just..." are the two words you never want to hear :)
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.
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.
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
"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."
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).