Finding the way to Design Patterns : SOLID

In my previous post on design patterns I discussed about why it’s a challenge for developers / organizations to adopt patterns as part of their development practices. I also had suggested that a dedicated effort to re-factor code should be made continuously as part of software life cycle especially in the early to mid-stages of development. Having said that, how do you go about re-factoring? How do some of the object oriented principles and design patterns help with re-factoring? So, if re factoring is important, the object oriented mechanisms that allow and facilitate this are important as well. In conclusion the learning needs to happen, slowly and steadily – as a result it will start becoming a habit to incorporate some of these patterns related principles.

I guess the challenge is where do you begin? There is a ton of information on the web, it’s all too overwhelming, scattered and fragmented. You need a have a structure and if you just pick up the Gang of Four book (our bible for design patterns), it can seem rather academic and intimidating for the first timer, abstract as well. The book of course is great, however it’s hard to jump into patterns pragmatically just by reading it.

As in my previous post in my concluding paragraph I had said that getting familiar with SOLID principles developed by Robert. C. Martin is great way to get started with principles that will lead the way towards patterns programming later.  Before expanding upon technically on what SOLID is about, I would like to discuss its importance in the whole OO programming space. If you come from a OO language background like Java, C++, C# etc. you already are familiar with Encapsulation, Inheritance, Polymorphism as foundational principles of OO and they are a daily part of your programming life. SOLID takes it one step further, lays out 5 principles that you can apply to re-factor and improve the code making it maintainable, reusable and efficient.

So when you start applying SOLID, you basically are applying some of the fundamental principles on which Design Patterns are developed. SOLID stands for Single Responsibility, Open-Closed principle, Lishkov Substitution principle, Interface Segregation and Dependency Inversion.

If you just take the first two: Single Responsibility and Open-Closed principle, just there you will improve the structure and quality of your classes.

Single Responsibility states: a class should have only a single responsibility.

Say, you are writing a Log class whose job is simply to write messages to different logging mediums. However you also gave it the responsibility of formatting the messages for these mediums, because it’s part of logging function. In addition, you gave it the responsibility of initializing and choosing the medium to log into, for ex: Event logs, Database, Log files etc. So now the Logger class has multiple reasons to change – one is, Write to the log medium, another is formatting the message: perhaps different mediums require different formatting and on top of that initializing the medium . So your class has now grown into one giant monolithic program that has multiple reasons to change – formatting for each medium, initializing the medium and logging to the medium. So if you need to change only one aspect : say change the formatting messages in database , you have to change that class and the rest of the code could possibly break because you needed to make changes for one aspect. We come across situations like this all the time in production code where we change one thing and potentially something else breaks , without us intending it . This sort of programming makes the code not only fragile, but totally un-pluggable.

Ideally in this situation, the Logger class should just take on the responsibility of writing to the medium being free of what medium it is writing to and what formatting that particular medium needs. Although it seems like they are all related functions , they merit to become individual classes based on their specific function and behavior. More so, ideally you should write an interface that can be implemented to write to different log mediums.

public interface ILog
void Write(String Message);

As you see , when you just take this one principle and follow it while writing the code you will see that you have written classes that are light weight and each is meant to do one particular job – this makes the design pluggable , reusable and efficient  . You can create classes that are specific to a medium – so adding mediums for logging becomes easy later. Also if there is a change required in it , say how you format the message for that medium, you change only the corresponding medium or the formatting class, avoiding the risk of the rest of the code breaking due to the one change you made in one big class.

As you go further and start applying one by one each principle you will see that certain patterns are shaping up, and possibly they can be applied to common scenarios. I guess I will stop here for now, and conclude that the first step is definitely to understand SOLID and start applying it in your programming life seriously.

Below is a great Video on Single Responsibility Principle by Robert C. Martin himself to learn more on it and get started :

We will discuss more on the rest of the SOLID in the upcoming post …until then happy programming.

Forms Authentication and Membership : Still going strong and .Net framework have come a long way. 1.0 went through a major change with the introduction of ASP.Net 2.0 having several boiler plate features which did not exist in the 1.0 version. Providers were a major component of these features with Membership and Roles added on top of Forms Authentication which was introduced with the 1.x version itself. Since then the combination of Forms authentication with Membership and Role Providers are a strong and proven mechanism that can be used to take care of Authentication as well as Authorization needs of a .Net web application. Together they can be used to Validate a User with Membership and then Create / Manage a Authentication ticket with Forms Authentication.

