Why agile software development is like teenage sex

Alexandre de Pellegrin writes: 

Today, Romain Gauthier (OCTO Technology, for the moment) sent me a funny post on Agile development. I really like Agile methods but it's so funny that I had to paste it here :

Why is agile software development like teenage sex?

• It's on everyone's mind all the time.
• Everyone is talking about it all the time.
• Everyone thinks everyone else is doing it.
• Almost no one is really doing it.

The few who are doing it are:

• doing it poorly
• hopeful it will be better next time
• not practicing it safely

Source:

http://javacolors.blogspot.com/2009/02/why-is-agile-software-development-like.html

The need for transparency in software development

David Cooksey talks about the Agile principle of transparency specifically in software development.

http://blog.thycoticsolutions.com/2011/04/14/the-agile-virtue-of-transparency/

Agile Development Principles To Live By

I'm currently reading an excellent book by Robert Martin (aka Uncle Bob) Agile Principles Patterns and Practises in C# (Prentice Hall).  I highly recommend it.
There is a fantastic list of agile principles in chapter 1, here's my synopsis of Robert's list.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
   The smaller the deliverable of software the higher the quality and the less risk of non-delivery.  The more often you can deliver the higher the overall quality. All deliverables are production quality code.
   
2. Welcome changing requirements, even late in the development. Agile processes harness change for the customer's competitive advantage. Embrace change, change is good, it demonstrates we have learnt more about the customer's needs. An agile development team should focus on software the is easy to change and maintain, simplifying the adaptive process. In my opinion I would also add to this, communicate the cost of change effectively to stakeholders as well; change does cost and whimsical change should be transparent and visible.
   
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. Each delivery should satisfy some customer need.
   
4. Business people and developers must work together daily throughout the project. In order to be agile there must be frequent interaction and assessment. A software project is not a fire and forget weapon.
   
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. People are always the most important factor in any software project, everything else is secondary and will not compensate for the wrong people on a project.
   
6. The most efficient and effective form of conveying information to and within a team is face-to-face conversation. Speech is a far richer and more concise form of communication over written forms, more information is imparted more quickly and with more detail. Documentation should be created incrementally, but only when NEEDED.
   
7. Working software is the primary measure of progress. The project is 30% done when 30% of all features needed are finished and delivered.
   
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.  It is not a 100metre sprint, its more like a marathon. Care should be taken not to over commit.
   
9. Continuous attention to technical excellence and good design enhances agility. High quality is the key to speed, badly written code generally leads to a do-over.  All team members must believe in and be committed to high quality and excellence. They do not create messes that they promise to fix next month.
   
10. Simplicity - the art of maximising the amount of work not done is essential.  Take the simplest path that is consistent with the team and project goals. They do not put a lot of importance on solving tomorrow's problems, nor do they try and defend against them today. Rather focus on writing clear quality code that is easy to change.
    
11. The best architecture, requirements, and design emerges from self organising teams. An agile team is a self organising team. Responsibilities should not be handed out, rather let the team decide and come to a consensus on decisions or let them choose who is best able to make these decisions if they feel they cannot contribute.  All team members should feel they have influence over decisions made.
    
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. The agile team knows that its environment is constantly changes and the best processes from yesterday may not still be best.
    

This post is meant to be a quick reference of valuable Agile information.

References:

• Agile Principles Patterns and Practises in C# (Prentice Hall)
• www.controlchaos.com
• Clarus Consulting (Thanks to Ed and Bruce for all their valuable advice and help over the last few months).

How to show a dialog in MVVM

In Mvvm you do not want direct references from your controllers (aka View-Models, I find it easier to call them controllers for simplicity).  This means you don't want code that specifically calls Window.Show or MessageBox.Show.  The reason is basically two-fold:

1. First you will be unable to unit test the controller.  Message-boxes or Dialogs popping open will halt the test.
2. If you decide to share some code with another project that uses a different UI technology, then not following Mvvm explicitly will prevent this. Also common is stakeholders changing their minds.

The solution is to make use of an Inversion of Control container (aka factory).

Message Box Usage

Message boxes pose a problem for unit testing because when open they block the thread from completing, meaning user intervention is required to continue a test. This is not acceptable. To circumvent this, MessageBox use can be accessed via an interface.

private IMessageBoxService backingMessageBoxService;

public IMessageBoxService MessageBox {

    get {

        return this.backingMessageBoxService ?? (this.backingMessageBoxService = new WpfMessageBoxService());

        }

        private set {

            // Provided for testing

            this.backingMessageBoxService = value;

        }

    }

}

