SMany Options, SLittle Time

My own SMOSLT product is one of the zaniest technologies I have ever worked on. I've got 6 months full time on this. This is a 'scratch an itch' project, and is not yet targeted for mass consumption or even easy understanding. Continue reading at your own risk:

PROBLEM: "I Want To Create Great Software, But I am Human"

If you are a human, you must make the decisions about which combinations of technologies to employ for your latest project. This used to be a reasonably straightforward task. But now there are too many excellent options.

What Keeps Anyone From Evaluating Options?


Humans like to strip away information to the sound bites - that is how we share it easily with others. Even when we have built complex logic models in our own head - which most of us already do.

When technology was much simpler - "Hmm should I use Visual Basic or Delphi to build this app?" sound bites did the trick. But now the complexities and combinations of technologies can be quite complex. Complex as in, "lots of moving parts" - not complex as in "only a genius could figure this out."  We are still smart enough to figure it out, rather the challenge is in the number of moving parts and competing objectives.

Though we don't need someone to do our thinking for us, we still need a way to grind through all the combinations of moving parts and carry the tally to the end, so we can see where it lands.

Unlikely Combinations

Great things have happened in history, from odd combinations. Managers like to think in terms of course grain swaths, but sometimes it is odd combinations of technologies that do the trick so well. How to use that one package which we like so much, but not suffer from it's minor defect? This is where odd combinations can make the difference.

SMOSLT does not solve this problem - nor does it try. Instead it lets you grind through the math automagically, and then keeps track of every combination and so you can compare the scores after it's done.

Information Theory and Options

If you view this same mathematical problem under the filter of information theory, the number of possible combinations of technologies is analogous to the capacity of the carrier, but being able to distinguish between each of these combinations is analogous to being able to read clean messages from this same carrier. Two different issues.

Extrapolating from this analogy, there is no problem with the carrier. The information we need is always available - the capacity of the carrier is superb. But our ability to tease meaningful messages from that carrier - not so much. This is the gap that SMOSLT attempts to address.

SMOSLT is a research project.

Any project which deals with technologies in anything other than sound bites isn't going to go mass market, at least not in 2015. 

So a project which is designed to schedule and score software combinations of technologies en masse against our favorite custom project is not going to catch the world on fire.

But it is a very interesting technical challenge.

Much has already been accomplished

Several pieces are in place, even if there are a couple crusty pieces still left.

The schedule stacker seems to run perfectly, and you can take an team inventory, create a Gannt chart schedule, apply resources, and come up with an hourly score for any combination of tasks and resources. It literally stacks your resources up against every task, until they are all complete.

This same schedule imports from and exports to ProjectLibre (think MSProject, the free and lesser version). So you're never stuck with a non-visual output, you can see it in real Gannt visuals.

The options runner itself is distinct from the project and actually can work with any domain, not just software technologies. It uses OptaPlanner in the background, and grinds through any combination of options until it either exhausts them all, or if there are too many, it figures out how to run the most likely options and score them first, until it runs out time.

Options are run as scores, arbitrarily set by each operator. The good news is you get to score every technology option against each type of situation it may encounter in a schedule. The bad news - you probably guessed it - you have to score each type of situation. This is where the next efforts must go, this process must be made much more generic, democratic, and persistent, instead of super custom and hard coded as it is now.

Schedules are created for you from a team inventory. This is nifty keeno but also both incomplete and wildly inaccurate. It is more of a proof of concept that it could happen, if adequate effort was provided. This is the second of two main pieces that must be addressed as additional work progresses. Note - nothing prevents the user from creating their own base schedule manually, just that the chances of anyone actually doing that for a meaningfully sized project is remote.

Scoring statistics are compiled into spreadsheets, and then re-prioritized at will. Eventually this must go visual and persisted in a database, but data wise, it's already working.

Why Chase Rainbows?

Since it is clarified that there is no obvious commercial value in something so abstract, Why put out the effort?

  1. We are in the initial years of growing a services shop in Austin, a town that doesn't even know us yet. Getting out in front of groups of people, especially people who are interested in knowing how their favorite technologies are being scored against other technologies.
  2. Running and scoring complex combinations of options seems to have every chance of being a future thrust in computing. In a world full of Michelle Bachmanns and Jon Stewarts and oversimplified fundamentalist messages from every spectrum, the ability to work with complexity without going weird seems oddly attractive. We'd like to be a part of that market. Surely the market of ideas has swung as far as it will go in the opposite direction.