Adventures in home working

Just recently I have been reading about luck and whether there is such a thing a lucky person.  It’s a big subject, but two ideas stuck with me:

1. People interact with so many people and things in so many different way these days that statistically “miracles” happen.  If you define miracles as events that have less than a 1 in a million chance of occurring then I read somewhere that most people will hear of one about once a month.  That means that people are going to come across someone being very lucky/unlucky , (perhaps 1 in 10,000 chance events),  pretty much every day just based on chance.
2. The second idea is much more interesting.  It seems that people who describe themselves as lucky seem to know more people than those that describe themselves as unlucky.  Not surprisingly the more people you know the better the chance that one of those people will be able to help you out in some way, or will know someone who knows someone ….This networking theory although obvious once it’s explained is pretty powerful.

Users don’t know what they want!. 

I have developed quite a few systems, and worked as an architect and systems integrator on many more and it’s always been pretty clear to me that in general users don’t know what they want.  Even if the user takes the trouble to write a specification, in the end it won’t meet their requirements for at least one of the following reasons:

1. The most likely is that they are not the customer, they just happen to be nominated as the customer’s representative.  If you are lucky it’s because they are respected by the customer community for being in touch with their needs, unfortunately that’s rarely the case.  I once had a customer who described his requirement for an aerodynamics analysis platform as, “I need a mega-floppy Unix box”. At first I thought he was joking but that really was the limit of his capacity to explain his requirement.  The guy could do computational fluid dynamics but he had no concept of his needs.
2. Even if the customer rep really understand the requirement they often don’t have the skills to communicate that requirement
3. If they can define the requirement they don’t have the skills required to manage the inevitable tradeoffs that need to be made to get the product to meet quality, time and cost targets.
4. If they can do all of the above they will probably fail because they will take away from the development team the essential feeling that they are responsible for project success.  The Project manager will probably love having a customer like this because, its takes a whole load of responsibility off the development team and places it on the customer.  Unfortunately in the end a failed project is a failed project, regardless of whether you can blame some poor customer representative or not.

Don’t get me wrong though I am not arguing against customer involvement, for two reasons:

1. Sometimes you get a really great customer, who you should really hire as quickly as possible!  Then employ them as a solution manager, product manager, solution architect or whatever term you like to use for the person on the development team responsible for defining the spec and making sure the product meets it.
2. If you can reach real customers, and find a way to engage them in the project then they can add real value.  That’s why some great open source projects have been built, because the developers interact very closely with their user community, who often also happen to be their testers and sometimes their developers.

So what’s my perfect customer engagement model?

1. Ensure that the development team takes responsibility for project success.  This means that if the customer rep says something that might compromise project success the development team don’t just role over and say yes they fight for what they believe.  I call this partnership.  I don’t go in for this “customer is king” idea where the relationship is long term, needs to be built on trust and is judged by long term success criteria, (I work in IT Out Sourcing).
2. Make sure that these three roles are filled in the project team.  There are loads more roles but these are the ones that are most often forgotten.
   1. Someone who owns the whole solution, the person who makes sure that there are no gaps and that the solution meets the needs of the customer and the service provider.  This person needs to worry about Process, Organisation, Location, Data, Application, technology, Security and Service dimensions.  It’s not just a Technology role.
   2. Someone who owns the user experience, the person who makes sure that when all of the bits of the solution get integrated together and delivered to the user it looks and feels like it was designed to be used, and that it fits into the users existing tools and processes
   3. Someone who owns the delivery of the service, (remember I am talking systems integration not software development), i.e. the same role as the user experience guy but from the perspective of the team or teams that are going to provision, manage, support and make money from the service
