UnFIT for use

February 26th 2008 at 12:33 PM Posted to Agile, Annoyances, Development

It always amazes me at how many people misinterpret FIT (Framework for Integrated Testing) and I guess it’s based on the way that it’s been marketed. I’m not exactly a big fan of FIT and the biggest reason is that people don’t really understand what it’s best for, and use it all over the place where it’s not very appropriate more so than people who do know what they’re doing with it. In the last month, I’d heard statements such as “FIT is good for driving tests below the UI layer”, “FIT is great for acceptance tests”, or “We use FIT all the time”. Please stop this!

Let’s have a look at this table I put together that compares FIT and JUnit. Of course, this comparison also applies when comparing FIT to NUnit or one of its other close brethren (TestNG, etc):

JUnit Comparison Versus FIT (Framework for Integrated Testing)

Let’s get this straight: The only thing FIT is good for, is using it as a tool to help communicate with a customer. That’s it. It’s terrible for writing automated test suites, FIT encourages terrible programming habits, IDEs offer very minimal tool support and many developers don’t seem to really understand, nor want to understand how it works. I’ve seen a test suite where developers deployed FIT tests to a web container because “it was HTML” and they thought it had to be deployed for it to run. Grrrr.

The biggest barrier for FIT is that it requires a lot of education around how developers best use it, how they use it to help aid communication, and then understanding how to maintain it. Unfortunately I’ve never seen the payback you get from investing this time that’s better spent directly trying to improve the communication gap. I think it’s because the conventions used to bridge HTML to code aren’t natural and, without spending the effort to really help developers understand it, quickly leading to a whole mess of tightly coupled code and eventually, test coma.

The recommendation
I’d use FIT sporadically to help bridge gaps between the team (analysts, developers, testers) and the customer – especially for data driven examples. Acceptance level tests in JUnit should be refactored to a point where it’s understandable to customers (i.e. using as much of their language as possible). If you decide to go down the FIT route, refactor mercilessly to split out what the FIT fixture do and how they do that (some sort of driver, component, etc). In my experience, the latter should be immediately usable in another test framework, and in fact, should be what you’re striving to reuse in that other test framework.

* Comments(5)

BCS Talk: Agile Programme Management

February 25th 2008 at 5:17 PM Posted to Agile

Last Thursday I went along to a BCS (British Computer Society) organised event presented by a major influence in the DSDM space, Jennifer Stapleton. Thanks to Ian for recommending this as I really enjoyed her talk.

The Presenter
As a presenter, Stapleton obviously knows what she is talking about. She’s extremely comfortable with the content, and extremely lively on her feet – something I’m not sure the level-floored room was most ideal for. I’ll admit that her slides appear a little old fashioned with lots of bullet point text, or just lots of text and, what looks like, clip art all over the place. I do think, however, that the content is definitely worth while. The lessons she’s learned from her eleven (plus) year involvement with DSDM, considered as one of the earliest agile methodologies, certainly shines through in many of her examples.

The Audience
The event apparently sold out the week the BCS announced it and based on the names on the empty sign up sheet and the number of empty chairs, I guess a lot of people didn’t turn up. A few people who turned up on the night didn’t seem to have any problems entering. I noticed many more people with grey hair and suits compared to the other events I’ve been to (mainly agile gatherings, or language specific interest groups). Based on the questions thrown from the audience, I guessed a higher proportion of them worked for government agencies and a few of them came from academic backgrounds.

The Content
I think that what Stapleton had to say was extremely compelling, though if you’ve done agile software development, prepare yourself for a different world. Programme management goes well beyond what you’d normally think about, especially at the project level, and although applying agile principles at that level probably isn’t different, I’m sure the practices that go along with it are.

She started off by clarifying some of the terms that she used – the differences between a programme and a project, the differences between a programme and a portfolio and how she describes tranches (think iterations at a bigger level). I think her definitions of the terms are essential as I think a lot of people simply group things together and label things incorrectly as a “programme”.

She talked about what you need to be an effective programme manager and how you go about managing portfolios, programmes and projects to meet a programme. She talked about the impact of budgeting cycles that last a year, and the impact it has (feast or famine), finishing with her “Agile Programme Management Maturity Model” (yes, another one!), a tool that helps her evaluate organisations she works with. She also touched very briefly on feedback and cycles of feedback needed although I don’t think she emphasised it nearly enough.

Find her slides at the London Central BCS website, or download them directly here.

A few new terms
SRO – Senior Responsible Owner. From this site, “The SRO should also work out if the structure required to deliver the Programme can realistically be achieved, in order to confirm that policy can be delivered.”
MSP2007 – Managing Successful Programmes 2007 – A qualification around the programme management space.

