Real World Agile

This weekend I had a problem to solve and when thinking about it, I thought how I would solve the issue as if it were a software problem as it raises some interesting points about being agile and how people get it wrong.

The Problem

We had a broken door handle on our bathroom, which has been irritating us for some time. We decided to remove it the other week and replace it but were left with a slight issue. When we removed the latch from the door we found it was round, whereas the new one was rectangular, it looked like this:


We realised at this point that we needed to shave away some of the door so we put off the job for another weekend, which meant we had no handle or lock on our bathroom door, not a major issue but annoying.

This Saturday my wife decided she was fed up with the door so decided to shave the wood away and put the latch in, which after much noise and swearing she achieved. This was great but now presented us with a much more pressing and imminent problem, which was that we had a baby sitter arriving shortly and we couldn’t leave the door in this state as she could potentially end up locked in the bathroom with no handle and then who knows what might happen!



Here we were left with a typical problem not unlike one you would be presented with in a software development scenario. We really needed to have a handle on the bathroom door, and needed it ASAP but simply didn’t have the time to complete the job 100%, so what to do?

After some discussion,  and much the my wife’s displeasure, we decided to put the handles on both sides and as many screws as we could do in time. This would mean the handle was functional and worked so it could be used. She would have much preferred that I 100% completed a handle on one side before starting the other but as it turned out we only managed to get 4 screws in during the time we had, so only one handle would have been done, leaving the door unusable.

What we actually ended up with was a solution that still needed some work, but solved the immediate problem.


Technical Debt

Now some people may argue that by only putting in 4 out of 8 screws we accumulated technical debt. I personally don’t believe this is true, this wasn’t really debt, what we had done is complete a first iteration. It may have been that someone (my wife most likely) had decided they didn’t like the handles and wanted different ones for example and in this scenario we would only have 4 screws to remove rather than 8. This is the point of getting the least done before getting the product in front of your end users, providing that it works as it ought to, but with potential for more gold plating at a later date.

Technical debt for me would have been one of the following:

  • Not putting the handles on and leaving the bolt through the middle. This would have worked and really could have been the bear minimum but would also have been really prone to breaking and would require immediate extra work to fix it.
  • Super gluing the handles on. This would have been fast to implement and would have solved the problem but would have resulted in extra work being done to remove the handles and then refit them properly at a later date.
  • Putting some sort of easier fitting handle or knob on, which would have needed to be removed at some point to be replaced by the real handles.

The reason why I consider these all debt as they require extra work or risk that wouldn’t have been necessary if the work was done to an acceptable standard in the first place.

Why such a strange blog post?

So why post this at all? Well the reason why is because so many teams don’t understand being agile. I’ve seen people who would happily have just put a handle on one side of the door, or super glued the handles, or even just left the bolt in the door and all these solutions are a bad idea. It’s important to prioritise what needs to be done first, and how that can be done to a standard where it can actually be given to the interested parties to try it out, without investing extra time in polishing something that isn’t a requirement yet.

You could also argue we shouldn’t have put the latch in the door just before going to dinner, but I’m sure you’ve all seen developers start a piece of work or bring in some framework or product to solve a problem when it isn’t really required at that time, creating a false priority that needs to be actioned, I’ll blog about that another day.


Scrum Pros and Cons

I’ve been working with agile and Scrum for some time now and much as in some ways I like it I also feel there are issues with the process, so thought I’d put them here as a discussion point.



Quick feedback loop with customer/product owner Requirements are only as good as the backlog
Changes can be made with less overhead Stifles innovation and creativity
Functionality only delivered when required People are not interchangeable resources
Pointing stories and using velocity of team is more effective than traditional estimating Overall Architecture and UX are better being thought about up front
Technical debt can be regularly tackled Requires highly skilled and disciplined team members
CI builds and automated testing should help prevent bugs Regular interaction and demos with the customer or product owner is essential
Planning sessions and refinement mean the whole team understand the problem domain Lots of time spent in meetings
Pairing is a good way to learn new skills and prevent errors  
With a decent backlog, and pointed stories it should be possible to pin point realistic delivery dates for features  
Well defined stories should mean less time spent coding the wrong thing  

Agile development is still preferable to many other processes. In the past I have seen development done in a number of ways that didn’t work, Chaos Driven (“Everything is high priority and needs doing yesterday”), Loudest Voice Driven (“I’m the boss and I want x now!”) and Victorian Waterfall (“You can’t leave until it’s all done”). Agile or Scrum is preferable to all of these.

That said I feel there must be a better way to tap into peoples motivation and inspire them in ways that Scrum seems to restrict. I’d like a process where the customer interaction and quick feedback loop could still exist, along with quality testing, but with more focus on the teams responsibility to push the envelope and develop fantastic solutions to problems.

Krypton Tuesday