The above code works in production, but during testing a mock will need to be injected into the MessageBox property.

        [Test(Description = "The save action should trigger a message box")]

        [Timeout(500)]

        public void SuccessfulSaveMessage() {

            var controller = new FormController(new ContactDataServiceStub());

            var accessor = new FormController_Accessor(controller);

            var messageBoxMock = new MessageBoxServiceMock();

            accessor.MessageBox = messageBoxMock;

            // Click the save button in the same way the View xaml would in production.

            controller.SaveCommand.Execute(controller.CurrentContact);

            Assert.IsTrue(messageBoxMock.WasShowCalled);

        }

public interface IGlassDemoDialog {

    event EventHandler Closed;

    void Show();

}

And from within your controller you can get a reference to the dialog through the use of an object factory (or using an interfaced property shown previously in this document).

var glassDialog = ObjectFactory.Container.GetInstance<IGlassDemoDialog>();

glassDialog.Show();

This of course assumes you have a registration with the object factory either in the app.config or in startup.

ObjectFactory.Initialize(init => {

    // Other config lines here

    init.For<IGlassDemoDialog>().Use<WpfGlassWindowDemo>();

});

Finally, your custom interface must be implemented by your View.

public partial class WpfGlassWindowDemo : Window, IGlassDemoDialog { }

[Test]

public void ShowGlassWindowTest() {

    var controller = new RighthandController();

    var mockRepository = new MockRepository();  // Rhino Mock

    var dialogMock = mockRepository.StrictMock<IGlassDemoDialog>();

    dialogMock.Expect(dialog => dialog.Show());

    mockRepository.ReplayAll();  // Prepare mocks.

    ObjectFactory.Initialize(init => {

        init.For<IGlassDemoDialog>().Use(dialogMock);

    });

    Assert.IsTrue(controller.GlassCommand.CanExecute(null));

    controller.GlassCommand.Execute(null);

    mockRepository.VerifyAll(); // Guarantee all mocks were used appropriately.

}  

Hosting WCF Services Outside IIS - Access Denied

If you are hosting a WCF services in a console app, windows service or any other non-IIS application, you need to listen on a particular url address. A normal user running an app or service doesn't have permission to do this unless that user is an admin (not a good thing for a wcf service). So in order to grant permission to reserve the namespace, you need to run a little command.

For IIS 7 (Vista/7 and Windows Server 2008)

netsh http add urlacl url=http://+:80/MyUri user=DOMAIN\user

The other commands are detailed here: http://msdn.microsoft.com/en-us/library/ms733768.aspx

The error you'll get if the user does not have this right is:

System.ServiceModel.AddressAccessDeniedException: HTTP could not register URL http://+:80/serviceurl/. Your process does not have access rights to this namespace (see http://go.microsoft.com/fwlink/?LinkId=70353 for details). ---> System.Net.HttpListenerException: Access is denied
at System.Net.HttpListener.AddAll()
at System.Net.HttpListener.Start()
at System.ServiceModel.Channels.SharedHttpTransportManager.OnOpen()
--- End of inner exception stack trace ---
at System.ServiceModel.Channels.SharedHttpTransportManager.OnOpen()
at System.ServiceModel.Channels.TransportManager.Open(TransportChannelListener channelListener)
at System.ServiceModel.Channels.TransportManagerContainer.Open(SelectTransportManagersCallback selectTransportManagerCallback)
at System.ServiceModel.Channels.TransportChannelListener.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.HttpChannelListener.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Dispatcher.ChannelDispatcher.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.ServiceHostBase.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open()
at ...


Incidentally, this is one of the best cases of a stacktrace containing a useful link that will help you solve the problem.

Reference:

AspNet Weblogs

WPF Is Dead

Will Silverlight 5 replace WPF? Silverlight has been fast approaching the functionality of WPF for sometime now.  Out-Of-Browser support, arguably the richest 3D functionality in a browser, the fastest language to code line of business apps.

But Microsoft gave some pretty damming signals about Silverlight in the last 18 months.  But at MIX11 the tune seems to have changed...

http://www.infoq.com/news/2011/04/Silverlight-MIX

And this from Microsoft's Product Manager for Silverlight Scott Barnes:

“Right now there's a faction war inside Microsoft over HTML5 vs Silverlight. oh and WPF is dead.. i mean..it kind of was..but now.. funeral.”

"Right now WPF has no Microsoft Product Manager. The rise and fall of Microsoft UX Platform. My thoughts on how such an amazing potentially game changing thing, just failed due to internal politics etc."

"WPF however has more ubiquity than Silverlight today, it’s got approx. 70%+ ubiquity in Windows based machines and furthermore it’s gotten deeper traction when it comes to Independent Software Vendors (ISV’s) so it presents quite a complex problem in around investment and it’s overall future.

