fuzzelogic Solutions

April 25, 2009

Projects: what causes failure

Filed under: Programming, projects — Tags: , — admin @ 6:05 pm

So we’ve all been there. The new project excitement, requirements, saying we learnt from the last failed project. We have agile, scrum, xp, lean etc. So why do we still get failed projects.

A google search on “why software projects fail” reveals around 20,100,000 hits. It does seem like the situation is here to stay. As an industry that works around analysing a problem and finding a solution, can we not fix this ?

What are the key factors that cause projects to fail? This is an open question, so feel free to add to it.

Seems like most lists out there favour the following as key factors…

  • Poor requirements
  • Poor practices
  • Changing requirements
  • Lack of understanding requirements
  • Lack of ownership.
  • Lack of communication
  • Lack of knowledge
    • programming
    • methodologies
    • domain
  • Lack of planning

To me the success factors seem obvious …

  • Requirements - If we understand what’s “poor requirements”, can’t we get better ones?
  • Communication - developers, steakholders, project managers, development managers…
  • Share knowledge -
    • ensure everyone knows the what, why and how.
    • Understand the techniques and methodoligies used - not just the words
    • collective code ownership : everyone should share responsibility for the quality of the code

This is a recurring problem within our industry, so why can’t we fix this?

April 16, 2009

Open closed principle

Filed under: OO, design — Tags: , , , — admin @ 5:17 pm

O.C.P : Open closed principle….
       an object is open for extension but closed for modification.

So to understand what this means, lets consider the following scenario - (There’s a bunch of code).

We have a product entity, and we can get lists of these back from our repository.
The Requirement for Today: we’re asked to create a filtered list of products that match a certain color, so we create the following product filter class, who’s job it is to filter the list.
     

public class ProductFilter{
               public IEnumberable<IProduct> GetItemsMatchingTheColor( IEnumerable<IProduct> fullList, Color color) {
                   foreach ( var item in fullList )
                       if ( item.ItsColor == color);
                            yield return item;
               }
           }

That’s fine, and it gets us what we want… but as we know, change is always around the corner….

Requirement a little in the future: we’re asked to get list filtered by Product size.

      
           public class ProductFilter{
              public IEnumberable<IProduct> GetItemsMatchingTheColor( IEnumerable<IProduct> fullList, Color color) {
                   foreach ( var item in fullList )
                       if ( item.ItsColor == color);
                            yield return item;
               }
               // Added this new method…
               public IEnumberable<IProduct> GetItemsMatchingSomeSize( IEnumerable<IProduct> fullList, ProductSize size) {
                   foreach ( var item in fullList )
                       if ( item.Size == size);
                            yield return item;
               }
           }

so what did we do here??? well we cracked open the filter object added the new behavior and rebuilt it.

Requirement a little further in the future: we’re asked to get list filtered by Product size AND Color.

public class ProductFilter{
public IEnumberable<IProduct> GetItemsMatchingTheColor( IEnumerable<IProduct> fullList, Color color) {
                   foreach ( var item in fullList )
                       if ( item.ItsColor == color);
                            yield return item;
               }

public IEnumberable<IProduct> GetItemsMatchingSomeSize( IEnumerable<IProduct> fullList, ProductSize size) {
                   foreach ( var item in fullList )
                       if ( item.Size == size);
                            yield return item;
               }
               // Added this new method…
               public IEnumberable<IProduct> GetItemsMatchingSomeSize( IEnumerable<IProduct> fullList, ProductSize size, Color color) {
                   foreach ( var item in fullList )
                       if ( item.Size == size &amp;&amp; item.ItsColor==color);
                            yield return item;
               }
           }

so what did we do here??? well AGAIN we cracked open the filter object added the new behavior and rebuilt it. Although we managed to extend the behavior of the object we violated the OCP. What are the benefits of OCP? Well by following the principle we have 2 benefits:
               1. Objects are extensible which will satisfiy changing requirements
               2. Objects are maintainable and stable, because they didn’t change, there’s less chance of introducing bugs.

So how do we do this, how do extend something without cracking it open?(one way)….

