I’m probably going to ditch some of the less popular content, but most sections which already exist will be getting an update. The main bits of work I’m intending on carrying out are:

• Completely new look and feel – I’ll keep the simple nav though.
• New blog section – probably powered by WordPress, that way I can update the site more frequently
• Flickr integration – my gallery will go and other peoples photo’s of the faithful city can take centre stage!
• The forum will be making a return – hopefully with the increased traffic, we can get some discussions going.  I’m hoping to get the recommendations etc. put in here so they can rated by you and not by me!
• New news feeds and up to date info. that will hopefully make this the place to come for all things Worcester.

Well that’s about it – there’s only me, so this may take a while! I’d love to hear from you all on any ideas, features etc. you might have – please comment here, or drop me an email at suggestions@seeworcester.co.uk – Thanks!

Enjoy!

SO my longer term options are:

No office – I need a “man cave” of some description, if I can’t hunt tigers then I should at least be able to have a space of my own with a comfy chair (and assorted desk toys – yes, civilization has really come this far)

Shoved in a corner somewhere – this could be on the landing, in the kitchen or as a result of some maneuver of furniture in the lounge (the lure of the TV would be too great)… and my less than heroic efforts to keep a desk tidy would undoubtedly rial my wife!

Purpose built lodge – this is the dream solution with only a couple of drawbacks:

1. They cost a fortune
2. Our garden is like the north face of the Eiger – in four years I haven’t so, much as grown a bean or dug a single hole – this would require me flattening an area of the garden – unless someone wants to lend me a digger – it ain’t happening.  And that alternative scenario would probably end in tears as I destroy the east wall of the garage.
3. I’d then have to build the thing!  Come on, I’m a software engineer – I can as much build a sensible, secure outhouse as I can build a space rocket
4. What about the electric? – don’t get me started.  I’m impatient, that’s all you need to know.  Not a good mix.

So that leaves me with the best idea that I’ve had this year… oddly though my wife thinks I’m mad!

The shed in a garage approach. I know, it’s a spectacular idea.  I get a man cave, I don’t have to heat the whole garage, it’s secure, it’s cheap too… even got electric on tap (metaphorically speaking – there was that time we had electric in one of the taps, made for an exciting shower.  I didn’t use that plumber again – still not sure how he managed it tbh, he was only fitting the dishwasher waste pipe…).  My wife thinks I’ve lost it – so I need your support… this could be the future of man caves across the nation….. unless you’ve got a better idea?

Campaign to follow

I was just chatting to one of our outgoing developers – someone I’m going to miss, he’s been a great evangelist for change in our practices – even if ultimately it has been like wading through treacle at times!  I was doing some handover bit’s of documentation in our Wiki, making sure I knew where all of our tools were and their respective setup instructions when I stumbled on a wiki entry pertaining to Sonar.  A tool for performing an automated code review – a tool whose name rang a bell but that I’d ultimately not paid any attention to.  I took a look and OMG what an unbelievably useful tool this is!  Oh the hours I have wasted telling folk that if statement should always have braces or that YOU SHOULD ONLY EVER HAVE ONE RETURN STATEMENT PER METHOD (when will they learn?! ).  “This has to be in anyone’s software tool arsenal”… was my immediate, unfounded conclusion!

All this got me thinking – we’ve got a lot of tools around for helping us with our software development, but are they really useful?  We gather all of this knowledge – but do we really need it?  Simply, the answer is: “It depends” – “what a cop out I hear you say!” – I’ll elaborate:

We have the following in place here (over and above all the usual development tools such as IDE’s and DB Managers):

• Task Management setup for Agile working
• Collaborative Code Reviewing
• Maven with Nexus Repository
• Continuous Integration
• Subversion with TortoiseSVN
• Code Coverage Analysis
• Automated Code Reviewing (aforementioned Sonar)
• Enterprise Wiki

That’s a lot of acquired knowledge – I can look at a single piece of work/task, see when it was built, what code changed, who reviewed it, what tests have run (and passed/failed), what areas of the code are most complex/at risk of low coverage – I can link to documents or information about the release in the Wiki.  I can even take a piece of code and look at its entire change history back to the year dot.  All of this with a few mouse clicks – GREAT!  Well yes it is, but is it useful?

