Aug 29, 2008

Do You Want An ALT.NET Group In Sydney?

I'm gauging interest on starting an ALT.NET group in Sydney.  I've tweeted about it, and posted on the altdotnet mailing list to see who might be a part of it and so far things are looking good.  I figure I might as well blog about it as well :-D

Now in case you don't know what I'm talking about, here's a definition of ALT.NET:

  • You’re the type of developer who uses what works while keeping an eye out for a better way.
  • You reach outside the mainstream to adopt the best of any community: Open Source, Agile, Java, Ruby, etc.
  • You’re not content with the status quo. Things can always be better expressed, more elegant and simple, more mutable, higher quality, etc.
  • You know tools are great, but they only take you so far. It’s the principles and knowledge that really matter. The best tools are those that embed the knowledge and encourage the principles

If you'd like to be a part of something like this, then leave a comment so I know who to get in touch with.

If there's enough interest to make it worth kicking off it'll then just be a matter of sorting out the logistics (i.e. finding a location, date & time, etc) and getting the message out.

Scrum Gathering on Monday & Tech.Ed Australia Starts Wednesday

Just a reminder of a few things happening next week.

First, there is a Scrum gathering on Monday night - http://www.scrum.com.au/2008/08/25/sydney-scrum-users-get-together-september-1 and it looks like the Syxpac user group will also be joining us.  It should be a fun night.

Secondly, Tech.Ed Australia starts on Wednesday.

If you're interested in seeing my session on building loosely coupled applications with Unity (ARC304), it's on Thursday at 11:45.  If you just want to catch up with me feel free to get in touch via the connect site, or email me.

It should be a long, tiring, enjoyable week :-)

Aug 24, 2008

Online Tipping

I just noticed a post by Seth Godin riffing that Ads are the new online tip jar.  He says that "If you like what you're reading, click an ad to say thanks." which resonates quite well with me because this is what I've started doing over the last few months.

It doesn't take much to click an ad, wait for a page to load, then use the browser back button and get back to what you were doing.  Takes a few seconds, and give the site creator something small in return.  It's an easier system than Sourceforge's donation mechanism, or the many forms of micro-payments (which just never seem to take off) so for now, clicking ads seems to be the best option.

Note: Whilst I do have ads on this site I don't want you to click them just because you read this post.  I'm not trying to drum up revenue.

Aug 22, 2008

Clone Detective for Visual Studio 2008

I just ran across a new project on CodePlex today called Clone Detective for Visual Studio from Immo Landwerth (also responsible for NQuery) and I've got to say that it's really quite cool.  I've blogged previously about detecting code clones with CCFinder but CCFinder is an external tool and a bit cumbersome to set up and use.

Clone Detective for VS may not be quite as powerful but it is incorporated into VS and is so much easier to use that it will probably become my tool of choice as a result.  It's so much better if you can detect your copy & paste development efforts in the same tool that you can fix them in.

Here's a quick screenshot of what it looks like:

image

We get 3 new windows we can look at (available from the View menu).

The Clone Explorer is where you initiate clone detection, and see results.  E.g. the AlternateTaxRules.cs file has 2 cloned sections.

The Clone Intersections looks at a file and shows you all the other files that share clones with it.  The different colours represent the different clones sections.

The Clone Results shows you an individual cloned piece of code and where it resides throughout the application (i.e. all the different files where  that same code occurs).

When you look at a file with clones you'll see a purple line next to the cloned lines (shown in the image).  By default visual studio just shows a single source file in the main window, however by dragging the tab with the filename in it to the right you can get to a side-by-side view which makes it so much easier to compare the clones before deciding it you should refactor or not.

From first impressions it looks to be a handy little tool and definitely one to keep in my VS toolbox.

Publish TFS Build Information to Twitter

I've put together a simple application to publish build status information from Team Foundation Server to Twitter.  It's built as a windows service that listens for the various build status events from TFS and tweets information depending on the event it receives.  At its core it uses the Readify.Useful.TeamFoundation.Common assembly from TFSDeployer for listening to the TFS events and the TwitterN library from amptools for talking to Twitter.

At the moment the application is still very much an alpha with things like error handling and customisation of messages not done as yet.  Even so, here's what some working results on Twitter:

image

If you're interested in getting a copy for yourself let then me know and I'll put the project up on codeplex.

Aug 20, 2008

An Introduction to Microsoft's ALM (Application Life-cycle Management)

Last year Microsoft launched the "Microsoft Application Platform".  The application platform is Microsoft's vision for how businesses can use Microsoft technology to improve information & knowledge management within their organisation and focuses on 5 key areas as follows, each of which wraps a number of Microsoft product & services offerings:

  • Business Intelligence
  • SOA & Business Process
  • Development
  • User Experience, and
  • Data Management

