blogs.conchango.com

Here is the slide deck I presented at the Microsoft Architect Forum yesterday. I've included the notes I wrote for those who want links to books and tools I mentioned. Keep an eye on Colin's blog for the first half and his responses to the questions raised in the Q&A session.

The last project I worked on had two major deliverables

1. To deliver a new inventory management system for the client
2. To mentor and train their developers, who had no previous .NET or OO experience but were AS400 / Cobol programmers.

The biggest improvement we found in the quality of their code was after we started exposing them to solid engineering practices.

Just because you are being Agile – doesn’t mean you should abandon good architectural principles – being Agile does not mean being a cowboy.

Design Fundamentals:

1. A class should have only one reason to exist (and so change).  Classes should be really simple and do really simple things.
2. Software entities should be open for extension, but closed for modification. Where extension is by inheritance (not always a good idea), this may break the ‘rule’ that all classes should be sealed unless absolutely necessary. See Decorator / Observer Patterns - a good book in this area is Head First Design Patterns.
3. Fat interfaces subject clients to changes in that interface to accommodate other clients’ needs. Separate out thin interfaces

See Robert C. Martin’s book Agile Software Development, Principles, Patterns, and Practices: for more info

Good Architecture will aid flexibility & minimise impact of change:

Because you don’t have a complete upfront spec – you should be thinking about the change that is coming. Therefore Layering and Encapsulation. Define the behaviour via interfaces – the implementation is not that important.

For example – if the system your are developing on currently talks to an AS400 but you know there are plans within the next couple of years to migrate to SQL Server – make sure you wrap all you data access in a layer – so only that will have to change if the migration ever occurs. We used an adapter and transformation pattern to isolate the AS400 idiosyncrasies – it proved very useful – and later on in the project we had to produce an entirely separate site hosted on a totally difference server – we swapped out the as400 adapters for web services and managed to use all the layers above with 0 changes.

Patterns & Frameworks:

Implemented role-based security via AzMan - which comes installed on Win2k3 server – when the security framework it was checked in suddenly some of the developers were locked out of the site – the reason being that they were running XP rather than Win2k3 Server – which doesn’t have AzMan inbuilt. Luckily I designed the security system using a provider pattern – 45 mins later I had created a Web Service on the development server to wrap the AzMan calls and implemented a AzManWebServiceProvider, which was invoked (via a config file setting) instead of the default AzManProvider, the developers running XP had their credentials passed over the WS and were authenticated that way.

• One of the facets of Scrum is that you work in 4 week time boxes called sprints.
• You have to deliver production level quality code every 4 weeks.
• “Nothing focuses the mind as the hangman’s noose” – so you have to think about how you can deliver successfully.

One of the best ways to do this is to design your architecture around tried and tested design patterns.

More than likely the problems you will encounter in your solution have been faced and solved by someone else - why re-invent the wheel - use patterns.

See Martin Fowler – Patterns of Enterprise Application Architecture and Steven Metsker Design Patterns C#

Good engineering practices will help you produce better quality code – with fewer bugs and assist you to meet your 4 week deadline.

In an Agile project developers have a lot more visible responsibility – they have more decisions to make, especially in Scrum where the team decided exactly what it can and can’t do within any given 4 week time box and because of the lack of a formal up-front specification document – the developer assume the role that was traditionally occupied by a business analyst

So if more of their time is being taken up with problem solving – how do we make sure they are also producing the best code they can?

Source Control – not only the use of source control, but the best practices around this – don’t leave items checked out over night – see James Simmonds' BuildUtilities.NET – includes sendMSN application which will all the developers a reminder via msn messenger telling them to remember to check everything in by 17:30.

Code Reuse – if you’ve got 4 weeks until you have to stand up in front of a room full of your bosses – are you going to decide:

1. that now is the perfect time for you to write that ADO data access block you’ve always dreamed of doing – or
2. are you going to use the one supplied, free of charge, by Microsoft?

QA Tools – Tools to check the quality of your code

• FxCop
• devAdvantage
• Red Gate Ants Profiler

Scrum Meetings – these are the daily meetings where all developers say what they were doing yesterday, today and what are their problems – this was included because it was seen as the best mechanism for letting everyone know what development tasks were being carried out – which leads to higher visibility of similar problem solvings, stops people from developing the same code. For information about starting to use Scrum look here .

Automated daily build – at least once a day a full automated build of the solution should occur – complete with all build verification tests, automatically generated documentation (NDoc), building of installer packages. This can only work properly if developers are following the source control best practices and check in their work before they go home. This can generate a large saving in man hours - on one project we had a dedicated "Build Master" who's entire job was to create adnn deploy build - not a very interesting job and creates a large dependancy (illness / holiday). All of those build steps can be automated - this will also have the added benefit of reducing human errors (distracted by a phone call when doing a build).

Build Tools to use:

• Microsoft SDC Build Tools - inbuilt support for IIS 6, SQL Server, BizTalk, Commerce Server, ACL and can also be integrated into MSI files - upgrade path to MSBuild
• NAnt

Installer Tools:

• WiX - Microsoft Open Source project - an XML based installer toolset
• NSIS - Nullsoft Scriptable Install System - very light weight installer technology - very customisable, very powerful.

