Mark Everard

As programmers, we’re very used to dealing with systems that are easy to understand and behave predictably (though I have worked with some codebases that are the exact opposite).

Aside from code, the majority of our day-to-day interactions in the workplace are with team members, managers, clients and other colleagues. These human interactions are often much harder to predict and respond to, but can have a much greater impact on your work environment, productivity and workplace happiness.

I attended Roy Osherove’s ‘Lead Better London’ course held at Skills Matter back in July (and have been meaning to post a follow up about it ever since). Roy was / is a leading voice in the .NET community (though now he’s exploring what Ruby has to offer) and is the author of ‘The Art of Unit Testing‘, which I consider to be THE book to read if you want to learn and become better at writing test code for your software. Roy regularly blogs about software team leadership issues over on FiveWhys.com, and it is from there where I found out about the course.

The 2-day course caught my eye, as it was focussed on managing people and software teams rather than any specific project methodology, such as agile. Courses such as these give you a great opportunity to take a step back and view your workplace and your interactions within it in a different light, without the distraction of your ‘real work’. Roy is a great mentor and from the off, ably demonstrated the ‘ninja’ leadership techniques he was trying to teach to us. His ability to listen, comprehend and consolidate a problem down to a fundamental is a skill I really want to perfect.

Things I took home with me from the course:

• Confidence to Lead: motivation to tackle the issues I see day-to-day in my workplace
• How I react: ability to recognise my own and my colleagues behavioural traits and adjust my response to suit
• Who I want to be: a clearer idea of the characteristics I believe make a good leader and the willpower to make sure I follow the right path.

The plural of Lego is Lego, not Legos. The word Lego is a trademark and should be used as such. Here is a picture of some Lego bricks.

Roy is holding another course in London this November (2011) , so if you’re interested in learning how to lead and grow a software team, then you should do what you need to do to get yourself on his course.

For me, the challenge now is to take the skills I’ve learnt and put them into practise in my day-to-day work life.

Let the human experiment begin……

Slides for a talk I gave to Fortune Cookie’s HTML developers, where I tried to press the following points:

1) WebForms != ASP.NET
2) MVC FTW

There have been a few scenarios played out recently that have got me thinking about ‘the effort required to maintain and drive a successful software platform’. Its clearly a difficult balancing act as not only do you have to develop a product with the functionality that end users desire, you also have to create a ecosystem of developers who are able to leverage your platform to create cool products!

Apple’s very public spat with Adobe over Flash support clearly demonstrates the difficulties with maintaining the right balance between the end-user and developer. Apple’s heavy handed approach to setting their strategic technological vision for the ‘good’ of iPhone / iPad user experience has ostracised a large section of experienced rich-interface developers, who were excited at the steps that Adobe had taken to enable their ideas on the Apple platform. Whether or not this was the correct call from Apple will only be borne out in time. If I were Adobe, I’d be throwing my weight behind Android and creating some great Flash development tools in the hope that Flash developers produce the killer apps to show that Flash on a mobile is a ‘workable’ technology.

Microsoft have been taking a different approach in recent years. Its latest successes (I’m not including Windows 7 in this – in fact, is that even considered a success?) are built on the foundations of the .NET platform, and have been driven entirely by a open, honest focus on developers and empowering them by giving them access to the best development tools (seriously Visual Studio is an amazing bit of kit). Their approach to Windows Mobile confirms their belief in this methodology. Stuck with a mobile offering that paled in comparison to competitors, they went away for a while, re-thought their whole approach (undoubtedly influenced by Apple’s App store success) and created Windows Mobile 7. In one swift announcement they turned me (and any other .NET developer) into a mobile developer. It will be interesting to see whether they can deliver an end-product that stands up too.

Being able to throw away a partially-successful platform and start again is a luxury that only the major players like Microsoft, Google, Apple can afford to do. Most smaller platform vendors can’t justify starting over from scratch. In fact, doing so could be the the single worst strategic decision they could make.

Instead the only choice left is to evolve and work extra-hard to improve the areas that need the most attention. The first step towards any solution is always admitting the problem.

An error doesn’t become a mistake until you refuse to correct it.

Orlando A. Battista

This then brings us back to the original conundrum. Where do you focus your development efforts? Who really is the most important user of your platform? Developer or end-user?

Renowned CMS anti-hero @McBoof approached these issues with his challenge to CMS vendors to rate the following CMS ‘features’ in order of priority:

• Editors – A user interface that is a editor or publisher’s wet dream
• Performance – The fastest, most stable and scalable CMS in the world
• Features – The richest set of features any CMS could dream of offering
• Developers – An open, standard, extensible product that makes developers salivate
• Website – A product that can give you a kick-ass website, really really quickly

What the results of this semi-serious survey actually tell you is open to debate….. but what is clear is that none of the CMS platforms mentioned excel across all areas. Simple rule of life: You can’t please all of the people all of the time!

Speaking as a developer, I obviously want to use tools and APIs that help me create solid, maintainable code and that generally means using the newest technology (ORM’s, Dependency injection, etc etc).

However I’m also aware that adding new features/APIs to existing platforms takes time and some features may rightly or wrongly not be considered a priority. For example, how long has it taken Microsoft to allow developers full control over rendered client Ids in WebForms? A well-known ASP.NET limitation which has been the bane of every front-end developer since the dawn of time (aka VBScript). Taken in isolation this didn’t make .NET a bad platform, just a slightly less perfect one.

This is where (as @joelabrahamsson pointed out on my last post) the development community should take the lead and not only point out any issues to the platform providers but also attempt to show the way and to provide sensible solutions/fixes to any issues that may be causing development woe.

This shouldn’t be a one way relationship. In return, a developer should expect open discourse and two way communication with the platform providers. Sharing things such as a development roadmap allows developers to make up their own mind about the platform’s direction and to have input on the proposed pathway. Any contentious proposals will soon be flagged up by the eager community, giving a chance to either re-think or to justify the initial line of thinking, as Apple’s Steve Jobs attempted with his ‘Thoughts on Flash’ open letter.

To me – that openness is the key to a successful platform. It gives great buy-in to the potential developer knowing that they can shape not only their end product but also help to shape the future of the entire platform.