But it works on my PC!

The random thoughts of Richard Fennell on technology and software development

PDC Keynote Day 1 thoughts

So the PDC2009 day 1 keynote is over and what was the story? Well it is more of a vision thing, but then again this is a PDC not a TechEd so what do you expect. For me the two major themes were

  • Dallas – a centralised data service that allows unified access to both public and private via subscriptions. Thus allowing core data being used for any purpose the user requires within the EULA of the data in question. It will be interesting what will be published in this manner, is there a market for a centralised data clearing house? only time will tell.
  • AppFabric – Basically taking the operating model for the Azure services and allow a company to have a similar model in their own IT system. Thus allowing code to be written that can work on the corporate system or Azure cloud without alteration. This I see as being big.,

So what was not mentioned, well it was mobile. The only comment was a ‘come to Mix in the spring for stuff about the next mobile offering. Whatever is shown there is going to have to very good to address the momentum of the iPhone. I think a good bet is that leveraging the Azure fabric might be important for the mobile offering

Access Services in SharePoint 2010 or: How I Learned to Stop Worrying and Love Access 2010

So what I have I been doing of late? The blog has been a bit quiet. Well I have been having a good look at Access Services in SharePoint 2010. This has been an interesting experience, as I am not historically what you might call an avid Access developer.

Like most .NET developers I had looked as Access as more of a file format than an application, something from the past. Something that I might use for a small data store, maybe in a web application hosted on a cheaper ISP that does not provide ‘a real’ SQL DB, or where an XML data files don’t seem right, often because I just can’t be bothered to work out the XPATH. When using Access as a data format it seems easier to get at my data using basic hand crafted SQL commands or maybe at most via a OLEDB Data Adaptor/DataSet. All very old old school. Thinking about Access in this way just seems an easy way out, playing it safe with the knowledge I have. I don’t for a second propose that this a good idea, you should not be looking at using any technology just because it is there and you already know it. There are obvious downsides, using Access in this manner meant that from the ADO.NET developer side I could not:

But equally, by treating Access as just a data format I was not able to make use of it as the Rapid Development tool it is. I was too hung up in the unpleasant idea of an MDB sitting of a server being poor at locking and saturating the network with unwanted traffic. I was not even considering Access as a front end to a MS-SQL solution, and it is not as if that is new technology, it has been around for ages. I was just sitting happily with my prejudices.

I don’t think this position is that rare for .NET developers these days. Access seems just looked down upon as something old in the Office pack that is best ignored, no good would come of using it in a business environment.

So enters Office 2010 and SharePoint 2010 Access Services, for me this changes the game. For those who don’t know this technology, you can create an Access database locally on your PC then publish it to SharePoint. Tables become SharePoint lists, macros become workflows and forms well become forms. Access becomes a RAD tool to create data driven SharePoint sites.

So how has this new technology been working for me? Well I can’t say I have grown to love the Access client, but I think that is mostly down to that fact that I am still not thinking right for it. Access is all about data binding, you don’t have to think about what form fields need to be copied to which DB columns, the wizards make a really good attempt to design forms for you based on the relationship of the tables in your DB and this just all seem unnatural to me. I think this is because I am usually working with design patterns to reduces the linkage between forms and data to a minimum e.g. the MVC pattern, and so consider this good practice; automated data binding seems seems wrong. So in Access I keep wanting to build things from first principles, but this is just not sensible. Better to let the tool get you close and then you add the polish, put away any thoughts of implementing design patterns as you would in a language such as C# or VB.NET.

I think this is the key to the degree of irritation I feel with the product, if you have got used to architecting from the ground up, especially in a Test Driven Development style, you have to turn everything on it head. It feels like you are cheating, not doing the job properly.

But wait! look at the benefits. A while ago I was involved in a project to provide a resource management data driven web site that was hosted within SharePoint. It contained the usual things, data entry forms, links to SQL and reports. It took a couple of weeks to build. I think I could write the same system in Access with SharePoint 2010 in an afternoon, and would be happy to have a client’s business analyst sit next to me while I did it, in a pair programming style, to design the forms, report layouts and columns as I went along. For the smaller scale data driven site Access Services is a great tool, but obviously it is not perfect. I do keep hitting points where I think ‘if I were in C# I could just do that’ but then I remember ‘yes but it would take would have taken me three days to get here not an hour’. Most project don’t need that last 10-20% you can only reach on .NET custom code, the client with be far happier with 80% done quickly and flexibly rather than 95% done a lot later. Also we have to factor in my relative lack of experience with Access as a RAD tool, reducing the productivity that could potentially be achieved by a more experienced Access developer.

Actually the bulk of the time I have spent has been on looking at how you can extend Access Service to reach that last 20% of functionality, and it not that hard. The key to remember is that the Access Services are just built on standard SharePoint objects. Ok there is a new service running to render the pages, but underneath there are just SharePoint lists and workflow, and where these exist there are events that you can programmatically handle. I have found that by trapping events such as ItemAdd() for the Access created SharePoint lists there is no real limit to what you can achieve via the SharePoint Object Model. And this development process is made even easier by the new Visual Studio 2010 templates for SharePoint features. If nothing else the fact that all the templates create a WSP for deployment as standard makes for far more robust feature development.

