Jamming with professionals

So I just watched this:  http://www.sciencedump.com/content/music-language (5  mins long - don't worry which uses the metaphor of music being a language. The video talks about how many musicians "can only be learned by following a strict regiment under the strict tutelage of a skilled teacher." and that with with learning spoken natural language that you are encouraged to make mistakes. It's argument that this model is wrong.

 - Learning is not something you are sent to do just a few times a week.
 - The people you speak to are not just beginners. They are proficient.
 - that if we are only aloud to speak with beginners we will take much longer to speak like an adult.

And that we should learn to embrace mistakes. That we should learn to encourage beginners to play and with accomplished musicians on a daily basis. And that "music works best when we have something to say." as well as that too many rules can slow down learning.

How does this compare with learning our craft? Many new working programmers are not allowed to be in an environment where they can make mistakes. Most of the time we are always 'in concert'. By the nature of those developers being paid to provide a professional service the majority will only ever end up sounding like band in the school play.

There are others who hack at home. These are the musicians that play without fear. They will make mistakes but learn but can also fall in to the trap having one way to do things. Without jamming with professionals how can the enthusiastic hacker know their weak points? Will they only be able to play one tune?

I guess the solution is that we need to have time & space to make our mistakes with mentored supervision. Now I know that there are some companies that promote this & with the advent of code dojo's, hackathons and code retreats we are being give a change to make mistakes. I just wish that I knew that when I was learning to play.

much chin stroking at ddd north

It seems like only yesterday that I was sharing stories and having drinks in the bar at Sunderland AFC after the original DDDNorth but somehow 12 months has passed and all of a sudden its DDD time again. This time the organisers moved the venue to Bradford in attempt to make the event closer to my house. So thanks for that.

The venue was the Bradford University's beautiful School of Management situated just outside the city centre. Registration was a little chaotic but after a quick reorganisation everyone was in and ready.

Stunning Venue.

The venue hosted 4 separate rooms for talks. Unfortunately I've not worked out how to fork myself so I'll take you though the ones I attended.

DDDNorth devs watching a session.

10 practices that made me the developer I am today - Gary Shutler

Before we ask the obvious question of do we want to be the developer Gary is today, it's worth pointing out Gary had aimed this session at developers new to the industry. What followed was a walk through of tips of how to really go from Joe average to a great developer. Most of the advice was sound (especially be diverse, and be responsible for your own training) but there was some controversy when Gary rated code reviews but didn't rate pairing. (note: very simplified interpretation). Gary's beard was immaculately groomed.

Gary gave some great advice.

Async C# 5.0 - Patterns for Real world user - Liam Westley

Technically my favourite session. Liam took us through the Task Asynchronous Pattern white paper.  Async is Microsoft's latest attempt to make doing more than one thing at once easy. What Liam does really well is slip from slides to code whilst maintaining an interesting patter. His test application was a simple mp3 organiser & player which give some great audio cues as to when things were done. This was definitely a session that I came out of eager to try new things. 

Liam's was a fascinating session.

Look Ma! No Frameworks - Gemma Cameron

Gemma's BDD message was that you don't need any stinking framework to do BDD. Forget about the tools and just have the conversations. She showed by the help of the audience how you could write meaningful test code with out having to be constrained by a frame works language. We had a live kata and some interesting discussion with good points raised by the grizzly looking Ian Cooper.

Gemma's interactive session was thought provoking

Websockets and SignalR - Chris Alcock

I've seen this talk before and somehow managed to be in here again. What I love about Chris is that he manages to pack in a tremendous amount of information in to an hour. SignalR and websockets on the front of it are powerful tools.

Another great buzz in the foyer. Not too unlike the sound of a Braun series 3.

Using nuget for fun and profit - Joel Hammond-Turner