3. Make sure you write these three documents, again there are often a lot more, especially on big projects but these are the core three that tend to be neglected:
   1. A Conceptual Architecture.  The document that describes at a high level all of the key concepts that people need to agree to in each of the Process, Organisation, Location, Data, Application, technology, Security and Service dimensions.  This document provides the framework off which all other documentation hangs.  The Solution Owner writes this document, it’s the “contract” with the rest of the team.  If anyone in the team can not deliver his bit of the solution consistent with the Conceptual Architecture they need to pipe up and resolve the issue with the Solution Owner.  All the way through the project the Solution Owners job is to ensure Conceptual Integrity is maintained.
   2. A Functional Specification.  The document that describes, in terms that the user can relate to, what functional capabilities are being delivered to him, which ones aren’t being delivered and any constraints in terms of devices, operating systems, network connectivity scenarios etc.  This document is the bible for the engineers on the project; it defines what’s got to be delivered.  Whereas the Conceptual Architecture describes all the bits that are needed in order to deliver and how they relate to each other.  The User Experience Owner writes this document and agrees it with the customer.  It’s the “contract” between the User Experience Owner, the developers and the project manager and the user, it binds everyone together and as such is probably the most important document on the project.  The UE owner maintains this document as the project progresses and it’s used to manage change with the customer, to define the structure of the acceptance testing and as the basis for user documentation etc.
   3. A Service Definition.  The document that describes

                                                               i.      How users provision, access and interact with the service.  

                                                             ii.      The volumetrics, (number of users, amount of data, number of transactions)

                                                            iii.      The service levels, (response times, hours of operation, hours of support etc).

The Service owner writes this document and agrees it with the customer.  It’s the contract between the development team, the user and the service delivery organisation.

4. Note in all three cases above the documents are written by their respective owners.  Bits of the document are not carved up and delegated.  The owner has full editorial control and ensures the integrity of the whole.
5. Make sure the project manager is not too powerful.  I personally quite like the team model that Microsoft uses in concept, although I have never had the chance to use it.  On most of my projects I like Customer, Solution Architect, Account Manager and Project Manager to work as the team.  Each person on the team needs to feel ownership of success, but focused on their perspective.
6. Engage real customers, often real users through interactive mechanisms that allow iterative refinement of the solution in a real business context.  I am not a huge fan of getting everyone in a workshop for a day, (fatigue quickly sets in, a few personalities dominate, no one has time to think things through).  My preference is a mix of short workshops, threaded discussion groups, blogs, regular surgeries, walkabouts.  Of course giving some real users access to your daily builds/regular builds either remotely or as their day to day working environment can also help build a great system.  Although this only works for certain types of users and products, where data contamination and business risk are acceptable.

Our local library celebrated its centenary today, there was a fete and a fancy dress competition, my wife loves making costumes and the girls all love dressing up so it’s no surprise that they all entered.  Stephie as Catherine Linton, Jenny as Heidi, Tessa as Mary Poppins and Anna as Sarah Crewe (the Little Princess).  They did pretty well taking 1^st, 2^nd and joint 3^rd places!!.  Anna unfortunately missed out but when you have three prizes and 4 kids someone is going to be disappointed.  As luck would have it though the photographer then chose Anna to be in the official photo of the event and he had no idea that he chose 3 kids from the same family!  He was a bit surprised when he took there names!

Last week Tessa also won the colouring competition at the library!

In this article, webservicespipeline.com discusses the rate of adoption of .NET compared to J2EE.  Its conclusions are quite suprising.  It seems that the rate of .NET adoption continues to grow at quite a rate, and puts usage on a par or slightly greater than J2EE.  It puts .NET success mainly down to increaded developer productivity and ease of deployment and management. 

This is signifiacnt for three main reasons:

1. In the hard nosed business of IT software development, even with all of Microsoft’s woes, when it comes down to making business decisions, many IT companies still seem to make decisions based on rational criteria, and long term strategy and architectural elegance or portability don’t win out in many cases.
2. There is likely to be a lot of new software developed for the Windows platform
3. Mono is going to be a pretty important Open Source project

