My thought’s on Programming Languages

I’m very much a believer in using the right tool for the job, a hammer is great tool for putting a nail in a wall, but it’s not so useful when putting a screw in a wall, most people change tools and pick up a screwdriver.

So what the hell do I mean by this we’ll often development team / departments use one tool (or programming language) the given language has its sweet spot but overtime with the advancement of the technology the teams have used the same language (tool) for different types of jobs which are often outside the programming languages sweet spot. There are many reason this happens, it can be laziness, fear of change etc.

If we consider programming languages like my toolbox in the garage I don’t just have a in hammer my toolbox, I have screwdrivers a drill set etc. Everyone of the tools in the toolbox has a different sweet spot and that’s why every good developer has multiple programming languages in their toolbox.

They know the sweet spots for each language and through real life experiences and trail and error they know which programming language solves a given problem best, really good developer/programmers out there know along with the above that the platforms they build there software to work on are changing all the time old assumption are being rewritten everyday!

So keep learning, keep trailing, keep making mistakes. Make sure you learn from not just your own mistakes but others too, it’s the fastest way to learn from my experiences, but what do I know, I make mistakes all the time!

Tagged , ,

Quality what’s that got to do with “Software Craftsmanship”

Last week I was in a meeting, were we trying to come up with idea’s to improve quality within the development teams. We weren’t necessarily trying to figure out how to improve quality ourself we wanted to encourage the individuals and teams as whole to promote quality.

One concept that came to in focus was that of Software Craftsmanship

“Software craftsmanship is an approach to software development that emphasizes the coding skills of the software developers themselves. It is a response by software developers to the perceived ills of the mainstream software industry, including the prioritization of financial concerns over developer accountability.”

Now you might be aware of the blog post Dan North posted last year on how “Programming is not a craft”

It’s a brilliant read Dan mentions the Software Craftsmanship Manifesto

And makes some very good points to improve it that I agree with, I got into programming to solve problems that’s why I program and continue to enjoy doing so. I like to be able to look back at the end of the day and see that I’ve added value I hate it when something goes wrong in the live environment because of release I’ve made it really annoy’s me.

Often when an issue like this happens I do some analysis and find it’s something I’ve not thought about or couldn’t have been replicated because of an issue with the test environment. Now a “day jobber” will probably just forget about it and carry on as if nothing has happened putting it down to a fluke or anomaly but not a professional (master craftsman).

A professional or master craftsman would work to understand the root course of the issue then fix it. The people that stand out from the crowd the “Software Craftsmen” not only find away to help improve the productivity of a team or help reduce the technical complexity of a product they deliver business value at the same time I’ve worked with people like this there aren’t as many of them out there as you might think you’ll find them mixed in with the “day jobbers”.

How do you identify your “master craftsmen” and your potential “craftsmen” well if you know what your looking for there easy to spot!


Go Radiator / Books / Presentations and Manchester Limited WIP

It’s been a while since I last posted a blog. So I thought I’d give you an update on what I’ve been up to over the last few months! It’s been a really busy time for me.

I’m currently working on a large project in work (probably not that large to very one but to me it is!). I started off as being one of the Tech Lead looking after one of the new technology areas (for which there are 6 or 7 we’ve had to pick over the last 6 months) and overseeing our continuous delivery / technical testing approach using tools like ThoughtWorks GO, Ruby Cucumber and Grinder (I do need to learn more about this one!). It’s been a challenge but one I’ve enjoyed.

But for the last month or so I’ve moved to more of a Iteration Manager/Delivery Manager (what ever your company calls it) role. It’s been something I’ve know I want to do for a long time and I’ve been building my soft skills up to do this role especially over the last 18 months so.

The challenges I’ve faced here have been just as interesting as the coding ones I’m used too (this is where I’m lying a bit I’ve been sticking my ore in management task/area’s for a long time persuading my bosses to try something new, managing the team incidents or small change tasks and organising a weekly continuous delivery huddle to improve cross team collaboration with the aim of continuously improving delivery process and techniques to name but a few!) but never the less these new challenges have made me question my beliefs and understanding in a good way.