The Takeaways

  • I like the fact that she explicitly considers change projects that tend to either flow alongside or follow a project (which also, may or may not be software based). In my experience, sponsors rarely think about how their project impacts other people and their roles in the organisation and this often has a huge impact on their success.
  • Agile organisations need agile leaders. According to Stapleton and in response to my question, they’re not somebody that you can train (although I’m not convinced about that if you consider mentoring).
  • At the programme management level, you don’t need to worry about the agile development process – instead it’s a focus on setting the right metrics (aligning rewards with goals and outcomes), and understanding how to co-ordinate and communicate results.
  • DSDM explicitly addresses a fixed vision problem not necessarily solved by XP or Scrum directly.
  • Simply presenting a model is not enough – I can see how people in the early stages of learning about agile programme management might use the APMMM as a direct measure (e.g. Organisation Z fits in category X because they do this or that) instead of trying to work out how to use it as a way to measure progress, or direct change.
  • What Stapleton talked about covers a lot of principles. A gap of practices still exist that make it difficult for inexperienced people to apply directly. It’s all good to want to get to X, the question is, what’s the best known ways of getting there or, at least, what are the options?

Comments(0)

Losing my London .Net Users Group virginity

February 20th 2008 at 3:04 PM Posted to .Net, Development

About 60 people (only of which three or four were female) crammed into a tiny room near Red Lion Square last night for the London DotNet Users Group meeting. I have no idea what the normal turnout rate is, though I guess the topic (TDD) probably drew quite a lot of people. Three people presented and the meeting ran for a total of three hours until 9:30pm at which point, we left for the pub and stayed until closing.

The three presenters for the evening and the topics included:

  • Zi Makki: TDD and the Data Access Layer
  • Sebastien Lambla: The MVP pattern
  • Ian Cooper: Best Practices for TDD

The first presenter covered some techniques for dealing with integration points with a database. I noticed that he used Coderush (all those bright colours and arrows hurts my eyes!) instead of Resharper though I think he was using VS2008. It seems that Coderush also lacks a way of extracting a class into a file for a different assembly or at least it wasn’t used. I’m pleased the presenter used BDD styled should as I’ve found these help focus the person writing the test. He finished with some very useful tips though I was worried by one of his final statements, “Avoid Integration Tests”. I think as a principle, fine. For someone in the early stages of learning TDD (think of the Shu in the Shu Ha Ri), it’s a dangerous blanket statement they may follow as integration tests can be useful points of feedback as well.

The second presenter talked about the Model View Presenter Pattern although after seeing his implementation, and I think it is probably more an example of both the Supervising Controller and the Presentation Model. I find it interesting to see how far Sebastien pushed the databinding features of ASP.Net. It’s given me some thought about how I might actually give databinding another real chance. I’m really interested to see how this works in an update mode in this same world. I also learned here that the Macbook Air isn’t great for doing presentations where you need to write code (the buttons are too small!)

The final presenter, Ian Cooper talked over lots of best practices around Test Driven Development. Ian has plenty of great things to say and one of my only issues was that there was probably far too much content on the slides to cover in just an hour.

One of the other topics that wasn’t covered and I think is important for newbies to TDD is understanding when to or when not to use it. As I wrote in a previous post, if you’re doing TDD all the time, you’re doing something wrong.

I really enjoyed talking to other people who went along and I’ll definitely be back again sometime.

* Comments(1)

The Extended Agile Reading List

February 20th 2008 at 10:57 AM Posted to Agile, Books, Coaching, Learning

Update (20 Feb): I probably want to add the same disclaimer that I did on the previous post. I highly recommend doing reading on these things and I do want to emphasis that reading will only get you so far, so try to find someone who’s worked with in this way before (i.e. an agile coach) to help you apply all these concepts appropriately.

Building upon the Essential Agile Reading List, here’s the extended one that includes either books that I’ve not read (and have been recommended) or those that help facilitate further understanding or more advanced practices. Buy all of them via Amazon’s Listmania here.

Methodologies and principles

Additional context

Teamwork

Continuous Improvement

Project Management

Requirements and planning

Development practices

* Comments(1)

An article on the Prime Directive

February 20th 2008 at 9:20 AM Posted to Agile, Retrospective

Read the article from InfoQ here. It’s a great read and has inputs from many of the passionate community members in this area.

Comments(0)

Some notes on C# 3.0

February 18th 2008 at 2:30 PM Posted to .Net, Development

I’ve been playing around with some of the new features of C#3.0. I installed VS2008 and the new Resharper 4.0 EAP available here. I expect most of the Jetbrains EAP stuff to be pretty buggy and I’ve already had it crash on me more than five times today. Still, being able to refactor and navigate around files is worth the buggy trial.

