Time to slow down the Oslo hype

In “Oslo” now Azure.. the model IS executable.
and it IS understandable and it IS searchable and it IS deployable.

So if i had 500 cloud apps or whatever 500 on-premise apps. and they all had some slightly different configuration for high evailability etc… and i hired a new systems administrator… and we sat down and had a conversation about our architecture. Me being the business owner or some manager with little I.T. experience. do you think anyof them would have a clue about the shape of the architecture or be able to effectively navigate across and in and out of its boundaries aligning them with business goals? Do you think you would be able to also tell how much this is costing you vs. how much it’s bringing in?
No i dont think so. But if you look closely at the combination of new stuff coming out you can imagine that conversation happening in some future time over a deployable and executable set of models that map to business goals. Which will let that conversation with the business leader or manager and the I.T. be more powerful and fruitful and lead to immediate if not quick and agile changes or decisions in direction to be made. so Pul Lease stop being so negative and look with a visionary eye at things. This is the perspective Microsoft has to take because they are not create a software package for you to start getting things out of it day 1. They are creating a platform to enable you, them or someone else with vision to figure out the rest and build ontop of it.

To be honest I think this is all crap. Microsoft habit is to rename old stuff and rebrand it. Now they even took someone else’s name. Why “OSLO” ? RDBMS and XML-like technologies. Yawn…

@BuggyFunBunny

“there will be no need for convoluted OO code” — Oh yeah, I’ve never heard THAT one before! Personally, I’d love it if someone figured out a way I don’t need to deal with the complexity of software and I could just stamp out solutions, but after 30+ years of trying, no one’s figured it out yet. This, despite repeated claims of having finally discovered El Dorado.

At least in my experience, there is no such thing as “just a CRUD app.” As time and use progresses, complexity rises such that merely a schema/catalog is not sufficient to describe that complexity.

It’s funny you bring up solid state drives, because the way I see it, these will make RDBMS’ obsolete as one of the primary reasons for an RDBMS is to facilitate the quick storage and retrieval of data from a very slow medium (i.e. disk platters). If everything is essentially “in memory”, then this problem goes away. Now you merely need the consistency aspects of the RDBMS. It turns out that these are better accomplished with things like DbC rather than having some sort of silly relational model mapping (which was previously necessary due to storage speed/capacity constraints).

What may be interesting, if it happens, is if Oslo folk return to first principles, and realize that the DATA *is the model*. Until java came along, the industry was coming to realize that what Dr. Codd had wrought was a purely declarative business rule engine. The database vendors were just getting to the point where they could implement 3NF databases nearly as fast as file systems. With such databases, and enforced DRI, CRUD applications could be generated from the catalog.

Some are now doing just that. Solid state disk machines will make this trivial. There will be no need for convoluted OO code (or any other kind).

Some folks are beginning to realize (again), that a RDBMS based system is *just CRUD*. Puts fancy coders out of work, but who cares?

And, no, it won’t be users (business analysts, or such) who specify the schema (using Oslo or similar).

It may be that using SQL Server is just a red herring, and not a return to first principles. We’ll have to wait and see.

@Pinky
Are you allowing comments at your blog?

@Jeff Olson
“Wait a second… didn’t I already talk about that?”

If you rewrote this and dropped the attitude it might be easier to follow but I’ll try to respond anyway.

Some of your points I agree with but I’d be interested in hearing more about specifics of yourve experience writing business focussed DSLs. I’ve heard the same sorts of arguments against many things, from TDD to DDD and acceptance testing, so I’m going to stay open-minded on business focussed DSLs for the moment (even staying open-minded on Oslo).

Whether the business see it, yes in some cases I think they could. Doesn’t mean they write it, or test it, or maintain it but yes there are cases where I think them seeing it has value. Also once the DSL is in place I’d have no problem with a domain expert or BA using it, in fact that as with authoring acceptance tests thats a desierable solution.

On acceptance tests I agree, but remember acceptance tests are *normally* about capturing representative examples not covering every case. They usually don’t say that in a production system “when dealing with network X in situation Y we will use fees based on Z”.

Regardless I think that *configuring* complex models through a DSL could have value and is something I do plan to explore more. In particular whilst you sometimes go through a GUI in these config heavy situations you can end up using ETL/spreadsheets. In these latter cases a DSL would be a big improvement. Effort/maintenance wise, yeah I get that its worse.

I say we just go ahead with an open source project and give business users the best possible DSL/programming language we can and let them spend the next decade writing, testing and maintaining their creation.

Hell, it would probably only take a month and they’d be begging programmers to come kill their Frankenstein.

(I think brain surgery is pretty neat, but I don’t see much point in trying to make it easier for the nurse to do the operation…)

@Colin

You really need to ask yourself what you’re gonna get out of the DSL vs. doing whatever-it-is-you’d-do-with-a-DSL-in-code.

Consider the following:
– Will it be more concise than the way you’re doing it right now?
– Do you want it to be something you can show to the business?