The skills that are getting me through (other than blind faith lol) is influencing and coaching skills I’ve been reading a book recommended to me by my old boss Steve Briggs “The Leader’s Guide to INFLUENCE” it’s about £8 on amazon it brilliant it’s making me work on skills I had already but refining them and making best use of them. Because now my main role isn’t to program/build software it’s to program/build teams, I mean that in a loose sense I’m not here to manipulate the team just help them see ways to improve or help solve issues with external parties within or outside the company. Another book I’ve been recommended but I’ve only just started reading in Influencer but it’s been recommend by “Mike Burrows” who I sore speak at Limited WIP Manchester the a few months back.

There’s been so many good video’s and blog’s I’ve read over the last few months I just can’t remember or list them all but here’s a few links its worth checking out:
CoffeScript – looks really promising something I want to learn this year!
HTML5 performance working group but the best part of this video is about how website performance has been linked directly to revenue, plus you can make massive hardware savings but don’t take my word for it watch the video
David J Anderson (Mr Kanban) this presentation is must watch for any agile/lean project manager

Finally I wanted to tell the work about my new GO Radiator project. It’s very simple Roy Morgan wrote a .Net app to read the CCTray out put form GO which works brilliantly but! and there is a but it’s design gives some short coming firstly because it’s a windows app every monitor that we want to display a GO Radiator on has to have computer and GO login account associated with it. The way you add pipelines to display isn’t brilliant and can get difficult to manage so I started the new Ruby / Sinatra / Haml version to solve some of these problem and move the idea forward.

In summary the new architecture is very simple there’s a Sinatra web service that can return JSON or a HTML view of the pipelines. The login code is separate and I’m thinking of making that a separate project or even Gem. Now this is about as fare as I’ve got at the moment. The next feature that need to be implemented are:
– Error handling on Ajax requests
– Build breaker name
– Profile creation (e.g. profile a has pipelines a, c and f to display)
– GO Error display
– ….

Here’s the code if anybody wants to help feel free to fork it.

Estimating in the agile world!

I’ve read this article by Dan North – the perils of estimation

With this question in mind “how do you plan in agile (or kanban)”

Up to now we’ve been using stories which are great for say 2 week planning but not for 1 month or 3 month planning, or you end up in the situation that Dan describes in his article above I’ve been there, I’m there now as well it’s a waste the estimate are worth the paper their written on!

So I’ve found a few things that might help and I’m going to try them out over the next few months and see:

The first idea/tool is Effect Maps – high level business value planning

Second, Deliberate Discovery (discussed in Dan North’s article above and in more detail here)

Third, estimate at the epic level using a good estimation process and alway give three point estimates:

  • best case
  • most likely
  • worst case

don’t be afraid to write down assumptions either if they change then your estimate becomes invalid and only let all three of your estimates be published be aware if someone just takes the best case!

Moving from NAnt to Rake….

On the new project in work the team took a decision to move from NAnt to Rake,  we’d got to a very mature state with our NAnt Build/Deployment scripts but we were finding it difficult to do more programmatic tasks e.g. for loops! This prompted our move to Rake as we could then write pure Ruby when needed, hopefully get more reuse from already existing gems and our code!

So how did the move go?

Very well thanks!

  • Its much easier than writing NAnt and using RubyMine as our IDE helps a lot.
  • We’ve bin following the best practice we learnt from our NAnt scripts, in most cases implementing the simple task is much the same but Rake/Ruby make the complex tasks much easier to write and maintain
  • Rake gives more scope around deployments there’s tools like Chef and Puppet which use Ruby, I’m excited to see were we go in this space.

Gems we used:

  • albacore
  • win32console
  • term-ansicolor
  • ruby-zip

We’ve written four helper classes:

  • template.rb – used to wrap erb
  • file.rb – extend the Ruby file class so that the expand_path method works for windows

def self.expand_path_windows(file_name)

  • iis.rb – used to wrap the appcmd calls for iis there is a ruby gem out there call inetmgr
  • robocopy.rb – this is the article we followed to create our class here

