TDD does not mean Test First

Posted on December 4, 2008 by Sarah

Those starting out on their XP or Agile journey often hear supposedly enlightening phrases touted by those in the know like “TDD will lead you to better, nicely encapsulated, decoupled code” which leaves them scratching their heads. They are scratching their heads because they understand the benefits of adopting these practices, but they can’t see how to actually apply them in their situation.

Take TDD for example – how can doing Test Driven Development/Design lead to good code? After all, you are only writing the same unit test before you write your code, instead of after. ‘How will that act magically transform my code base?’ The problem is that when you first hear about TDD, all you really hear is ‘Test First’. What you usually don’t hear is that when you actually test drive your application, you need to ensure that each test you write should be a good test, and it will look nothing like the tests you are used to writing. So, the first problem is that we don’t explain the what a good test should look like loudly enough.

Another problem is that you can’t expect a code base filled with statics and procedural code to magically transform by adding tests. The developers who are responsible for that code will continue to work on it, and they will find a way of writing unit tests which allows them to continue with their procedural code (although it will violate the rules of a good test). This will cause two bad side effects: tests will be hard to write, so developers will not get into the habit of test-first; and the code will still be as stinky as ever, so they won’t believe that TDD works. The other side of the coin is that the developers need to understand basic concepts and principles like single-responsibility, encapsulation and dependancy injection because without this understanding and mindset, it is really hard to write good tests, and the code base will never improve.

The other problem is that the developers don’t actually realise that they can’t just change how they write tests; they are actually changing how they think about code, how they write the code and how they design the code. And this can be scary, especially for the ‘technical architects’ who are used to spending a few weeks in front of a white board designing the application before writing a single line of code. It also takes a lot of discipline and you need to unlearn nearly all software development practices and instincts that you know. 

The simple phrase of “TDD will lead to better code” has bigger implications than just writing tests upfront. Those starting out on their XP journey need to understand the bigger ramifications before they can begin to embrace their new practices. Those in the know need to understand that others don’t realise that there are bigger ramifications and when they see the head scratching, try to explain why the phrase is so (hopefully this post will help).

TDD does lead to better code – test first does not.

Posted in Agile, Testing | 3 Comments

Australia to censor the internet

Posted on December 4, 2008 by Sarah

If you haven’t heard of Australia’s plans to censor the internet, let me be the first to inform you. The current government has a plan “to force all Australian ISPs to implement server-based filtering systems to block access to ‘child pornography’, ‘X-rated material’, ‘violence’, ‘prohibited’ material, ‘inappropriate’ material and ‘unwanted’ material on a secret blacklist compiled by a government agency”[1].  

Originally, the plan stated that the mandatory ISP-level blocking would be opt-out. However, Communications Minister Stephen Conroy has now revealed that there are no such plans to allow opt-out and that all users internet will be subject to filtering and blocking.

So, what is the big deal? Blocking child pornography – thats a good thing, right. Yes it is, until you look at the technology that they are planning to use. Apparently, tests have shown that the filters block the wrong content in at least 25% of cases[2]. The technology also needs to look at everything coming through (not just headers) to determine if it should be on the blacklist and the filter they use isn’t that performant – the internet will become slow again.

And lets not go into civil rights, freedom of speech or the beauties of an open internet. And exactly where will the draw the line. Today its kiddie porn, tomorrow: anti-government websites.; no blogs allowed – no opinions allowed. 

It is good to see that the media seems to be behind the anti-censorship parties[2] and that protests and petitions are happening around all capital cities on 13th December : see http://nocensorship.info/ for more info.

Lastly, let me leave you with my letter of petition[3] to Stephen Conroy:

Senator Stephen Conroy
Minister for Broadband, Communications and the Digital Economy
Level 4, 4 Treasury Place
Melbourne Vic 3002

Dear Minister,

As an Australian citizen and an internet user, I wish to advise you of my serious concerns about your mandatory Internet filtering policy.

Given the importance your Government has attached to modernising Australia’s broadband network, pursuing a policy that can only slow down and increase the costs of home internet access seems misguided at best. Australian households are diverse, and most do not have young children, so mandating a one-size-fits-all clean feed approach will not serve the public well. I don’t think it is the Government’s role to decide what’s appropriate for me or my children, and neither do most Australians.

Given the amount of Internet content available, the Government will never be able to classify it all and filters will always result in an unacceptable level of over-blocking. I feel that the time and money could be spent in better ways both to protect children and improve Australia’s digital infrastructure. Australian parents need better education about the risks their children face online. Trying to rid the Internet of adult content is futile, and can only distract from that mission.

Sincerely,

Internet User

Sarah Taraporewalla

