- deploy webapp to web
- set up Jenkins and Nexus to actually deploy releases
- set up dns to point to each of docker instances
- Code Server: bitbucket
- Continuous Delivery Server: Jenkins
- Binary Artifact Server: Nexus OSS
- Web facing code generator: SMOSLT.webgen (on Vaadin)
We are proud to use these internationally prominent local Austin, TX resources to host and manage our public servers
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
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?
If you’re a developer or software architect, you want to use SMOSLT to keep yourself from being pulled off track by the wrong technologies.
Your problem is different, if you are the provider of one of those technologies that developers or software architects chose from. You want what your shop provides to be represented accurately. When developers and architects know how your product or service works, they can consume it properly and be happy customers.
How To Use SMOSLT to Position Your Product or Service
- Provide a SideEffect class that might represent how your product/service would score in a typical shop
- Provide tips and docs on how your prospective customers would improve specific scores using your product/service
- Compare your own scores to other products in a category, and show how and why yours provides an advantage
- Provide setup and admin/ops costs for others to create their own contextually accurate scores for your product/service
- Speed up setup and lower admin/ops costs in order to ratchet up your scoring in certain areas
- Improve docs and market presence to improve
- RDD (ResumeDrivenDevelopment) scores, such as propelled GIT to prominence
- ManagerSpeak scores (where IBM and Oracle scored highest for decades)
- POLR scores (PathOfLeastResistance) where products such as maven and Apache web server gained their prominence
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:
- Even just a couple surprising options might save you 10x what you invested in the 2 Day Challenge
- You’ll find yourself much more well versed in some of the options than you were before you started
- 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.
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…
The Effect of Getting Options Right:
SMOSLT is initially distributed under the GNU version 3 license.
There are at least three ways to create a SideEffect class (java file) that can be used as an option:
- same wizard as above, only run on your local box
- Copy and paste an existing TemplateSideEffect.java file
Any are OK, but if you are willing to do number 1 above, your work product can be automagically shared with others
more here later
If I am earnest and hard working as a software developer, is that not good enough?