Random Software Development & Climbing Thoughts

Test Clean-Up

2012-11-02T08:31:00.005Z

I've recently had a massive clean up of dependencies between our Core solution, tests & everything else that comes to mind.

During this time I noticed a number of tests which fell in to the following categories:

WTF? Are they testing!

They've been in our test suite & build server for a long time in there current guise. The first set are similar to:

[Test]

public void BuildMeAPanda()

{

var panda = new Panda("Chi Chi");

Assert.That("Chi Chi", panda.Name);

}

As you can see we are simply testing the logic of a constructor. Not too much value in this. Although it looks good on our code coverage stats!!!

[Ignored]

The second are ignored tests which seem to have been written with a future intend - i.e:

[Test, Ignore("Really need to work out how to test this!")]

public void InteractWithDb()

{

var panda = new Panda();

var repo = new PandaRepository();

repo.Save(panda);

// work out what to do here!

}

Broken & [Ignored]

The third are the they broke the build, I must get the build in, quickly ignore the test ones:

[Test, Ignore("This breaks the build I'll re-instate it later")]

public void Bug52358()

{

// Arrange

... Lots of code

// Act

... Some more code

// Assert

... Some assertion

}

My view on these tests is to eradicate them. If they've not been in your build cycle for some time then they are not adding any value. They are simply adding overhead to your build time, your thoughts and general clunk within your solution.

I would also try to re-instate the Broken but ignored tests, however, if they fail and you can't understand them within a time boxed amount of time delete them...

The only occurrence that I've not done this - is on those integration tests where you use them occasionally - a prime example of this is testing email & sms sends. However, these should appear in a different project called:

.IntegrationTests

They should be clearly labelled with:

[Ignore("Integration tests!")]

And over time you probably want to delete these too!?!

Why is Agile/Lean so tough?

2012-02-07T09:03:00.000Z

I watched an excellent video by Ken Schwaber the other day regarding SCRUM. Like all these things certain stuff just resonated with me…

One of the key points was how tough SCRUM was to implement and the relative poor success rate in implementing SCRUM. The reason behind this is due to the tough questions that SCRUM highlights, my firm belief is that “Agile methodologies” like SCRUM, Kanban, etc do exactly this on the tin. Highlight your problems – I recall a quote, “It’s like developing software in a room with all the lights full blast, compared to the dark room you’ve been sat in for last 5 years!”

People often see “Agile methodologies” as silver bullets – follow some simple rules and this will change your software development process for the better. I mean what else could be simpler? It will make you able to accept changing requirements late in the build process, build better quality and deliver faster. The honest truth is that just following these simple rules won’t help your process. The reason you’re looking for a change is usually because of the three reasons highlighted.

You’ve got to accept that there are going to be some really tough questions that are highlighted.
You’ve got to accept that you have to answer these questions to be successful.
Only you can answer these questions, not anybody else.
If you’re scared of answering tough questions and having tough conversations then do not engage with these “methodologies”. Or if you do then be prepared to fail.
So who is “you” – it’s everyone from the top to the bottom.

The answers to these questions will inevitably lead to change, and once again this change has to be done in the correct manner. Embracing change, and ensuring that everyone is happy with the change is extremely hard to do – it needs time and effort from people. It needs people to address people’s concerns, discuss why the change is better than the status quo.

There are better articles about managing change at the following locations:

Making Change Stick - TOC Handbook

An excellent cartoon - Over Come Resistance to Change

Am I a Code Monkey?

2011-10-14T17:17:00.002Z

Last night’s XPMan was really good. We did some TDD but with no code – essentially we created tests and then created a sequence diagram to pass the tests. We then applied the RGR (Red, Green, and Refactor) to the sequence diagram as we built up the tests; I found it a really good exercise in returning to the basics of TDD. One key thing for me was that it’s really important to do the simplest thing first and get this to go red before you do anything overly complex. During the second kata and my second pair of the evening this became quite pertinent.

However, there is one discussion which provoked some thought and quite a heated exchange. This came in the form of, “I’m a code monkey and I should just fulfil the requirements given to me by the BA’s/customers.” This provoked quite a debate about if a BA asked you to jump of a build would you do it? Another comment was about reading the Agile Manifesto.

So here’s my 50p worth. Yes I am a code monkey, but professionally I need to question what I’m doing. However, this has to be done in the correct manner – asking what the business value is of a specific requirement/user story is? Rather than just saying no. By asking this question – you are just ensuring that the person asking for the work to be done has considered whether it is valuable. If the answer is yes, then you have to fulfil this obligation to the customer and complete the requirement/user story even if you deem it as spurious. This is the professional thing to do.

It’s really important not to blindly accept what people are telling you what to do, but to ask questions and occasionally say no in the right manner – but the manner in saying no has nothing to do with the Agile Manifesto, more the way you say it.

Maybe an unrelated thing – the Agile Manifesto say’s that we value the things on the left more than the right – but remember the things on the right we still value. Something I sometimes forget about is that we still need a plan, we still need a contract negotiation – it’s just we value the following changing requirements & customer collaboration over the other two.

So yes I am a code monkey, but it’s important to question what you’re doing before committing to it.

XPMan Introduction to Kanban

2011-09-08T22:50:00.000Z

Tonight I facilitated an intro to Kanban at XPMan. This was to run through what Kanban is, and introduce the 5 core properties of Kanban.

The slides for the presentation/discussion points contained the following:

Visualising workflow
Limit WIP
Measure & Manage Flow
Make Process Policies Explicit
Use Models to Evaluate Improvement Opportunities

We didn't cover everything in Kanban, but hopefully people got an idea of what it is and how they can start using it.