I'm not going to iterate through the various products that sit under each umbrella, instead I'm going to drill into the Development area as that's the one I find most interesting.

Development Platform

The Development area of the application platform is actually called Development & Application Life-Cycle Management, and normally gets tagged with the ALM acronym.  The good news is that this isn't just an attempt by Microsoft's to sell you on their tools (though obviously that's a major element of it) but it's also an acknowledgement that good processes and practices need to be followed to ensure that applications don't cost an arm and a leg to not only develop, but also to maintain in the future.

From a Microsoft ALM whitepaper comes this little gem: "Acquiring tools to support ALM, such as Microsoft® Visual Studio® Team System (VSTS), is straightforward. Introducing and driving an ALM strategy within your organization, and understanding the necessary changes required within your business, is more difficult."

The introduction section of the same whitepaper talks to the fact that project failures can be traced to a limited number of root causes described as:

  • Lack of visibility into project status
  • Ineffective Team Communication
  • Balancing Business Demands with Project Risk
  • Unpredictable Delivery Times and Quality

These are all valid and legitimate issues.  Issues which both traditional and agile development methodologies attempt to resolve.

What is ALM?

Microsoft's ALM offering is a combination of both development processes and supporting software to help automate whichever ALM provided process you follow.  In the ALM offering Microsoft have included processes for both agile and traditional development models.

Because technology is always on the move a normal development methodology won't specify what technology a team should use, just the processes and practices to follow.  A team can be using .NET, Ruby, Java, PHP, Cobol, whatever.  The difference with ALM is that even though it includes methodologies to follow, it also includes tools and technologies to support those methodologies - namely Visual Studio Team System (VSTS).

Knowing that VSTS is part of the Microsoft ALM offering it might be easy to fall into a trap of thinking that ALM is just VSTS by another name. It's not.  VSTS in and of itself does not require any specific development process.  It is designed to help you automate your development activities now matter what they might be.  How a team then uses VSTS is up to them.  In fact, you can easily find teams using VSTS that have a development process as loosely defined as "write code and see if it works".  That's not something that can be considered as ALM, simply because it fails to address the project management aspects of application development.

How Does VSTS support ALM processes?

So, knowing that VSTS is part of the ALM offering, how does it help? What should the ALM support tool offer us?

According to Wikipedia, ALM offerings are generally expected to cover the following features:

  • Requirements Visualization
  • Requirements Management
  • Feature Management
  • Modelling
  • Design
  • Project Management
  • Change Management
  • Configuration Management
  • Build Management
  • Testing
  • Release Management
  • Deployment
  • Monitoring and Reporting
  • Workflow

And VSTS offers support for all of these items.

Project Management, Requirements Management, Change Management, etc are all process/methodology related items and Team Foundation Server includes process templates for both agile and traditional development methodologies (the MSF Agile and MSF CMMI templates) as well as letting you plug in your own process templates if you wish to use an alternative methodology (e.g the Scrum template).

For more info on VSTS and how it supports ALM have a look at the Team System site.

 

It should be noted that Microsoft has an online assessment tool to help you gauge how well you are performing Application Life-Cycle Management.

Aug 11, 2008

Crunch Time

I was at client a while ago that were after any assistance they could get on a project exhibiting all the symptoms of a classic Death March project.  A waterfall based process gone horribly wrong, developers working ridiculous hours, poor code quality, emergency fixes, misunderstood and late-changing requirements, staff leaving due to stress and so much more.  It was all there.

I was originally going to write about how this all came about, but the more I thought about it the more I realised that how it came about wasn't really that interesting to me.  What was interesting was what crunch time revealed:

1. Communications.  The prevalent form of communication during crunch time was verbal, and typically face to face with a notepad or whiteboard handy.  Hardly any emails, hardly any paperwork, just people talking to people to ensure communications were clear and understanding was mutual.  Fast and effective.

2. Team work.  Pressure can do one of two things to a team - either break it apart or bring it together and form something stronger.  In this case it was the latter.  Watching how the team came together to support each other and achieve a result was fantastic.

3. Blurring of boundaries.  There is usually a very clear departmental delineation between the developers and the infrastructure people (i.e. the team responsible for the production environment).  This is the case in many large firms, however during this particular crunch period the line was much more "malleable" with people from both departments working extremely closely together to find problems and get things resolved as quickly and efficiently as possible.  Why developers couldn't have read-only access to production on a regular basis is still a mystery, but at least they overcame it during the crunch.

4. Impediment Removal.  The manager responsible for the development team did everything in their power to remove obstacles.  Whatever it took, they did it.  This ensured that the team could focus on delivering the project and that nothing else interrupted them.  At one point the CEO even picked people up from their homes to save them time on the commute.

5. One prioritised task at a time.  During the crunch all the remaining tasks were prioritised in a simple excel sheet.  Each developer took a task and worked on it, and nothing else.  No multitasking, no new jobs until the current task was complete.  This avoided the usual situation of having 5 tasks all active at once as trying to task swap between them as the mood takes you.  The excel sheet was communicated to everyone everyday so that all stakeholders were kept up to date on progress.

 

It's really interesting how crunch time forces you to genuinely prioritise what you do. How much regularly wasted time teams usually have and how much of that just isn't necessary when a deadline looms and just how effective people can be if you clear the decks for them.

What's even more interesting is that this is the sort of behaviour we want from an agile team each and every day of the year.  Just without the soul crushing pressure of a death march project :-)

Something to think about, isn't it?

What is a Unit Test?

I've talked about unit testing a number of times in the past, however I often do so with the assumption that we have a shared understanding of what a unit test actually is.

A unit test is simply a test that ensures that a single class does what it is meant to without needing to cross classes boundaries in order to execute, with the exception of using mocks and stubs.  This is often represented using the ACID acronym, commonly talked used when referring to database transactions.:

  • Atomic
  • Consistent
  • Isolated
  • Durable

A test that verifies multiple pieces of functionality is not atomic.

A test that changes results based on external factors (such as time of day) is not consistent.

A test that hits a database, file system, network or even interacts with other business classes is not isolated.  Neither are tests that need to be run in a specific order.

A test that fails if a config files isn't set correctly, or if specific data isn't available or breaks when other classes in the application change (not including the class under test) is not durable.

It's a pretty simple way of thinking of things.

And just to be really clear a test written using a unit testing framework (NUnit, MSTest, xUnit, etc) isn't automatically a unit test either.

 

So does that mean we should only write tests to meet this criteria.  Not at all! Just don't call them "unit tests".  They are integration tests. And they are absolutely required when testing your application.  Unit testing only one part of the overall testing picture.

As a note, when I write tests I typically store unit tests and integration tests in separate assemblies to make it clear what type of tests are stored in each.  And when I do TDD I will quite happily use integration tests as a part of the TDD process - but only after I have already done as much as I can with unit tests.

Aug 4, 2008

Should I Unit Test Private Methods?

I was talking with a team last week about unit testing and TDD and the question came up as to whether private methods should be tested.  I immediately said "no way" without any hesitation and was really surprised at the reaction from some of the team.  We had a very interesting chat about it, and I thought I'd put down my thinking here as well to see what you think.

Firstly I see unit testing as black box testing.  We should test our classes through their public and internal methods - i.e. from the viewpoint of a consumer of of the class; without any understanding of how that functionality may be implemented internally.

Next, the only reason for a class to have private methods is to support the public and internal methods of that class.  If there are private methods that aren't reached through public or internal methods then you have dead code and it should be removed.  Similarly, if you can't hit all of the code in your private methods through the public/internal methods then you have dead code in your method and it, likewise, needs to be removed.

Now, in order to test private methods your code needs to have some way of exposing those private methods to the test classes, meaning they can't actually be private methods in all situations.  They need to be private for release builds, but accessible for test builds.  You can try using compiler directives or some other mechanism to control accessibility however this is error prone and it's easy to accidentally release a version of an assembly with the private methods exposed as internal or public methods.  More often though you'll simply see people writing exposing methods that really should be private just to make it easier to test.  Not a design choice.

Further, tying tests to private methods makes your tests brittle.  If start to refactor a class I should be free to make changes to the private methods without impacting the externally exposed functionality of the class.  For example, if I rename an internal or public method I would expect tests to fail, but renaming a private method should have no impact on the tests and I would expect that they should continue to function correctly.

For me these reasons are reason enough.

 

So why would you want to test a private method?  The argument is something like this "If my public method does a lot of work - e.,g. setting up connections to databases and so forth, and my private method is just doing a small piece of logic then I want to test that the logic is correct without needing to go through all the other work."  It sounds like a reasonable argument but it's an argument that's only required when poor design decisions have been made.

A well designed class will do one thing and one thing only (the single concern principle) and will call out to other classes for functionality such as connecting to databases or file systems, etc.  By using dependency injection and programming to interfaces you can make testing much simpler by passing mock objects to the class under test without actually needing to do the work of connecting to a database for instance.  Not only does this help with the separation of concerns principle, but it also means my unit tests will actually be unit tests and not integration tests.  And by using mock objects they'll also be a lot faster to run.

 

So, what do you think? Leave a comment if you agree or disagree.  I'd like to hear your thoughts on the subject.