Category: Uncategorized

I had one of my best weekends so far, a weekend with wonderful .net developers. On Saturday, there was Openspace Coding Day and on Sunday
Alt.Net UK Conference. Grateful for EMC Cohango for hosting and Thoughtworks for Sunday lunch.

---

As open space coding day is supposed to be an unconference, there was no keynote speaker, no PowerPoint, and people were expected to offer a subject that is in their interest zone, without being an expert on it. The fundamental rules are:
– Whoever shows up is the right group
– Whatever happens is the only thing that could have
– Whenever it starts is the right time
– When it’s over, it’s over.

My choices were for IoC with MVC 2.0 for morning session, and MVC 2.0 with Spark for the afternoon session.

For IoC session, Autofac was the main subject to be discussed in the session, and discussed the benefit of IoC and why should we use?
After two hours, we could not find the reason that every project should use an IoC tool, i.e. Autofac, WindsorCastle, or Spring, or Unity; however we end up with lots of learning:
— As you apply the fundamental philosophy behind the loosely coupled components, you may not need a tool to take care of it.
— IoC and Dependency Injection are not the same thing.
— Once you register your container [at the start up of project], you don’t have register again.
— There are nice open source projects, i.e. an ecommerce project suteki you can check if you want to look at.
— There is a nice open source tool for easy installation of an open source project, hornget that I will try asap [after lots of praise].

MVC 2.0 and Spark session benefited from Jeremy’s inputs, and we followed ScottGu’s MVC 2.0 article and then spark was the popular view engine.

---

On AltnetUK day, I had “Software as Art” which forces me write another blog on that. The main discussion was around what makes it different software engineering process from an engineering process and art… My concern is I can’t see the design part, since if we are going to create artisan table, not an assembly line produced table; who is going to pay it, or how should we market it? [Yes, it will cost much more…]
Then, “What if your company renamed Waterfall as Agile?” was a discussion about why we should be using it, and if we have enough pain in the development process without being agile, how can we improve the process [without telling you are doing agile]. Nice inputs were
— If you can’t change your company, change your company by Fowler
— Don’t tell you want to do agile, do agile and tell them it is waterfall [start being agile].
— By picking up the most important parts first and delivering those parts will improve the process with small frequent shipments.
— Creating documents, reports won’t help software to be better! [believe in hearth]
— Lean Thinking is a nice to book to start thinking in agile…

Can’t finish without adding the idea of @serialseb: to rename altnet as alternative group, since we are all developers and we should be able to switch between languages/platforms [which should give us more power in terms of awarenes what we have and we are missing…]

All in all, it was wonderful as:

1. Sharing knowledge is helpful
— Looking into new technologies/tools expands your understanding, especially you are in a company does not use the latest technologies, and you are learning/trying them on your own…
— Any book/article you have to read gets high priority on your waiting list [or gets into your zone at least].
2. Sharing experience is priceless
— “How did your project fail?” is not a question everyone would share in your company, but here it starts discussions with twenty people with lots of feedback that you can take back.
— The pitfalls on software projects on a broader view, gives you more question to ask for your own project.
— There are always gaps to improve, and this kind of activities let you see the gap! [Rest depends on you]
3. Hearing other people’s questions/worries on a subject makes it more interesting and you start to question in a deeper philosophical sense.
4. Have the chance to meet and discuss with the people that you follow their blogs, i.e. @JeremySkinner,@serialseb, @gojkoadzic and their inputs were incredibly useful for both days.

To minimize the risk, to deliver a successful project, teams look for a methodology that they can rely on. Most of the development methodologies started with the idea of manufacturing systems: “X delivers high quality, efficient and excellent products applying Y methodology, why we can’t?”
X is one of Japanese companies, and Y is applied on assembly line. But since, we can convert a developer into a computer, we can apply the same logic, can’t we?
Both have project plans, design and production phases. Both have quality assurance, and apply TQM principles.
They should have budget, risk analysis and decision phases…
However, software projects have unique products per projects, where manufacturing companies are producing same lego pieces. Once they have a specification, all lego pieces can interact with each other, and can produce millions of them…Once you have a specification for a part, you produce it, and that’s all, reusable code can be consumed for the new project, but probably they will pick a new language/technology and will not use it, since production of a piece takes three months up to three years… 
I can’t make generalizations because there are trillions of parameters around this subject.  But I had a training on a new methodology last week. [It was an iterative and incremental methodology developed for company].
To be able to outsource, that put planning, analysis and design phases into iterative cycles, and finished the iteration with implementation. The model/documentation that will be handed to outsources can’t set into stone. To make risk analysis perfectly, you can’t assume during development any risks will not arise, and the analysis should not be reviewed.  Throughout all my development experience, I did not have any project changing requirements, changing scope/analysis after all planning phases finishes. But then, it was upto developers to ask questions and contribute to the depth/quality of the delivery.  If you are going to outsource, and trying to perfect your documentation, i.e. every piece of code developers are going to write is in [uml] documents, you can’t expect outsourced developers not to ask questions and change your analysis documents.
Waterfall was not useful, since it was set into stone assuming all phases will be done one by one without review/update.
Iterative and incremental process was not useful, since it was helping with the outputs/artifacts.
However, I am not happy with this model as well since it is a spiral model without any implementation cycle.

If a new framework is developed in your company, and you are going to use it, without proper documentation you can face lots of difficulties. It may company culture “to go and ask questions” but it can be a pain after five questions [ten maybe?]

With defensive programming, and agile methodologies around, lots of developers write their unit tests, created their exceptions carefully, every piece of code is in UML diagrams [object and sequence models,…] but unless it is a culture, nobody creates comments in their code.

Some does, but this becomes more confusing since there is no standard, a few people apply their own standards…

From the very beginning of the .NET [and C#], <summary> tags are there for documentation…This time, I will give  some examples how to use it. 

namespace  EC.Domain.ProductDMgr{ 
/// <summary>  
/// Product Data Transfer Object  
/// </summary> 
public class ProductDTO{ 

  private readonly int prodId; 
  private readonly string title;  private readonly int dissection; 
  /// <summary> 
   /// ProdId is the product Identifier 
  /// </summary> 
  public int ProdId { get { return prodId; } } 
  /// <summary>Title is the title of the product</summary> 
  public string Title { get { return title; } } 
  /// <summary> Dissection is the department of the product </summary>  
  public int Dissection { get { return dissection; } } 
  /// <summary>   
  /// The constructor of the product with identifier and title 
  /// </summary> 
  /// <param name=”prodId”>Identifier of the product</param> 
  /// <param name=”title”>Title of the product</param> 
  /// <param name=”dissection”>Dissection of the product in the store</param> 
  /// <exception cref=”ArgumentOutOfRangeException”> Exception for Dissection bigger than 999</exception>  
  public ProductDTO(int prodId, string title, int dissection) 
  this.prodId = prodId; 
  this.title = title; 
    if (dissection > 999)
        throw new ArgumentOutOfRangeException(“dissection”, “Dissection should be equal or less than 999”); 
    else
    { 
         this.dissection = dissection;
     } 
  } 
}
Anyone  using your assembly should be more confident about the objects and parameters now:

 

And during the development, that will add extra mile speed to the project:

For detailed info, you may refer to msdn.

There are codeplex projects [SandCastle, AjaxDoc] running on to extend this documentation and create msdn like help documents/websites.