Philosophy

Most of the new, shiny software libraries, designs, and development methodologies are either junk or old ideas. And your project may end up a disaster you don't understand this.

Wow! That's provocative. Give us a moment. Hear us out.

Let's start by looking at a most obvious example, JavaScript. There is nothing new in JavaScript that wasn't in Lisp in the early 1980s. Unfortunately, there is a whole lot missing from JavaScript that's been in Lisp all along. Each release of JavaScript adds a little more of the power that was available decades ago. And the JavaScript community gets excited thinking it's created something new and beautiful and powerful.

Of course the folks who work so hard to advance JavaScript are making progress and things are getting better.

But it is also true that there is nothing new and JavaScript still contains many flaws. Indeed, we would all be better off if we just admitted JavaScript is a flawed subset of Lisp and the real solution is to expand JavaScript to include the full functionality of Lisp. Lisp with an Algol syntax.

This opinion about JavaScript is neither unique nor terribly controversial. Well-respected engineers like Douglas Crockford have been saying such things for years.

So, we conclude, JavaScript--by some measures the most widely used programming language today--is an incomplete reapplication of an old idea.

Let's talk about junk.

There are 125ish so-called "web frameworks" listed in Wikipedia. More than one-hundred-and-twenty-five ways to do mostly the same thing. Heck, there are more than 40 frameworks for Java alone! Ask yourself, why was the 2nd or 10th or 25th or 40th framework built? Obviously because all those before did not scratch an itch. But, are there really more than 100 disjoint itches?

Of course not.

Dissatisfaction with current solutions motivates each new solution. But the resulting new golden child doesn't solve the problem because of a failure identify the root cause of the dissatisfaction. Instead it essentially follows the same flawed design of the previous framework (we have written more about this particular problem).

Whatever the cause, clearly, there aren't 125ish ways to solve the same problem optimally. Indeed, many of the frameworks today are just a mess.

Understanding powerful and timeless ideas from the past and seeing through the emptiness of many--though, of course, not all--new ideas is critically important because failing to do so results in over-budget, or, worse, outright failed projects.

Project teams can't know how to get the most out a good library, design, and/or methodology unless they understand the science and engineering behind the technology. For example, experienced Lisp engineers approach JavaScript code fundamentally differently than most JavaScript programmers: they express code applicatively compared to imperatively. Owing to this difference, they usually express more function with fewer lines, thereby decreasing construction cost.

And it goes without saying that choosing a defective technology, will, by definition and at a minimum, result in increased program construction costs. In the worst case, choosing the wrong technology will result of project failure.

This, then, is the root of our philosophy:

Our Practice

Our principals are university-trained computer scientists, software engineers, and business executives that have decades of experience in software construction and program management.

Through the years, we've built systems of all sizes and types. From medical device software subject to the Federal Drug Administration software development life cycle standards to throw-away prototypes used to sketch new business ideas to investors.

Because projects are different sizes, with difference complexities, and different challenges, we do not force a single development process and system design on all projects. Instead, we work with our clients to select the development process that will ensure project success. Whether back-of-the-napkin informal or the formality required to build software that can be used in systems where failure could result in the loss of human life, we've done it before.

Our principals are former executives who have held C-level appointments in public companies.

This is another key difference in ALTOVISO. We know what it's like to make payroll. We know that this isn't a game or a hobby, but rather a business...a race to produce a product that solves a problem and ultimately helps a business produce a profit for its owners. We have a lot of fun building things. But there is no point to it all unless those things make economic sense to their owners.

We think this real world perspective makes us different and makes us better. We look forward to discussing your next project. Drop us an email at consult@altoviso.com