I just recently started an ASP.Net MVC3 project with .Net framework 4. The MVC3 project template gives you a choice to add all the basic code to implement your security via Forms Authentication / Membership . I have had 4 successful projects with Forms / Membership – 2 were even integrated with SSO. I had all the reason to go for it because I felt very comfortable with it. I must say it took me only at most an hour to configure everything the way I wanted it to work. I did not have to struggle with anything or learn any new technology tricks. I loved that feeling , because every step of the way otherwise you end up learning something new with every version that’s introduced. I don’t consider that a bad thing , however as much as changing technologies are good to have,  stable features give you the comfort and speed required to get the project going. ASP.Net MVC has kept all the goodness except that now the security functions are called via Controller / Action methods.

Forms Authentication and Membership Timeline

Together they can be used to Validate a User with Membership and Create / Manage a Authentication ticket with Forms Authentication.

ASP.Net MVC has kept all the goodness except that now the security functions are called via Controller / Action methods.

If you are using Single Sign On with some kind of federated database , it’s really easy to integrate the two together as well. Just make sure that the credentials which exist in the federated database also exist in the ASP.Net membership database. Once the credentials are authenticated in the SSO database , you take the same credentials and validate them against the Membership database and assign Roles accordingly if you have them. The only catch is if the SSO system creates an authentication ticket that has it’s own expiry , you need to make sure you are signed out of the SSO system when the user signs out of forms authentication system. Forms authentication system creates it’s own ticket – which has it’s own expiry.

Not that the Forms authentication / Membership system is suitable for all systems – several larger corporations have their own home grown authentication and authorization systems. Their custom needs may be complicated enough not be able to use Forms Authentication / Membership . However for all small and mid sized applications, where a reliable boiler plate security mechanism is required , the Forms Authentication / Membership works without any major issues. It is also comforting to see that it is stable enough for Microsoft to have kept it the same way without having the need to make many changes through version 4. Just thought I should discuss this via blog because good to see something stable and strong in an ever changing world of technology.

Why write a blog?

I started blogging not long ago. It has been an eye opening experience for me. I have come to realize that writing a quality blog is one of the hardest endeavors. It requires strong articulation skills along with creative thinking on coming up with topics to write about. Once you have decided the topics , building content within your blog that your targeted audience will find useful is even harder. It’s a test of multiple skills and imagination. So , it’s an extremely challenging and a rewarding experience.

Blog content is a very valuable asset in the cloud which merits in itself as a compelling source of information on any subject matter.

There are a lot of people writing blogs, which is a great thing because it is creating enormous content on the web which is available to each and everyone. It is also creating a sense of community amongst different people making the world smaller and a more informed place. Blog content is a very valuable asset in the cloud which merits in itself as a compelling source of information on any subject matter. These are first hand experiences and thoughts of people; information which is more valuable a lot of times than available in books. We can definitely hope that history will be much more accurate in the decades and centuries to come because now we have all these archives from people who lived that experience for future generation to read.

This blog targets niche audience of technical people mostly in the software development world. As a tech pro, should you take up writing a blog ? Why should you write a blog ? There are several advantages of writing a blog as a technical professional , apart from giving you a visibility within your own community of professionals. The ones that jumped at me after starting a blog are :

1 ) It gives an expression to your thoughts and ideas which is a very rewarding experience intellectually.

2) You identify your strengths and weaknesses in the topic / subject matter in which you write a blog .

3) You become more detail oriented because now you care about accuracy of content that others are reading globally.

I think the second reason is the most compelling one for a technical professional where you need to constantly hone your skills in a constant dynamic environment of cutting edge technologies. I am amazed at the quality of work people are doing by reading their blogs. It gives one a perspective of where one’s short comings are with respect to the outside world. We can get so easily cocooned in our own organizational environments where our knowledge is limited enough to fool us into thinking that we know best .

It can become even a life changing experience because suddenly you have all this audience who follows you and you know you have valuable information and ideas which can benefit the community.

On the other hand the first reason gives you a lot of satisfaction when you write a great blog on your personal knowledge and ideas. It acts as as a vent for your thoughts and brings back a lot of self confidence when readers appreciate it. It can become even a life changing experience because suddenly you have all this audience who follows you and you know you have valuable information and ideas which can benefit the community.

A blog gives a chance of introspection and self evaluation.

The third reason again benefits you in your profession where sometimes most of us go only up to the detail that is needed to get our job done. Yes, the job got done and may be you got that raise or bonus you were looking for. However is that enough for your growth eventually ? Have you thought about how you measure up to your peers in the same field ? There is a good chance if you have to find a new job you will find that the depth and breadth you thought you had is not necessarily there. A blog gives a chance of introspection and self evaluation.