In the long run were going to try and write our own gems and release them for anything we’ve done we can’t find a gem for already we’ll see how it goes!

Is Architecture difficult or do we make it difficult?

I’ve been moved on to a new team in work to look a building a new platform for the company which by all accounts will be all singing and all dancing! (try not to laugh!). Just to make thing more interesting we’ve got 4+ new piece of technology to use as well e.g. CMS, CRM.

Today I was in a meeting for 4 hours were we where trying to get to grips with just part of the architecture! We did make some head way but I can’t help but feeling like were doing it all wrong maybe it the agile bug or just plain old common scenes that’s telling me were biting off more than we can chew!

I know what I want do, solve one business problem at time and refactor the applications into the new architecture bit by bit adding value at every stage, I don’t think are current systems are that far away from what we really need there’s lots of refactoring to do but we would add more value than trying to do the big bang approach where currently taking which we’ve tried unsuccessfully in the past! This is a brilliant presentation that gives a good overview of the approach I’m talking about and emphasize  good eXtreme Programming practices and what I do believe is the most important thing for every delivery team good communication

Continous Delivery Video

We’ve produced this video at work around Continuous Delivery and GO Agile Release Management

What is Continuous Delivery and why do we need it?

In this post I’m probably not going to answer the question above in great detail because I think Continuous Delivery is too big a subject to answered properly in one blog post, Jez Humble and David Farley had to write book on it! (Continuous Delivery: Reliable software releases through build, test and deployment automation) which I recommend and would use a reference manual.

We’ve currently started to use GO Agile Release Management (I recommend that tool) we’ve also been automating are delivery process though to the live environment, this has started to be rolled out though all the delivery teams.

So what sparked me to write this blog post? A conversation I had a work where someone stated that we’d probably got our 80% gain for 20% effort done out of Continuous Delivery! I can understand why they said this remark there a manager!

What’s worrying is there seems to be a growing number of people who associate Continuous Delivery with just automating your CI and release pipelines, in my option its a mind set its about going on a journey to improve your productivity, reducing your cycle time, helping your customers achieve their goals.

To achieve this you will need to do more than just automate your CI and deployment pipelines (although this is a good start!) you might want to remove the waste involved in branching by employing branching within code this involves careful release management with your product owner(s), understanding your backlog and the business goal/direction. Moving to a no defect culture within your delivery teams is another good step, but this should all be focused on providing a better service to the business you can do this by asking them “what they want?”.

I could go on but I’m worried all I’m doing is rambling!

So in summary the main point I’m trying to get across is that Continuous Delivery is a journey there isn’t an end point,  some of us will go further or move more quickly along that journey than others but as long as you realise its a journey not a race your in the right mind set to succeed and always focus on helping your customer achieve there goals.

Three books that are a must read as a developer?

A question was asked in work the other week “Three books that are a must read as a developer?” there where lots of good replies from different people within the team.

My response was basis on build a good foundation which is language agnostic and provide a good resource for later. The books are as follows and I recommend you read them in this order as well:

1) Head First Object-Oriented Analysis and Design

2) Clean Code: A Handbook of Agile Software Craftsmanship

3) The Art of Agile Development

Reading these books and putting the knowledge you gain from them into practice should start you on the journey to becoming a Master (Do you ever really get there?) software craftsman.


I recommend starting a book club not just to read these books but others that you come across its a great way to force yourself to keep going and get other people perspective on what the author is saying.

Cultural change is free – John Seddon

I’ve just watch this video by John Seddon on  System Thinking. It’s not the first time I’ve seen one of John’s videos on System Thinking, but watching it go me thinking about some issues I been facing in work, both of which are around resourcing! The answer is to improve the skill set of the team, in this case we need more testers so instead of dev’s picking more work up why don’t you move them on to testing a story and get live (obviously not a story they worked on!).

How to solve the problem long term, look at the demand from the business, analyse what is the most common demand and work at improving the process around that type of demand e.g. bring in automated testing this can vastly reduce the work load of QA and allow them to focus on automation of other task within the testing area or do more exploratory testing which future reduces issues in live which reduces failure demand which increase value demand thought the system.