Talk Talk Customer Support Hell

A non-technical friend of mine asked me to help her with a problem with her Talk Talk broadband.

Due to various confusions at the Talk Talk end she had three of their modems available.

I went through all of the usual drills involved in setting up the modem. I reentered the username and password, I looked at the connection details and even ran the diagnostics utility (it reported an authentication problem).  The computer could access the modem, the modem could read the adsl status, but it would go no further.  There were no external connections being made.

The next step was to call the helpdesk.  The first try consisted of waiting against piped music and was then disconnected.

The second call got me through to a helpdesk operator who went through her script (ingnoring the fact that I had diagnostic information that should have been of use).  The script forces the use of IE under Windows 2000.  After 20 mins I was told I was being passed to 2nd line support.  The line then disconnected.

The third call got through to another individual who insisted on going through the entire script again. He did not notice that I was able to predict the next step. 20 mins later (including a pointless reboot of a slow laptop) I was eventually passed to second line support.  Answering exactly the same questions about the lights on the modem to this individual he determined that the modem was broken (it was clearly accessing the ADSL line, but he ignored that). I am now awaiting the arrival of the new modem so I can go and set it up again. 

Thoughts on Model View Presenter

Over the last year I have been working on a couple of applications (Winforms) that use the MVP pattern. There is a lot of articles published covering MVC and MVP to various degrees of detail.  They all seem to stop at the point where you have one controller, one view and a simple model.  I am trying to find out if anyone else has been trying to solve the same problem in the same way.  Very little of the literature actually describes the implementation of a Domain Model.

The model component consists of a Domain Model that is a tree of Composite Entities with attached Business Rules.  The Business Rules entities use XPathNavigator to negotiate the structure of the model.  We have defined an abstract type system for the attributes so that that can be treated polymorphically (all types may be set to a string) and may be invalid (for example an integer attribute may be set to “XXX”). Our business rules perform a selection of functions:  Providing defaults, performing calculations and providing validation.  When the rules are applied we obtain a set of rule messages that determines the result of the action.  Business functions are implemented as Facades over the model components so that the controller need only make a single call.  By using our navigator compenents we can refer to other parts of the model using an XPath expression – this makes our rules rugged with respect to changes in the structure of the model (for excample introduction of an intemediate node).

The Business Entity layer is distinct from the persistance layer – it only depends upon the database to provide the values of the primary keys which it holds as attributes.  The Pesistence Layer consists of a set of interfaces that may be implemented by a concrete implementation.  By keeping the persistance layer distinct from the model we protect ourselves from changes in the persistance mechanism.  Our reporting requirements have forced us to duplicate calculations between views and the rules.  Since we load the model from the views it is an easy task to ensure that these calculations are in step (we have a model checker that loads each business entity from the database and fires the rules – if the model and database views are in step then there will be no mesages recorded).

The closest that I have found to what we are doing is the CSLA.NET.  The big difference is that CSLA deals in terms of a collection of “broken rules” and unifies the persistance and data access objects.  It seems to provide no core functionality for implementing business functions other than validation and authorisation.

The Microsoft UIP seems to implement the Model View Controller pattern.  This is a very heavyweight solution and seems to have reduced the model component to little more than a data container.

The Microsoft Validation Application block seems to be heading in the same direction as the business rules approach that we have been taking.  Again this stops at validation (no defaults or calculations) and may only validate a single object.