Scripps has become very puzzling.  It is difficult to discern the governing priciples of software development ( DevelopmentPrinciples )

THe situation is best understood in its historical context.

In the beginning, Scripps had two web initiatives.  The first was owned by the Newspaper Division.  They needed to get their content online and fast.	But also cheaply.	Newspapers operate on very tight budgets, and as the content is advertiser supported, they weren't making a lot of money.  THis has not stopped them from trying though, and their approach of building simple, inexpensive systems has served them pretty well.

At little later, it was decided that the category stations needed a web presence as well.  Specifically HGTV.  They viewed their site merely as an extension of reinforcement of their brand.  HGTV was successful and money was no object.  However, they ran into various problems with ISP's, vendors, carriers, etc, and decided that the whole effort needed to be brought in house and controlled.

After a couple of years, the newspaper group was centrally managed by a staff of 5, but the category group had at least twice this, and as the internet became more critical to business, it became clear that the newspapers would have to start thinking about their sites along similar terms as the category division.

With the new focus came bigger projects and bigger bills.  And so this is the crux of the conundrum.  On the one hand, I'm excited becasue now we can focus on doing a good job technically, but on the other hand, the bottom line trumps all.

How do we balance cost, strategy, technology and ROI?  Consider the SHNS (ShnsContentFlow ).  We isolated the performance issues, the technology issues, the architectural issues, and even bits of strategy that need to be addressed, but did we end up doing anything about it?  No.  I applied the best band-aids I could to keep them going, because we are too married to the sweetheart hosting deal they have in DC.  But I ask you, just because it's cheap doesn't mean its the way to go.  Doesn't the site have value?  Should we be willing to invest in its value?  Should we expand its value?  And doesn't the current set up leave the brand at risk?  Isn't the lesson from HGTV that it's all about the brand?

So there you have it.  To pieces of the puzzle that don't quite fit together.  So how to we fix it?  Split them back up?  Not smart.  Clearly there is overlap.
Just use separate account reps?  I don't think that will ever work.  Clearly, the coordination of the two agendas will end up favoring one of the two halves, leaving the other feeling cheated, if not suspicious.

One thing is certain, Bob is happy when teh NT group are helping him, and it has nothing to do with NT.  I don't work close enought with Ron any more to know what makes him happy, but I hear it isn't the current situation.  The current investment in FF leaves the newspaper div with too much skin in the game to back out, and it does work for those that could afford to implement it.  Th ecurrent FF is too expensive to roll out and possibly even to keep up with, especially with vignette dropping tcl in favor of J2EE.

Let me make these observations - Vignette is dropping TCL for java as a marketing move because that is what the market wants.  The market may not be very rational, but it is what it is.  For that reason, customers will always get orphaned and forced into unneeded upgrades that are driven by shareholders and release cycles.  In my mind it is just another reason to leverage open source technologies - the upgrades are for what is needed.  Tomcat doesn't change because they need to trigger another buying season.  They fix bugs and add features in generally the most prudent fashion - on the basis of need.

FF is too expensive because they never bothered to build the tools they would need to manage and roll out sites, and the schema is overly complex.  This was a result of planing for the unknown at every turn.  If only they knew more about what to expect.  Also of trying to put EVERYTHING in the db.

Lastly, they still do not ''get'' XML.	The internal use of NITF is worthless.  I still contend, binary formats should be translated into xml representations of the their actual structure, XSL should be used to transform that into a format compatible with the db, and the those documents should be ingested.  Support becomes simple, and flexibilty is preserved.  WHen it comes to trouble shooting, the first XML doc will tell you if you are dealing with the original format properly, or if there is some deviation.  When it comes time to ingest to the db, that code is very simple and less bug prone, and the xml doc clearly shows what will end up in the db and where.  In between you have xslt which is simply concerned with the translation.  issues of parsing and generation become consistant and generic, now only the exceptional stuff has to be worried about.  Plu sstatements like 'We support NITF' are worthless.  I helped write our spec.  We had to bastardize it to accommodate our needs, so our NITF is not the NIFT from other sources, and what will we do when the industry upgrades its definitions of NITF?  Our whole feed chain end up at the mercy of an NAA commitee.  BUt I digres...


I ''grew up'' with the newspapers, so I know a little more about what they want and need than the category side ( does the broadcast division even exist anymore ;-) ).  I hear phrases like accountability, responsibility,etc.  I think these are all just code words for a lack of trust.  And nothings instills less trust than phrases like 'trust me' and "you wouldn't understand".