Posted in Uncategorized | 1 Comment

I don't believe in IPMs

Posted on November 25, 2008 by Sarah

I like celebrating on successes, whether it is making a test pass, finishing a task on a story or finishing the story itself. I also love celebrating what we have achieved in an iteration. If we complete 15 story points in one iteration – Great :) . If we completed 20 points in the last iteration, well it was still great – we added 15 points worth of value to the application.

It is because of this love of celebrating successes that I really hate signing up to delivering a certain amount of points or certain stories at the start of an iteration (commonly in IPMs). 

I have heard the reasons for signing up to what you deliver in the iteration including having a clear goal about what will be achieved that week; knowing how many stories we think we can cover so that the BAs can plan and define the stories for the next iteration; and you won’t know how fast you can go if you don’t say how many points you will achieve. I have counter-arguments to these (of course).

The first: having a clear goal about what will be achieved in that iteration. If you don’t sign up to stories, how will you know what goal you are working towards? Easy – we are working on the current release. Our goal for the iteration is actually to complete as many stories for the release that we can achieve. The business can still prioritize top stories, so we know which stories we should deliver first, but our actual goal of the iteration is to work through as many stories in the backlog as possible. 

The second: knowing how many stories we think we can cover so that the BAs can plan and define the stories for the next iteration. If you have a look at how I would run a IPM-less project, you can see that the BA will always have know when they need to start defining the next lot of stories, governed by how full the bucket is.

The third: You don’t know how fast you can go if you don’t say how many points you will achieve. Agh, my favorite argument, worthy of its own post. I will just touch briefly on it. Sometimes, people say “last iteration we said we would complete 20 stories, but we only completed 17 stories. This week, lets say we will achieve 20 stories again so we can improve on last iterations effort”. That is all very well, but this is just an arbitrary number. Without the goal of completing 20 points, I could say “so far in this iteration, we have achieved 12 points. We have 2 more days left – hey if we work well then we can beat that this iteration”. Knowing how fast you can go is only relevant when working out when the release will be deliverable, and this can always be done with yesterday’s weather.

How would I do it?

At the beginning of the release, you have a backlog of the stories for the release with estimates on them, so you can gauge how long you think the release will take to complete (there is no difference here). Then, you identify which stories are the most risky to play (which will deliver value) and ones which have to be played first and you prioritize the top 10 (at this stage this is just an arbitrary number, depending on the number of pairs you have). You then have a bucket which holds top 5 (again, arbitrary) stories.

 

  • When a developer picks up a new story they have to pick up something from the bucket, but what they pick up is their choice – first in first served basis. 
  • Any bugs which arise are added to the bucket (assuming the business wants to fix them). 
  • No new stories can be added to the bucket until it is empty.    
  • The business has the power to replace a story in the bucket if they feel something else will deliver better value.
  • When the bucket is starting to look empty, the BA can then define the next lot of stories, taken from the original top 10 which will go into the bucket.
  • 5 new stories get added to the prioritized list so that we still have a Top 10.

 

Working in this manner has many advantages:

 

  1.  Developers can be incentivized to completing their story quickly because they want to their pick of the stories in the bucket (if they took a long time, then a great story could disappear)
  2. The team is self-organizing as the developers decide which story they want to pick up first, in much the same manner as QAs self organize.
  3. You only define the stories which will go into the bucket; you don’t waste your time defining stories for an IPM which will get thrown out because the developers didn’t feel like they could work on them.
  4. You cut down on one meeting (the IPM).
  5. Increases team morale as you celebrate what you achieved instead of morning what you didn’t deliver.
  6. You plan your release date using yesterday’s weather, instead of yesterday’s weather and an arbitrary forecast.

 

I would still hold weekly showcases, where you celebrate all that you achieved that week and weekly retrospectives, where you can talk about what will make us go faster.

I still believe in iterations: just not IPMs.

Posted in Agile | 4 Comments

Living in the code

Posted on November 20, 2008 by Sarah

Someone shared an observation with me today regarding the way ThoughtWorkers talk when referring to classes. Apparently, we say “this guy” a lot; as in “this guy has the responsibility for that action”.

After thinking about it, I guess that’s what happens when you live in the code. (Or, just a habit that one person started which has infiltrated everyone’s vocabulary.)

Posted in Design | 1 Comment

Using Builders in Tests

Posted on November 18, 2008 by Sarah

An annoying part of writing a test is the amount of setup an object can need in order to use it within the test. 

public void ShouldCalculateVolume()
{
	Box box = new Box();
	box.Type = Cardboard;
	box.Width = 10;
	box.Height = 20;
	box.Depth = 40;
	Assert.AreEqual(8000, box.Volume)
}