I'd like to re-emphasis that you should apply it to your current process - it doesn't replace what you do currently it just overlays it. Look at the stats that you get out of it, and let them drive your incremental change

Links:
Kanban Dev mailing group
Limited WIP Society, Manchester
Kanban 101
Limited WIP society

Books:
Kanban - written by David Anderson the "creator" of Kanban for software development.
Personal Kanban - how to apply Kanban to yourself!
Scrumban - applying Kanban with SCRUM
The Goal - need I say anything?

XPManchester:
XPManchester blog
XPManchester group

Thanks to everyone who turned up and joined in. Hopefully provoked some interesting conversations and more importantly gave you some ideas to take away.

Collective Code Ownership

2011-09-05T20:19:00.001Z

I recently asked the following question - What does good team code ownership look like?

Everyone adding (good) test coverage
Discussing the code
Design strategy
Adhere to code standards
Tool box of patterns

Everyone adding (good) test coverage

This is especially important, tests make everyone feel secure when making changes to the code base. Everyone in the team must know the benefits of tests, so must maintain them and add other good tests.

Discussing the Code

The code is essentially a living entity, i.e. we add functionality, we have to look after it, it is often sick! So it's important that the team talks about the code base. This is powerful because it gives people are deeper understanding of the code base.

Design strategy

A way to improve the design - most code bases have areas that don't give us the necessary ways to change the code, or they are hard to test. So they need to be refactored & improved upon. We are currently doing this with our UI - using MVP.

Adhere to code standards

Currently we don't have any standards, however, I do think we have a good code style. This is mainly garnered from Uncle Bob's clean code videos - which are excellent by the way - you should watch them if you've not (or read his book Clean Code)!

Toolbox of Patterns

You've got to be able to change the code, this becomes linked to discussing the code. Patterns can help with discussing the code... Having a design strategy - links to this!

This is not a comprehensive list but it's a good start...

Remember:
“It's important not to own code you've written in a code base; however it’s important that people respect the way the code was written”

Limited WIP Society - Open Space

2011-08-18T09:10:00.002Z

I attended the second Limited WIP Society group @ LateRooms.com - this was in the format of an Open Space - essentially this is a conference style half hour time slots on things about Kanban and other systems thinking stuff... The tracks that I attended are below - I've tried to remember as much as possible!!

MMF’s (Minimum Marketable Feature)

This was interesting discussion - the main point was the importance of understanding what value. The definition of value must be shared between the business and development...

Other interesting points:

Capability in order to be able to deliver a MMF – so in essence there has to be the technical ability to deliver something within a day. I.e. can you write code, test it and deploy it easily enough in a day. If you can’t then your transaction cost is too much and you are not going to get the benefit from a MMF. The other interesting discussion was about business capability – the business needs to be in a position where it can receive MMF’s and understand the impact on them.
MMF’s are all about reducing risk, delivering value, and having a constant feedback cycle.
Someone mentioned a graph in order to decide on whether an item is an MMF – I can’t find it at the moment.
Alkthough it’s important to say “No” – some times its better to give people options to the business users.
I’ve also heard of people using the following to decide on an MMF or to clear a backlog:

Somewhat unrelated but still important:

Kanban doesn’t work with multiple delivery teams. If the team does not deliver the same thing then Kanban can’t work.

Daily Stand-Ups & Retrospectives

The focus of the meeting should be unblocking the blocked issues – everything else is unimportant.
Important that at the stand-up the team is protected. You need to reduce the external pressure.
Managers have a changed role within Kanban – they have to prioritise and help to unblock issues – rather than manage people.
The granularity of tasks is important – if the tasks are too big and nothing moves then something is probably wrong.
The issues within the stand-up are important but the detail of the issue is not important.
Some retrospectives should focus on analysing data others should be in the normal retrospective style – i.e. what went well, what went not too well, and what can we do better next time. It’s important that during a retrospective that everyone has done the best that they can do.

Coaching

This was an interesting talk but unfortunately I didn’t take many notes. It mainly surrounded the fact that the change to Kanban is a cultural one which can be hard to invoke. Somehow we managed to start talking about The Choice by Goldratt! @wisemonkeyash talked about the glaze of resistance/layers of resistance and has posted this awesome link about why change is difficult. We started to talk about mermaids, and crocodiles! However, the overaching thing for me was that everyone is open to change it is just the way in which you invoke the change that is important. It has certainly highlighted that I need to read “The Choice” and other books – i.e. Driving Technical Change.

Identify Bottlenecks

This was mostly inspired by the Theory of Constraints – why and how it is important to find a bottleneck. What to do with a bottleneck and other random thoughts about inventory in software development. I found this talk to be one of the most interesting because it’s a topic that I'm very interested in at the moment - for this reason I'm not going to excessively talk about it! This blog contains enough thoughts about this! It’s highlighted some interesting things about trying to elevate the bottleneck – something we are not doing at the moment.

An excellent night. I know I've probably missed some information!

Efficient Vs. Effective

2011-07-27T22:19:00.000Z

I've been thinking about "The Goal" of Kanban in our organisation for some time.

I believe that there are numerous (side/non) goals - however, the one true goal is to deliver high quality, business value to the customer. However, to enable this to happen a Kaizen (continous improvement) environment is likely to aid & probably help you on this "path" to the goal (you might never get to the goal - it is after all a goal). You also have to accept that life/business/software dev/nothing is never static so you have to be able to adapt your process to ensure that you keep delivering value to your customer. This Kaizen environment helps people to eliminate waste, but also empower people to make changes to a process or system which isn't helping to deliver value to the customer. Anything that doesn't add value is essentially waste.

I think there is a lot of "Non-Value Added" time during software development. In fact maybe the only "Value Added" time is the point in which you push/pull it to live. Everything else might just be "Non-Value Added" time!