Joel has found the solution to code reuse and its been right under our noses. It's NuGet! In this session Joel showed us how to set up our own NuGet server and his PublishNPackage tooling. He's used this effectively to reorganise big code dumps of shared code and is now an integral part of his build process. We got a quick insight how this will be used with CI build too.

I just wanted to thank the organisers for today. It was amazing.

Returning to Who is agile

A few months ago I wrote a review of the Who is Agile set of interviews compiled by Yves Hanoulle. Time has passed now as Yves has been back in touch and as the book has evolved I'm writing this follow up.

I think that any community has its fair share of navel gazing and it seems that the agile community suffers especially from this. Too often the Agile manifesto's signatories are put up on pedestals and listened to without question. Too often are practicioners sat around telling each other "didn't we do well". When I first came to read "Who is agile" these were the biases that I was laden with and consequently I had some reservations of the underlying purpose of this book and the value that it would bring to those not in the circles of the contributers. I also think that this behaviour is why there are such strong opinions still over agile and I think that some of the criticism is valid.

(It's probably worth reflecting on at this point that this cynicism may be saying more about me that it is about any community)

So inspite of the review Yves has continued on with adding to the book and I've continued to read it.
After grumpily dismissing the format I think I've now think I've worked out at least one way to read it. This book is not about names, nor agile. It's a book about people. If you forget the names and bio bits and just read the questions and answers you get a fantastic insight into how these people tick. Some of the best interviews are where the interviewees talk less about software development and more about the other stuff that defines them. I believe in that to be a good software developer you need to have experience in other 'stuff'. Some stories are very personal too and it's fascinating the influence that some of those incidents have on those people.

I normally read the book on the kindle but that is only half the fun. As the book has become to big to email to the kindle (via gmail at least its > 20mb) I've found I read it less but when I do there's added value. Each interview is scattered with lots of hyperlinks, some go to just some strange places, others infomative distractions, or just plain definitons. You could get lost for hours just reading through some of the links and if you are stuck for ideas for books each interview will suggest a new one. This is really Who is agile's strengh. It's a cornucopia of information! (or a yak-shaving utopia).

The other criticism I had originally was that the book had a narrow geographical focus. Yves has done well by getting a more diverse (geographically) set of people. Yes the book still is predominatly a euro-us set of interviews but there's more from futher a fields. This feels more like a truly diverse publication.

I'm impressed with how the book has progressed. For its current minimum price ($9.49) there is so much in there. Don't be put off it you don't know (or like) agile. This is not an agile book, it's a book full of stories about software people.

The evils of auto properties & object initializers in c#

I've been thinking a little bit about object orientation recently. It seems that OO was the poster child of the 1990s and has been the leading paradigm through the first decade of the new millenium. The thought behind this was that object reuse would solve all our problems but in reality they didn't. Even with languages gaining objects, C evolves to C++, and being built with objects from the ground up such as Java and C# people still seem to just not get it.

Back in OO school I learnt that objects should be polymorphic, inheritable and encapsulate discrete bits of behaviour. In OO college I learnt that we should strive for low coupling between our classes and high cohesion. In OO university I learnt about the SOLID principles and that I should favour composition over inheritance. It's been a long journey and I'm still on it but all over I'm still seeing non OO code in .NET all over the place. Is OO too hard for people? Or is just a broken paradigm?

Well my friends, OO is hard but I don't think the C# language designers have helped.  The two worst features for Object Orientation in c# are auto properties and object initializer syntax. "What?" I hear you say, "Auto Properties? But they're so useful! (and cute). Object initializers they save so much time!"

They are evil.

More and more I'm beginning to see classes like this:


and initialisation like this:


People are abandoning the general principles of object orientation. We are exposing the internals of our objects with gay abandon. This is a dark route that inevitably leads to pain. Every time you use a vanilla auto property you are introducing an opportuntity for coupling, which reduces the modularity and resue of your code. Your classes becomes mutable so lose all the goodness that immutability brings. By allowing 'Children' to be initialised in this way you break the Principle of Least Knowledge and couple your class even further. It's no wonder that we can't do OO if we take short cuts like this. Now of course there are reasons for using initializers, simple DTOs and anonymous classes spring to mind but don't be fooled by this syntactic sugar, it will rot your teeth!

Source Control

I was just asked about source control by a friend that has only had experience in VSS. Thought I would share my rant:

Git (and other DVCSs) are a revolution in source control. They really are. Honest. I'll come back to why later but lets concentrate on what you know, VSS.

VSS has a very bad reputation nowadays. This is primarly because vss is known for corrupting its repository (http://www.codinghorror.com/blog/2006/08/source-control-anything-but-sourcesafe.html) but also because of its concurrency strategy, lock-unlock-modify

(http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.vsn-models.lock-unlock) which has gone out of fashion. Most VCSs (e.g. svc, cvs) use copy-modify-merge

(http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.vsn-models.copy-merge) because this allows more developers to work on the same bit of code at the same time. This strategy is great but the risk is that you get problems when you merge. Obviously you get conflicts when you are merging in code into a different version of a file of the code you;ve checked out but some people keep whole versions of the codebase unmerged for extended periods of time. These can be versioned as well and are know as branches.

The rational behind branches is sensible. If you have major project N that is going to be being built for 6 months then you will want to a) keep it in source source control b) not have it messing up the code you are maintaining. So a 'branch' of the code is taken and you have the benefits of source control. the trouble comes when merging the branch back in quite often the code is so divergent that you have to do a lengthy and risk prone re-integration. (funny thing is that VSS has these integration problems too). Lot's of people more clever than me have struggled with this http://accurev.com/blog/2012/03/07/avoiding-merge-hell/ , http://martinfowler.com/bliki/SemanticConflict.html . Anyway the bottom line is that merging is hard in many vcs's.