Picture the scenario – we have a piece of legacy code, it is large and cumbersome.  As a development team, we’ve adopted this unwieldy code – documentation is lacking and half of the code base is unused legacy.  Support for this product is time consuming and tricky.  The smallest change can render other parts of the system unusable.  Self respecting software engineers would suggest that we might be better off chucking it in the bin and starting again – but we all know that:

1. This isn’t financially viable (at least that’s the perception)
2. That we’re actually part of the club of 95% of other software developers that have the same problem (and that when you look under the hood of most software houses code base you’ll find that most software in the world seems to exist in this state!)

But it doesn’t have to stay this way – these tools don’t just serve to give management stats – they’re so much more important than that, they are the means to making it better – they also ensure that new software is developed better from the get go.  You might not ever need to know 98% of the detail that is stored collectively, but when a piece of code that was changed causes a major headache – you’ll be glad you can find the history and the details associated!

You’ll be able to track the change, see the code coverage details, the build history of that changed and ultimately challenge the correct developer (quietly if it’s you)!  You’ll also be able to look at the code that was changed and see how it was reviewed – what did we miss? How can we improve it? We can raise a change off the back of this with the details – whilst at the same time rolling back to an earlier release if we need to make a quick fix.  The point is, that we can make a sensible informed decision based on a whole raft of useful data.  This is all in addition to the usual benefits these tools bring – management, quality, reviewing etc. etc. etc.

BUT – there are some fundamental caveats to this.  This will only work if you follow it through all the way.  The implementation of a bunch of tools is just that – the key to making them work for you, is the culture and the implementation of the right process (should not be a cumbersome activity!).  The tools will give you the ability to collect the data without the administrative overhead – an integrated suite of tools (such as the Atlassian tools) will take a lot of the leg work out of the capture (it’ll record the code reviews in the task, the check ins, the code coverage – you just need to record your work log and check your code in (like you always have!)), everything is driven from the Task… the systems gather it all together for your consumption, hooking into Subversion and Maven to give you that complete picture.  Use the knowledge you’ve gathered – use it to inform your code coverage strategy, your estimating, your configuration management strategy – don’t expect to use it all, just be glad that it is there when you need it.  My final piece of advice is to make your choice of tools a collaborative effort – don’t forget to include your support desk, your test team even your requirements analysts, if you can settle on the same toolset, you won’t be double accounting – take it from me, unnecessary extra admin is a recipe for failure (the team will quickly become disenfranchised)!

In conclusion – use the tools, put simply, they work.  Use them properly, understand them and embrace them – let them do the work.  And as I always say: Don’t be slave to the process, if you are, the process has failed.

And if there’s one thing I’ve learnt – that is that the need to stay current as a paramount requirement is largely bull crap!  I strongly believe that a good software engineer, is always a good software engineer.  So you’ve not cut a line of Java in ten years, so you’ve never used a Cascading Style Sheet in anger – you don’t even know what the Hibernate means, let alone how it works… you know what?  It doesn’t actually matter…

Well that’s easy for you to say, I hear you cry!  Maybe you’re you’re just saying it to make me feel better – well yes that is partly true, but I have good reason!  For years I have seen good talent squandered, people working on unexciting, unchallenging projects because they don’t have the confidence to do better – I am guilty of this charge as much as the next person.  For 10 years I have worked in software, but for a large part of that I have managed teams – I’ve always tried to maintain a technical hand in things and the level I work at generally means that I’m sometimes required to get stuck in – problem is that this can be sporadic, sometimes I’m expected to be technically deep into something, other times I might go months without cutting so much as a System.out.println.

Whenever I’ve been out of it for a while –  I always fret about my ability to be a “softie” again, but everytime this happens, I discover it’s entirely misplaced – sure I’ve probably forgotten half the Java API (frankly I didn’t know that much in the first place!).  There are those around you that seem to know all the latest frameworks and design patterns – but, whilst useful, many of these things are just the in vogue thing – and the really good ones are rarely that complex!

As you start cutting code again you’ll discover:

• Actually there are plenty of people around you who can help
• The internet is an incredible resource of knowledge – code by example, don’t afraid to be a lazy coder! If someone else has done it and you can use it, then use it!  There is no point in reinventing the wheel.
• And the most important thing to remember, is that the principle’s in software development never really change.  The rules and concepts never really change.  I’ve discovered this recently writing Objective-C, it’s different enough from vanilla C that I needed a tutorial to get started (especially around the basic language concepts), but once I’d got the basics I very quickly found my feet and the C knowledge I had from years ago seemed to just come back to me.  The same was true, when after 10 years, I found myself writing a bit of VB again (yes I know!) – it all came back pretty quickly, I was actually quite pleased with my output*.
• You don’t have to be the Guru on day 1 – frankly, I don’t think I ever was the Guru anyway!

This has been a real eye opener for me – it’s good because it reminds me of the reasons I got into this business in the first place.  Understanding code, solving problems, working out how a bit of code works and making it do what I want is gratifying – and it’s a skill you never loose, no matter how long you’ve been out of it!  So get stuck in – you just might enjoy it!

* I know many developers turn their noses up at VB and I know it generally doesn’t have much of a place in modern development – but I think I’ll always have a fondness for BASIC.  Especially VB, I think because it’s where I started out, but also because you could build simple apps so quickly – a great way to learn… sorry!

It’s a cold December evening – but in amongst the black timbered buildings of the ancient city of Worcester, a sight that will warm your cockles!  There is the bright light and heart warming sound of a steam powered carousel, there is the steaming smell of mulled wine and the hustle and bustle of folks looking for that unusual gift for Christmas.  The market stalls are covered in trinkets and the proprietors are wrapped up in top hats and woolly scarves. It is a scene I never tire of!

We go every year – not least to pick up our waxed cheeses and hot nuts (sorry I can’t say it without it sounding like a euphemism)… it’s great for the city and a great atmosphere for the lead up to Christmas.

I can only apologise for the cheesey sentimentality – but I’d love to encourage anyone reading this to come to Worcester on first week of December and share in the festivities… if you spot me from my photo, I’ll buy you a mulled wine! See you there…?

Is it a coincidence that you appeared to have learned the word “No” in the last week or two and now won’t do as you’re told?  Terrible two’s here we come… it can’t be that bad?  Can it?

As a UI developer I wanted talk about the state of the Web when it comes to standards development.  I have become increasingly aware of the importance of the MVC over the years – but there seems to be a shift to breaking that out even further at the UI level.  Content/Style/Behaviour.

So we understand the need for MVC we have our Model – the DB, we have our controller in the middle tier – this is the mediator between the user and the data (the business logic) and the View – the interface for your system to the user.  When you develop on the iPhone you see this broken down in the UI a stage further with view controllers, interface elements and the model which could be a webservice utility.  And in the world of web development we see that applied in the UI too…

The internet is about accessibility – it should be available to anyone, anywhere.  With the advent of the internet on the phone, be it a smart phone or otherwise, there are a plethora of browsers, screens and processing capabilities – nothing should be assumed.  With this in mind your content should always be accessible to anyone who wants to consume it – at this stage the style should be irrelevant, a smartphone may be better suited to a different style, than a netbook… or even from a traditional WAP lightweight view.  So the first step is to seperate out the style from the content – style sheets should obviously be used, but they should do more than colour your fonts or set border widths.  A stylesheet should be targeted to the destination platform (i.e. one for mobile, one for full fat browser etc.) – of the browser is non- standard, too old etc. then a sensible linear layout is what you should be showing to the user.  It should be responsible for your layout too – this is often missed.

Next is the behaviour – not all browsers support JavaScript, some will have it turned off.  Never assume that JavaScript will be there for you – a common mistake is to let JavaScript do the validation for you – no, no and thrice no!   By all means offer JavaScript validation to enhance the users experience – but never more than that.  You might have a funky bit of Ajax and JQuery for submitting some data dynamically – but you will need to make provision for those that don’t have the capability – this is often/nearly always forgotten.

So what is the standard to use?  Well I probably want to talk a little more on HTML5 and XHTML in another blog – but opting for a standard to validate against is a good idea – it’s always worth checking around the web to see who does/doesn’t – you might be suprised!  This is only half the battle though – the key is to think about and design your websites with good practice in mind (seems obvious to write this really) – but in a world where I see copious business logic and code accessing databases up in the JSP’s we still have a long way to go people…!  And yes I’ve been guilty of these sins in the past…  I have lots to say on this subject, be afraid… more to follow!