However, there is a solution: builders. Builders help by allowing you to only setup the data relevant to the test, but still having a fully formed object. By chaining your methods, you also reduce the amount of lines required for setup. Another advantage of using builders is obvious when you start to refactor the object: instead of fixing all your tests because you have added a new mandatory field, you only have one point of failure.

public void ShouldCalculateVolume()
{
	Box box = new BoxBuilder().Width(10).Height(20).Depth(40).Build();
	Assert.AreEqual(8000, box.Volume)
}

public class BoxBuilder
{
	int width = 1;
	int height = 1;
	int depth = 1;
	Material type = Cardboard;

	public Box Build()
	{
		Box box = new Box();
		box.Type = Cardboard;
		box.Width = width;
		box.Height = height;
		box.Depth = depth;
		return box;
	}

	public BoxBuilder Width(width)
	{
		this.width = width;
		return this;
	}
	public BoxBuilder Height(height)
	{
		this.height = height;
		return this;
	}
	public BoxBuilder Depth(depth)
	{
		this.depth = depth;
		return this;
	}
}

Of course, my example is quite trivial and the only obvious benefit is that I put all the property definitions on one line. However, when you start adding other more complex objects (like perhaps those within your aggregate), then you have some powerful testing techniques under your fingers.

Posted in Testing | 2 Comments

Women in Technology – who cares? I do.

Posted on November 14, 2008 by Sarah

There is no denying that finding a women working in the field of information technology is a rare occurrence. At my current client, I have only seen 1 women in a sea of male developers; it was a similar story at my previous client. Luckily for me and my kind, ThoughtWorks wants to change this.

I find that a few people still have to be convinced that it is a good thing for women to be in technology. Why should we actively seek to improve the number of women in technology? Various people have answers which a supported by research and their findings, like Innovation is enabled best in teams which are 50:50 [1] and the fact that there is no difference in the abilities between males and females except for certain physical tasks like throwing a ball. But these are not my reasons why we should strive to get equal numbers of women and men in technology (although, they do help to convince those out there who say there is no problem).

Want to know my number one answer to why the number of men and women should be equal?

Why not. 

Unfortunately, not everyone likes the idea of actively recruiting more women. The most common outcry that I hear to that statement is “we want hire good people, not just hire someone because they are a women”. I am quite amazed at the number of times this statement arises. However, I agree with it. I don’t want women in my organisation just because they are female. But do these nay-sayers really believe that we would hire any just girl off the street without regard to their qualifications.

Increasing the number of women recruited is not about hiring any women who acts for a job; nor is it about discounting a potential hire because they are male. It’s about finding new ways to reach out to the technologists so the target audience has a higher percentage of women.

My final imparting note, for now, is to look around your workplace and answer these 3 small questions.

How many women do you work with?

Do you think that it’s acceptable?

What are you going to do about it?

Posted in women in IT | 8 Comments

Retrospectives for the code base

Posted on October 27, 2008 by Sarah

At the conclusion of a lot of projects, we conduct retrospectives in order to gain a deeper understanding of the success factors of the project, discuss what could be improved and how to incorporate these into future projects.

How many of these focus around the actual design elements of the software developed? I have not heard of any projects which have had a post-development analysis, so I can only conclude that it is through introspection that good developers learn and improve. I wonder why teams have not done this retrospective analysis, or if they have why I haven’t heard of it.

I am approaching the conclusion of my current project, so I will be keen to try a technical-only retrospective, where we take a look at the various patterns we employed, and how effective they were in solving our problems.

Posted in Uncategorized | 3 Comments

Recursive Trees

Posted on October 15, 2008 by Sarah

I like recursive algorithms, and I like trees (I mean the data structure, not the perennial wooden plant - of course I like them too). So today, I was very glad when I had the chance to implement one on my current project. 

The main construct of the tree is the node. Generally, the node is comprised of the data which describes the node, and a list of all children nodes. For example, in the tree below, node 6 (the circle with 6 in it) has the children node 5 and node 11, and has the data of 6.

There a certain descriptors of a tree, and their use is context specific. One such descriptor would be the root node – a node without any parents. The root node for this tree is node 2 (the one at the top). Another descriptor would be leaf nodes – nodes without any children. The leaf nodes for this tree are nodes 2, 5, 11 and 4. 

For my project, I had to create my tree from the data in a structure similar to : [ [7, 2], [7, 6, 5], [7, 6, 11], [5, 9, 4] ], where the root node was empty (not 2 as in this diagram). Creating the tree was easy with the help of a little recursion and the use of a stack.