There is one major difference between a standard SharePoint site and one created by Access, and it is that SharePoint Designer cannot open the Access site. I thought this would be an issue when I first heard about the limitation, but it turn out not to be. Anything you might have wanted to do in SharePoint Designer you can do quicker and easier in Access for this type of data driven site. Ok the range of things you can do is more limited, but again you get that 80% you need with much less pain.

So how has my experience with Access 2010 been? Exasperating, frustrating but undeniably productive. I am not sure it is the right product for an ISV style company who want to roll out single solution to many client sites (but it could be used for this if needed via the SharePoint site template gallery); but for a smaller data driven site (with or without custom extensions) written within an IT department it is a very strong contender. Taking Access in many ways back to it roots.

So if you need small data driven sites I would suggest you put aside your prejudices and have a look at the beta program for Office/SharePoint 2010, I think you will be surprised.

Your support can keep our industry's history alive

We had a company outing at the weekend to Bletchley Park for their Annual Enigma Reunion event. A great chance to see the place where Enigma was cracked and some of the equipment they used to do it, such as the working  rebuild of a Turing Bombe

Turing Bombe rebuild

Whilst down there we also took the chance to have a good look around the National Museum of Computing, which shares the site; you know are are getting old when a third of a museum is devoted to equipment you have worked on!

Black Marble at the Mueseum of Computing by Colosus

I would urge anyone interested in the history of our industry to take the time to drop by Bletchley Park to have a look at both the museums on the site. And if you can, donate to aid their upkeep as neither Bletchley or the Computing Museum get any governmental support. Think of them live steam preservation societies, full of keen volunteers, with loads of ideas and partially working equipment that just need a bit of money to save a history the UK led the world in.

Welcome to the past of software development

I was at an interesting meeting at my local BCS branch tonight ‘Opening The Black Box: An Introduction to Quality Driven Development’  by Tim Hunter. I had heard of TDD and DDD etal. but QDD was new to me.

What we got was a hour framed by the basic premise that ‘Waterfall is good - Agile is bad’ (or progressive methods as the speaker called anything that was not waterfall). As another attendee pointed out in the Q&A, this tone in the presentation tended to cloud the more balanced points, managing to get the backs up of a good few attendees by the speaker’s seeming lack of understanding of god agile practices. He seemed to see agile as developers messing around, no documentation, testing or general engineering discipline. He argued that without waterfall, and specifically quality gates, we could not write quality systems. This is not the Agile I know.

Agile, if adopted properly is very constraining from an engineering point of view. We have detailed specification by example, open reporting practices, regular re-estimation of remaining work, test driven development, pair programming, automated builds, regular potentially shippable products with quality gates to move products between states of publication so we don’t just release everything we build. The list goes on and on; OK no team is going to use it all, but the tools are there in the tool box. A team can set where on the agility spectrum they choose to sit.

I agree with the sessions premise that quality gates are important, but not that waterfall is the only way to enforce them. You can put the whole methodology choice aside and frame the discussion in how do we get staff who take pride in their work and are empowered produce quality products via their working environment. I would argue there is more hope for this in an agile framework where the whole team buys into the ethos of software craftsmanship, as opposed to any methodology where an onerous procedure is imposed, a system must be habitable as Alistair Cockburn puts it.

I felt the session was too pessimistic over the quality of people in our industry. The speaker wanting to make rules because he perceived people were of low quality and had to be forced to do a half way decent job. OK I am a bit pessimistic, not too bad a trait for a developer or tester, but we have to hope for more, to strive for more. This is something I think the agile community does do, they are trying to write better software and become better craftsman everyday. They care.

For me the key question is how can we bring more people along with us. Especially the people who have given up and just turn up to do their IT related job and avoid as much hassle as possible. They are the ones who don’t turn up to the BSC, community conference or any user groups or even read a book or blog on the subject. What can we do for them?

The setup story for TFS 2010

I have been looking at the various install and upgrade stories for the TFS 2010 Beta. I have to say they are very nice compared to the older TFS versions. You now have a SharePoint like model where you install the product then use a separate configuration tool to upgrade or setup the features required. There are plenty of places to verify your setting as you go along to greatly reducing the potential mistakes.

One side effect of this model is that it is vital to get all your prerequisites in place. The lack of these has been the cause of the only upgrade scenario I have tried that has failed. This was on a VPC I used for TFS 2008 demos. This VPC used a differencing VHD using the older 2004 format that had a 16Gb limit and this disk was virtual full. To upgrade to TFS 2010 I needed to upgrade SQL to 2008 and this in turn needed Visual Studio 2008 patched to SP1 which needed over 6Gb free space, which was never going to happen on that VHD. So my upgrade failed, but that said this is not a realistic scenario, who has servers with just 16Gb these days!

