Do look a gift horse in the mouth, or "turn me into an application".

Image by kropekk_pl from Pixabay.

Deutsche Version der Publikation.

I've previously told the story about a wonderful IT startup that, nonetheless, brought nothing but problems to its owner.

Link: "Dissidents of the Silicon Valley. IT development approaches for startups."

In that article, we discussed whether it's possible to take the road less traveled when growing a startup into a business bypassing standard acceleration practice. We've also taken a close look at whether a startup requires an evaluation of IT development tools and methods, or they are always the same and independent of other factors.

In this article, we discuss an interesting experience that on one hand should be called a startup (it fits the startup category nicely by virtue of being innovative), while on the other hand the project barely "grazed" the market by accident. The founder didn't even think about making a business or publicly open tool out of this.

Thanks to this project we have encountered a wonderful phenomenon with a plethora of underlying IT development myths circulating on the market. The project's result became a sketch of the future where the entire IT industry is heading.

We've been approached by a professor of the veterinary faculty of Texas University, who asked us to develop a tool for his job. He wanted a machine to be able to determine a horse's age based on the photographs of its teeth. While it would have been absolutely necessary at the later stages, I have omitted analyzing the intricate details of the business model since it was initially required to develop only the technology itself.

We were so excited about creating the technology that even when the dedicated research budget came to an end, we voluntarily continued developing the project and brought it to a point where we were certain the task was feasible. While we were using ready-made functions from other projects whenever we could, we managed to create a custom AI in the form of a "smart solver" instead of an infamous "dumb" neural network.

As a result, the machine successfully handled identifying teeth on images and then proceeding to highlight predetermined elements of the image. Then, upon interrogating the client, we have received an array of a horse's age signs expressed in specific important indicators.

Everything fit quite nicely into a solution for the task at hand by utilizing the "smart solver", which meant we could proceed with creating a fully automated intelligent ability to determine an animal's age. This is precisely the way sophisticated artificial intelligence is created. We were effectively preparing to transfer the procedures of determining an animal's age, the very same procedures that are happening in a "living" specialist's brain.

As if often happens in our field of work, while our questions were formulated based on machine requirements of solving a task, they simultaneously helped the specialist to fully understand the entire process of his decision-making process. Focal psychoanalysis, if you will. The final result was a small little dedicated AI aimed to solve one specific task.

After making sure the client's initial desire could be brought to life, we cheerfully asked him about the project's next steps. We've already envisioned an astonishing product capable of captivating the imagination of investors who would do a better job at commercializing the technology starting with Big Data for animalistic research to a horse-trading consultant or even a horse racing betting advisor. Which is a decent market in North America.

And to our astonishment, we have learned that our client, a well off American with considerable livestock, was creating a tool... for himself.

As he is both a renowned professional as well as a university lecturer, someone in his university threw in the idea that nowadays even students are writing essays on neural networks by feeding them countless images for tasks made out of thin air. So why wouldn't he use the same method to resolve his problems? You know, to stop running around his expansive ranch and trade fairs, and entrust this work to cowboys armed with an application. Just imagine this beautiful picture. And most importantly, this picture is nearly completed. Yet the devil lies in the details, so let's take a look at accompanying myths.

The easy development myth.

Myth number one: IT is easy. Every progressive pupil, even more so a student, can quickly and easily create an application.

The idea that every small pizza place or cobbler should have an easy time creating an application for their clients has long been realized. Then why shouldn't every individual create himself the necessary tools for not only processing data but also... thinking?

However, the simplicity and readiness of IT solutions used by pupils or advanced users are achieved through the work of countless dedicated developers of tools and platforms, configured to the likes of a specific user by an "operator", leaning on the shoulders of these "IT giants".

It's great living in a world where people consider IT to be so tamed and friendly that they are happily entrusting it with their daily tasks, isn't it?

So how to understand which ideas could be accomplished on one's own? Or should you request the help of a nerdy pupil or that neighbor who's finished a 3-month long IT developer course? And which ideas lack a readily available tool and you need an engineer?

The keyword here is "typical". Platforms, constructors for creating applications and websites, and other similar tools are created for "typical" and frequently demanded tasks. Innovation is not even being considered here.

If your idea demands innovation, then almost everything your solution will be based upon will be created from the ground up.

The key difference is whether this is a typical business or an innovative startup.

