There’s a cute adage about World War 4. “I don’t know what weapons World War 3 will be fought with, but World War 4 will be fought with sticks and stones”
Here’s my cute adage, only about [any software development project]:
I don’t know what you will be working on 10 years from now, but I do know what you won’t be working on – the project you are doing now. Because the project you are doing now will probably be abandoned or jettisoned, just like almost every software project.
If you are a brilliant developer, what determines your success in the world?
Is it your raw talent?
Or is it the choices you make about which technologies to use?
Any reasonable observer with experience in software development might quickly conclude that SMOSLT is over-reach.
It is simply not reasonable to expect that a user would accept the inadequacies of the tooling, and invest the time necessary for such a dubious result. After all, scheduling is already a shot in the dark. Adding this layer on top of it only makes the process more prone to error. So goes this line of thinking. And it’s not wrong, either.
Then there is the issue of time. Resources spent on front end analytics only subtract from the resources available to develop the software itself.
Much better to simply make a commitment to a known path, than waste away the hours and days and even weeks figuring out all the could’a would’a should’a factors that one might consider.
[this only applies when SMOSLT is mature enough to actually pass the 2 Day Challenge]
Here’s what we hope you’ll conclude:
SMOSLT is built for speed, not accuracy.
It is much better to sustain just a little bit of analysis than to avoid glaze over by not doing any analysis at all. Your vendors will probably appreciate it as well. From PAAS vendors to hardware and software vendors, everyone wants a reasonable shot at your business. This allows you to give them just that.
Then, once you select a set of approaches, you also know a little bit more of what is expected from that approach. You might have scored a technology or a vendor one way, and discover later that your scoring was off. But now you know what you expected, it wasn’t just a glaze-over decision. So your attention is properly focused on the objectives at hand.
Goldilocks was hungry. She tasted the porridge from the first bowl.
“This porridge is too hot!” she exclaimed.
So, she tasted the porridge from the second bowl.
“This porridge is too cold,” she said
So, she tasted the last bowl of porridge.
“Ahhh, this porridge is just right,” she said happily…
If I am earnest and hard working as a software developer, is that not good enough?
Information Theory generally postulates that the value of information can roughly be described as surprise.
In that context, SMOSLT provides value only as it offers the user information that is surprising, or not visible, without it.
You’d like to do more.
You’d like for your software development projects to be
But you’re also grounded in reality. You know that you can’t even know all the possibilities, much less follow through on them.
This is where SMOSLT can help you visualize what you would not otherwise be able to consider as options.
SMOSLT is free software (free as in free beer) and is supported by a single person.
Development of this software might stop at any minute, should it’s author become otherwise occupied, such as involvement in contracts.
For the moment, it is in active development.
You probably won’t understand SMOSLT as an app until you first read why SMOSLT is run within an IDE. It just won’t make sense.
This is the main SMOSLT project, where all the important action happens.
These actions include
Orchestrated primarily from app module, but also manually from within IDE, given no UI
Java classes consumed by other modules. Kept separate just for purposes of clarity.
Assumptions are required for SMOSLT to do anything meaningful.
This is YOUR area, because you are responsible for all assumptions, even though you might start out with 100% default or partially customized assumptions provided by others. This is like what the cop tells you: “Ignorance is no excuse” the results you get will be no more satisfactory or correct than the assumptions you used to initiate a specific run.
Areas that assumptions cover:
Stacker, or ScheduleStacker, creates a real schedule from a ProjectLibre specification template. Stacker knows nothing about SMOSLT or all the fancy stuff that SMOSLT does, it just stacks up tasks and allocates resources like it is told to do.
Stacker is designed to be as simple and fast as possible, because it might get called to re-stack a schedule thousands of different times in a single session.
Stacker could theoretically be used by anyone, without any SMOSLT usage. It is not anticipated that anyone would wish to do this, but it is welcomed if desired.
SMOSLT does it’s active work in SMOSLT code, and does not interact directly with ProjectLibre APIs. A ProjectLibre schedule is entirely converted into SMOSLT code, and then when done entirely converted back into ProjectLibre file. Ne’r does the twain meet. This conversion happens in this module.
Only the brave should ever crack open this module. ProjectLibre APIs can be quite challenging to the uninitiated, and a giant black hole of time. As of Oct 2014, it is being rewritten ground up anyway.
Someday SMOSLT may be runnable from a real GUI, like you would expect from any decent application.
That day has not yet come. So until then, it is run from a command line. This command line , or CLI code is maintained here.
SMOSLT.options
See separate document
SMOSLT.analytics
The mathematics of creating software has turned upside down.
There is a sweet spot, some mix of consuming work by others, and just simply re-creating it. Finding this sweet spot is getting to be a ridiculous proposition. Not because the options are too few, but because they are too great.
Pick the right set of building blocks, and you can develop anything super quickly:
This has become a ridiculously time consuming process. Just knowing what options to pick from can consume an entire career. Picking the right combination of hundreds, even thousands of options? Mathematically it’s absurd to even think about it.
Obviously there are many approaches to solving this problem:
SMOSLT is an attempt to add one more option to this list. It is a variation on the glaze over approach. It doesn’t solve the problem, it just delays the moment of glaze over, letting you consider options a few more minutes longer before glazing over, and hopefully without halting your software development career in the process.
SMOSLT won’t feed your dog automatically, solve world hunger, or get your favorite politician elected. It may help you take a few more deep breaths before charging off and building software with ill considered technology combinations that end up sucking the life force out of your body. If it accomplishes even a part of that modest goal, it’s a big win.