Tag Archives : Operations

Morning Coffee 57

  • Scott Hanselman’s post on Mindful Coding reminded me of the practice of rubberducking. The basic idea is that when you’re stuck on a problem, you explain it out loud to an inanimate object – aka the rubber duck. (though when I originally heard about this practice, it was a teddy bear.) Maybe instgead of Coding Mindfully, we should be Coding Out Loud?
  • Quick side note to the previous bullet: I have often worked thru a problem by explaining it to my wife who, like Scott’s wife, nods in all the right places, but cares not about such things. But calling your wife a rubber duck is bad for your health, so I’d rather call it Coding Out Loud.
  • I’m a couple weeks behind on this, but Microsoft along with BEA, BMC, Cisco, Dell, EMC, HP, IBM, Intel, and Sun submitted the Service Modeling Language to the W3C. For those not plauing along at home, SML is the new name for the System Definition Model and is a core deliverable of the Dynamic System Initiative. Good to see it’s gotten such broad support for this.
  • Jezz Santos and Edward Baker wrote a series of posts entitled “Factories 201“. The entire series is good, but I particularly liked Jezz’ post How Long Will It Take?¬†His rough estimate is that it takes at least five products built with a software factory before you recoup your investment in building the factory itself. Sounds like a fair assumption.

Morning Doughnuts 5

  • Joel Dehlin, a former Microsoft employee and the CIO of the LDS church is conducting a series of tech talks. The next one is being planned for the bay area. If you are interested you can respond to his post here. The dates would be between April 22 – 26 with a tentative agenda as follows:
      • Keynote
      • Infrastructure breakout
      • Development breakout
      • Interaction Design breakout
      • Community breakout
      • Building to building video breakout
  • Everything needs a 12 step program now. CNN has a 12 step program to cure your email addiction here. I started thinking about this after Harry’s post saying he had hit zero email bounce prior to going on his secret mission.
  • I read an interesting blog on XNA and how it fits into Microsoft’s strategy in gaming. I am not sure I agree with all of the points, but I found the arguments to be compelling.
  • My BYU Cougars are now up to 21 in the AP Poll. I can’t think of a year when both the football and basketball teams have both had such successful seasons.
  • Between today and tomorrow I will be finalizing my vision document for how I think monitoring should work in the Service-Oriented Infrastructure project I am on. As I was outlining my vision it really hit me how much there is to do.

Is SML Another Unwanted Modeling Language?

Piyush Pant wonders if SML solves a problem that nobody has? He also points out SysML¬†project, which recently got folded into the OMG. Well, that explains why we called it “Service” instead of “System” modeling language.

Now that I work in IT, I can definitely say that SML will eventually solve a problem that I have. Most people agree that operations today is way to dependent on manual processes to scale effectively. Now SML doesn’t solve that issue directly – as Piyush pointed out SML is a meta-modeling specification. However, SML is the foundation for the next generation of operational modeling tools like what we see in Visual Studio Team System for Architects. As I wrote several years ago, VSTS:A solves a very common problem – developers lack of understanding about the deployment environment. Piyush, haven’t you ever had a long weekend going back to the drawing board because the solution you had built was undeployable and you didn’t discover that fact until the operations team attempted to deploy it? If you haven’t, I envy you.

On the surface, I agree with Piyush when he says that “history of software is littered with unsuccessful attempts to impose monolithic modeling constructs”. However, the fact that it keeps happening indicates the problem hasn’t been solved. Wanting to solve a problem and being able to solve a problem are two different things. Furthermore, the history of software is also littered with very successful attempts to raise the level of abstraction by the introduction of new programming languages: C, C++, VB and Ruby are all examples of this. Given that Code is Model, what we have is a history of software littered with some successful and some unsuccessful modeling constructs. I would argue that the successful modeling constructs have taken a bottom up approach – build a language a small abstraction step above something that actually runs and compile down. These unsuccessful modeling constructs (*cough* UML *cough*) take a top down approach – build a language way above anything that actually runs and hope a miracle happens to keep it in sync with the stuff you actually build.

The question is whether SML will be top-down (i.e. a failure) or bottoms-up (i.e. a success). So far, it’s to early to tell, but I have high hopes.