From 1999 onwards the relentless march of technology would continue and my interest would continue to be piqued.  But the shift in the industry and in my interest was very much away from the PC thick clients (most of the PC’s I built were pretty thick). In 1999 I was still writing desktop applications – like it was erm’… 1999.  Of course living in the constant fear of the millennium bug – I wasn’t scared were you?  People say it was a dud – but I can’t help feeling that if we hadn’t prepared it could have been worse – a dud was perhaps a good outcome… of course history won’t judge it that way!

But in 2000 I got my first foray into web development – ASP.  This was amazing, I could link my web pages to a database back end and display dynamic content… wow!  And not wishing to blow ones own trumpet, but with the assistance of my awesome graphics designer friend we produced some damn fine apps…

My days of Windows for everything were mostly behind me… I made the mistake of installing Windows ME on my ailing Duron 800 (still got the same soundcard and floppy drive as that old SX25 – so technically still the same machine)… the early versions of Windows XP were flaky at best too… I’d had enough and Apple had just brought out the iMac G4 – still the best bit of engineered hardware I think I’ve ever owned (sorry laptop, you’re just not as nice to look at!)… I made the leap, with an extra £200 chucked in for a copy of Virtual PC (just in case) – which I rarely used.  Mac OSX was a breath of fresh air and as someone interested in UI, this was the way forward.

As for gaming, I had bought a PS2 – I finally saw the benefit of the console for gaming – not least cos I owned a Mac now and there weren’t many games for it back then!  It was kind of sad that games development now seemed have escaped the hobby programmer – games like GTA cost millions to make… oh yeah GTA, how could I forget you?  GTAIII came out and I was hooked – much to my wife’s displeasure (and with a 2 year old in the house, my opportunities to play games like this are somewhat reduced!) – this would easily be my game of the decade though…

It’s difficult to talk about my software focus to much, because over these last 10 years I have been working in software development – there is way too much to write here and I’m sure it’s not that interesting to many!   A lot of the topics that I’ll write about in my blog such as Mobile development, processes, technology, platforms etc. are all from my experience throughout this decade so I’d be repeating myself! Also this was an opportunity for me to reminisce about days gone by and my early experiences of computing and software – 2000-2009 wasn’t long enough ago for me to remember it all through sepia toned glasses yet (or should that Cyan/Magenta glasses?).  So I’m probably going to leave this series of blogs and get on with something that you might actually want to read!

But before I finish this trip down memory lane, one piece of advice… if you feel like taking the same journey and you fancy digging out a game from the 80′s that you remember fondly – DON’T DO IT.  Just remember it fondly, if you play it – you will realise that by today’s standards it will absolutely suck (to use an americanism)! Love it – don’t play it…!  Thanks for reading!

Over the years it’s been clear to me that one of the areas that has seen the most attention in the field of software development is the area of practice and process.  For the uninitiated, this can send a shiver down one’s spine!  But it shouldn’t be scary – I take this mantra with me whenever I talk about process – remember this and you’ll be good:

“The process works for you, if you become slave to the process – the process has failed”

A software process is not about box ticking, it’s about making your development easier – it’s about giving confidence to the powers that be, that you can deliver (on time, with the right product, at the right level of quality).  And most importantly it’s about having that confidence yourself, that you can deliver…

So what process should you choose – well this where it might be controversial – I don’t think there is a right process for anyone.  I’ve seen them and heard them and used many of them – by the book and off the cuff…  some more famous than others – from RUP to EUP, from RAD to Agile, from Waterfall to DSDM (I bet only a few of you have heard of that one!) – I’m certainly not here to advise on any of these – but I can tell you what I’ve learnt…

In the beginning we wrote code – and it was good. As programmers, we loved getting stuck in: you tell us what you want and we’ll write it – every now and again we’ll show you what we’re doing (if you’re lucky). Except it wasn’t good – estimates were unwieldy and feared, tasking/planning was impossible, code was unsupportable and unreliable.