So what exactly is efficiency within Software Development - well to me now it's clear - thanks to wikipedia & the above mind burb! Efficiency in software development is anything that is not "Value Adding" in your current value stream.

Now you might think - well if you've got Kaizen time (i.e. slack time to improve your process) how is this adding value to your current value stream. Well it might be something to help improve the flow within the value stream. This is as important because you are trying to optimise the current value stream - so essentially you are aiming to add value or remove waste from your value stream (agh confusing!). It's important to accept that these might fail sometimes - but hey people make mistakes and learn from them.

I think Effectiveness & Efficiency get confused. I'm certainly confused this late at night! Let me give some arbitrary examples of measuring these two things...

Measuring Effectiveness might be measuring the number of LOC (Lines Of Code) a developer writes. However, this is irrelevant in line with the "Goal".

Measuring Efficiency might be measuring the amount of Business Value a developer delivers to the business. This is more relevant to the "Goal", and to some degree is measurable against the goal.

However, this will promote local optima - promoting selfishness, and definitely promoting a non-kaizen environment. This would lead to a process which is not optimised - you essentially get silos of optimised process, with other areas unoptimised. That's why it is important to look at your full value stream when measuring Efficiency.

Before measuring Effectiveness think about the impact this might have on your overall "Goal".

Thanks to the following for making me think about this stuff way too much:

Increased WIP = Increase in Lead Time

2011-07-14T13:45:00.001Z

I've been viewing our Cumulative Flow Diagram and some interesting stats surrounding the work we are developing, our current flow rate and WIP. Today I was able to see how increasing our WIP directly affects our Lead Time.

Our big spike is due to all the items being placed on the backlog (TODO) - although some of these may never be implemented more on this in the future!

