I taught a class a few years ago at Columbia Business School called “What Makes a Hit a Hit—and a Flop a Flop.” As a grizzled 25-year veteran of tech product reviews, I intended to bestow my hard-won wisdom on this group of young, idealistic entrepreneurs-to-be.

I shared, for example, the story of the Storm, which was the first touch-screen BlackBerry phone. BlackBerry rushed it out the door, riddled with embarrassing bugs, hoping to catch the 2008 holiday season. That was about the last most people heard of it.

“Never treat your customers as beta testers,” I concluded. “Get your software right the first time. It's hard to recover from a bad first impression.”

I nodded my head, satisfied that I'd made my point—when I noticed that three or four hands had shot into the air. They belonged to students who had spent their summers working at software companies.

“But software is never really finished,” argued one young woman. “You ship something that's reasonably close; you can always push out a software fix later.”

I was aghast. “You would ship your software knowing that there are bugs in it?”

By this point, my students were all but rolling their eyes at me. “Professor Pogue, every software product ships with known bugs. You try to fix the big ones in time for 1.0, but then you have to put it out there to get the revenue flowing. You can always polish it up later.” Really, I thought?

On the train ride home, I realized they were right about one thing: buggy software isn't just an occasional fluke; it's now the rule. Tech companies routinely treat their paying customers as unpaid beta testers.

It's not just about bugs, either. These days software designers let public feedback guide the fundamental design of the software: what features it offers, how it works.

Let me be clear: I'm a huge, raving fan of crowdsourcing. The wisdom of the masses beats the wisdom of a few programmers every time. That's why beta-testing programs are such a win-win: tech fans get to try out some new product early (and shape its development), and the company gets thousands of guinea pigs scouring for flaws—for free.

That's why Microsoft offers each new version of Windows to the public months before it is finished. This year, for the first time in many years, Apple did the same with its OS X Yosemite operating system. And Google is famous for labeling its services “beta” for a very, very long time. (Google Docs was in beta testing for three years; Gmail, five years.)

But those unfinished products are free and labeled “beta.” Where things get ugly is when companies sell products—without telling their audience that the software isn't fully baked.

Part of our disgruntlement at being served flawed software probably stems from our conception of software itself—as something that is, in fact, finishable. Software used to come in boxes, bearing version numbers. We understood each as a milestone—a program frozen in stone.

But nowadays software is a living, constantly evolving entity. Consider phone apps: nobody seems to mind that new versions pour out constantly, sometimes many times a year. Or Web sites: they're software, too, and they're perpetually changing.

Maybe that's why Adobe no longer produces boxed, numbered versions of Photoshop; instead the only way to get Photoshop is to subscribe to its steady evolution all year long.

Maybe it's time to stop thinking about traditional programs any differently. Maybe we should get rid of frozen, numbered editions, much as Adobe has done.

That wouldn't eliminate the frustration of bugginess, but at least we would comprehend software's true nature: a product that is never finished.

The most egregious tech bugs: ScientificAmerican.com/nov2014/pogue.