On the second day came Waterfall – and it was better. This is what you learnt at Uni – the importance of requirements and design.  One thing flows into the next.  You don’t write a design doc until the requirements are finalised and signed off, you don’t write a line of code until the design is complete.  Sure you could revisit the design or the requirements (that’s what DSDM tried to bring)… but why would you, it’s signed off? – what the customer gets, is their own look out, because they signed off the requirements.  How could they be unhappy?  Well they were unhappy – because actually, it wasn’t what they wanted and your interpretation was different from theirs, and actually since the requirements were written things have changed – because it’s been such a long time!  Yet in my experience, as flawed as Waterfall is, it is still prevalent across the industry – I think that it represents a favourite for management (Waterfall is deemed a nice fit for PRINCE2) – often more “Agile”processes are deemed chaotic and unmanageable, this is usually because they aren’t really Agile they are more like the first day of development returned with a new name!  Waterfall appears predictable on the face of it and is used as a stick to beat the customer with – the reality is that Waterfall doesn’t usually work, and often the stick is used to beat the developers with!  There are times when Waterfall is appropriate (in small doses) – Safety Critical, is an example of this – the design and the requirements often need to be absolutely crystal before work can continue – but even in this case, there is room for maneuver with some aspects of Agile being appropriate.

On the third day, there were the Unified Processes – RUP, EUP, OpenUP – this is surely better.  Yes, this is better.  But here comes another one of my cautions – back in 2003 we decided that RUP was the answer to our prayers… it came with a nice set of documents, it came with a set of phases telling us what we should be doing (and requirements were still happening during development – nice!), we got training out of it, we all got a funky sounded job role and we used the word Artifact for the first time!  But the mistake we made was to swallow the RUP book whole… we were doomed!  There is a lot of process in RUP and a lot of Artifacts.  RUP itself, warns not to take the whole process, just the bits you need – but for some reason human nature prevailed and we took the lot (I see it time and time again with PRINCE2, ITIL, CMMi, <insert process here>).  RUP is a great process to start from – large, distributed projects benefit for this and deliver successfully against it.  If you’re a small team, this may be heavyweight for you – but I have taken a couple of things from RUP such as the Vision Document and the Architectural Design Doc. as well the phases

On the fourth day came the Agile processes – Scrumm, Agile and XP.  These are the industry favourites at the moment.  I really believe that these processes are here to stay – they reflect the way that software should be developed.  Other engineering disciplines are different and it is difficult to compare software to building bridges – so it needs a different approach.  Human beings are fickle and they change their minds – so Agile supports this. Every software build is like building that bridge for the very first time – every software project is different, sometimes this means that the requirement or design element you dreamed up last week doesn’t actually make sense when you cut the code – it doesn’t matter how much upfront design you do, this will always be the case (one of the reasons why I don’t like round trip engineering – but that’s for another blog).  The ability to be able to define, change and discard requirements throughout the development process is essential.  Agile (I use the word agile to represent any of the Agile based processes) comes with a warning sticker though – drop your guard on management at your peril.  If anything, Agile processes require more management than Waterfall – the beauty, is that the bulk of the management is propagated to the whole team.  If Agile is not managed – it is chaos, and you might as well dig out your Waterfall notes from that lecture way back when, because you’ll get more success from that than you will from a crazy Agile process (which isn’t agile or a process any more!) – pick good tools to help you, especially ones the team like and you’ll find this is easy!  We use the Atlassian tools here as a complete solution, but I’ve used/seen FogBugz, Mylyn, even Bugzilla used with great success.

On the fifth day we threw the process books in the bin and we did it our way – that’s the ticket!  Now you’ve got it – the most successful projects I’ve worked on over the years have not had a label for the process.  Every project is different, every team is different, every culture is different.  There are elements of all processes that work best – easily the most successful project (from a software development process POV) used elements of RUP, Agile and even waterfall – we defined the team structure, the SCM strategy, the testing strategy. One of my favourite elements was that we used the same person who managed the requirements to manage the test bench and testing strategy… that really focuses the mind to follow the requirements and question them.  Even our requirements documents were a mixture of UML Use Cases and old fashioned structured requirements – it’s what worked for us.  When we felt the timeboxes were too short, we made them longer – we used postcards to plan the tasks, and then FogBugz to disseminate them… we used continuous integration for the first time.

This was how it was going to be forever?  Wasn’t it?  Well 5 years on I still battle to persuade people that this might be the way to go… and I still make the niave assumption (I’m not afraid to admit I still have a lot to learn!), that the process that worked on that project will work anywhere – of course, for all of the reasons listed above – it’s about tailoring and cherry picking the best bits.

So on the sixth day and the seventh day – we rested.  Well it was the weekend by then and our process was so good we didn’t need to do any overtime.  Pint anyone?