So if you have not started blogging yet , wait no more ; wear your thinking cap and pick up your digital pen . May be you will write a smashing post !

Technical Knowledge : Breadth and Depth

I could have titled this blog “Professional Knowledge : Breadth and Depth “ – however thought that since my blog focuses on a niche readership,  “Technical Knowledge” would sound more appropriate . Anyway, often times at work discussions come up on how mastering a certain subject area leads to growth , especially for technology professionals. Depth plays a key role in technology professions in leading to both job satisfaction and growth. So is depth more important that breadth? I think both are equally important, and they both contribute to an individual’s job performance and satisfaction.

Why Depth?

1) Depth in a subject area establishes you as an expert – the deeper you drill within a subject area focusing on niche fields the better you will do at the design and execution level. Depth is instrumental in achieving high quality results, thus better performance by you as a professional. Say for example , you develop a mastery on ‘Design Patterns’  with regular practice and study – your expertise in that area could play a pivotal role in robust architecture and solid implementation of the architecture which will take the project a long way for years to come.

2) All technical projects / undertakings are team efforts – not individual heroic endeavors. An ‘expert’ in each area of the technical solution will be required to fill the places as opposed to some one who just knows a little bit of all. For example , a software project may have a ‘Single Sign On’ expert just handling the Authentication aspect of the solution where he/she is the ultimate ‘go to’ person  for it. Hence having a niche expertise helps you build your value within  the organization almost always to fill in that spot of your expertise across different projects. A key to job security especially for those who work as consultants.

3) Depth can easily make you a ‘Mentor’ or ‘Leader’ in your area , very important for your own job satisfaction . Let me give you my own example in this case. All along in my career , I made careful choices while consulting – I chose to take up projects which were ‘ASP.Net and C# ‘ centric – this quickly helped me establish myself as a mentor as well as a lead in those areas allowing me to provide expert help and guidance across projects. This leads to great satisfaction , sense of value and achievement.

“Having a niche expertise helps you build your value within  the organization almost always to fill in that spot of your expertise across different projects.”

Why Breadth ?

1) Breadth gives you a vision , an ability to see beyond the purview of a narrow expertise. For example, a business problem can be solved either with a Client Server Architecture or Service Oriented Architecture. If you do not keep up at least with what SOA means , it’s application at a high level , your problem solving abilities are stunted by lack of broader knowledge.

2) If depth establishes you as an expert , breadth can establish you as a sound thinker. A ‘subject matter expert’ may not necessarily be able to lead the overall project , whereas breadth

sound thinker

helps in being a leader and decision maker for the whole project. A typical software project has BAs, QA , Developers, Designers , Project Managers etc. – a professional with a broad understanding of how each works can listen and guide everyone effectively .

3) Breadth just makes you a lot better communicator – it’s easy to communicate in areas where you are deep , however breadth enhances the conversation power many fold because you can quote examples from beyond your forte. A great asset for meetings , hallway brainstorms and white board discussions. This can lead you to opportunities that you want to explore to grow as a professional.

 “Breadth gives you a vision , an ability to see beyond the purview of a narrow expertise.”

The power of knowledge is immense in IT : having both depth and breadth will round you up as a sound professional as well as a leader. Practice gives depth and study can give breadth , combined the result is a highly valued professional.  I always feel in technology you can ‘Read your way up’ –  a small investment in time of may be even an hour a day makes a big difference , it keeps you abreast with the new stuff.  I think if one has the time , if say you work 9 hours day , may be extending it to 10 hours by adding that extra reading time at work itself will better prepare you with your project work in applying and understanding better techniques.

Continuous Integration : the Value Proposition

The topic of Continuous Integration  has gained a lot of ground in the past few years in the Software Development world – several high quality tools have emerged . Some companies have adopted it as integral part of SDLC methodology. Some I think are still trying to understand it , however a lot have not yet just made it their daily practice due to either lack of tools within the company or lack of a process. I have worked in this industry for more than 20 years and there are several reasons why I think CI adds immense value to software development process to make it efficient and productive. After going through many sucessful and some unsuccessful projects , here is how I conclude CI brings in value:

1 ) Bugs are detected on a daily / regular basis and remedied right away by integrating code checked in by different developers into Source Control . Continuous Integration works by kicking off a build process on your build server based on check-ins made by the team . CI tools give you the option to build as a check-in is made or at a certain frequency or at a certain time etc. So you get to control how you go about it. If a Build is required to be done as a check-in is done by a developer , right away bugs / integration problems get detected – they are remedied as you go along daily, reducing many integration hassles and mitigating risks earlier.

