Month: March 2011

Software Estimation

Software Estimation : take your time with it

A lot has been said and done about Software estimation – books have been written , techniques have been developed and blogs have been published.  I am no estimation guru and I am not writing this blog to enumerate estimation techniques.  However I would like to make a strong point on off-the-cuff estimates. Never do it . I have almost always been burnt by off-the-cuff estimates , whenever I have done it during my career. We all fall into the trap of doing it one way or the other. Several scenarios contribute to developers making those impromptu estimates ….one I have seen is when some non technical Stake holder comments – “that’s easy right ? that can be done in 10 minutes” . Off you go…the statement can play on your psyche and make you say “Yeah sure…I should be able to finish it quickly ” – even though you didn’t admit to 10 minutes , you almost committed to doing it in a very very short span without analysing it .

We all have a tendency to say what others would like to hear, however we all very well know that in case of Software estimates we better not do that – ” Things always take more time what they seemed like they would take in Software development” . I have heard so many developers admit to it and yet not take the time to go through detailed estimation effort. In most cases estimates are taken as commitments by Managers or Stake holders. If you have given a development plan with estimates on it , the rest of the group will take it as a commitment. So not only is making impromptu/unprepared estimates a big mistake , eventually it can start proving you incompetent and inexperienced. A great sign of experience and maturity in a Software professional is that he/she takes all the time that can be in analyzing the problem to the lowest granularity level and then measuring the effort .  All small efforts should be taken into account and unknowns should be listed. If you have to do that you cannot give off-the-cuff estimates , no matter how trivial it may seem .

Trivializing development tasks is a very common thing in software engineering and it is done by experienced software professionals as well.   Most people find it difficult to handle situations where their tasks get trivialized by others – a common retort is “Why don’t you do it then?” which is very unprofessional. Or a lot of programmers eager to make the Stake holders happy succumb to the pressure and give very aggressive estimates. Both reactions are destructive. The best policy is always to say -“I need to go over it in detail before giving any estimate”. According to me there are no Trivial tasks in software engineering – there are always hidden consequences and unknowns. These can come to haunt you later so it is wise to be cautious in making any statements which will be taken as commitments . Estimation comes with experience and unfortunately we all learn it the hard way – real world programming teaches you to realize , “It’s not what it seems at the first glance” .

SDLC, Software Configuration Management, Source Control, Team System, TFS

TFS : Make the most of it

The decision to buy TFS or Team Foundation Server is not an easy one ; it’s an expensive product, although Microsoft has introduced TFS Basic as of this writing , however several larger organizations with budgets have already invested in the TFS full version. Interestingly enough , where I was before I worked for different groups who all used TFS , but barely tapped it’s potential. TFS almost immediately gets adopted as a Source Control because of  it’s  containment inside Visual Studio IDE. It easily becomes a developer’s everyday tool where developers use it for Source Control as well as Continuous Integration. The Continuous Integration support works off of the IDE again and you need not use any other tool to configure it. The only other configuration that happens is on the Server side where you are hosting the Team Foundation Build Service. So , this is still in the Developer’s paradigm or a Build Master who interacts directly with Developers.

However , this is barely any use of what TFS can offer – TFS is an End To End SDLC tool which can be used for the entire Life Cycle Management of the Project by all team members without having to use anything else. Team members include non developers like Business Analysts, Project Managers , Testers , End Users and other Stake Holders. However the problem with all these non developers using TFS comes with TFS client being Team Explorer which installs a shell of Visual Studio and uses the Visual Studio interface for TFS connectivity . This can turn off a lot of non developers in the team from using it because most of these people are not used to having Visual Studio as an application on their machines.Even the Developers ended up not making full use of it because Project Managers or BAs don’t use it where Requirements and Work Items can be created, against which development can be done and tracked.

If your organization has already invested in TFS , I think you must make a dedicated effort in getting everyone to make use of it so the entire SDLC can be managed efficiently with just one tool.  This blog is not meant to be an advertisement for TFS : the idea is if you have chosen to invest in TFS , get most on your investment by getting the Team to use it as SDLC tool so you get the right value for your money. TFS integrates with Sharepoint and MS Project Manager – two very popular enterprise Project Management and Collaboration tools. The adjustment needs to happen mainly in installing the Team Explorer client which is Visual Studio GUI interface . I have used VS 2008 Team system and started using the 2010. Team Explorer for 2008 is free and a seperate install. Once that’s done you can connect to TFS server and your Team’s project and  manage everything from there itself.

We used TFS for our entire cycle as well as Post Production support for one of our projects. One major issue we found was we had our customers create issues in Sharepoint site of the Team Project . As of this writing the 2008 version lacked a good integration where the Work Items or Issues created by Sharepoint users could not be easily imported into the Visual Studio client interface. We had to Excel export the Sharepoint items and then import them back into Team explorer through Excel, which is a kind of round about way to achieve something that could have been offered as simple one click function from the tool itself. I am not sure if they fixed this in the newer 2010 version , if so then completes the product without any holes for SDLC management.

