The Pick Effect

Way back in the day, in the late 60s and early 70s, developers Dick Pick and Don Nelson creating system that was known by many names over the years, but most commonly just called "Pick", after it's primary creator.

It was an operating system, a language, a query language and a database, all at once.

Initially running on minicomputers, it was eventually adapted to microcomputers and even mainframes.

The thing that, I think, was interesting about it was it's end-to-end approach: It was not merely a language, it was a smoothly integrated whole, a full environment for developers to build systems. The core language was a variant of BASIC, and was easy to learn and be productive with quickly. You didn't need another operating system, you didn't need to choose database - that was all in the box, along with authorization and authentication and other features - you could focus entirely on building your business applications. It's "MultiValued" database was quite innovative at the time.

Eventually Pick was overtaken by other systems in functionality, and versions ran on other operating systems, and today it has all but faded away entirely, having gone through many owners.

All-in-One

It invites comparison, however, to the kind of enthusiastic following that other "all in one" tools have had, over time.

SmallTalk, for instance, was in some ways similar, although for a very different purpose. SmallTalk, which is still very much alive, if somewhat niche, is it's own IDE, language and runtime, all in one. In it's early days it was even the operating system.

The famous Lisp Machine was another example - the language ran directly on the underlying hardware, and provided a fully functional environment that was easy and quick to learn, and highly productive.

Fewer Choices

Strangely, one of the factors that seems to contribute to the popularity of such comprehensive solutions is that they offer fewer choices than other options.

If you put together your own stack for application development, you have a lot of choices to make. First, operating system - it's even fairly likely that the OS you develop with won't be the one you deploy on, multiplying the possible combinations. Then you need to pick a language, a deploy mechanism, a data store (or several), a means of configuration, a means of deployment.

Batteries Included

The other critical bit of a system that reduces the number of choices the user has to make is that it has to have all the pieces - that is, if some critical segment of functionality is missing, the system will likely not get widely adopted.

You have to have an end-to-end soup-to-nuts system overall, or you can't expect any serious adoption - missing pieces, such as a data store, a deploy method, or the ability to support multiple users, mean the whole system is severely limited in value.

Fewer Choices Today

But surely all of these "all-in-one" systems are ancient history, right? Today, people want lots of choices, don't they?

I don't believe evidence supports this: Look at a system such as the iPhone, an iconic success in the industry, and one of the most limited platforms in recent years. Other systems follow suite - we consider it a benefit when a system comes pre-loaded with the basics, not a flaw.

There is the well-known pitfall of analysis paralysis, of course. This implies, however, that we are taking too much time to select among choices - what if the problem is that there are simply too many choices to decide among in any reasonable time?

The Paradox of choice is an exploration of how too many options actually reduces adoption overall. This is even more the case when the choices are very expensive to reverse - the cost of changing our minds being very high increases the stress of choice considerably. Of course, if those choices are at all unclear , incomplete, or overlapping, the problem gets much worse.

The Value of Opinions

The other thing that is lost when everything is "a-la-carte" is the value of opinions. In the case of high-end restaurants, for example, there may be one or a small number of pre-set menus, representing the expert view of the creators of the food as to the way they should be combined and sequenced.

In software it is the same: By giving many choices to our clients, we are, in effect, depriving them of our valuable expertise and saying "we dunno - you figure out how to put it all together, we just sell the parts". If the rest of the world worked this way, there would be a Radio Shack on every corner, and pre-assembled TVs wouldn't exist, you'd just roll your own.

If we emphasize the value of expertise, however, then the recommended combination or combinations embody the best knowledge of the provider - you get a development platform that is batteries included, no assembly required.

I have recently been told by many choices that the consultants favorite answer ("it depends") is not a good answer - instead, they want the combo meal, not a buffet - they want to know what combination is most recommended, as they do not in many cases have the time and tolerance for risk to go try it themselves and see if the blend they come up with actually works.