I have been quite happy with my two monitor setup at home,  but using maxivista I am now able to drive three monitors from my main desktop PC.  This is just great.  I can now have my email in one, my RSS feeds in another, be using Office in another etc.  I am also using a lot of virtual PC’s and I can have these displaying on different monitors.  So I can have RedHat on one monitor and SUSE on another and still be using Office on my third.  It really must have driven my productivity up 20% when I am doing this sort of work, which is probably 50% of the time.  That’s at least £100/day.  A staggering return on investment – the third monitor, (old laptop), was being scrapped and Maxivista is about $40!!

The other great advantage is that your concentration and focus is not disrupted, you might think it would be, but it seems that by not switching applications all the time, and by being able to focus on the task at hand on your primary screen, the other two monitors just provide supporting information.

We really must get more people to understand the value proposition of multiple screens!  

This is one of the areas I am going to be looking at so its good news that there has been a recent flurry of activity around it.  here are some of the more important links. 

The debate was started by the EC report into this topic which is summarised here the full report can be found here.   One of the nice things about this report is that its been reviewed by Microsoft and Sun, and their comments on it, (at least those they made public), are also published.  Tim Bray, a man with some credibility in this area, (now working for Sun), describes his meeting with the EC team here.  John Udell writes up his views on the EC report here.  Dare Obasanjo responds to Tim Bray here.  

Then the thread starts to drift a bit, but Tim Bray also talks about his views on how the OpenOffice team have used XML, he is impressed!  And a snippet on how Microsoft have used XML in Office 2003, he is less than impressed!  Tim also talks about the use of custom schema’s and concludes they are not a good idea, (Microsoft implement them in Office 2003, OpenOffice don’t).  Jean, (a MS employee), gives his point of view, Jean like Tim is also a member of the team that created XML.

I just read this post by Greg that describes the impact RSS has had on his productivity,  it’s as if I wrote it myself so for once I will repeat it here in full!

My RSS reader saves me about 300 hours a week

The one about how using RSS opens up information to me in a way that is so reliable I could only do it this way manually if there were two of me…

Okay, so maybe it’s a little exaggerated. But seriously, I read an incredible amount of information these days. So much more than I ever did, and a lot of it on the Internet. Not only that, but I get the information I need (or want) so fast now that I can practically always act faster than most people when news breaks. Research that used to take hours and hours of searching and browsing now takes just minutes. I’m consuming much, much more information and doing so in much, much less time. What I can accomplish today in the information gathering department would have taken two of me just a year or so ago, before I found the real beauty of RSS.

I use RSS feeds for practically everything now. Rarely do I browse to a web site these days as my first method of gathering my daily doses of information. The data comes to me, based on my subscriptions. I know what I need, and I use the tools to get it. I find information sources just once, and then let the tools take care of the rest. I update my information world in real time, using tools like FeedDemon to do the dirty work for me. I focus on consuming, and the rest is practically magic.

RSS has made me a more productive, and therefore (in theory ) more valuable employee where I work. A huge part of my job is staying up to date with the latest technology, trends and issues. I subscribe to a couple hundred feeds that I review several times daily, some of which are aggregated feeds or feeds that are the result of a search of thousands of blogs and other sources for certain keywords or subjects. Then there’s the couple hundred others that I review periodically, both work-related and otherwise.

When news breaks, when someone writes a new article that I might care about, when new security patches or alerts are released, when Woot! posts their latest great deal for cheap geeks on the web, it all comes straight to me.

In a nutshell, RSS has enabled me to work (and play) on the ‘net in a way that would not be practical (or even possible) without the technology.

I have recently been doing some research into Open Source, its an interesting subject from so many perspectives.  That’s not what this article is about but if you want to follow up on it I recommend The Success of Open Source.  Anyway reading this book prompted me to think a bit more about daily builds.  Yes I know I already posted on this topic a few days ago but I can’t resist linking it with the Linux philosophy which can be summarised as:

“get it working then make it better”