On one hand, it’s pretty widely known within the company that WPF has been ear marked for death for quite some time and had it not had such prolific ubiquity or ISV’s that build software used by many on it (Autodesk 3DSMAX, Visual Studio, Expression etc) it would have been taken out back and shot long ago. It simply is too hard to kill, so the only way Microsoft to date knows how is to either spend majority of its focus on convincing developers that Silverlight is the better option and/or reduce the noise around WPF altogether hoping that others will pick up on the subtle tones that it’s better you don’t adopt but under the Smokey hazed veil of the a-typical response “It depends”.

WPF has no investment, it’s kept together by a skeleton crew and its evangelism / community efforts have little to no funding attached to it. It’s dead, the question now is how is the corpse going to be buried and no amount of cheer leading will change that outcome in the near future."

Check out the rest of Scott's damning article here.

So... Silverlight and HTML5 is the future of all development on the Windows platform then?

Rest in peace WPF, WinForms will be there to keep you company on the other side.

MEF versus IoC

The Microsoft Extensibility Framework (MEF) has been around for a couple of years now and is used to allow extension to Windows applications without changing the original code (Recomposition).  It can be used with either Silverlight, WPF, and WinForms. MEF is not a replacement to PRISM. The PRISM toolkit to help you implement the MVVM pattern and is similar to MVVM Light or any of the other MVVM Toolkits. PRISM is also only intended for WPF and Silverlight.  So what is MEF?  The MEF Website describes it as
"Application requirements change frequently and software is constantly evolving. As a result, such applications often become monolithic making it difficult to add new functionality. The Managed Extensibility Framework (MEF) is a new library in .NET Framework 4 and Silverlight 4 that addresses this problem by simplifying the design of extensible applications and components."


I've been a long standing fan of IoC, and after reading many articles about MEF and writing a few test applications, there seems to be a cross over with IoC.  IoC is far more generic and is a more broad pattern to use across your entire system, whereas MEF is specifically targeting extending and recomposition of the UI.  So where's the cross over?  MEF is a kind of object factory (aka container), it makes replacement of UI Views and Controllers (aka View-Models) easy.  By decorating a public property with an attribute the MEF framework with find all subclasses of (or a chosen one) and instantiate it and inject it into the property.  Very much like an IoC container.  But MEF does have some cool features for searching application folders for runtime add-ins etc.  But so does StructureMap.

Here's an excellent comparison from MSDN:

Journal Article.

My take on it, is MEF will suit people new to IoC better, and might be more approachable. The documentation for MEF is pretty good, better than StructureMap's documentation for sure.  Using a mature feature rich IoC container like StructureMap however you get most of the functionality of MEF, but it requires a little more work to use. But it gives you the advantage of a unified approach and good consistency.

Object Oriented Software Design Principles - Refresher

I was caught out the other day when it would have been really useful to remember more specifics around the fundamental software design principles. I thought it was time I refreshed my memory since my last post on the topic.

Software design principles are not things that change as often as technology and toolkits and it seems odd to me that its not as cool to learn about modern best practise and established principles. Most developers learn over time a "gut feel" of when code smells right or not.  But when quizzed to elaborate why, struggle to do so.

SOLID is a great acronym to remember; it covers most of a developers "good sense of smell".

• S - Single Responsibility Principle - the notion that a class should have a single responsibility or strong theme. This also (at least in my opinion) covers the Separation of Concern principle. The intention is to make it clear what a class does, where to put new code, and to keep class size small and easy to comprehend. Avoid the God-Object anti-pattern; a large be-all-and-do-all large object.
  
• O - Open / Close Principle - Classes should be open for extension but closed for modification. The basic idea is to intentionally design how a class can be legitimately extended. Don't allow unintended or accidental modification. For example, seal your classes unless you know its legitimate to subclass; carefully control your public interfaces, don't make all classes public as a matter of course.
  
• L - Liskov's Substitution Principle - the notion that “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”. To a certain extent this is a given in .NET; any argument type that is not sealed, including interfaces, any subclass can be given as that argument.
  
• I - Interface Segregation Principle - the notion that “many client specific interfaces are better than one general purpose interface. I also interpret this to mean interface separation between classes is far better than "welding" classes together directly. But also reinforcing the SRP and SoC principles of preferring many small tightly themed interfaces.
  
• D - Dependency Inversion Principle - When adding related dependent objects to an object, reference them by abstractions (interface or abstract). This way any object in the system can be substituted with a test object or a future replacement.

Some behavioural practises:

DRY - Don't Repeat Yourself. 

Don't write the same piece of code twice. A modification should not need to be performed in two places.

KISS YAGNI - Keep It Simple Stupid You Ain't Going to Need It. If you don't need it now, don't write it now. Most of us developers are guilty of over engineering that borders on making a class or library less usable.

Occam's Razor - Refers to a process of shaving away assumptions (and possibly risks) from two or more competing hypothesis to leave the best with the least assumptions and therefore the highest chance of success.

References:

• Wikipedia GRASP
• Occam's Razor
• Wikipedia SOLID