Everytime I have to use Typemock I need to ask does my code stinks?

Ok a bit sweeping but I think there is truth in this, if you have to resort to a mocking framework (such as Typemock the one I use) I think it is vital to ask ‘why am I using this tool?’ I think there are three possible answers:

  1. I have to mock some back box that is huge and messy that if I don’t mock it will mean any isolated testing is impossible e.g. SharePoint
  2. I have to mock a complex object, I could write it all by hand, but it is quicker to use an auto-mocking framework. Why do loads of typing when a tool can generate it for me? (the same argument as to why using Refactoring tools are good, they are faster than me typing and make less mistakes)
  3. My own code is badly designed and the only way to test it is to use a mocking framework to swap out functional units via ‘magic’ at runtime.

If the bit of code I am testing fails into either of the first two categories it is OK, but if it is in third I know must seriously consider some refactoring. Ok this is not always possible for technical or budgetary reasons, but I should at least consider it. Actually you could consider category 1 as a special case of category 3, a better testable design may be possible, but it is out of your control.

So given this I looked at the new Typemock feature with interest, the ability to fake out DateTime.Now. Something you have not been able to do in the past due to the DataTime classes deep location in the .NET framework. OK it is a really cool feature, but that is certainly not a good enough reason to use it. I have to ask if I need to mock this call out does my code stink?

Historically I would have defined an interface for a date services and used it to pass in a test or production implementation using dependency injection e.g.

public class MyApplication 
{
public MyApplication(IDateProvider dateProvider)
{
// so we use
DateTime date1 = dateProvider.GetCurrentDate();
// as opposed to
DateTime date2 = DateTime.Now
}
}

So in the new world with the new Typemock feature I have three options:

  1. Just call DateTime.Now in my code, because now I know I can use Typemock to intercept the call and return the value I want for test purposes
  2. Write my own date provider and use dependency injection to swap in different versions (or if I want to be really flexible use a IoC framework like Castle Windsor)
  3. Write my own date provider class with a static GetDate method, but not use dependency injection, just call the method directory wherever I would have called DateTime.Now and use Typemock to intercept calls to this static method in tests (the old way to get round the limitation that Typemock cannot mock classes from MSCORELIB

I think this bring me back full circle to my first question: does the fact I use the new feature of Typemock to mock out DateTime.Now mean my code stinks? Well after bit of thought I think it does. I would always favour putting in some design patterns to aid testing, so in this case some dependency injection would appear the best option. Like all services it would allow me to centralise all date functions in one place, so a good SOA pattern. With all my date service in one place I can make a sensible choice of how I want to mock it out, manual or via an auto mocking framework.

So in summary, in mocking, like in so many things in life, just because you can do it is no reason why you should do something in a polite society. If you can, it is better to address a code smell with good design as opposed to a clever tool.

A day at the Architect Insight Conference

I was at the Architect Insight Conference yesterday, so the big question is do I better know the role of the architect in the development process – I have to say no. Don’t get me wrong the event was interesting, I especially enjoyed the interactive group discussion sessions, one of which I chaired if that is the right term. As I have said about other conference I tend to find I get more from the discussions with other delegates than the more tradition presentation sessions.

For me the role of the architect is very fluid. There are many different ways to run a project and a company. Some define a role for the architect, usually those with more formal structures, for others the role is actually an emergent virtual role that the team as a whole perform, usually as part of an agile planning process. There is no single silver bullet solution for all project types, recognising this is probably the big insight of the conference.

Give this why does it seem that people aspire to being an architect? what do the think the role entails that makes it appeal so much?

A very noticeable comment in our interactive session was that recent computer science graduate did not seem to have done much programming as part of their courses. They all seemed to be focused on the business/analysis aspects of the industry. Is this driving people to the perceived glamour/rock star role of architect? More than one delegate went as far as to say they were now looking at A Level students to fill junior developer roles. Graduates were either not interest or lacked the skills companies would expect after completing a degree course. It was easier to train up suitable 18 year olds. In our industry a keen enquiring mind is more important than a degree, something that seems to beaten out of many people at university.

This harks back to my formative years, I was a thin-sandwich course student mixing 6 months at university followed by 6 months in industry (which I hasten to add I would not recommend, better a couple of years study and then a year out in industry). Many people I worked with were not student/graduate engineers but HND students, in my opinion an educational route sadly underused with this current government target of 50% of people going to university. HND’s aimed to turn out good technicians, people who knew the job of making and testing the product, but without the grounding in theoretical theory a graduate would have. Very much a craftsmanship point of view where staff are trained up within team, not arriving from university as the finished article.

So the key takeaway for the conference for me? Software development is a people/communication process. It is key to get everyone involved in the all stages of the process. Whatever else an architect is, they should not a person in an ivory tower lobbing out huge specification tomes to the minions below.