public void BuildTree(List data)
{
	Node rootNode = new Node()
	for each (List treePath in data)
	{
		rootNode.AddChild(treePath as Stack)
	}
}

public class Node
{
	private string _name;
	private List<node> _children = new List<node>();

	public void AddChild(Stack path)
	{
		Node child = FindOrCreate(path.pop())
		if (path.Count > 0)
		{
			child.AddChild(path)
		}
	}

	private void FindOrCreate(string name)
	{
		Maybe<node> child = _children.Find(name)
		if (child.IsPresent)
		{
			return child.Force()
			// if you haven't seen my post on maybe objects, this will return the child node
		}
		return CreateChild(name)
	}

	private void CreateChild(string name)
	{
		Node child = new Node(name)
		_children.Add(child)
		return child
	}
}

Persisting this is not as complicated as we first thought. When kicking around persistence ideas, we talked about using Oracle’s parent-child recursive constraints. But, all you need is a Node table [int id; string name] which holds the data for each Node, and a mapping table (I called it a parentage table) [int parent_Id; int child_Id] which holds the relationship between parent and child node. Voila! No need of recursive constraints within the database layer.

Recursion is a really powerful tool, and as I proved to myself, trees are actually quite easy to persist.

Posted in Design | 5 Comments

What is Agile?

Posted on October 6, 2008 by Sarah

At the moment, it seems quite vogue to say your company is Agile. But what does it really mean? 

Before joining ThoughtWorks, I worked for a company which decided to go Lean. To the managers, they were doing all the right things – making Lean training courses mandatory; making every employee watch videos about it and answer quizzes; incentivizing waste reduction initiatives.

I asked my former colleagues the other day how all that Lean stuff was going. Their answer didn’t surprise me – nothing had changed in the organization, except now they have dual screens and they are getting faster machines.

The problem? The workers, the man-on-the-street saw the Lean initiative as YAIBUM (Yet Another Initiative By Upper Management). Lean processes were in place, the company called itself Lean but how can they really claim it if the employees do not believe it.

Being Agile is not about the procedures you have in place, not about how many black-belts you employee nor about which variant you choose to follow, and definitely not about marketing.

Agile is a philosophy; it is a way of thinking. It is about looking at what is happening in your environment and constantly assessing how to do it better. It is not the different methodologies like Lean, Scrum, XP or KanBan; these are merely tools which help you to improve. You can use one particular methodology, or parts from all of them – as long as you recognize that they are only guidelines and if they don’t work in a particular situation you should find one that does. One size does not fit all.

Next time someone/company/yourself claims to be Agile, double check – are they talking abut the way of being, or just some methodology?

Posted in Agile | 1 Comment

Are types of testing important?

Posted on October 2, 2008 by Sarah

The comments on my last post about acceptance tests have made me think a little more about testing, particularly the value in specifically declaring the type of testing you are doing. 

Unit testing is a method of testing that verifies the individual units of source code are working properly
http://en.wikipedia.org/wiki/Unit_testing

 

Integration testing…is the phase of software testing in which individual software modules are combined and tested as a group
http://en.wikipedia.org/wiki/Integration_testing

But what is the distinction between unit and integration tests? How granular do you make your unit tests? For instance, would you consider testing an aggregate object unit testing or integration testing? More importantly, what value do we get in declaring it.

When first learning how to write good tests, and learning about TDD and other wonderful testing practices, specifying what type of test you are writing helps define the boundaries of the test. Knowing this helps you know what objects to piece together to form the test for example to use a canned repository or use the real one. But once mastered, do you still need to explicitly call out the type. 

I understand that some people use these distinctions in their CI process – their CI build runs the unit tests first and then, only if they are successful, they run the integration (mainly database) tests, and then the “acceptance” tests. The main drivers for doing this are that, by their nature, unit tests are quite fast and so you fail fast; integration (and acceptance) tests are often too slow as they sometimes start up the whole framework, or talk to slow database connections.

If someone gave me these reasons I think I would run through the 5 Ys with them to make sure that the problem they were actually solving by separating out the integration tests was the correct problem. For instance:

Why do you run integration tests after your unit tests? Because they are slow and take a long time to run.
Why do they take a long time to run? Because Rails initializes the whole environment when testing.
Why do you need to initialize the environment? Umm…I guess I don’t need it for my tests…but Rails does it for me automatically.
Why don’t you remove this unneeded dependancy? Umm…..

That’s where I would probably stop with the questioning, because I would point them in the direction of George Malamidis‘s work around for fast unit tests. My point is that there maybe a better solution than separating the tests.

 

So, what value do we really get by explicitly declaring what type a test should conform to?

Posted in Testing | 1 Comment