Regarding question 1: If the answer is yes, then maybe you should consider reworking your approach to the problem in terms of implementation.

A DSL itself is a kind of framework of patterns to solve a specific issue. Maybe you need a similar approach for your code, itself? This is where tooling comes into play, though.. as the refactoring/maint story for Oslo-based DSLs is not-yet-at-all clear (and it may be quite nice, by v3 or so). C#, on the other hand, has pretty kickass tooling right now.

Regarding question 2: If the answer is yes, then maybe you need to consider rethinking your approach to testing and verifiability of what you say your code can/does do for the business.

You’re gonna need some real deal, no BS acceptance criteria from the domain experts, anyway, in order to make a valuable/meaningful DSL. You can leverage that work to instead hammer out a useful set of test criteria in order to make your code pass muster.

Then you can show your executable specs/acceptance criteria/etc to the domain expert. And if he wants to see the code that makes that stuff work? See question 1 (rethink your implementation to make it more intention-revealing when looking at the specs).

Also, this brings up the point of what value you get from showing a business DSL to the user when they aren’t the ones who use it. Sure they can suss out what it does.. but how do they know it really works? To satisfy that need, you’d have to: A) show them the framework that the DSL sits on top of.. which means you’d be showing them the underlying code that you wanted to hide, anyways or B) provide them with meaningful executable spec reports based on acceptance criteria they provided.

Wait a second… didn’t I already talk about that?

Really.. I’m not trying to hammer on anyone about it, but I feel like a business DSL is seriously a nuclear option when it comes to solving problems. Very powerful, but it comes at a high price (a customer’s willingness to own and be heavily integrated into all aspects of the design, implementation, maint, etc of the DSL). I think, maybe, in situations of where a user possesses very important and very esoteric knowledge and already possesses a reasonable degree of technical competence.. it might be something to consider. But be aware of the price and only use it as a last resort.

My greatest fear (hopefully unjustified), with Oslo, is that we’ll find ourselves in another XML/SOA-style nightmare scenario where every bit of technology friction within the business looks like a nail to be hammered by the DSL hammer.

Q: And who will be put under this spell by Microsoft’s marketing department?

A: Your IT Manager.

Q: And who will feel the pain?

A: You and the business.

Q: And why did we go down this road in the first place?

A: Because DSLs sound cool (YAGNI warning sign numero uno).

@Jeff,

Thanks for the comment.

“Technical DSLs, things that result in a net reduction in keystrokes for you as a developer are where the value in DSLs lies.”

Agreed, but the effort to reward ratio of an external DSL has to be favorable. I know it’s early, and I haven’t even seen the visual tooling for Oslo yet, but so far it looks to me like internal DSL’s in IronRuby or even (gasp) C# 3+ may provide more bang for the buck than external DSL’s with Oslo.

When someone actually puts forward the premise that creating tools for the business to use to implement business logic is a good idea, asking your the following questions:

– Who will design it?
– Who will implement it?
– Who will *maintain* it?
– Who will get the blame when rules validly defined rules in a business DSL cause havoc because of erroneous implementation?
– Who will get the blame when invalid rules are implemented in the business DSL, causing havoc?

By default, the answers to all of those questions are: “You, gentle developer.”

These are the kinds of questions that need to be answered (bringing up issues of collective design, ownership, oversight, test burden, code review at the framework and script level, etc, etc ad nauseum) and no amount of cool tooling will answer them for you. These are the real problems. Maybe Microsoft can give us some help with these problems, as well.

Designing fun tools to “throw over the wall” to the business so they can start doing “whatever” is a bad idea unless you’re prepared to deal with the above questions. And, in my modest experience, providing the “right” answers to those questions makes the whole premise of a business DSL seem less and less appealing. And we’re not even talking about reasonable expectations for business buy-in and commitment, here.

Bottom line: When you think of some idea sounds cool and fun to implement (like, say “Let’s give Portfolio Managers a tool so they can design strategies to algorithmically rebalance complex portfolios of multiple assets types), you need to hope and pray that the YAGNI alarm is going off in the back of your head.

Technical DSLs, things that result in a net reduction in keystrokes for you as a developer are where the value in DSLs lies.

Everything else is gonna be pain, 9 times out of 10. The business needs to be good at the business. If they wanted to be code monkeys, they would be.

DSLs are cool because it’s a fun, challenging field. But be very weary of what does and does not add value, with regard to them.

History shows this is indeed hard to happen. But I think there’s hope. There are success stories that contribute to the quest for such thing: http://www.infoq.com/presentations/fields-business-natural-languages-ruby (reading material here http://blog.jayfields.com/2006/07/bnl-01-introduction.html )

I agree too. Where’s the behavior? The most interesting aspect of software is NOT ITS DATA!!!! It’s the behavior. I’d like them to go in more of a DDD direction on this.

I LOL’d. PHBs eat that stuff up!