2) In medium to large scale projects there are different groups , stake holders . DBAs who work in conjunction with Application Developers sometimes want to look at GUI or application in action to see what type of data was entered that caused a SQL / Stored Procedure to fail. Although DBAs don’t necessarily need to look at application running in Dev Integration server to detect data related problems , however it gives them a great way to Visualize what an application developer has to say about why a SQL exception may have occured. It expedites problem detection by running the application as well as other runtime SQL method call capture tools like SQL Profiler concurrently.

3) A little while ago I wrote a blog about how the gap between UX Designers and Developers can be bridged by following certain practices with the development cycle. Continuous Integration can play a key role in shortening the gap : UX Designers often or almost always need to see the final integrated UI after the UI developers take UX designer’s Mocks / CSS / Javascript and integtrate their code with it. If you have a CI in place the UX designer can just go to the dev server and look at the latest dev build helping him see how the final UI looks without having to sit next to the developer. Obvious as it is , this will aid in UI layout related debugging and early detection of any cosmetic problems as well as work flow related issues.

4) Progress Track and Control are an integral part of Project Management and SDLC. PMs , BAs and Management stake holders need to be kept in the loop as regularly as possible for better Control management of any software project. A great way to measure development progress by non technical groups is to look at the actual application taking shape on the Dev Build server. Needless to say how this will help very early in the Iteration of a project. Any problems , risks or change requirements can be made early on saving time and money which are the two crucial cornerstones for a Project’s success.

5) In this age of globalization and distributed enterprise , CI can play a crucial role in bringing different groups together . Developers could be in India , UX team could be in US and other stake holders could be anywhere. If dev build servers can be accessed via the company Intranet or VPN from anywhere then the communication and collaboration gap is not widened by geographical distances and Project can be delivered on time even with a distributed arrangement like this. Here is a diagram that visually conveys the idea….

Continuous Integration Integration with Project Team
Entire Team Interaction with CI

The reasons above qualify enough for every organization to adopt and invest in CI – especially for medium to large projects . There are several tools available – form Open Source to Proprietory . Cruise Control is a well know open source tool as welll as TFS by Microsoft which ia an end-to-end SDLC tool. These are just examples. Web is full of articles, blogs and tools that you can use for CI. If you have not taken the time to integrate it into your team’s dev process , wait no more it’s worth your while and money.

Cruise Control

MonoDroid : First impressions

Just like everyone , I have been bitten by the Handheld bug . Mobile Phones and tablets will definitely be the wave of the future and will influence the way we live and conduct business in a huge manner. Android

They already have started doing so , they are so much a part of us. I am excited about the whole tablet mania which I think will revolutionize the use of computers . As a result, I wanted to write some ‘apps’ as well, may be make some extra cash or start a business.

I started out thinking iPhone and iPad , however soon realized that I would have to own a Mac computer to do development on these because I did not come across a good development environment on Windows for iPad or iPhone . ‘MonoTouch’ by Novell was closest to the development technologies I am most familiar with , however MonoDevelop and MonoTouch also are required to be used on a Mac. Hence I decided to go the Android way – which allowed programming easily on Windows… and once again a very promising Mobile OS , thought this would be my best middle ground.

C# and .Net being my strongest technology stacks , I decided on trying MonoDroid by Novell so I could use Visual Studio 2010 and C# to do Android programming. I had choice of Java and Eclipse as well, which I have installed parallely along with Android SDK just for comparison’s sake. I thought if MonoDroid works I am better off with it since it gives me a chance to program in C# and .Net , chances are very good I’ll save time in learning nuances of Java which I left behind a few years ago. Having said that I did try the ‘Hello World’ program with Java and Eclipse , ran the application successfully on the Android emulator.

MonoDroid gave me a similar experience as Java in terms of installation and running of the simple “Hello World” program. The installation of MonoDroid required an extra installation of MonoDroid SDK.. other than installing Java SDK , Android SDK , ADT Plugin and the Development environment which is VS 2010 in .Net . All you need to do is follow the instructions in the order they are supposed to be installed in , everything goes smoothly. I was also able to run the “Hello World” program with MonoDroid in the Android Emulator. So far so good. I started getting deeper with this encouragement , thought I’ll try different things like reading XML data and displaying in a ListView or GridView. I also tried things like reading from the existing databases like the Contacts database from the Device and printing some Contact names on the screen.