The other issue with traditonal VCS's is that they make commits something you do rarely. In a normal VCS you commit to a repositroy only when you are finished. This goes against the meme 'commit early and often' http://www.codinghorror.com/blog/2008/08/check-in-early-check-in-often.html . Wouldn't it be great to create check points when you've finished a bit of code? Or if you just wanted to hide something somewhere? Also what happens if you want to share you codebase with 2 or more servers? Well in step DVCSs.

Distributed Version Control Systems such as Git, Mercurial (also known as hg) make the repository local. So you can have your own personal source control system on your own machine. This means you have all the benfits of a VCS locally. if your server goes down, you have the code. If you make a mistake, you can rollback. It's awsome and it promotes commit early and often. Git is even better because you can branch really easily and mor important merge really easily so all this merge hell that occurs with other systems is lessened (if you use it right). You can pull code in form as many sources as possible and push up to them and every thing. Git is so horrendously powerful that you can rewrite commit history, cherry pick commits. This is also dangerous too. (with great power come great responsibiltiy). It also means there's a crap load to learn. Also for windows you have to use a linux shell and the tools are best used on the command line. This also is a shock to windows devs. Luckily github has brought out a windows client that makes the experience more palatable. In short Git is much, much better than any other VCS I have used despite its learning curve.

i've not mentioned TFS. It's basically VSS next but with a CI server and an issue tracker built in. Its fukcing awful. Read this article and comments:

http://www.itwriting.com/blog/4744-real-world-microsoft-team-foundation-server-not-very-good-says-thoughtworks.html

I've used

VSS

SVN

Star team

TFS

HG

and Git in anger. SVN,HG and Git are the only ones I'd return too. SVN just looks like a dinosaur compared to the other 2.

Hope that helps.

Re: Over testing

It seems that one of the questions I asked on StackOverflow has gained some attention today, @dhh (of Ruby-on-Rails and 37Signals fame) mentioned it in a post on "over testing".

He's railed before against rspec and now he's being vocal about automated developer testing in general.
Whilst its great to question the status quo, I hope this doesn't signal a return to untested code.