Group Design – eXtreme Whiteboarding – use of UML like class, object and sequence diagrams, but sketched out really quickly – if you are lucky enough to be in a good – agile friendly environment such as a war room – then while you’re sketching this out other developers are free to contribute / pick holes – by the time you’ve finished – it’s already been peer reviewed and accepted by everyone in the room.

Unit Testing – unit testing is king – it’s the most fundamental of the more advanced practices. Every developer has written a test harness – whether it was a windows application littered with textboxes and dropdown list in VB 6 – or a console app in .net. Now thankfully we have a much more elegant solution in NUnit or another application that is gathering more support – MBUnit. Unit testing is much improved in VSTS. TestDriven.NET has just been released - it integrates directly into VS.NET 2003.

More on the importance of unit tests on the next slide

Refactoring – the process of cleaning up and improving code internal code – to reduce complexity and the cost of future maintenance. Technical Debt. Requires unit tests – otherwise you’ll fear making any changes, because you won’t know if those changes have broken any pre-existing functionality. One of the reasons refactoring is so important is that you generally only understand the entire problem space once you’ve solved it. In test driven development the mantra is red, green, refactor .

The seminal book is this area is Martin Fowler’s Refactoring. If you go to refactoring.com there are a list of links – one is the brilliant “table of smells”
Recently another excellent refactoring book is Joshua Kerievsky’s Refactoring to Patterns – published as part of Addison-Wesley Signature Series.

Peer Review – the whole is greater than the sum of it’s parts – many of the positives of group design – but at a much lower level – instead of being about the design – you are analysing the actual implementation of the design. Means that no matter what the quality of the developers on the team – the work they produce will be good.

Continuous Integration – the whole automated daily build is run every time a developer checks in their code. This practice had the single largest effect on the team – one of the problems the developers were having was making sure their source compiled before they checked their work in – we used to get broken builds 2 / 3 times a day – this would kill productivity – which is not good when you have a deadline a few weeks away – when you have a large team a broken build can burn up and waste man hours at a frightening rate of knots. CI works well because of the introduction of peer pressure – when a build fails the entire dev team is emailed – saying that the build is broken and lists the recent items that have been checked in, and the developer responsible for checking them in. A nice dunce stigma is attached. Within the first week of introducing it – we had achieved out objectives – we reduced the number to 0. 

Tools to use:

• CruiseControl.NET – it has a very useful webdashboard that allows you to see the state of your build and it allows you to display the results of the build process – i.e. the unit test, code coverage and FxCop results.
• Draco.NET - this has recently been updated and now includes a webdashboard, sys tray app etc.

Going back to James Simmonds' BuildUtilities.NET – he released a version last week – if the build fails – all the developers will be msn’d a message saying the build has broken or the unit tests have failed.

The zenith – Test Driven Development - a practice that comes out of XP – you write the tests before you write the code.
A great book is Test-Driven Development in Microsoft .NET by James Newkirk (who originally worked on NUnit) – now works for MS and is working on the unit testing capabilities of VSTS

What’s missing from the Pyramid? – wiki’s & code generation.

What is a wiki? - Invented by Ward Cunningham – simple CMS system – think of it as Notepad for the web. We use it to store all dynamic context generated from a project - such as "how to do a build" - the document is created by one person - then passed onto the next - who will try and perform a build using the notes - and will fill in any errors or missing steps. This process continues until ever developer in the group has had a go - the document should now be perfect guide describing the process from the lowest common denominator's point of view.

• FlexWiki is a very good .NET wiki implementation. You can download the binaries here.

Code Generation – incredibly powerful, but people can be very scared of it. But many don’t realise that they use it every day – when they fire up VS. Hopefully this will become more and more accepted once VSTS is released – the class designer is a perfect example of how powerful and time saving code gen can be.

Take a look at CodeSmith – has asp.net like syntax – can generate any ASCII file. I Demo’d it to our .NET Community – they were very dubious, until I ran one of the examples that comes with the tool against a database – it generated all the CRUD operations for the entire database in under a second – over 2000 lines of code from 74.

Many of these Engineering Practices are in VSTS - here is a  list of tools affected / outdated by Team System.

What have we done with the Pyramid? – We’ve used it as a focus for our .netfusion solution – a culmination of almost 5 years of .net experience – we’re covering off all the layers of the pyramid –

• Class Library for code reuse - 15,000 lines of code,
• Knowledgebase of "how to" documents (unit testing, code coverage etc)
• Project Accelerators that speed up the development process – including a build system that installs and configures all the tools – reduces 15 man days work to a few minutes – essential as all this set-up work has to occur during the first sprint.
  

Why can Unit Tests be important for Agile?

Because….

If you code your unit tests properly (using coding standards / naming conventions)…

• NCover (GDN version NOT Sourceforge)
• Microsoft SDC CoverageEye.NET 2.0

Again code coverage is now a integrated part of VSTS – which is good as it’s quite tricky to set up.

As you can see only 50% of the Top method was executed  - using the NCover you can see that the reason only 50% was executes – is that we’ve tested to see what happens when the stack is empty, but not what happens when the stack has items.

If you want a full tutorial see my article Making Code Coverage more palatable with NCoverViewer and NCoverBrowser.

Code coverage sounds great? It does have its good and bad points…

*http://www.iunknown.com/000415.html
See Also How to Misuse Code Coverage for more information