To summarize some of the information I can see (and you can't!):

Average Lead Time for any sized item from inception to live:

35 days - 7 and 11 items in progress
21 days - 2 and 5 items in progress

There are a number of things to note:

Variability in size has an impact on lead time - large items increase lead time.
Increase in Work in Progress decreases lead time.

The above ties nicely in to Little's Law.

Ye Olde Story

2011-06-30T09:29:00.000Z

Back at the start of time, or rather the inception of the company there was a small IT department this had to work closely with the business in order to fulfill the ever changing requirements of the business. The IT department of two had to work this way to ensure that the newly found company always had the competitive advantage.

Unfortunately, as the company got bigger more things started to flow in to the system (IT team) and slowly the development team of two where overwhelmed with the requests being asked of them. They became the bottleneck in the system. In order to alleviate this bottleneck the company hired two more people, this had the desired affect and the IT team could develop some of the functionality that the business wanted. At the same time the company hired more people with more great ideas of how to improve the business.

As the business grew, the list of items for IT expanded exponentially until it became full of things which added little bits of business value but at high cost, the list of items was not prioritised.

At this time the IT department decided that it needed to help manage this list of items because the development team couldn’t complete all the work. The company decided on introducing contracts and processes so that when those pesky users could only put something on the list if it was fully thought of – or at least had enough detail to work on. The customer started to gold plate features/products just to ensure they get there idea got through; this meant that the bottleneck which was the development team started to do work on items which added very little value to the business.

Parts of the process was deemed to work well for a period of time, but alas no-one recorded the before and after to see whether the new found processes improved the flow through the system. Even more importantly, no-one measured whether the development team delivered value to the customer.

The IT department started to monitor work it realised that it was slow to deliver change to the business. The processes that had been put in place to manage the work were not delivering value to the customer as quickly as the IT department had envisioned.

The solution to delivering value was simple but hard to implement. The IT department needed to realise the following:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

The “pesky end users” where in fact the customers and needed help to get rid of items which didn’t add value or not have a good ROI – this needed to be done through improved communication – rather than more processes and barriers.

Fortunately, the IT department realised that it needed to evolve from its current state in to a new state, where it delivered high value software to its customer. This was only going to happen through hard work, and through frank conversations within the team, and by evolving there processes to match their customers’ needs.

How Communities Can Help You

2011-06-11T09:12:00.001Z

I was fortunate enough to attend Agile North Conference yesterday. I spent all the day in the practitioner based stream of the conference. I came away from yesterday brimming full of ideas of how to deal with some of the problems that we have at work. I’d say that most software development companies have these common problems.

Most areas where people live and work will have regular user groups for people who are interested in their craft (software development). I regularly attend XPManchester which is another great community from which to get ideas about eXtreme Programming, although there are other things which come out. Come along!

After XPManchester I met up with a couple of team members who had attended the BCS event about automated testing. I was slightly late to the pub but could hear the geek conversation going on downstairs – my colleagues were also brimming full of ideas and thoughts from that event.

These community events are really fantastic place to get new ideas from, talk to passionate people and generally get a buzz for development back – if you ever lose it!

There are loads of ideas out there, go and read about them. If something isn’t working at work then try to apply an idea to it. If it works then great – if not then don’t get disheartened keep trying different ideas until you find one which works for your environment, and even go back to ideas. If they failed back then it might be just because you didn’t do it in small enough chunks, or you didn’t really implement it properly.

Keep the changes small, and quick to reverse.

Once you’ve found something that works, share it with the community! Most other companies are having similar problems to yours!

Share the communities you find with your fellow colleagues at work - some people will definitely be interested in attending!

Playing By the Rules

2011-05-23T19:14:00.000Z

I’ve been trying to reflect on some of the recent successes we’ve had at work. These successes where highlighted in a recent retrospective we ran last week. Increased teamwork/collaboration, and improved built in quality to a certain degree.

How over the last couple of months has the team seen such a rapid improvement?

The answer is pretty simple really - we have been playing by the "rules" outlined in eXtreme Programming & SCRUM (to a certain degree):

Pairing
Test Driven Development
Planning Poker
Retrospection
Daily Stand Up's
Continuous Integration (to some degree)
Reflecting on Agile In A Flash cards
Watching Clean Coders

As one of the Agile In A Flash cards said the other day - we have been playing by the rules, which is something we must keep doing until as a team we are more mature. Once more mature we can start to review the "rules" and adapt them to our situation if they do not fit. Hopefully this will allow us to further satisfy the needs of our customers. In my opinion the most important part of software development.

As a team we probably need to refine our pairing, and having properly defined roles during pairing. How to ensure that both driver and navigator are working together. A common problem is the navigator is distracted. We could simply do the write a failing test then swap, scenario which I have seen work well at XPMan. Another way is to use the Pomodoro Technique. As I'm writing this it's probably the case that as a team we should decide on a way to pair and follow this for a couple of weeks an retrospect on it!

Test Driven Development is another area that we need to get better at, but I think we know what we need to do - we just need to start doing it!

As you can see there is still much to do, a recent mind map highlighted just how far our team has to go. Some of this is in relation to rules we've not implemented and some of this is just to enusre we keep applying the "rules"

Feeling the Rhythm

2011-05-13T22:35:00.000Z

This week has seen our team embark on a major piece of new functionality for our legacy system.

Our progress has been relatively slow up until today, this might be due to the stories being epics, or it might be that we are doing all the right stuff!

Test first (although probably not true TDD), pairing, getting existing code under test before modifications, improving the design of the existing code base.

We have two pairs who are working together on two stories. Two of the people have swapped mid-week, Russell and I, have “owned” a story for the week.

The two stories we are working on are quite different, the first story (which I fortunately picked) was to create a new page for the legacy system. The code for this has been written using TDD; the new page interacts with the legacy system through the Model. You might question why I stated “not true TDD” earlier – the reason is that we are lacking the automated acceptance tests to ensure that the outer ring of the TDD cycle is correct. This is something I’ll be feeding in to the next sprint.

The other story is updating an existing page. Essentially this job is three fold – get the code under test, improve the design (change to MVP), and make the functional changes. This has been a huge job. Unfortunately, we are not going to be able to fit everything in to this sprint; however, we will be able to leave the code in a better state than when we started! We are forcing ourselves to pay back the technical debt that has been accrued – this is quite painful and time consuming!

The pairing has been extremely beneficial – it’s made the team focus on getting the job done. I can’t say whether it’s improved the code quality, my gut feeling is that it’s caused conversations about the design of the code, which has simplified it (the tests also help with this), and also caught some things which are just plain wrong. We even had a CRC session to flesh out some of the details of the classes and to ensure that they had the correct responsibilities (thanks Sam & XPMan!). Pairing also seems to add energy to development or maybe that’s the caffeine!

It’s felt like we’ve not moved much for most of the week, but this afternoon the team’s feeling was that we were eventually getting somewhere! The team decided to add a couple of hours to our afternoon – something which I’m not always too keen on – I’m a believer of a sustainable pace. However, I also believe that if the team is agreed then this rule can be bent a little. So we stayed for a couple of hours, and managed to get a couple more tasks off the list, and now we are pretty close to completing the two stories.

This week has had a really good rhythm to it. The Red-Green-Refactor cycle lets you get in to an amazing flow, of sadness then happiness, then more happiness as the code is refactored. The team has been trying to apply what we’ve learnt from the cleancoders.com webcasts to the code base. Especially the Boy Scout rule.

It’s important that we ensure that we deliver business value, but also improve the code base to work with, and have fun!

Motivated Individuals - Great Teams

2011-05-03T10:00:00.000Z

Getting up at 4:30am in the morning on your holiday may seem like a bit of a daft thing to be doing; in the end holidays are meant to be relaxing and a time to unwind. Some people enjoy lazing on a beach. Unfortunately, that’s not my idea of a holiday - my ideal holiday is cramming as much “stuff” in to the shortest possible time. “Stuff” is defined as ski touring (where I’ve been), ice climbing, rock climbing, skiing.

So what’s the reason for getting up so early and how does this relate to anything at all!!!

Well the reason for getting up early (especially in huts) – is because the hut guardians generally want you on the hill early so you can be back early. The reasons are probably three fold:

In winter the afternoons bring a greater chance of avalanches.
In summer the afternoon brings the possibility of thunderstorms.
It also gives you the most amount of time to achieve your goal - i.e. go up a hill/mountain!

I'm not one for getting up early, however, on holiday it seems even easier to get up than it does on a work day. It is quite simple go to bed a lot earlier than normal so that you can ensure that you are fresh in the morning - there is also not much to do in a hut after dinner!

When you get up in the morning at "silly o'clock", there is an enviable buzz around the hut - people are psyched for the day ahead. This energy is really amazing, you can feel it flowing through the building.

This is the perfect example of building teams around motivated individuals (read principle 5), if a software team had the same buzz as my fellow mountaineers/hut goers then it would probably build kick-ass software. Quite assumptive I know!

My mind now ponders at how to get this motivation flowing through everyone in a team; is getting people up at 4:30am in the morning reasonable!!!

Having a shared goal would be a good start, and finding out what motivates each individual in the team...

Baby Steps

2011-04-20T21:51:00.000Z

We’ve been recently working on moving the legacy UI code to MVP. This week has seen my focus move from doing some of the initial work, to a support role within our team. So the focus has been on fixing live issues that we currently have within our system. I might blog about the reasons I think we have these support issues in the future.

As the week has progressed (it feels like a long week, maybe because it’s a short week!) – I’ve been getting more involved with a colleague who is now converting the legacy code to MVP. It’s been extremely interesting pairing/mentoring the developer. My colleague is quite new to MVP and test first approach so it has been interesting to see how focus can be lost quite easily – thinking about other sections of the system.

I think this is to do with focusing on the problem at hand, not getting distracted by other issues and just solving the current red issue – the broken test. Once this is green we can think about things which might be important or not be – i.e. how can we improve the current design and the current code base. Or even add another test to highlight the current hacked – I’m very much of the ilk of doing the simplest thing to green. Maybe I’m just plain lazy or like to KISS. Maybe I want to ensure that my focus is on the smallest possible thing. A former colleague always used to say, “I can only concentrate on one thing at once.”

This has made me think about a number of things. Developing software is hard; thinking about an entire system and its interactions is even harder. Sometimes developers struggle to focus on their current problem and get distracted by something completely different (i.e. the entire system!).

This is the reason it’s important to write tests first. The act of writing the test focuses the mind on what it is we want the method/SUT to do, we can then focus on doing the simplest thing to get the test green. Once this is done we then focus on refactoring. We then repeat. This ensures that we keep focused as we write the code – it’s a very nice rhythm, and very rewarding (amazing how seeing something go green gives me a thrill!!).

I recently sent out the code kata that Roy Osherove put on his blog – the string kata. It's interesting that the notes say ensure you do not rush ahead of yourself and do not scroll down. Something any human being would want to do, we are thirsty animals for information and problem solving! I know that some people might struggle with this!

I suppose this poses a couple of questions for me:

Are we killing the inquisitiveness by stopping people from rushing a head, or just simply focusing the brain power of the individual/pair (I know that in a pair one will concentrate on the code, and the other on the design) on the problem at hand?
Do we currently struggle to focus on a single thing?
Can the human brain multithread?!

Exposing Code Smells with Tests

2011-04-13T22:35:00.000Z

I’ve managed to complete my other project within my original estimates – I will blog about whether visualising the work and the other approaches I took worked/helped next time!

Today’s task has been to start converting the UI layer of the main legacy system that our team maintains to MVP. I’m not going to delve in to the reasons why we chose MVP; well I think we just decided that it would be the easiest path to getting the UI under test. The team probably has more experience with MVP than MVC so it’s probably a wise choice!

I’ve taken a relatively simple screen to start with, one that shows the notes on a specific Sales Order, allows some filtering, and allows the user to add an additional note. Instead of delving straight in to the ASP.Net code and slotting tests around the existing functionality, I chose to simply abstract the current functionality in to the presenter. This was all done using tests to drive the code. Essentially the tests are what the code does “as-is”, so I suppose you could say that I let the current implementation drive the tests to a certain degree.

As I started to increase the number of tests around my newly created notes presenter class, interesting patterns and problems with the existing code emerged. Since I’ve become an advocate of a Test-First approach, I’ve noticed that code not written by tests doesn’t show problems – early in the development cycle. I also think (maybe wrongly) that code doesn’t get refactored if you don’t have good tests – therefore ending up spaghetti-fied or just damn hard to highlight problems.

The existing code does a number of things:

Shows all the notes; Or;
Allows you to filter notes
Then displays the count of each of the types of notes

Now as the tests have grown I’ve found the existing code does the following:

Shows filtered notes/all notes
Then gets all the notes again to display the count of each of the types of notes.

The presenter should just get all the notes then filter based on the current filter criteria. This removes the dependency on multiple calls for the notes.

The other thing I found was that the NHibernate ISession is used at quite a high level – with the Service (essentially the Model that I’ve been using for the Notes – it was in existence already) that I am calling to get the Notes. The problem was that I had to force the ISession in from the Presenter. This has made me feel really uncomfortable –a code smell! I’ve had to mock the ISession object out for all of the tests since I am using constructor injection. Really this dependency should be pushed right in to a Model.

Thinking about it further (as I write this blog post) – it is probably about time to create a real model. I thought I could have got away with using the existing note service for this purpose. This in essence would be a model/façade so I no longer have to mock the NHibernate ISession.

This is something I will endeavour to do on the next phase of development (i.e. tomorrow!).

I find it interesting that the things above highlight themselves after only writing a dozen or so tests. It definitely backs up my thoughts on test-first development, and makes it even more crucial to write them all the time. There has also been the added benefit that I’ve been able to fix a minor UI bug with the code that I’ve written.

Visualising Your Own Work

2011-03-31T15:48:00.001Z

The project that I’m working on at the moment is pretty small. I’ve been given the freedom, or ability to introduce some of the concepts that I’ve been reading, and thinking about over the last year.

To summarise – I have my own features for the functionality that I am going to implement. These have been written as acceptance criteria using SpecFlow – and the Given, When, Then syntax. Hopefully, this will ensure that the product that I develop delivers what the user wants (I can’t say what the user wants as this is a confidential product). I’ve found that my customer is extremely positive about using this, although we’ve probably not had as much face-to-face conversation as I would have liked. Maybe I should explain this… I’m convinced that some of the acceptance criteria would be better business aligned if we had a discussion rather than e-mail chain. Ironically, since I’m new, I’m probably a tad nervous or shy to be forcing workshops on people (people who know me might laugh at my shy reference!).

I’ve found the Given, When, Then extremely useful and forces me to think about what is important for the user. I’ve also used BDD/TDD for it as well – I’m more than confident that the design of the component I have written is a lot cleaner than I would have written a couple of years back. I’m pretty happy with the design and lack of duplication in the code. I’ve tried to be extremely hard on the refactoring – something I need to work on more and more.

The other thing I’ve started as of today is my own visual board. The reason for this is I’ve been struggling to focus on what to work on next. I’m interested in seeing how this works; I can already feel the benefit of having something visual forcing me to think what is next and get on with the work! Therefore, I know have:

I’ve had to get rid of what the cards actually say sorry, but they are just succinct pieces of work for this project. The pink items are blocks, or rather problems with the card – these need to be resolved before the card can be moved to “Done”.

I’m not going to apply Work In Progress limits yet, I’m not sure whether I need to apply this to the project – my estimate is that the work will take 10 days, so should fit in a single iteration!?

Really I should have a Continuous Integration environment for the project!

What's in a Role Anyway?

2011-03-23T10:46:00.000Z

We recently had a discussion about what the state of the development community at the moment. I've also had a blog post with a comment, where I stated is there a need for a BA!? This centred mainly around the make up of the team and who or what key skills you need in a team. As I’ve become accustomed to being just a developer over the past couple of years which has included either of the following: writing code, or supporting production code. Although this has been my primary role over the last couple of years I’ve come to realise – probably since discussing and studying Agile & XP especially that this is simply cannot be the case anymore.

The main reason for this is due to the fact that XP & SCRUM just has a concept of a team – this includes everyone who is needed to deliver a product or rather something of value to the customer. The idea that when the time comes to deliver everyone needs to be able to help to deliver the product – this is mainly because there is not one person responsible for the delivery – the team is responsible. So this means that if there are tests to complete before the iteration completion date and no development work – then everyone needs to “muck in” to complete the tests.

This leads to teams of individuals with multiple skillsets – as an individual you might for one day have your developer “hat” on – the next day your “hat” is firmly in the “test” ring. Traditional role definitions are probably not well used here and are probably redundant. You are essentially just a team member who has more experience in development than testing, BUT you must be able to help with testing if the needs arise. If there is a bottle neck you must be able to relieve the pressure on the bottle neck – otherwise the “team” will not deliver.

This ability to learn different skills leads me to another important asset of any team member – you must be willing to learn. I think Agile especially encourages this, since everything is an experiment? I was listening to a Podcast with Lisa Crispin and a couple of her final thoughts centred on the need to learn and willingness to learn. It must have struck a chord - because I was skiing at the time! I believe these are key skills for anybody working within in an Agile team.

For me this leads to a couple of core things to look for in team members:

Willingness to learn
Ability to adapt to the needs of the team

"Specification By Example" - Initial Thoughts

2011-03-21T16:19:00.006Z

I’ve been reading through the excellent “Specification by Example” in it’s early form from Manning. I’ve often struggled with the upstream practises of Agile. Recently I attended a work presentation surrounding capturing requirements and other work which BA’s undertake - it looked very “watefall-isk”! My concern was how to counter this discussion around sign off and the need for documentation.

I’m so glad that I was able to get hold of “Specification by Example” – it’s given me plenty of ideas of how to promote a different way to work. The benefit of living documentation has got to be a good starting/selling point!?

This lead me to ponder what the role of a BA was within an agile/lean organisation. It seems to have been an area that has been left behind over the years. This is primarily due to the fact that most of the original Agile Manifesto signatories where people from the software development field.

I’ve often wondered whether User Stories is all Business Analysts should do; in fact do you need Business Analysts?

Specification by Example answers a lot of questions around capturing requirements in the early phases of an agile/lean project. I’ve tried to map out how I see the process within our organisation – I’m not sure whether it’s what is intended but it’s something that I want to try out in the future:

I will write more about the book, but my first impressions are that I would recommend this to anybody who is developing software, it is extremely informative and well written.

What is Strategic vs. Tactical?

2011-03-16T21:32:00.002Z

Over the last couple of years the term strategic and tactical has become more apparent to me, this is probably because people have talked about the need for strategic software solutions against the need for tactical software solutions.

I’ve been pondering what this actually means to me! What impact does a tactical solution have on the end user? What does a strategic solution have on an end user? My gut feeling is that the answer would be nothing.

So let’s flip the question around, because I believe the term is coined by developers/management. It may even be an excuse for not doing certain practises. A tactical solution is a quick fix; with very light weight Project Management around it, there may not be time to do any tests and the whole attitude is doing whatever it takes to deliver with the least amount of effort. A strategic solution has PM’s, BA’s and Project Management around the solution. This makes it strategic because there is more governance. We’d prefer to take our time on this project because of its strategic importance.

The definition for strategy is:

“A word of military origin refers to plan of action designed to achieve a particular goal.” or;
“Highly important to an intended objective”

The definition for tactical is:

“Less of a long-term significance than strategic operations”

From briefly wiki-ing and searching on the web, the terms “strategic” & “tactical” seem to have their history in the military. Strange that software development has adopted these words, my view is that there meaning has been modified incorrectly for software development.

If you were to apply these words to software development, maybe they should have a different meaning to what I’ve seen. So here is my 50p’s worth. The strategy is where the overall “architecture” of the company is going – i.e. we want everything to be SOA. The actual implementation – writing of code is tactical – i.e. we will implement this through a RESTFul service using WCF.

Both the development of the application and the overall “architecture” of the system should be aimed to align closely with what the customer actually wants.

The customer probably doesn’t care what the strategy is – they probably only care what the tactical delivery is!?

The Joy of Post Holing

2011-03-07T16:39:00.008Z

We had a really magnificent week away in Italy - this was all part of my dad's rehabilation after he broke his ankle/leg in Switzerland on the Piz Trubinesca. You may know about this if you've chatted to me - if you don't you can read the over media hyped version @ you can see it here!

We stayed in Livigno in the Picolo Tibet - which is run by Ercole (I think that's how you spell it!) - he was a fellow patient in the St Moritz hospital that my dad spent 20 days in following the accident.

We spent the first part of the week skiing - it's really good swishing down the slopes on the skis. I changed to snowboarding a couple of years back, but have since gone back to skiing. Due to a damaged board after a big gust in Scotland slightly damaged the board, and also I've got the gear for ski mountaineering now!

The second part of the week was spent ice climbing. The approaches where pretty awkward due to the depth of the snow - not having snow shoes really tells. Post holing as the "yanks" call it is really exhausting and time consuming when approaching routes. It seems to take a quarter of the time to get down after the route! It may well be time to invest in some snow shoes - the only problem is that they need to be easy to carry and collapsible - it seems that there is already a patent pending!

The first ice route was a WI 4+ it took about an hour and half to get to the bottom of the route the guide book time for the approach was half an hour! The Joy of Post Holing! It was really interesting climbing the top pitch the ice must have been half a metre thick sheet of ice. It kept thudding as you placed the axes and crampons. Quite interesting really - I didn't put much protection because the ice wasn't that thick!!! Both pitches where fantastic.

The second ice route was a WI 5 the guidebook says it is only a 90 metre route. It ended up being more like a 200 metre route. The gully was quite long to get to the main pitch which is a really nice sustained 5 pitch. The ice was just good enough to climb on the left - the centre was all rotten out - it had been in the sun too long and was really mushy!!! It was a really good route to do on the final day before travelling back to Zurich. Something to get the arms pumped!!!

A really good trip and a good place for my dad to continue his rehabilitation - to quote after the WI 4+ - "That's the hardest thing I've been on since the accident!".

Hopefully Scotland will stay/get in nick again so we can get up there for some more ice climbing in the coming weeks. Back to training & work for now!

Delayed Value

2011-02-25T09:34:00.004Z

Having my last look at the board today, I found it interesting that we have work items sat in the "Ready For Production" column. The total items in this has grown over the last couple of weeks - we now have 7 items ready for "Production".

These items all have a varying level of "Business Value" (value) associated with them - but are sat in the system. They are all blocked by the same thing - the legacy system has a quarterly release cycle.

This poses a couple of questions:

Is there a threshold before the amount of value being delivered outweighs the cost of putting that value live?
Should every single piece of item developed be pushed live as soon as it is ready - therefore giving you an instance ROI?
Are the items of high enough value to the customer if they can just sit in the "Done" column for a couple of weeks?
Do the customers have visibility of what is "Done"?

My gut feel is that the first question is a cop out - the cost of pushing things in to a live environment should be minimal because you should really have seemless CI. It should be of no extra cost to put code in to a live environment. If it costs - you need to spend time & money on improving this build & deploy system. This is an Internal Quality as Martin Fowler puts it.

If you push every single piece of work live you need to have customers who can accept a constantly changing system. This maybe difficult but I think it depends on what you are delivering - i.e. defect fixes, and minor enhancements could be dropped in at any point. With large changes in functionality - it depends on how involved the customer has been with the development. Here we probably can't do it, because the customer is not overly involved.

The above statement probably answers the last two questions as well. It's all about the customer deciding on what to develop - this way they can decide upon the items with the highest value. They also know when items are complete.

This is one of the 4 principles in the Agile Manifesto - "Customer Collaboration".

Team Foundation Server - Test Presentation

2011-02-18T15:49:00.005Z

Since I joined my current company I've been tasked with learning about Team Foundation Server. It was seen as key component to future development within the company. However, previous initiatives have fallen by the way side over the years. I think these have not worked because they have failed to interact with the larger audience of IT - i.e. outside of just the .Net development teams.

It has often been seen as a “thing” that was coming but no-one really knew about.

We finally get a production ready instance of TFS 2010 this week. After numerable test instances have been used and “toyed” with.

Weirdly I'm leaving my current company in the next week, and yet this initiative seems to be finally getting some steam behind it; or at least it felt that way today.

We've been using it within our development team for.Net technologies for the last 5 years or so, more recently we've been starting to use it for User Stories/requirements, work item tracking and general reporting. CI builds where going to be my next task.

Today I've given a presentation to the Test team. After a trial demo to our development team the other week, this seemed to send everyone to sleep!? I decided to change the format, I hoped it would make it more interactive and actual let me know what people thought about TFS, what they'd heard about for so long - but never really seen. I also needed some help - since I'm not really a "Tester" (although I'm trying harder to become multi-skilled - I might blog about this separately!!!) - so didn't know what to show them. I can give a demo to developers easy since I know what they want to do.

This led me to the following format for the presentation:

Get an understanding of what the group knew about TFS?
What they thought TFS was?
What they thought TFS would do for them?

I linked this to another item:

What are the current problems within "Test"?

This gave me a lot of ideas as to what they actually wanted to see, it also highlighted what TFS wasn't going to give them. I.e. it isn't going to solve World hunger, or poverty!!!

After this I let the group drive the demo:

What do you want to start using?
What do you want to see?
What do you want to explore?

I found this helpful, and hopefully they enjoyed it and saw the potential of TFS. I have to re-emphasis that I am no expert on it from a "Test" perspective - I simply know of its potential to fulfil some of the problems that they currently have. It's essential that someone takes the time and interest in the tool to try to solve some of their problems.

It's definitely a tact I'd take with any other presentation/demo I'm giving in the future!

BDD - Initial Experiences

2011-02-16T10:00:00.006Z

I've recently discovered BDD or rather there has been an increase in communication about this topic around me - someone mentioned Cucumber at XPManXL!

I found the extremely well written Cuke4Ninja site, and started to discuss Specs more with my colleagues. Jason highlighted that SpecFlow seemed like a good implementation for .Net development.

This all seemed to align with both Gojko Adzic at Agile Yorkshire which I unfortunately missed, but made up for with attending XPManchester where John(no) gave a presentation/discussion about BDD for his Masters... He asked us to implement a Chess Kata using some features which he has developed - these can be downloaded from GitHub.

I spent a bit of time trying to implement the features. My first experience of BDD! I found it quite overwhelming initially with all the specs running. I.e. I had quite a lot of specs/tests running and didn't know where to start.

Retrospectively I should have included a single feature - implemented it till green and then incrementally added features as I went along. This is something I am going to do on my second attempt. I plan to throw away my initial code and start again. Although I'll probably use a similar design I'm interested to see how after my initial attempt how it will differ - will it be better design?

Initial thoughts are that features are a way to have a shared vocabulary between developers and business users. I also think that they are the Acceptance Criteria which are usually written on the back of User Story cards.

I'm also slightly confused at when to start delving deeper from high level features in to say lower level "Behaviours/Features". This I'm sure will become apparent as I spend more time using BDD.

Kanban - Retrospective - Categories for Improvement

2011-02-09T17:10:00.005Z

We keep having weekly retrospectives about the Kanban board.

Last week’s retrospective probably went a tad off target, or maybe it produced ideas which don’t improve the process of our team, rather than general ideas about the board. Note: no idea is wrong or right during these retrospectives – it’s just the focus might have been lost on the purpose of Kanban.

Last week we looked at things that “went well”, things that “went wrong” and things that we wanted to “improve”. We then voted on which improvement ideas we wanted to implement. You can see what we implemented in my last blog post.
This week we invited Andy (our very own Lean/Agile samurai) to the retrospective, partly to see how we should run a retrospective, and partly to get some focus back on Kanban.

The following was the rough structure of the retrospective. The first was a discussion between pairs about “Why we wanted to do Kanban?” and also “What we wanted to change?” These where put on post it’s and stuck to the wall randomly.

We silently organised as a team the post-it’s into groups. I found it especially interesting the commonality between the post-it’s that each of the pairs came up with – probably not very interesting since we all share the same goals & grievances!

The team then came up with the following list of categories for each of the groups of the post-its (in no particular order – I just wrote them down this way!!):

Teamwork
Customer Satisfaction
Problem Identification
Prioritisation
Predictability
Speed
Transparency

The team scored each of these with either an “x” “–“ or “tick” depending on how we felt things were currently. We scored the majority with a “-“on some categorices and “x”’s on other categories – as you would expect. None we scored with a “tick” – we had some small ticks though!!!

We then paired again (with different pairs) and asked each other how we could improve the process targeting the above categories.

We fed this all back in to a whiteboard – and came up with a list of things to improve. We each had 3 votes again and got to vote on an idea we’d like to implement. The ideas we are going to implement are as follows:

Measure cycle time overall and between different work types & stages.
Limit number of items coming in to the start of the workflow & each stage.
Cut things down into smaller chunks of highest value.

We are going to try to implement these this coming week, to see if it improves parts of the process. The impact might not be immediate but Rome wasn’t built in a day (I’ve used that quote too often recently!).

An important thing for me is that we start to get some stats about the work we do in our “development system” – i.e. how long it takes for us to complete different work – what is the cycle time for a specific type of work?

3 Weeks of Kanban

2011-02-07T11:18:00.003Z

So we've had the kanban (note the small k!) board for nearly 3 weeks now. It's been quite a learning curve. Especially since a few of us know the theory and some are really new to it.

The first thing to know is that the daily stand up is a new idea, so quite a few people are alien to what the purpose of the meeting is. This makes it seem quite an arduous task to stand in front of the board for 30 minutes initially (times have come down in recent weeks).

This is primarily due to a lack of shared knowledge\understanding of the purpose of the daily stand-up. As I will now highlight!!!

Compared to a SCRUM meeting the Kanban daily meeting is significantly different. My understanding of SCRUM meetings are that they take the following format, each member of the team say’s:

What they did yesterday.
What they plan to do today.
What issues you have.

Having read about these meetings, my general understanding is that they do not scale – i.e. they start to take longer than the 15 minutes allotted when you have more than 10 team members (note: everyone is involved!).

My understanding of the format of a Kanban meeting is as follows:

Highlight anything that is “blocking” a work item – we call this an “Issue”.
Pull the next work items in from “Done” columns.

I’ve read that mature adoptees of Kanban will actually perform a retrospective during the meeting. I.e. why is this issue preventing this item from moving? How do we prevent this from happening again?

So you can see that I have a specific understanding of daily stand-ups! How are we going to share this knowledge?

Well today I’ve been trying to write the ideas above in to an “explicit policy”. So now we have a “Purpose of Daily Stand-Up” – which ironically has the information highlighted above. This is a single power point slide – the key here is brevity (which I’m not very good at most of the time!).
We also needed a definition of an “Issue” so that people are aware of what we are trying to highlight during the meeting.

“Solving Issues” also has a definition and ideas of how to solve issues. The most important thing is that anybody can solve the issue. Another important thing is that the issue is taken away from the daily stand-up – otherwise it turns in to a conversation between only a few people; then no progress is made during the stand-up people not involved in the conversation get bored.
All of these lead in to a Retrospective – i.e. “How can we improve flow?”, “How can improve different areas of our process?” These are placed on another slide. So now we have four slides which hopefully outline “explicit policies” or definitions – hopefully these will help over the coming weeks.

Other things that we probably need to consider:

Size items – could we use T-Shirt sizes?
Mark on items when they move – i.e. transition to “Done”, transition to “In Progress”.
Mark on items each day they are in a certain area on the board.

So to summarise some important lessons:

We are always learning.
We have plenty of good ideas from all the team for the board.
The board will change.
We probably have too much Work In Progress.
Meetings need a purpose or goal.
Meetings need an agenda.