About the problems of a typical business that outgrew the potential of readily available platform-tools without "noticing" this, I'll tell you some other time.

Right now let's continue with the "solver" for a dentist who didn't like running after his four-legged patients.

The advice our clients received from his university colleague was based on general assumptions of neural network capabilities. Usually, the network's operator has to live up to the developer's requirements when formulating a task it should resolve. And to assess whether a neural network is viable to resolve your specific problem, you should hire a specialist.

Looking at a mare's jaw photo provided by the client it has dawned on us that there are many details on the image aside from the ones important to resolving the aging conundrum: the animal itself, the background, the cowboy's fingers, desperately trying to make the horse say "cheese".

We realized that the neural network will either never move past the learning stage or this solution will take up not only our client's entire lifespan but also his successors'. Just imagine that instead of creating himself an assistant the client would have adopted an ever-dimwitted student who would require constant attention without any hopes for success. As if a chain-bound slave on a Roman galley, our veterinary would be sitting there, leaving all his responsibilities unattended, feeding images to the neural network, and telling it the age of every horse on every image.

We concluded that we'd need to at least help the neural network and direct its attention to the most important parts of an image. And after highlighting these elements it would have a promising chance of success within a foreseeable leaning time frame. Then our client would have a chance to reap the rewards of its work during his life span. But like I said earlier, we've found an even more interesting solution without using a neural network. The final result, of course, was based around a logical combination of a multitude of factors instead of a simple calculation of elements or the lack of thereof.

The application of innovative tools often requires preliminary research on whether said tools can be used at all.

The same goes for using out-of-the-box platforms (Wordpress, etc.) used to create software for a typical business project. The platform operator (the nerdy pupil or the neighbor-student) will begin the development and drive it to its limits, piling on plugins and bandaids, organically discovering those limits. Assessing your plans and whether they match the tool is outside of his scope.

So what could be completed using out-of-the-box solutions and what must be developed from scratch?

This, of course, is not a question just about technological expertise. Since out-of-the-box solutions cannot be adjusted to meet the consumers' demands and requirements, are prone to security issues, and are harder to plan an IPO with, many businesses avoid using them. But this is a topic for a different article.

The eternal application myth.

Another myth that creates the illusion of IT accessibility is that it's generally possible to create an IT product that would not require changes and has no associated usage expenses. A Perpetuum mobile, if you will. Doesn't even require oil changes.

IT is the fastest-changing industry. I won't even come close to listing all the reasons, but I will indicate some significant ones.

Every project exists in a technological infrastructure and as such must be modernized along with the modernization of said infrastructure.

Ready-made solutions used to develop a product often feature free services for businesses at their starting stage. Platforms, libraries, operational systems, and even out-of-the-box solutions are in themselves updating, requiring updates from all their users.

But even if you are not growing as a business and continue using this "relatively free" segment of the IT market, changes could catch up with you in the form of your provider's... "death".

Yes, every network "denizen" has a life cycle, the drama of an "abandoned project", or having its life support switched off after being devoured by a "giant".

In the case of our dentist, the problem could have become a lack of support of the chosen neural network by its developers, should he have gone that route.

I'm also skeptical of "eternal" technology and the "eternal" consumer demand for it. Changes to a live product are inevitable.

It could be that people will always be determining a horse's age by looking at its teeth, just like they did it long before. But let our fantasies run wild, and the future of medicine and diagnostics is full of nanochips and analyzers, smart toothbrushes, and wearables.

Then again, if a business with this application existed it would probably either adopt the technology to new uses or expand veterinary assistance.

Another quite plausible source of constant changes to software would be market regulators.

The market is entering a massive stage and the hero of our article with his ideas about IT accessibility for everybody is the perfect confirmation of this transition.

At this stage, the regulation and general public participation in shaping the ethics of the IT industry are a guarantee.

Yet another slightly less obvious motivator and source of change for all existing players in the IT market is a slow but steady decay of the old and the emergence of new trends.

At the time of its concession as an idea, our image processing product highlighted the appearance of a new trend. No wonder this idea was born in a university environment, where the future is so close you can almost touch it. IT has already served the topic of receiving, finding, transmitting, and structuring information. And now the nature of the product is changing right before our eyes.

Software products keep integrating into the user's cognitive and mental processes more and more, assisting and even fully automating them.