Out of the box support for the new language features looks interesting as well as some of the new tools and refactorings in place. Interestingly, default settings suggests constant use of the new var keyword replacing the class declaration you should be using. I’m a little uncomfortable with this as the default setting though it could be because I’m not used to seeing C# code like that.

I started playing around with extension methods, trying to convert the ReflectUtil I wrote back in this post. After a rewrite, some of the APIs looked a bit better although at the cost of making some private inner classes and delegates public. I’m not sure if I like it yet and still trying to think of some guidelines for when to use it. I think definitely having all the extension methods grouped together would help – either in one big Extension class (if you don’t have too many) or in a [Class]Extension class so they’re much easier to locate. If you find youreself writing StringUtil classes, consider converting them to Extension classes. Right now, extension methods only work on instances, so if you want to be able to add static methods, vote on the topic here. I’m not yet convinced it’s that useful just yet though.

Lambda expressions look especially nice although now it’s just plain confusing how you have three ways to do something and there’s really little benefit out of the two more verbose ways. Use this to replace anonymous delegates with a less verbose method.

* Comments(3)

A Simple Definition: Dependency Injection

February 15th 2008 at 9:46 AM Posted to Development

A programming concept that focuses on the separation of two concerns; the first being where something comes from, and the other being how it is used.

* Comments(2)

If you do Test Driven Development all the time, you’re doing something wrong

February 05th 2008 at 4:49 PM Posted to Agile, Coaching, Development, Learning

I’m a big fan of Test Driven Development, and even more of a fan of Behaviour Driven Development. So it makes me sad to see really great developers adopt these techniques a bit too dogmatically.

Most developers operate in two modes when they’re writing code. Test driven development helps amazingly with only one of them. Use it for the alternative and you’ll quickly become frustrated, hate TDD and never use it again.

What are these modes? Experimentation and, what I call Focused mode.

Experimentation mode’s main objective is learning. It might involve poking at a library, tool, language or framework to understand how it works, how to interact with it, and perhaps understand some of its limitations. You might learn how to configure it, how to deploy it, and even how to test it. If you write code, it usually is throw away code because you don’t apply the same level of code quality because it stops you learning about things quickly. When people apply TDD during this mode, the first normal hurdle is they don’t know where they should be test driving it because they haven’t learned where the cost-benefits payback lies. They spend a long time writing their test only to find out the thing they’re doing won’t work in that way and then sulk over the time spent writing the test.

Focused mode’s main objective is producing something that will be put into production, used by people and extended upon. Here you want to write just enough code to provide the correct functionality. This is the most ideal time to apply TDD. You care about the quality of the code you produce here.

Recognise what mode you’re operating in, and understand where to apply (and where not to apply) TDD to get maximum benefits. In short, avoid TDD during experimentation and use it when you’re focused.

* Comments(15)

What Analysis Skills Are Useful

February 03rd 2008 at 11:33 AM Posted to Analysis, Coaching, Teams

I’ve worked with some analysts who think their job is to scribe, writing down what users say into documentation. Sure, some skills of an analyst might require some scribing though rarely is it the entire job. Here’s a list of things I’ve observed excellent analysts focus on.

  • Focus on differences, look for patterns, and highlight these differences to the stakeholders. Determine where the origins of these differences come from. Is it a real reason, or is it an inconsistency because the domain vocabulary is a little bit too loose. Are the differences driven through something that adds value or do they come from coincidences.
  • Involve more than just the stakeholders. Talk to developers or operations people and involve them in meetings. Understand the potential costs and brainstorm options with them to weigh up each options costs and benefits. Different points of view (ala Wisdom of Crowds) results in higher quality results.
  • Go beyond what people say what they want. Don’t follow the “customer is always right” saying blindly. They may know what they want deep down. They just may not be able to express it. Also be sure that you’re talking to the right customer. Different groups of end users have different interests that are separate from stakeholders. A solution needs to balance all of their needs. Use scenarios and personas to draw these out.
  • Clarify the vocabulary. Look for synonyms. Encourage people to use the same word all the time as much as possible. Use clarifying techniques, “Oh, do you mean X?” or contrasting techniques, “So you don’t mean X, you mean Y”, or “Do you mean X or Y or Z”.
  • Drive for as much consistency as possible. Drive it through everything where possible beyond just vocabulary. Think about how features complement each other, and how the behaviours work.
  • Customer time is important. You really want to prepare for meetings. Ensure people now about the agenda, questions (using both specific, directed or open), priorities.

Comments(0)