If if we consider a few design principles… encapsulate what varies: in this case the filter specification. (I’ll also sneek in the specification pattern here)

    /// <summary>
    /// Interface to be implemented by objects that act as specifications
    /// </summary>
    /// <typeparam name=”T”></typeparam>
    public interface ISpecification<T>
    {
        bool IsSatisfiedBy(T item);
    }

    /// <summary>
    /// Interface to be implemented by objects that support filtering
    /// </summary>
    /// <typeparam name=”TypeToFilter”></typeparam>
    public interface IFilter<TypeToFilter>
    {
        IEnumerable<TypeToFilter> Filter(IEnumerable<TypeToFilter> completelist, ISpecification<TypeToFilter> specification);
    }

// For completeness of the sample….

    /// <summary>
    /// The Product interface.
    /// </summary>
    public interface IProduct
    {
        string Name { get; set; }
        Color ItsColor { get; set; }
        ProductSize Size { get; set; }
    }

    /// <summary>
    /// Enum defining the sizes
    /// </summary>
    public enum ProductSize
    {
        Small, Medium, Large, ReallyBig
    }

Now the refactored Filter object.

    /// <summary>
    /// The Filter class
    /// </summary>
    public class ProductFilter : IFilter<IProduct>
    {   �
        public IEnumerable<IProduct> Filter(IEnumerable<IProduct> completelist, ISpecification<IProduct> specification)
        {
             foreach (var product in completelist )
                 if ( specification.IsSatisfiedBy ( product ))
                     yield return product;
        }
    }

Now we have a Product filter object that accepts a complete list of products and specification that we can filter on. All we need to do now is provide the filtering specifications.

    #region -[ Specifications ]-

    /// <summary>
    /// Individual specification for a color filter
    /// </summary>
    public class ColorFilterSpecification : ISpecification<IProduct>
    {
        Color colorToMatch;

        public ColorFilterSpecification(Color colorToMatch)
        {
            this.colorToMatch = colorToMatch;
        }
        public bool IsSatisfiedBy(IProduct item)
        {
            return item.ItsColor == colorToMatch;
        }
    }
    /// <summary>
    /// Individual specification for a Size filter
    /// </summary>
    public class SizeFilterSpecification : ISpecification<IProduct>
    {
        ProductSize sizeToMatch;
        public SizeFilterSpecification(ProductSize sizeToMatch)
        {
            this.sizeToMatch = sizeToMatch;
        }
        public bool IsSatisfiedBy(IProduct item)
        {
            return item.Size == sizeToMatch;
        }

    }

    /// <summary>
    /// Without exploding this into a full blow specification pattern
    /// where you can “chain” specifications together in .. AND, OR..etc
    /// a very basic “And” specification
    /// </summary>
    public class AndSpecification<T> : ISpecification<T>
    {
        ISpecification<T> first;
        ISpecification<T> second;

        public AndSpecification(ISpecification<T> first, ISpecification<T> second)
        {
            this.first = first;
            this.second = second;
        }
        public bool IsSatisfiedBy(T item)
        {
            return ( first.IsSatisfiedBy(item) &amp;&amp; second.IsSatisfiedBy(item));
        }
    }

    /// <summary>
    /// Without exploding this into a full blow specification pattern
    /// where you can “chain” specifications together in .. AND, OR..etc
    /// a very basic “OR” specification
    /// </summary>
    public class ORSpecification<T> : ISpecification<T>
    {
        ISpecification<T> first;
        ISpecification<T> second;

        public ORSpecification(ISpecification<T> first, ISpecification<T> second)
        {
            this.first = first;
            this.second = second;
        }
        public bool IsSatisfiedBy(T item)
        {
            return (first.IsSatisfiedBy(item) || second.IsSatisfiedBy(item));
        }
    }

    #endregion

And to test all this actually works, here’s a very basic set of tests using MSTest built into the Visual studio

using System;
using System.Text;
using System.Collections.Generic;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;
//using Reference to where your code lives.
using System.Drawing;

namespace _Tests_For_OOConcepts
{
    /// <summary>
    /// Summary description for FilterTests
    /// </summary>
    [TestClass]
    public class FilterTests
    {

        IEnumerable<IProduct> complete_list;
        IEnumerable<IProduct> results;
        IFilter<IProduct> System_under_test;
            �
        [TestInitialize]
        public void startup()
        {
            complete_list = Fake_list_of_products();
            System_under_test = new ProductFilter();
        }

