Re: Declarative constraints in practical terms

Frank Hamersley wrote:
> dawn wrote:
> [....]
>
> > I lean toward not duplicating constraints, coding and maintaining them
> > in multiple places and languages, but I understand that someone else
> > might choose the other strategy. Whatever choice, it doesn't look
> > obvious to me that declarative constraints are better as I gather it
> > appears to many others.
>
> Dawn - I hold you are exhibiting the classic "all eggs in one basket"
> mentality that afflicts the average [those below average are unlikely to
> know what constitutes an egg :-)] IT practitioner and which I frequently
> also characterise as the "fair weather sailor" mentat.

Now that you've got me classified...

>
> Firstly, please, please promise me you will never ever design or build
> an aircraft that I might ever be likely to ever fly in (or stand under).

No need to worry there

> Aircraft today (as in the past) have all critical systems in a double
> or triple redundant arrangement and I deeply suspect yours won't have
> any redundancy at all!

It sounds like you want not only multiple places where constraints are checked, but different people/teams coding different approaches to making these checks. OK, I do understand that we need to reduce or eliminate single points of failure based on a risk assessment. Measure twice, cut once is a good strategy. If we specify only once what our constraints are, we might get that wrong.

Now look at how we write software, with a typical scenario something like this. We put drop-down list of colors from a validation table on the front-end. We then have a middle tier verify that the selected color is valid (while wrapping it in an object perhaps). Then we have the dbms perform a third validation on it. Three languages used, three run-time environments, and sometimes three different specifications for the constraint. Then we deploy it and the user thinks "I don't know what the color is, but I'll guess blue."

Are we measuring with a micrometer and cutting with an axe? Care and redundant systems for quality sake are one thing. Redundancy because we don't have the tools to do it better might be unnecessarily expensive.

> The same thinking can be applied to "declarative constraints" in IT
> system building. IMO it is simple first order thinking to presume a
> single layer of constraints is going to be adequate to secure a system
> against decay. Building software is an engineering activity and should
> be approached in the same critical fashion - with some degree of
> over-engineering commensurate with the risk.

agreed

> Therefore the correct discussion is not about "better" in a singular
> sense such as you use it above, but using combinations of techniques to
> achieve the "best". Dismissing the declarative approach out of hand on
> a pretext is not ever going to reach that best outcome.

I don't dismiss it out of hand. I would think you could hear the struggle coming through.

> > This relates to the fact that the RM is not sufficient for writing
> > software (as mentioned in my current blog entry that I'll again boldly
> > advertise as being at http://www.tincat-group.com/mewsings ) and coding
> > constraints using the RM doesn't seem like it can get you all the way
> > there. So if you go that route, you end up duplicating your work, both
> > up front and for all maintenance.
>
> ibid.
>
> > Is there a way to get the best of both worlds on this one?
>
> Some will argue that there are better forms and places (than others) to
> make your investments. Regardless which is promoted over any other, I
> argue that diversity and hedging your bets is a very useful survival trait.

So you like to have redundant metadata (e.g. constraints). I suppose redundant data of all kinds mitigates some risks. But it introduces some too, right?

> So drawing from "both worlds" is ideal rather than an a negative
> antagonistic event - IMO.
>
> > This issue
> > is really bothering me, so thanks in advance for any help you can give
> > me to gain a better understanding and apologies for bringing it up
> > again.
>
> On a more philosophical note having read your past posts and conversed
> on several threads I have formed a view that you are ensconced in a
> comfort zone with MV

This is somewhat true related to the data model, but I'm a move-forward-from-here person and not a sit-in-a-comfort-zone type. For example, the issue of constraints is not related to MV, per se. Constraints might be coded in multiple places using MV databases too, even if they are not coded in SQL.

> and subsequently seek to justify that state of
> affairs

I think you are reading me wrong on that, Frank. I have much more of a "seek to understand" approach, since I think I have experienced something that could shed light on how to get better productivity in software development, but I'm not sure exactly what that something is. My intuition is that it is related to the RM and SQL coming on the scene with the complexity and lack of flexibility that might have added. So, I've been studying it to form opinions based on more than just my experiences and intuition.

> mostly by trying to comparatively write off the RM

I've come to some conclusions that the RM has led to some trouble-spots for software development, which is why I started blogging on that topic. I have not been dismissive, but very studious in my efforts, quite beyond what the average IT practitioner (a category in which you placed me ;-) would be likely to do if they simply wanted to write off the RM.

> rather than
> by simply promoting the virtues of MV.

I don't have a horse in that race and I don't necessarily think that MV as it stands today is the future of IT. But with VSAM, IMS, SQL-DBMS, and MV in my background, I can see some magic in MV that it would be good to bottle up for the industry to move further in developer productivity gains. And in addition to some good mathematics and concepts, it looks to me like there is something about the RM that may have poisoned the waters unnecessarily and should be remedied. My interest is in better, faster, less expensive, and more flexible software development.

> I know comparative treatment is
> a useful tool but in your hands it always seems to come down as black,
> rarely white and never shades between!

Hmmm. I get accused of being too gray, seeing all sides, so if I'm finally getting to some 0's and 1's out of it, that might be progress. If I didn't see any value at all in the RM, I wouldn't bother probing and asking questions about it.

> It seems to me no matter what evidence or logical deductions are
> presented that this state of affairs will not change. Consequently I
> find interesting that you bother to project any ambivalence at all on
> these subjects.

You are right that if my inclinations were as you have suggested, there would be no point. So, you don't have me pegged right yet, I suspect. I'm here to learn, not to proselytize, whereas with my blog I am trying to write what I have learned and lay out a case for others to consider in those areas in which I have an opinion. Here I render opinions, too, but it is so that I can find out what I'm not seeing clearly and make corrections. I am not nearly as fixed on any particular solution as the average RM proponent. I'm directed toward a goal related to software development. HTH.

Cheers! --dawn Received on Wed Feb 22 2006 - 14:00:55 CET