Is the flock now going to consider testing as harmful?

DHH's post, in my opinon is actually very good but it doesn't cover new ground. Its been observed for some time that :

• TDD is not about just 'catching bugs'. 
• 100% Coverage is not pragmatic in 100% of cases.
• Code coverage is a metric that is fundamentally useless.
• Great swathes of tests are a maintenance headache.
• Writing testable code is a constraint on your design.

Before I got into writing automated tests I used to write a pseudo code comment, then write the code, then remove the comment. Then unit testing came a long and I began to automate that psuedo-code. Of course things take longer this way. Not only do you have to solve the difficult problem but you also have solve the difficult "getting things under test" problem. But here's where the power lies: By writing your intentions down you are forcing yourself to consider what you are doing. Its an extra step. Yeah there will be some rock star, alcohol drinking brogrammer who can write that code a billion times better than you without tests but even ninjas make mistakes sometimes. So I prefer to set up a test up front.

Now as time has progressed I find it more useful to write my expectations of what the stakeholders want. This means I think less about passing code and more about making features. TDD still has a place, a Behaviour Driven-style seems to fit better for me. Some of the BDD tooling I've used just was too much of an overhead in my situation, which is why our team dropped SpecFlow (a cucumber port) for MSpec (a cousin of RSpec). But we don't need to use any of those tools. It's entirely possible to do BDD with XUnit or anyother flavour of automated testing tools. It's just about OK to write tests after as long as you are clear what you are testing. (You wouldn't want to test the wrong thing.)

What the rise of TDD has given us though is a focus on quality, a return to craftsmanship. We don't want a return to shops thinking its ok to just sling code out and for their customers (or QA) to deal with the aftermath. There is of course a balance. I'm glad that people are beginning to question the practice. Over the last few weeks I've heard Dan North, Michael Feathers and now DHH push back but please don't stop testing.

Who is agile : a review.

I suprised myself last night in the reaction that I had to this book. I wasn't sure what to expect from the book but I'd seen a couple of tweets about it. So I fired up leanpub, chose my price and downloaded.

I loaded the pdf and flicked through the first few pages, skimming the contents, and reading a few further pages. The format is a standard set of questions, an extra question and a recommendation of who to interview. I flicked through the first interview with Lisa Crispin which was painless, relatively interesting,  but the questions were uninspiring (I'm guessing a generic questionairre is difficult to 'jazz up').

I then looked at the names down the list and thought about the format and felt little bit angry. Is this book an intropection of the circle that the authors know? What does it give to anyone else? What about all the people this book doesn't cover? Are they not agile?

So I have some reserverations. I had kind of thought this book would be a guide of how to be agile. I was wrong. Fortunately, so far, it's not so bad.

I probably know of, read, and respect 10ish of the 30 odd in the book. Some of the interviews I've read are fairly intesting but the power this book are the links that people mention. I've spent the last hour getting lost in the technical/agile and non technical books. The interviews are all light reading too. Something you can, by its nature pick up, read one and leave for a few weeks.

What I was pleased about was the communites section at the back. There's a ton of interesting information and ideas about things you can do in your community some stuff I hope to bring.

What I must remember is that this is a work in progress and it can be regenerated on demand. If agile is your thing or you are wondering if its more that just scrum & TDD then I'd certainly recommend you pick this up. If you are looking for another agile manual, there are better suited texts.

Looking forward to the updates and following the links.

Sprint retrospective: INVEST in good stories.

The column to the right of the 6 cards is 'done'

I've just come back from a sprint's worth of holiday and so unfortunately have not been able to be in work during the sprint. We set a fairly low and what I thought was an achievable target.

However on my return I've see a lot of cards in the 'almost done' column. This was not the new beginning I had hoped for.

In the retrospective, the team explain that the blue cards were all dependent on all the cards being done.

The green cards were started by branching off the blue and therefore were dependent too. Nothing could go out. There's an acronym that can help here, INVEST. Stories should be Independent, Negotatiable, Valueable, Estimatable and Testable. Because the project is a rewrite and we have made breaking changes the cards had to go out together. We have decided to consider more the impact of doing this in the future.

Process meltdown.

After our process meltdown. We've decided to dust ourselves down and try again. What I think we've done is retrospect ourselves into a corner. We used retrospectives to remove the barriers to our productivity but by reducing some of the ceremony somehow we have removed all structure. This combined with a change in personnel and the disruption of the Christmas period has resulted in a development process that is best described as sluggish anarchy.

Rushing Shu, Ha, Ri

We've decided to re-adopt scrum again. Why? I feel we started to run before we could walk. There is a phrase that has been picked up by the agile community, Shu, Ha, Ri. This phrase borrowed from Akido shows different stages of learning.

In the phase of Shu, the person tries to abide by the rules. She tries to learn all the principles and informations by heart. But she can't abide by all the rules while she is doing the practice. Her body(including her brain) starts to remember them bit by bit through repetitious practices. When the time comes she can internalize and abide by all the rules -- when Shu is achieved, Shu phase is finished and she enters into Ha phase.
In the phase of Ha, she tries to break the (old) rules. She tries to self-reflect on herself and her knowledge, and come up with anti-theses such as exceptions of the rules in the real world. But she can't break all the old rules while she is doing the practice. Her rules start to get more complete(or becomes more like "case-by-case") as the rules encompass exceptions bit by bit. When the time comes she can break all the rules and see the both sides of every rule (maybe substituting with a set of her own rules) -- when Ha is achieved, Ha phase is finished and she enters into Ri phase.
In the phase of Ri, she tries to leave the rules. She tries to get free from all the rules, and get into the state of no distinction, or into a new dimension. But she can't leave all the rules while she is doing the practice. Her body starts to forget them bit by bit through following natural laws and flows (or Tao). When the time comes she can leave all the rules -- when Ri is achieved, Ri phase is finished and she enters into a new dimension of Shu.

We feel that we tried to enter the Ha stage before mastering the Shu.

Learning to fail habitually

The one thing I don't like about scrum is it is a framework for exposing failure. This can be used as a positive but after a number of failed sprints your team can become demotivated. We kept on over committing on story points per iteration and rather than reduce we tried to combat low velocity by removing impediments. This became habitual. We were learning to accept loss as a norm.

Process rebirth

So today we've started the sprint with a much smaller number of points. The idea behind this is that we can achieve the goal. Hopefully this will make us feel better about the process and motivated to continue.

acceptance

We've been revisiting the Agile in a Flash cards at the daily stand-up. As a team that purports to follow agile priniciples I don't mind saying that we've lost our way a little bit. By removing the percieved hurdles that were preventing from producing faster we seem to have gone too far. The process is lacking any structure at the minute but with new members of the team comes fresh energy. It's time to pull our socks up. What the cards do is provide us a discussion point to focus on and retrospect over where we've come from and where we want to get too. Admitting this is the first stage. Doing something about it is the second stage.

Metrolink: Highlights from the passenger's charter

The top web search result for "Metrolink Complaints" brings back Passenger Charter last updated in 2008 it has some encouraging quotes. All emphasis is my own.

The vision behind the Metrolink system is to provide a safe, efficient environmentally friendly and reliable tram system for Greater Manchester that will integrate with other transport modes and fulfill the aspirations of the Passenger Transport Authority.

Advance information on planned disruptions to service will be made available as soon as practically possible in advance. Information will be prominently displayed at all stops. We will always endeavour to minimise passenger disruption to services.

We want all passengers to have a trouble free journey and therefore ask you to consider the needs of your fellow passengers at all times.

We will continue to aim for improved standards of punctuality and reliability. We will publish our reliability and punctuality figures set against agreed target levels at Metrolink stops every four weeks. These figures will be independently advised every year.

We will provide real time information about our services by means of public address systems and information screens.

How many of screens actually work?

We recognise that passengers want to know what is happening when things go wrong. Our staff on trams and on the Metrolink system will help by providing as much information as they can to passengers.

For comments or complaints regarding general operation, maintenance and cleanliness of the Metrolink system, passengers should contact Stagecoach’s Customer Service team. For issues relating to policy, for example fares and future Metrolink expansion, passengers should contact GMPTE’s Customer Relations department.

Note Stagecoach do not run the service anymore.

If you have a complaint, we want to find out what went wrong and put it right for the future.

Senior managers carefully monitor the number and type of comments we receive. We will use this information to improve our service in the future.

This is my favourite

We do our best to give you the service you have the right to expect. Our aim is to provide customer satisfaction by improving our services in response to your comments.

We will always do our best to satisfy all complaints. If you still wish to take the matter further you can refer it to your local Passenger Focus Group, an independent public body set up by the Government to protect the interests of Britain's rail passengers. They are funded by the Department for Transport but their independence is guaranteed by an act of Parliament. They use their knowledge to influence decisions on behalf of rail passengers and work with the rail industry, other passenger groups and government to secure journey improvements. The address for Passenger Focus in the area served by Metrolink is: Passenger Focus 9th Floor Store Street Manchester M1 2RP Tel: 0870 336 6095 Fax: 0161 244 5981

Manchester's Metrolink: An utter disgrace.

Regular reader. Sorry not a software topic just wanted to get some thoughts out.

This morning's delayed tram

I love public transport. It's brilliant. Instead of crawling along in rush hour traffic, getting cramp in my foot as I leave the clutch at biting point I get to have a nice walk to the local public transport stop(healthy), stare vacantly into space as I wait for my carriage to arrive (meditative) and then I take a short journey where I read my book to somewhere vaguely near my destination (educational). Then I take a further walk and I'm there(even healthier). Or that's the idea. It's not quite working out that way. You see I use Manchester's Metrolink.
Metrolink is a light railway system that spans the city. When it was created it filled the need for better transport links from Bury and Altrincham to the city centre. I remember travelling on the Altrincham line for the first time. It was quick, clean and efficient. Sure there were some problems but my co-workers who used the system didn't seem to be affected too adversley. I don't know what's happened but things have got worse, much worse. I've been a commuter on the Altrincham line for 4 years and the service has degraded to such an extent that I feel that the people of Greater Manchester need answers from those who run the system. So why do I feel angry?
Price hikes.
On January 3rd prices across the system were increased on average by 6%  This price raise was described by the media as 'Inflation busting' 
This irks me on two points. I thought the point of public transport was to provide cheap, quick, links across the city to stimulate the economy, and ease the burden on the roads. What instead has happened is that by raising prices potential commuters are driven away from using the Metrolink in favour of driving or just not bothering. This price hike has been introduced at the same time as Manchester city centre begins to charge cars to park on a Sunday.
Its a 'double whammy' for Manchester residents and plays into the hands of places like the Trafford Centre which provides much better parking facilities and although there's not a Metrolink there, a reasonably efficient bus service.
Poor service.
Since the price increase I have made 26 commuter time journeys. Of those journeys, 6  of them have had some form of disruption. That's 23% of my commuting journeys have had delays. In the last 2 days 100% of my journeys have been delayed. I'm writing this after spending 76 minutes on the tram (a normal jourey tkes 20 mins).
Tonight's Journey.
This particular journey was so farcical it beggar's belief. I was travelling from Altrincham to Piccadilly to get to an event starting at 6.30. I buy a return ticket from Altrincham (more on this later)at 17.33. As soon as I set down the driver reports over the tannoy that there is a failed vehicle in the city centre and the line is suspended. Most people leave the tram, an angry few commutters are talking to the driver. I can just hear him and I'm sure he says that we shouldn't ring up to complain because that will just tie up the people trying to sort the problem out. I chance it and decide to wait - buses from Altrincham crawl up the A56 and to be fair Metrolink normally sort it within 20 mins and I've bought a ticket. After 10 mins or so the tram then starts moving. We are informed that the service will stop at Deansgate-Castlefield
Altrincham is at the end of the line and just before the stop before (Navigation Road) the track becomes single file. There is signal where trams have to wait for the other to pass. Our tram pootles to there and then doesn't move for 10 mins. The driver then informs us that the he can't contact Network Rail to get the signal changed. We wait for what seems like another 10 minutes the driver then informs good news - the service will continue to Piccadilly. Unfortunately neither he or the control room can get the signal changed. Minutes pass and eventually we move. The driver apologies once again. 
We begin thundering up the line. Angry commuters squeeze on and off  at Timperley, Sale, Dane Road, Stretford and Old Trafford but at least the thing is moving.  We then stop just past Old Trafford. There's always a delay now between Old Trafford and Trafford Bar as the Chorlton line joins the Altrincham one. This delay seems to take longer than normal thought, it couldn't be ano... The driver comes on the tannoy. "Sorry blah ... blah... there's been a backup of all the trams trying to get through Cornbrook. We're just waiting for our turn". Fair enough. (I look at my watch its 6.30. I'm now late.)  More minutes pass, I hear something over the driver's radio about telling customers of the Eccles & Chorlton lines that their tickets are valid on the buses.  Phew! I'm on the Altrincham line. Driver comes back on, apparently the computer system is overloaded at Cornbrook so they can't let us move. I am now officially livid. My normal stop, Trafford Bar, is 200 yards away and Old Trafford is about 100 yards away and I am stuck on a packed tram, missing my evening event and unable to move. 18.49, 1 hour and 16 mins later I arrive at Trafford Bar. I should be in Piccadilly Gardens, 20 mins ago. Do I risk it? Can Metrolink get me 4 stops closer? I didn't want to find out.
Dealing with delays on the Altrincham line.
I mainly travel between Trafford Bar and Altrincham. To catch up a common tactic of Metrolink is to terminate vehicles at Timperley so they can turn around. This means that commuters who want to go to Altrincham (read most of the people remaining) have to either wait or walk. Walking takes 28 mins. If most people are getting off at Altrincham why can't the service terminate at Navigation Road, 10 mins walk away?
There are 3 places on the line where trams get delayed.
1) Between Altrincham & Navigation Road
2) Between Old Trafford & Trafford Bar.
3) Between Trafford Bar & Cornbrook
Why can't trams wait in the stations for signals to change? At least then the commuters can make a decision of whether to stay on or off. Ticket inspectors over Safety Inspectors.
In a bid to reduce the number of fare dodgers there have been an increase in the number of safety officers. At one point I've been checked 3 times on a journey. At no point have safety officers been there to prevent the over-crowding that occurs or been there to provide information when a delay happens,
Poor ticket flexibility
Today I wanted to buy a ticket at Altrincham from Trafford Bar (where my season pass ends) to Piccadilly. So I have 2 options. I can either get off a Trafford Bar, buy a return from there and wait for the next tram or buy a full return from Altrincham. Today I spent £4.30 and gave up at Trafford Bar. I actually paid twice for this journey.
What the hell is going on?
It seems to be that this transport system is reeling from one cock-up to the next. I've had one person from my team at work leave due in part to the Metrolink commute. His train/tram season ticket was accepted by most inspectors but then he got slapped with a £50 fine (for his first offence!). Poor information on the train system caused this.

There's probably more I could haul out of the memory banks if I wanted to, such as the cock up of the wiring at Altrincham where you had to pay someone to stand there until someone ordered some sleeving because it was too close to the footbridge. I think you get the idea though. Metrolink is mismanaged and not fit for purpose.
I feel it's Metrolink's duty to explain its self and to sort it out!