PS: we used TFS for all of our .Net projects . I know that TFS can be used with other stacks as well , like Java for example – however not sure if the Continuous Integartion would work correctly for Java because TFS Build engine uses MSBuild and the .Proj files to make builds. Anyways if you are a MS shop with .Net projects then TFS is definitely a great project management and collaboration tool.

Design Patterns, Object Oriented Programming, Software Architecture

Design Patterns : A practical observation

I was looking up the history of design patterns : according to Wikipedia, they originated in 1977/79 and gained popularity in 1994 after the famous Gof4 book was released. I have been in the Software Engineering world for 20 years now : working for small to mid size and large organizations developing commercial software : surprisingly even though Internet and Google have been here for over a decade , design patterns have not made way into software development shops  as much as they should have –  framework developers have probably used them more profusely :  however software built for direct end user still does not make use of design patterns as much.

Based on my experience and exposure plus having tried to gain knowledge of patterns myself here are a few reasons I can think of:

1) Understanding Patterns from Gof4 and other books requires a solid background of at least one Object Oriented language like Java, C++ , C# etc.

2) The concept of patterns can be very abstract : even though understood in theory , practice of existing patterns does not come easy even if you are programming in object oriented languages.

3) Software development is a team effort and patterns cannot be part of the entire architecture of the product unless all developers in the team are comfortable with them. It may require a significant amount of effort and dedication from an IT shop to get everyone up to speed with Patterns, something which a lot of them may not afford to due to time/cost constraints .

4) Although software architecture has always existed, there is more focus in recent years on the formal role of  “Architect” and dedicated positions which concentrate on design / architecture as opposed to implementation. Pure Software Architects do find a lot more time to focus on the Patterns , hence in Software Shops where such Architects exist , you will see more use of the Patterns.

Design Patterns as laid out by G0f4 book and others are undoubtedly great mechanisms to achieve good design of a software system. However I feel that one can still achieve a reasonably well designed implementation if you keep few core values in mind : Performance , Reusability and Refactoring. There should be a constant effort from a team’s side to Refactor the code , which will not only clean code , achieve Reusability as well. In some scenarios there could be a trade off in Performance in trying to achieve Reusability. For example a typical scenario is taking a layered approach in designing reusable layers , however performance could get impacted if the Request and Response have to travel so many layers. So a balance needs to be achieved between the two. This kind of dedicated effort in applying some of these core principles can result in great software whether the code is written in an OO language or not.

Design Patterns are nothing but Common Solutions to recurring problems in Software Application development. So if we all start paying more attention to recurring problems and find Reusable solutions to these problems , we have used/invented design patterns to implement our software. This is not to undermine the formal OO approach of several Design Patterns : they are extremely useful if applied – however if they cannot be applied directly for whatever reason, adhering to practices of Refactoring and Reusability keeping in mind Performance can also result in well written Software.

However if you are a OO programmer I think a thorough understanding of SOLID principles as laid out by Robert C Martin along with GOf4 and several other OO patterns will further help in building a strong architecture.

ASP.Net, ASP.Net MVC, MVC

ASP.Net MVC : Diving a little more deep

As we further continue our journey of understanding the ASP.net MVC better , a great way to learn any framework is to examine the source code. Fortunately the source code is available for ASP.net MVC framework to download or browse over the web at CodePlex ( I have provided the link to Source code below) . Currently they have the latest Version 3 RTM code available to look at. In my case this part came much later because I had an aggressive timeline and there was not much time to learn. However giving the framework source code a thorough look will make you very comfortable with the use of the framework itself because you are able to analyse what happens behind the scenes very well. Not only that, having gone under the hood gives a lot more command over how to effectively achieve the required results without breaking into too much sweat and frustration. A huge productivity gain if you put in some upfront time diving deeper in understanding of design.

A question I have seen a lot in discussion forums being asked is how come ASP.Net MVC does not implement the Observer pattern with Models and Views? In my last post I have mentioned that MVC is a strong use case of Observer pattern in certain scenarios. MVC was conceived for Desktop applications and it is much simpler to have several instances of Views of the same Model and update all the Views when a Model state changes by either one of the Views or some other means. However in the web paradigm generally a View instance is not even available in real time after the View object finishes rendering the HTML. The Model is more passive in nature unlike in an Observer pattern where the Model notifies the Subscriber Views of changes. The Model simply supplies the data that View queries and presents. This does not in any way violate the MVC principle because the MVC pattern’s essential goal is to separate or loosely couple the Model from the Presentation or the View.

