Ovid's First Law of Software Technology

Ovid on 2009-10-02T09:59:13

Technologies which aim to "improve" software but cannot be easily explained should be ignored.


So...

Adrian on 2009-10-02T10:15:48

... I'm still not totall clear about this roles nonsense :-) :-)

Re:So...

Ovid on 2009-10-02T10:27:18

I knew someone would bring that up :)

Roles are shared behavior with methods which can't conflict. It's tough to get any simpler than that.

Re:So...

Adrian on 2009-10-02T10:40:57

I'm partially kidding :-)

I don't really buy your law though. It was tough for me to "get" roles for various reasons. It was tough for me to get declarative Prolog-ish languages when I first encountered them. I know a bunch of people who took a hell of a time to understand OO. I know a bunch of folk who don't really "get" TDD, XP or Scrum.

Yes - there are nice sound bites for all of them. But they don't really "explain". The concepts are often deep - even if they have a simple container.

Re:So...

Ovid on 2009-10-02T11:08:57

The actual law should read (and I knew this when I posted my rather hyperbolic comment): "the more difficult it is to explain a technology which aims to "improve" software, the more likely it is that that this technology fails in its goals. Not quite as catchy, though :)

See Aspect-oriented programming for a great example. What's a "pointcut"? What's a "join point"? What's "advice"? Why is "advice" described as "additional behavior"? "Advice", to me, reads "optional behavior". And does AOP require special IDEs to properly handle it or not? It's issues like this which make it hard to grok and limits its adoption.

Roles appear to solve the problems which AOP attempts to solve by separating responsibility from behavior. Yes, they are hard to explain to people who have been trained in traditional OOP, but they are very, very easy to use.

Re:So...

Alias on 2009-10-02T13:39:09

Aspect-oriented programming is used to concisely implement cross-cutting concerns across a high number of classes and methods that would otherwise require immense quantities of hard-to-maintain code spread out over your whole application.

Examples of cross-cutting concerns which are very amenable to Aspect techniques include logging, debugging and performance monitoring.

Re:So...

Ovid on 2009-10-02T14:00:42

So what's a "pointcut"? What's a "join point"? Do you really need a custom IDE to use AOP or not? (I've heard both ways)

Re:So...

Ovid on 2009-10-02T11:11:35

I should add that posting known hyperbolic comments can often make for great discussions. I see you're getting a few retweets for disagreeing with me :)

Re:So...

dmaestro on 2009-10-02T15:02:31

Ovid's "Inheritance versus Roles" paper first gave me the confirmation that roles is the way to go, in Perl at least.

I like the simple description above, too.

For me, who learned from the OO gurus and now practice accordingly, I had to see roles as a safe form of (hush!) Multiple Inheritance (hush!) which solves the crippling problem of method name conflicts.