Category Archives: Summary

‘Sticks and Stones’ version of Software Development

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.

How To Keep Your Software Development Process Relevant Over Time

Continue reading

Is SMOSLT Over-reach? Or This Has To Be Done?

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.

Paralysis by Analysis?

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.

Take the 2 Day Challenge

[this only applies when SMOSLT is mature enough to actually pass the 2 Day Challenge]

  • Take a couple of days and use SMOSLT against a sample generated schedule that most closely approximates your own.
  • Don’t use hundreds of options, just stick with a few dozen.
  • Don’t try to get your scoring perfect, accept some approximate scores modestly tailored to fit your own realities
  • Don’t try to get the runs perfect, instead just see if you can find any surprising combinations

Here’s what we hope you’ll conclude:

  1. Even just a couple surprising options might save you 10x what you invested in the 2 Day Challenge
  2. You’ll find yourself much more well versed in some of the options than you were before you started
  3. You’ll find yourself thinking in new ways, looking at new metrics, and getting comfortable in ways that you didn’t expect.

This Has To Be Done?

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.


Don’t Sell Yourself Short

You’d like to do more.

You’d like for your software development projects to be

  • better designed
  • more maintainable
  • less dependent on obsolete practices and technologies

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 Development Status

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.

SMOSLT Project/Modules Summary

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

  • running the other modules
  • Taking the assumptions you give it, and coming up with a list of costs based on those assumptions.

SMOSTLT sequence of events within modules:


Orchestrated primarily from app module, but also manually from within IDE, given no UI

  • before firing, user has already
    • created a compliant PL file
    • created list of options and other assumptions in assume module
    • created SideEffect code that drives each option.
  • imports PL file
  • imports assumptions from assume module
  • sends each of these to the optaplanner options module
    • options
    • schedule binary
    • analytics
  • optaplanner options module then folows this sequence
    • toggles one option on or off at a time
    • sends that combination of options to stacker
      • which can be on separate threads or machines if required
      • which writes each score and binary to analytics module
      • which also then returns score back to options module
    • runs to some reasonable termination whatever that means
      • brute force if options list small enough
      • more elaborate search process if options list too big
  • user then reviews run in analytics module



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:

  • Unit costs for include.
  • Beliefs about if-then consequences – if I have a java task with no testing, then I will get 30% more unanticipated work fixing bugs. That’s a belief. No one can know what really happens until it does.
  • Story templates. If every task is a story, per agile approaches, then the sum total of all tasks is a narrative arc that makes up a story template. No story template is truly representative of what really happens, but to anticipate costs you have to start somewhere.
  • Actual ProjectLibre files. Ease of use demands that you start with a ProjectLibre template, compliant to SMOSLT specifications.


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.



See separate document



Impossible to Know What is Possible

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:

  • Platforms
  • Tools
  • Languages
  • Practices
  • Sequences

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:

  • The glaze over approach – study options until you glaze over. Then pick what you studied.
  • The social media approach – ask your friends, follow social media.
  • The FoxNews approach – just know what is right. If you disagree, you are wrong. There, done.
  • The career halt approach – just stop being productive until you’ve studied every option
  • The management by following approach – pick the latest offering by big, credible vendors like Oracle, IBM

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.

  • The SMOSLT approach – present combinations of options in terms of palatable math, metrics.

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.