Hence to achieve MVC in web applications a variation of basic MVC was developed called Model 2. In Model 2 the request from the Client Browser is passed to a Controller. In case of ASP.Net MVC this is a central Controller called Front Controller which simply takes a Http request, parses it to create the right Controller instance to execute the right Action. To see this implementation you can look at the MvcHandler.cs in source which acts as the Front Controller –

1) ProcessRequest function of the handler parses the request to create the right controller instance.

2) The ControllerBase.cs has the definition for the Execute() function that in turn executes the request. The Controller.cs derives from ControllerBase implementing the IController interface which has the contract for Execute() method. All controllers derive from the Controller.cs.  This method gets called from the ProcessRequest of MvcHandler.

3 ) The actual invocation of action  is done by the InvokeAction method of the ControllerActionInvoker.cs class. The InvokeAction returns an ActionResult type which is an abstract representation of the type of the View that gets returned.

The intention of outlining above is to give you a way to trace the sequence of flow in the Source Code of how the Model 2 was achieved. This completes the understanding of how the request went through the pipeline and completed. I would not like include the actual code listings here: it is a good exercise to have a look at the code yourself and trace out the pipeline.

There are several references to get a better understanding of the Model 2 itself. I suggest to go though Model 2 on Page. 549 of the Head First Design Patterns book. There is a great article by Dino Esposito in MSDN Magazine, which illustrates Model 2 very well here.

ASP.NET MVC 3 RTM Source code on CodePlex .

 

ASP.Net, ASP.Net MVC, MVC

ASP.Net MVC : coming up to speed

In my last blog post I talked about how I chanced upon ASP.Net  MVC at my last project and my thoughts on whether a development group should consider it as a design choice for their future projects. In fact few months have passed since I wrote the last blog post, and ASP.Net MVC has taken another leap with MVC 3. From Microsoft’s side there is big push of course and I do see a lot of adoption from development groups in different organizations. There is a learning curve that I see most groups are going through and it can be hard or easy depending on the background that you come from your previous development tasks.

The best way to get started with ASP.Net MVC is if you already are not familiar with MVC as a pattern, familiarize yourself with it.  There are several websites that discuss it as a pattern : in the pattern world, it’s more of a ‘framework pattern’ as opposed to a ‘basic pattern’ from the Gang of Four patterns. So based on your level of understanding of patterns, start with Basic patterns aka Gof4 and then understand it as an aggregate pattern of different basic patterns. MVC itself is acheived by different pattern proponents and architects as an aggregate of different types of patterns: like in Head First Design Patterns book, the authors acheive MVC by combining the Observer , Strategy and the Composite pattern.  You will observe after your readings that several implementations of MVC are a strong use case of Observer pattern where Views subscribe to changes in the Model – also of Composite patten for the View itself.  In the web model though , the use case of Observer pattern may not exist due to the stateless nature of the View. So ASP.Net MVC is one variation of the basic MVC pattern adapted to web paradigm.

It’s the most important step to get as clear an understanding of MVC under the hood from a patterns perspective: this gives a you a much clearer perception of Model, Controller and View , their interaction. You could jump start into it by creating a “Hello World” application in Visual Studio 2008 , 2010 – however it will become very difficult as you go further in accomplishing all your programming functions because the underlying concepts are not clear, especially for those who are used to ASP.Net web forms programming.

Another important start is to pick up a good book , by now there is MVC 3 , however while I am writing this , few good books are out on MVC 2. The ones I read are books by Steve Sanderson and Jeffery Palermo , famous authors. Both are great books in their own regard: Sandeson’s book covers all basics extensively – so read that as your first basic book and Jeffery Palermo’s book covers several advanced topics , like dependency injection , different unit testing methods in a lot more detail. Both will go a long way in getting your foot in the ground , and being well prepared with your project work. I have listed at the end of the blog all the books I read to get up to speed and they helped me a lot. It is good to get few copies of books like this for the whole team and everybody reads it. Of course , there is ton of websites and without a doubt you should follow Scott Gu, Scott Hanselman, Phil Haack and Stack Overflow. The books combined with the websites will give you an understanding of the ASP.Net MVC framework which is written on top of MVC design pattern.

Another new concept that may get thrown at you with ASP.Net MVC is Routing , the ‘RESTful’ way of doing things – it’s undoubtedly a strong concept and you must be very familiar with it from day one. ‘REST’ is meant to be the way Web programming is done – as you progress you will see how important it is for you to be very clear on some concepts like the HTTP methods of GET and POST . WIKIPEDIA itself has some great information on REST , HTTP Methods etc.  As far as Routing itself is concerned the the two books I mentioned above do cover it extensively as to how to achieve it with ASP.Net MVC framework.

Here is a list of all the links for References:

Gang Of Four Patterns Book

Head First Design Patterns

Steve Sanderson’s MVC Pro Book

Jeffery Palermo’s MVC Book

Scott Guthrie

Scott Hanselman

Phil Haack

WIKIPEDIA On REST

Good Luck With MVC !