Image of an optical paradox, the "Penrose Triangle"

We Code the “Impossible”—Not the Impossible


As you can see on the Art+Logic website, our slogan is

Coding the “impossible.”®

This refers to the fact that in many cases, clients have come to Art+Logic with a problem that they were told was “impossible” to solve, and we delivered. This is an honest claim. It does not mean that we code what we believe to be impossible. This would be a dishonest claim.
At some custom software firms, it is their primary goal to make a sale—any sale—without concern for how the project will be accomplished. There are software salespeople who will promise the moon and stars in three months for a fixed cost of $10,000. In fairness to the developers at those firms, the salespeople do not involve them in the sales process, so they are usually the first to be surprised, long before the client is disappointed. Many software horror stories going back decades start in such ways.

At Art+Logic, it is not our goal to close a sale and then challenge our developers to make the project happen. Developers have active roles in our sales process. Developers talk to our prospective clients from the first or second meeting. This approach provides the following benefits:

  • Developers can answer technical questions that clients may have.
  • Developers can get a technical lay of the land.
  • Perhaps most importantly: Developers can spot technical reasons why Art+Logic is not a good fit for a proposed project.

Some proposals are so outrageous that even nontechnical people can spot them:

  • “We want to build the next in three months.”
  • “We want to build software to support our healthcare business, but we don’t want to have to worry about HIPAA compliance. Can we just ignore it?”

On the other hand, some proposals sound reasonable at first glance. Upon digging deeper, developers may uncover problematic implicit requirements. Some off-the-cuff ideas, when translated into technical concerns, reveal themselves as truly impossible:

  • We need an optimal solution to the Traveling Salesman Problem with a fast, deterministic algorithm.
  • We need to transmit 300TB of data across the internet in 20 seconds to a 100GB storage device.
  • We need to solve the Halting Problem.

Many salespeople have never heard of the Halting Problem, and their experience with the Traveling Salesman Problem is more hands-on rather than algorithmic. Therefore, without the support of developers, it can be easy to overlook serious—even fatal—flaws in a proposal. At Art+Logic, our developers get the opportunity to spot such flaws before any money has changed hands, saving a lot of headaches all around.
So, how do we handle impossible proposals? Roughly speaking, they fall into three categories:

So long and good luck!

Some people are very attached to their ideas and don’t like being told that they can’t get everything they want. At Art+Logic, we politely decline their proposal and wish them the best.

Have you looked at it this way?

Other people are quite willing to recognize difficulties with their proposal as long as a decent explanation is given. In these cases, we identify the sticking points and try to reformulate their proposal into something possible. We do this completely transparently; it’s not a bait-and-switch.

OK, let’s do the “impossible”!

Between the first two categories, there lies a range of proposals from adventurous clients who believe in taking calculated risks. They believe us when we tell them that something is impossible, but they don’t want to settle for something less than revolutionary. In these cases, while dutifully pointing out the risks, we work to transform the impossible requirements of their proposal into “impossible” requirements, i.e. things that are not strictly impossible but have never been done before.
Again, Art+Logic is able to have such conversations during the sales process because we involve developers from the start.
Image via The Penrose Triangle – Optical Illusions Cube Paradox

+ more

Accurate Timing

Accurate Timing

In many tasks we need to do something at given intervals of time. The most obvious ways may not give you the best results. Time? Meh. The most basic tasks that don't have what you might call CPU-scale time requirements can be handled with the usual language and...

read more