I’ve recently signed up for a Kryton Tuesday course, which the extremely pro-active @Sparklypips is organising at our work. So far I have been going through the material for the first course, ‘Go: How to Overcome Fear, Pick Yourself, & Start a Project that Matters’ by Seth Godin which I have already found really inspirational.

Failure is something I worry about everyday. I worry about whether the code I write is tidy enough, whether it’s clever enough and whether it will be accepted by my peers. I worry that I might not make the deadline, that maybe I underestimated the complexity or worst of all that someone will discover that I’m a phony.

My biggest failure though is the failure to ever start anything. I have notepads where I scrawl ideas, I take time to think about things I could make, but I never do. I always have an excuse, I don’t have time, it won’t be profitable, I don’t have the right tools, or people will point and laugh at my stupidity.

Doing this course has already made me think about how to improve this, and how I can make something without the fear, how I can really try and do something that I both enjoy and that may help others. I’m determined to make something, and if it ‘fails’ then that’s fine, I’ll use the experience to make help shape the next idea. If that fails too then I’ll try again, but most of all I’ll try and enjoy the process, learning’s and freedom. I think that will help me overcome my fears.

Wielding the power of Excel

I was reading this article on the BBC about Excel today, which made gave me some ideas about a post. There is no doubt Excel is a powerful tool (other spread sheet software is available!) but unfortunately it is often misused, or used in error.

Firstly anyone has used it will know how easy it is to make a mistake. Its easy to construct a bad formula or worse one that returns an error. I joked on twitter earlier about unit testing spread sheets but as far as I’m aware this isn’t possible or doesn’t happen. This means that potentially important business decisions can be made with poorly tested calculations, the effects could be disastrous.

Worse though is that while data lives in a spread sheet on someone’s hard drive its not available for others to use. The same is true of Access databases, which potentially live on single machines, where the data is not organised or shared in anyway that is useful to other people in the business.

As I am currently interested in data analysis its a real shame to think that potentially useful data is languishing on employees hard drives. It would be great if instead of storing data in this way that Excel users were accessing a data store, a warehouse for example, where they could use a product like PowerPivot to show visualisations, but without the need to store the data locally. That said in this day and age I still think that is not a particularly common scenario. The data needs to  be easily available to Excel users, in a way that makes logical sense, so that it can be manipulated without having to always go through IT.

While this is a long way from Big Data, I think this is one of the first steps a business can make to become more data aware. To link a companies systems, like CRM’s, sales data, website stats, HR information and accounting, would begin to empower a business to look at details that really matter, like when are the busiest periods, who are the most likely customers, and how much services cost to implement. I’m sure it would be possible in any business to see interesting patterns, and to surface facts that no one was aware of.

Finally I noticed that its Big Data Week starting tomorrow, which includes a day in London on the 25th April. I’d like to have made it along as some of the topics sound great, but doubt I will be able to.

Adventures in Big Data–a Prelude

I like many people have become interested in Big Data recently. At the moment it is just an interest, it doesn’t really come into my day job so its just something I’ve been investigating and researching in my spare time, but for me its very early days. These are mainly notes for myself, to remind what I’m planning to look at and read, but may well help someone starting out on the same journey.


The first thing I decided to do was look up some good old fashioned books. The ones that have looked into so far are the following:

Big Data Now: Current Perspectives from O’Reilly Radar – This book is simply a collection of articles but so far that has been a strength for me as its allowed me to dip into all sorts of areas, it seems a nice starting point. At least I now know what Hadoop, MapReduce, Pig and various other terms mean.

Big Data: A Revolution That Will Transform How We Live, Work and Think – I confess that I haven’t read this yet, but it at least sounds interesting in principle and I hope to get some good ideas from it.

Data Science Starter Kit – I’ve been recommended this but haven’t picked it up as yet, I will probably move onto that when I understand some of the basic concepts and decide how I plan to do some experimenting.

Big Data from Manning – This isn’t in print until later this year but I’m quite keen to get hold of it as it sounds like it has some decent information, and I tend to like Manning books.


One thing I’ve found so far is that there is very little based on Windows, nearly everything I have read is about Unix as the OS, so it looks like I might have to get my hands dirty with that, plus I may have to look into Ruby and Python as languages to start out with, or even return to doing some command line scripts or Perl to get going.

The one Microsoft offering I have seen is HDInsight, which essentially appears to be Hadoop on Azure, Microsoft’s Cloud Service. I’ve done a little work with Azure in the past so will certainly look into this to see how usable it is for me, and what kind of samples I can create.

Hopefully I’ll update my blog regularly when I find interesting articles, or if I roll up some sort of test or code.

Starting the Game