I think MonoDroid is a very good start in Android development , their 1.1 version released as of this writing . They have done a good job of creating C# and .Net object wrappers around Android SDK – which makes it very easy to look up different objects and methods within the MonoDroid API in correlation with Android API.  For example ‘ContentResolver’ as in Android API is named the same way in MonoDroid API and so are the corresponding methods. However the debugging with a breakpoint in the code does not always work – I am so used to examining the objects in runtime to learn more about them or fix some runtime bugs – it was very frustrating at times without understanding why the debugging did not work. I raised this in the MonoDroid forums on MonoDroid site and they said that they are trying to fix the debugging issues in the next release.

They have done a good job of creating C# and .Net object wrappers around Android SDK – which makes it very easy to look up different objects and methods within the MonoDroid API in correlation with Android API.

Another issue I ran into was that while going through several iterations of development I was constantly making small changes and redeploying. The modified binary would not get redeployed right away after hitting F5 or clicking ‘Start Debugging’ . Again it was creating road blocks while making changes and wanting to see them right away . I learnt later that “the new binary isn’t deployed immediately because it can’t; the only way to update the app is to build a new package (.apk) and install the new package (plus an intermediate package uninstall). Package creation is not an instance process, hence the delay. MonoDroid group said that they intend to improve the package creation experience in the future, but there’s only so much that can be done…” .

So, all in all it was a mixed experience with being able to start very well to hit some high points and some low points. It does get a little frustrating with not too many examples on the web or documentation – there are few programmers who are fairly actively making posts on MonoDroid but you are a lot on your own . One of the things I started doing was first copy code example from Android API and then convert them to .Net code using the IntelliSense . That helped in terms of at least getting the code to a point where it looked right syntactically and ready to run. There is a steep learning curve in understanding Android API – which can take a few weeks depending on how much time you have in your hands.

MonoDroid is definitely a step in the positive direction attracting .Net developers quickly into Android programming – however the development experience still needs to improve . I am not sure if it’s ready for real world deployment applications because I have not yet seen any Show Cases of MonoDroid real world Apps unlike MonoTouch which a lot of people have already used to develop Commercial applications selling in the market. However if you want to do Android programming and want to stick to .Net technologies , I am sure with a little more wait it would be worth it , considering Mono’s reputation. MonoDroid will soon be upto where MonoTouch already is. Give it a try and experience for yourself by starting from here.

UX Designers and Developers: Bridging the gap

The other day I was watching a presentation on SlideShare about how the UX designers can work with Developers without getting into conflicts. All my career like many Software Engineers I have had to interact closely with UX designers …the problem mostly stems from the fact that the tools used by both the groups are different as well as the frameworks and languages to achieve the end result . There is some overlap between the two with Javascript / JQuery – however, depending on whether the Client Script impacts the UX interaction or some server related activity , the designer or the developer takes over the definition of the code. A synergy needs to be created between both of them because at the end of the day the UI that we see is the combined effort of these two groups.

The tools and frameworks themselves don’t offer much in terms of creating that collaboration and synergy – however as part of the process , the groups need to mingle and work side by side. Designers do need to understand how the developers incorporate their code into the designs- and developers need to understand to a certain extent the working of Styles and HTML .

Just recently I went through two ASP.Net MVC projects and we used the help of a UX team to put together our styles and layouts. As usual, the mock ups were created which the developers used to incorporate their code into, to achieve the end user requirement of the UI.   There were issues with how the developers had used the mock ups with their code , as expected. Most times the designer would call me and say hey I need to be able to run the web page in development like the developers do, so when I make a change I see it and go through iterations. I made a decision that she needs to get familiar with running the solution in Visual Studio 2010. This helped a lot – saved us precious time by the designer not having to ask the developers to make a fix and publish it on the dev server. The designer at the same time was happy having the independence to make the change in the final UI and seeing the page in debug mode.

One of the other bad practices I noticed with a recent client is that the UX designers would put their wire frames either in Dropbox or zip them up and email the development team. The development team had to always download them and copy one by one in their project. There was no version history , no way to tell what changed other than looking at the rendered page . This can become a development nightmare in a very UI centric project.

All mock ups and styles should be version controlled , preferably in a similar version control system as being used by Developers. This makes it easy for Developers to compare the changes as well as Share the styles if it makes sense into their project from the styles folder of the Designer team in Source control .

I am not sure in the future how much will be offered by Development tool makers in terms of both Developers and Designers being able to use the same tool to do their jobs. However I think if Designers and Developers both understand to a certain extent each other’s code , work side by side and follow good version control practices,  the UI development would be much less of a hassle. The Designers need to understand the interweaving of Server side code with Client side code and the Developers need to understand Javascript , CSS and HTML standards to a reasonable extent.

So there need not be any love lost between Designers and Developers – collaboration and communication can surely bridge the gap.

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” .

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 : 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.