The Startup
Published in

The Startup

Software Is Not a Product

Drop the P titles.

Two bronze figurine men climbing a wall with binary code printed on it.
Photo by Brett Sayles from Pexels

When a purchase is completed that means goods are delivered. You should not seek the assistance of the seller to benefit from the product unless said good is defective. Tangible products may have expiration dates, best before dates or certain amount of life expectancy but the sole owner must be the buyer and the buyer should retain all rights to that specific instance of the product. Buyer must remain the sole party that has any say on the modifications of the product. In a world with freedom and laws, this is how things supposed to work. In reality though, it is sketchy, corrupt and disgusting.

Software is a component. It should work together with and not against or not in place of the hardware. The practice of manufacturing good-enough low quality hardware then coupling it with a logic board and calling it a day literally jeopardizes lives. More of that here :

Killing off Tradecrafts

Tim Cook once stated that the reason for outsourcing the manufacture was simply because United States lack the necessary skilled workers specialized in precision tooling. We are talking about the same company who is religiously against repair works and against ownership. Talk about hippie capitalism. These folks, like it or not dictate your life and who gets to make a living or not. They have articially made it impossible to carry out trades. Vocational schools are replaced by sketchy online software classes and youtubers with no skill whatsoever than just running a pyramid scheme of circle-jerking.

In case you are capable enough, Software-centric business doctrine is simple : Handle it where you can control it. Bay area people especially hate removable hardware, quality craftsmanship, closed circuit systems and static anything. Nebraska called it though ;

Software is a service. Software can not be a product itself. I repeat. Software. CAN NOT. BE. A. PRODUCT. Because software can not be a product, suppliers force the product to become obsolete without the software so they can work around the loopholes. It is unacceptable. The burden must not be on the buyer. In case you would like your product to be dependant on your software, consider this a burden for your entity. You are now obliged to make, whatever unnecessarily software ridden piece of article you have just sold, to operate just as fine and under circumstances designated with customer as it was advertised.

Battle of Effs

I am calling it.

Efficiency is inefficient in ensuring efficacy.

Thank to physics, bay area people can not bend rules as much as they would like to but they can sure as hell warp minds. They shamelessly market the idea that efficiency is something they project in their ideas. Whereas they are the absolute opposite of efficiency.

A small li-po battery can not outperform a big li-po battery. Bigger is bigger. A smaller sensor can not outperform a bigger sensor when it comes to photography. A small engine car can not outperform a bigger engine car.

Quality and performance can only be appreciated when their extremes are considered. You can not appreciate a leica camera if you are displaying it on an LCD. You require the proper display device and appreciation of the craft itself to distinguish it from a smartphone camera.

The M1 Chip, 1.0 turbocharged european vehicles, 3000mah battery iphones all have one thing in common. They try to make up for what they lack in hardware in the software department. This is called fraud and “getting tricked by a business”. For what its worth they are efficient in their act but they lack efficacy.

We are not there yet

We as humanity have not advanced far enough to depend on software solely. Let alone technology, our laws and regulations couldn’t keep up with all the lingo. We have collectively made data hoarders rich for decades and GDPR was only discussed couple years ago. Sadly all it achieved is legitimizing the data hoarders. We are far too primitive to rely on software but we rely anyways. It works horribly, even Bay Area folks and their pristine top notch systems fail. But it is “Good Enough”. Whole industry is under the effect of dunning kruger syndrome. We produce sub-par software and content with it. We even go ahead and call this abomination a product.

Whatever language you utilize to “craft” your “product” you are essentially using program text to create a mathematical object describing a state space and the transformations in this state space. When “crafting” the space you end up having to visualize the output. Most often than not when a software fails it fails because code that get executed does the exact thing it is designed to but the design is the culprit.

Product Designer? What?

You can design your “service” around software and it would be suitable. It would make the process of maintaining a team, relaying ideas and handling issues much easier. When you set sail with the “product” mindset you are bound to fail at whatever business you are conducting. Software is a component at best. The sooner you realize this and act upon it the better.

A chair is a product because you can understand it as a human being. You see the material, weight, flaws instantly. You can test it, repurpose it and above all you do not need the permission of salesman to alter its color, fear of manufacturer to invade your privacy and guaranteed diminished benefit over the years. If a chair were a software you would expect it to break one day, get put together the other day, find a stranger casually sitting on it, changing its color without asking you, perform better or lesser: UNEXPECTEDLY each day.

When software is treated as a product you inherently increase the anxiety within your team. It is not tangible. It can haphazardly stop operating one day and employees have to start each day, go to bed each night expecting this.

Chair stays relevant to its initial purpose. Software does not and can not. Stop putting software in the center and focus on delivering the service or components you have promised to your customers. Also stop stealing methodologies from Toyota and other manufacturing geniuses. You can not apply Kaizen to a project that is considered a product but its codes cryptically hidden away from even the trained eye let alone an RTE. I don’t have a dog in this fight so don’t consider me a neo-luddite. Consider me a customer who is not satisfied with good enough.




Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +756K followers.

Recommended from Medium

CS373 Spring 2022: Griffin Urban

Testing your Hadoop program with Maven on IntelliJ

How To Succeed In A Coding Bootcamp: Lesson 1

Ahh CRUD how is this working?

WordPress Developer

Mathematical Induction

The State of Web Browsers

Setup MongoDB on macOS

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


Passionate about, Creative Writing & Fiction, UI, Software Philosophy. Enthusiastic about Flutter, TLA+, Python, Decentralized systems. /

More from Medium

How I manage to work with full remote teams

Product roadmaps in Agile

Yes We Kanban — Getting the Most out of your SaaS Development Sprints

Product Backlog…