Re: Declarative constraints in practical terms
Date: Thu, 23 Feb 2006 03:42:13 GMT
Message-ID: <paaLf.14172$yK1.12889_at_news-server.bigpond.net.au>
dawn wrote:
> 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...
... with some hesitation that can not be conveyed with this medium. I claim relief due to the parlorous state of affairs within "IT".
>>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
It would be instructive to contemplate the very act - that industry has a crash and burn outcome ratio distinctly different to ours!
>> 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."
What, no test flights at all?
> 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.
In the case of IT we seem to use an axe regardless of how we measure. If the spec demands micrometer accuracy then cut with a tool that can deliver.
>>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.
I see your struggle as a quest to see what is next (such as you admit below) rather than examine what is already at hand. Personally I believe there is much more we could do with what we have today before we try to navel gaze the future.
>>>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?
True - but that is what we are paid to do - and to resolve prior to deployment. Like aircraft engineers, we can not expect to be present on every scheduled flight to fix up the oversights that we missed in the development and test phase. We should behave accordingly.
Furthermore that very risk creates a tension that can be leveraged to produce a better quality result - before giving it to the punters, not after.
>>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.
Fair enough - but I feel your baseline is wanting.
>>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,
We already have plenty of productivity - just very little of quality. I know you combine these attributes into the single term, but as the infoworld article showed, a manager can't afford and shouldn't need to differentiate good code and bad code to grade the "productivity".
> 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.
And so I have provided some counterpoints with little effect I suspect. IMO you have formed the basis for your views on "classic" by which I mean prevalent IT practice. This is not a good basis.
>>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.
IMO the RM is not the root cause, simply an agent exposing the charlatans. Of course it is always much easier to shoot the messenger than deal with the message.
> 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.
True - I did place you in the "above average" category - because you use your experience to mitigate risk inherent in the unstructured tools you promote. However this is not an option for a newbie and as wise(r) heads we should ensure this modus operandi is guarded against rather than sanctioned.
>>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.
By your own hand in a single paragraph, you first declare you don't and then you do have a horse in the race. Which is it to be?
>> 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.
IMO that is merely artifice in your style to encourage engagement.
> If I didn't see any value at all in the RM, I wouldn't bother probing
> and asking questions about it.
Your agenda is to discredit it, not to inform yourself. More artifice!
>>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.
So you hope - I am not swayed.
> 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.
Heh heh - that is perfectly aligned with how you characterise RM adherents - rigid and unduly structured, blind to progress whilst you have to flexibility to reach nirvana.
> I'm directed toward a goal related to software development. HTH.
I guess my interest is somewhat broader - encompassing not only the act of development, but the whole box and dice. Wholistic (sic) if you like.
Cheers, Frank. Received on Thu Feb 23 2006 - 04:42:13 CET