        [TestMethod]
        public void List_only_contains_items_of_a_specified_COLOR()
        {
            results = Action_the_system_under_test_with(new ColorFilterSpecification(Color.Orange));

            foreach (var item in results)
                Assert.IsTrue(item.ItsColor == Color.Orange);
        }
    �
        [TestMethod]
        public void List_only_contains_items_of_a_specified_SIZE()
        {
            results = Action_the_system_under_test_with( new SizeFilterSpecification(ProductSize.Small) );
            foreach (var item in results)
                Assert.IsTrue(item.Size == ProductSize.Small);
        }
    �
        [TestMethod]
        public void List_only_contains_items_of_a_specified_SIZE_AND_COLOR()
        {
            var the_matching_criteria = new AndSpecification<IProduct>(new ColorFilterSpecification(Color.AliceBlue),
                                                                        new SizeFilterSpecification(ProductSize.Small));
                   �
            results = Action_the_system_under_test_with(the_matching_criteria);
            foreach (var item in results)
            {
                Assert.IsTrue(item.Size == ProductSize.Small);
                Assert.IsTrue(item.ItsColor == Color.AliceBlue);
            }
        }

        public IEnumerable<IProduct> Action_the_system_under_test_with(ISpecification<IProduct> the_filter_specification_to_use)
        {
            return System_under_test.Filter(complete_list, the_filter_specification_to_use);
        }
        public IEnumerable<IProduct> Fake_list_of_products()
        {

            yield return new FakeProduct(”apple”, Color.Red, ProductSize.Large);
            yield return new FakeProduct(”apple2″, Color.Red, ProductSize.Medium);
            yield return new FakeProduct(”orange”, Color.Orange, ProductSize.Medium);
            yield return new FakeProduct(”orange2″, Color.Orange, ProductSize.Large);
            yield return new FakeProduct(”bananna”, Color.Yellow, ProductSize.Small);
            yield return new FakeProduct(”bananna2″, Color.Yellow, ProductSize.ReallyBig);
            yield return new FakeProduct(”stuffed bear”, Color.AliceBlue, ProductSize.ReallyBig);
            yield return new FakeProduct(”stuffed bear2″, Color.Orange, ProductSize.Small);
        }

    }

    public class FakeProduct : IProduct
    {

        public FakeProduct(string name, Color theColor, ProductSize itsSize)
        {
            this.Name = name;
            this.ItsColor = theColor;
            this.Size = itsSize;
        }
    �
        public string Name {get;set;}
        public Color ItsColor {get;set;}
        public ProductSize Size { get; set; }
    }

}

So now we can vary the filter specification, add new specifications and extend the filtering object without actually modifying the source code of the Filter object.

Hope this helps
Zak

Object-oriented design principles

Filed under: OO, Programming, Uncategorized — Tags: , , , — admin @ 4:28 pm

A few design principles to get you going (which are in NO special order). In addition to the basic OO principles, here’s my pin up post on design principles to strive toward (I’ll add to this as we go along). 

  • Hide details of the implementation: Code to contracts and not implementations. Contracts are either abstract classes or pure interfaces.
  • Keep coupling to a minimum : a class can depend on native types (basic ints,bools etc) but should only depend on a select few peer classes. If the dependencies are high, consider this a smell and refactor to reduce the dependency. This can include creating new specialized types that are composed of the dependencies, but again this must be managed correctly.
  • Maintain maximum cohesion: a class should focus on a single concept.
  • Favour composition over inheritance: there’s a few different ways to get objects to collaborate – inheritance, composition, subscription through event handling.
  • Adhere to the Open closed principle: an object should be opened for extension (able to extend its behaviour )but closed for modification (while extending the behaviour you should not modify its source code)
  • Follow LSP where possible. Liskov Substitution principle: objects that have references to base types should be able to use derived types without knowing the difference. The basic concept behind polymorphism. TIP: design objects around behaviour and not data.
  • Use Inversion of control / Dependency Inversion principle :a formal definition: High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
  • Employ the Interface Segregation principle: Objects should not be forced to depend on interfaces that they don’t use.
  • Consider using the Law of Demeter : Only talk to your immediate friends, so the following would be considered a violation …
    • var payment= Client.Wallet.GetMoney(10.00);
    • This will be an interesting one to enforce if you plan on sticking to Domain driven design principles which suggest that you should get to entities through their aggregates.
  • Encapsulate the variations: when encountering variants encapsulate those bits that vary and make them first class citizens.
  • Consider using Factories for object creation.

The above are principles and guidelines and violating them in okay, but only if you understand why doing so is better than following them.

 Hope this helps!

 

 

 

 

Powered by WordPress