This probably ought to have been my first post, but better late than never. One of the hardest parts of being a software developer is getting your first gig, every company seems to want x number of years experience, plus a long list of technologies that you have used, which can be really daunting. It seems especially hard these days, what with companies cutting back during these austerity years, but there are opportunities, you just need to be prepared for them, so here are some tips that I have learnt over the years.

Get coding – The best thing to do if you want to be a developer is to write code. Write things for yourself, do samples, maybe even join an open source project. The more code you write and also read the higher chance you will have of improving your skills.

Be ready for interviews – Interviews for software developers will vary but generally they will expect you to have an understanding of the technology/language that the company is currently using, which could involve you having to take tests, writing code or pseudo-code on a white board, drawing diagrams etc. They will always expect you to talk about your experiences though and this is your chance to show how much you have learnt about development, how you find and resolve bugs, how to deal with customer requests, what to do when it looks like you can’t meet a deadline.

Read up on the company – I know this goes without saying but its really important to try and understand what the company you are applying to is trying to achieve, what sort of problems they are trying to solve and how they interact with their customers. If nothing else looking at their website will give you an idea if its the type of place you want to work.

Don’t be a smartarse – Developers as a rule are know it all’s. They all know better than the guy before and will do a better job than the current staff but whilst its good to be enthusiastic, and show you have great ideas, you don’t want to berate the people interviewing you.

Learn to communicate – I believe that the most important skill for a developer these days, especially in an agile environment is communication. You might be the best coder in the world but if you can’t pass your ideas onto your teammates, can’t understand a customers requirements, or don’t know how to ask for advice then you will have a hard time progressing in your career. Its far easier to teach someone to code than to teach them to be a decent team fit.

Try and understand users – Users aren’t that weird or complicated, they are just normal people like you and me. We are all users of systems, so try and think about the things that you like when you are on a site, or what you find really grating. Understanding this will put you at a real advantage when looking to develop software that people will actually want to use.

Lower your expectations – This may sound defeatist but sometimes its best to accept that your first job may not be at some blue chip company, doing full time development, earning a great wage with all the benefits that go with it. It may be that you have to start in a support role, learning to understand customer requirements and problems, or that you have to do some freelancing for friends to get some experience. None of this is bad though, it will help to drive you on to achieve what you want, plus give you an invaluable insight to how software development works in the real world.

I hope this is at least a bit helpful to someone, software development can be a really rewarding career so if you want to pursue it then you need to get out there and get doing it for real.

Where to start levelling up your skills?

Well I haven’t updated this blog for nearly a year and thought it was about time. To start with though I thought I would write a post about some of the things that have helped me on my path, some thoughts, ideas and links to blogs that are worth reading.

My first port of call would be to check out Scott Hanselman. He writes a decent and interesting blog, which I don’t find hard work like some of the others. His podcast is great too, so I suggest trying that out, and he also appears on one of my favourite podcasts, This Developers Life. I like that podcast because its more about the developers themselves and their thoughts, what makes them tick, its really insightful and interesting.

Another blog that talks more about the process of development rather than the tech itself is Coding Horror, written by Jeff Atwood of stackoverflow fame. Stackoverflow should really be any developers first point of call for questions and investigating problems, I suggest one of the first things you should do is get an account and get involved.

For learning both tekpub and pluralsight seem to be good options, I’ve seen some of the tekpub videos and they certainly help to show you good concepts and techniques. There are also decent videos available on dnrtv which can be watched for free.

There are many other blogs that are worth checking out, for starters try Jon Skeet, Phil Haack, Scott Gu, Martin Fowler, they should all have at least something worth reading.

Events wise in the UK its worth checking out NxtGenUG which is a user group with a number of locations who have decent speakers, or the DDD days which are held throughout the year, if you can get in that is.

Finally I’ll leave you with some of the thoughts that have been passed onto me over the years but people wiser than myself:

  • Other peoples code often looks more complicated than it is, its hard to put yourself in their position when they wrote it but you can understand it, you just need to be methodical
  • The most obvious solution to a problem is often the right one
  • Making the code readable is far more important than showing your off your technical prowess or showboating

Good luck out there with your development career, its a great trade to be in with exciting prospects, but it will require hard work and dedication!

My new software development blog

I thought that it was finally time to do some blogging about what I have been doing development wise recently and as I had been pretty lax about posting content on my other blog I though I’d start a new one. This one will now be focused on information related to software development, whereas the other will be about video games and other things I get up to.

It was quite hard to think of a name for this blog and in the end I went for Level 1 Developer, as that’s how I often feel, like I’m starting at the bottom of some new technology and trying to get my head round it. In the last couple of years I have had to learn about ASP.NET MVC, BizTalk, SharePoint and InfoPath, plus various other techniques and best practices. Its not a bad thing though, its great to learn new skills and broaden my repertoire.

Hopefully someone will find something useful here, I’d like to be able to help some people with issues as so many others have helped me.