OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] XML As Fall Guy

On Wed, Nov 27, 2013 at 8:20 AM, davep <davep@dpawson.co.uk> wrote:
On 26/11/13 17:09, Michael Kay wrote:

On 26 Nov 2013, at 16:07, cbullard@hiwaay.net wrote:

The politics will obscure yes, still there are some clues:

1.  MarkLogic is being blamed with the statement that having XML is
in the database is apples in the orange bin.

What I've sometimes seen on projects like this is that a decision is
made to use some technology, and then it isn't followed through. They
buy the software, and they use it, but they aren't committed to it,
or they try and hedge their bets. Someone discovers, say, (no idea if
this is true) that there's a feature in the product that allows them
to use SQL, and that's what they know, so they do everything in SQL,
and no-one tells them that if they're going to do everything in SQL
then MarkLogic isn't really designed for that. This happens very
easily when the technology decisions are made by people with no
contact with the actual developers, who may even hate the guts of the
people who made the technology decisions and be determined to prove
them wrong or to get the decisions reversed. That can be because of
commercial factors (subcontractors competing for a bigger slice of
the pie) or simply personal cussedness: developers don't like being
told they can't use their favourite technology.

I've seen TDD / pair programming treated like this. The management
believe its the latest thing and introduce it. The staff pick it up
and make the right noises... without belief. Token lip service
is the best they'll ever see, no matter what management do.

TDD is a process it cannot solve people problems (neither can any particular database). That is moreso when the people that mandate or are charged with effecting it's use don't understand why it works (or doesn't) and it's limitations.

TDD is effectively an approximation algorithm. It uses incrementally developed tests to search the solution space for an optimal solution.
Like any other approximation algorithm it is vulnerable to getting stuck in local optima so you don't want to use it for problems that are or should be amenable to an "analytic" solutions. This was illustrated when Ron Jefferies blogged about trying and failing to solve Sudoku with TDD whereas Peter Norvig solved the same problem because he knew and applied an analytic solution.

The languages in this community are predisposed to the functional paradigm. Beck himself blogged about not finding TDD a good fit for FP when he tried to apply it to Haskell.


"Management" see it's potential to homogenise software development, I doubt they understand it's limitations. They don't  recognise that it grew out of a set of problems that may be peculiar to imperative objective programming and it's not necessarily a universal solution to other types of programming (especially if they are trying to homogenise software development).

TDD or any other technique is no more the answer than Oracle or any other database (albeit for different reasons). I'd be amazed if it could be proven to be more effective than any other technique that entailed up-front automated testing.

What did Mr Brooks say - No Silver Bullet. At the root of all these are people problems that the industry by design self-perpetuates.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS