Delegates

Imagine we are writing an Employees Collection class which has methods to filter by first name and department. The code looks so similar, can we somehow parameterize it to remove the duplication?

 

using System;
using System.Collections.Generic;

namespace CodingArchitect.Demos.Delegates
{
    public class EmployeesCollection
    {
        private readonly List<Employee> employees =
            new List<Employee>();

        public EmployeesCollection FilterByFirstName(string firstName)
        {
            var matches = new EmployeesCollection();
            foreach (var employee in employees)
            {
                if(string.Equals(employee.FirstName, firstName,
                    StringComparison.InvariantCulture))
                {
                    matches.Add(employee);
                }
            }
            return matches;
        }

        public EmployeesCollection FilterByDepartment(string department)
        {
            var matches = new EmployeesCollection();
            foreach (var employee in employees)
            {
                if (string.Equals(employee.Department, department,
                    StringComparison.InvariantCulture))
                {
                    matches.Add(employee);
                }
            }
            return matches;
        }

        private void Add(Employee employee)
        {
            employees.Add(employee);
        }
    }
    public class Employee
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string Department { get; set; }
    }
}

Parameterize Method refactoring immediately comes to mind, only in this case the parameter should be a function which does the actual filtering. Passing functions as parameters is perfectly valid in C#. Now the condition alone can be passed as a delegate to the filter method. I am reusing the Predicate<T> delegate defined in the BCL. This is exactly what the FindAll method on the List<T> type in BCL does.

 

using System;
using System.Collections.Generic;

namespace CodingArchitect.Demos.Delegates
{
    public class EmployeesCollection
    {
        private readonly List<Employee> employees =
            new List<Employee>();

        public EmployeesCollection Filter(Predicate<Employee> condition)
        {
            var matches = new EmployeesCollection();
            foreach (var employee in employees)
            {
                if (condition(employee))
                {
                    matches.Add(employee);
                }
            }
            return matches;
        }

        private void Add(Employee employee)
        {
            employees.Add(employee);
        }
    }
    public class Employee
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string Department { get; set; }
    }
}

The condition predicate can now be passed from the call site using a delegate (syntactic sugar like anonymous delegates, lambda expressions make it easier further).

Expectations

One morning a butcher was surprised to see a dog enter his shop with a note in his mouth. He took the note and it read  “Can I have twelve sausages and a leg of lamb, please?” The dog had money on his mouth, as well. So the butcher took the money and put the sausages and mat in a bag, placing it in the dog’s mouth. The butcher was impressed, and since it was closing time, he decided to follow the dog.

The dog was walking down the street when he came to level crossing, he put down the bag, jumped up and pressed the button. Then he waited patiently, bag in the mouth, for the lights to turn green. When they did, he walked across the road, with butcher following him.

The dog then came to a bus stop and started looking at timetable. He the sat on one of the seats provided and waited. Along came a bus. The dog walked round to the front, looked at the number, and went back to his seat. Another bus came along. Again the dog went and looked the number, notice it was right bus, and climbed on. The butcher, by now, open-mouthed, followed him onto the bus. The bus traveled through the town and out into the suburbs, the dog looking at the scenery. Eventually he got up and moved to the front of the bus. He stood on two back paws and pushed the button to stop the bus. When the bus stopped, he got off, his groceries still in his mouth. The butcher followed.

Finally dog turned into a house. He walked up the path, and dropped the bag on the step. Then he rang the doorbell. There was no response from inside. The dog walked back down the path, then ran and flung the door, himself against the door. The butcher watches, big guy opens the door and start abusing the dog, kicking him and punching him and swearing at him.

The butcher runs forward and stops the man, “What in heaven’s name are you doing? This dog is genius.”

The man responds: “ you call this clever ? This is the second time this week that this stupid dog forgotten his key”

Lesson:

You may continue to exceed onlooker’s expectations but you will always falls short of bosses’ expectations

Source: A forwarded e-mail.

PS: Don’t read too much into the parable, it is just to make you laugh.

Some words of advice for the aspiring architect

Some advice to people who want to take up software architecture as a profession.

I won’t say that I am the perfect architect and I had followed all of this advice myself. Some of this I am still trying hard to implement myself and I have failed in a few occasions. But I do understand that these are the goals and I have to aim high to hit high.

“There are three kinds of men. The one that learns by reading. The few who learn by observation. The rest of them have to pee on the electric fence for themselves.”

And some these lessons have been learnt by peeing on the electric fence. Yeah I have had very few people to observe and books like “97 things every architect should know” weren’t out there then.

Can I become and architect in the next 21 days, 24 hours?

No it is not possible to teach yourself architecture in 24 hours. May be 21 days. Well No again. Why? Read Peter Norvigs classic here.

"Bad programming is easy. Idiots can learn it in 21 days, even if they are dummies.

An architect should be able to work at / communicate at varied levels of abstraction.

If you are a hands on developer aspiring to move into the role – You should be able to ‘see the forests for trees’ or raise your level of abstraction when needed. This is a very helpful when

• You need to dive into an existing system and understand it.
• Communicate with stake holders without over whelming them with the details.

If you are into the role for sometime now you should be able to dive into the details when it is required. The devil is in the details :-). This is very helpful when 

• You are estimating / breaking down the system to provide commitments to stake holders
• Communicate with other members of the development team (you need to speak to a developer in a lower level of abstraction).

An architect should have knowledge in a breadth of technologies.

An architect should be a Jack of all trades. Do not misunderstand this quote, the full quote will probably be a better one

"Jack of all trades, master of none, though oftentimes better than master of one".

How can you learn all the technologies coming out today, especially that the technologies are coming out at a frantic pace?

Welcome to meta-learning. Learn things at a meta level, meaning both Windows Azure and Google App Engine are PaaS. If you learn them at a conceptual level and correlate the concepts between them it is easier. Same applies to .NET and J2EE. But if you do not know the underlying concepts, this becomes really hard and virtually impossible. Of course there will be nuances specific to a technology which you have to learn as well.

Remember the Golden Hammer rule:

If all you have is a Golden Hammer, everything looks like nail.

Use the power of networks, community.

Learn from the community, Contribute to the community. I will quote ayende here.

Another point that I want to bring up is the importance of professional networks to bring information to us. No one can really keep track on all the things that are going on in the industry, and I have come to rely more & more on the opinions of the people in my social network to evaluate and consider alternatives in areas that aren’t offering acute pain. That allows me to be on top of things and learn what is going on at an “executive brief” level. That allows me to concentrate on the things that are acute to me, knowing the other people running into other problems will explore other areas and bring their results to my attention. – from http://ayende.com/Blog/archive/2010/01/24/the-paradox-of-choice-best-of-breed-or-cheapest-of.aspx

It is the age of networks damn it, Use Twitter, RSS, Stackoverflow, Quora whatever…

The people who you work with are Important

If you are not working with bright developers who keep pushing you to the the next level, demanding managers who keep pushing you to the next level, You will be mediocre. Choose your colleagues carefully.

• When was the last you heard about a cool concept/technology from a colleague?
• When was the last you participated in a good tech talk as a team?
• When was the last your colleague suggested you a great article / book?
• When was the last when your manager suggested you a technology you have never heard of?

An architect should understand that time is not an infinite resource

Engineering is not about perfect solutions, It is about doing the best you can with Limited resources – Randy Pausch, The Last Lecture

You cannot design / architect every aspect of the solution to perfection. Instead an architect should identify what are the most important modules of the system and focus his effort on making them the best. Eric Evans talks about this under the head of Strategic Design.

As an architect if you make any technological mistakes, it is amplified because of the number of people who follow you

Do not learn on the job, learning is continuous and you should have to learn things before hand. Keep a practice ground,  may be a pet project, may be code & design katas. Even though this applies to any programmer, this applies even more to architects.

Sprint Zero is really important

People are good at emulating something that’s already there. So setup a good representative sample usage of the proposed architecture in code.

Know your limitations as an architect working from a vendor side @ an offshore location

Expect you to be heard less, having less voice in a few scenarios.

Learn to disagree and commit

This is the most important thing that you need to learn as an architect. Not always your opinion will be given a fair consideration (no matter how hard you believe it). You have the following options

• Learn to either disagree gracefully but still commit for the other alternative.
• Ask for forgiveness than for permission. Implement your solution and prove that it works better, anyone can raise objections to solutions in air (not implemented) but very few can resist the hard reality.

Learn when to quit

Since you have not become an architect in 21 days and became one through your hard earned knowledge there will be many occasions when other stakeholders (esp. higher up ex: Clients, Project Managers) will be hell bent on implementing what you think as the obvious wrong solution. If you too strongly believe in what you think should be the solution, explaining it and moving out of the solution implementation is a very valid alternative. Keep your ego in check in these scenarios and you have the options listed in Disagree and Commit. Remember that your stakeholders are too stressed that they start believing in laetrile, they are human too.

If you raise hell about a problem, they focus on you more than the problem. You become the problem.

You cannot swim against the current for long, you have to either swim with the current or swim out of it.

Expect to work for the worst

I know this is flamebait and a highly biased personal opinion. The sorry state of software project management is that people take up the profession because they cannot keep pace with technology any more. It is very likely that you will end up working for managers like that, prepare yourselves. Expect the worst; you won’t be disappointed if you end up working for one.

A corollary to that, when you do get to work with good Managers, do whatever it takes to be with them. The others might think you are insane / mad but it doesn’t matter.

If you are an aspiring architect / practicing architect and if you have stopped keeping up with technology, its time to quit the profession.

Stay on top of development

This becomes really crucial if you are hands on guy. Coding your modules as well as staying on top of other modules becomes really hard. Code reviews are a good way to understand what is going on in the rest of project and learning a few techniques from your team members.

Comment source commits into the Version Control System and have a Source Monitor like SVN Monitor, read the comments periodically (may be once in two days). Dive in to the source when needed. Reviewing every line of code is impossible, so pair with new members yourselves or pair new members with existing team members till they pick up the project idioms and practices. This can keep the review effort to minimum.

Automate mundane things using a static analysis tool like NDepend.

Bridge the generation gap

I have to do much better here. As an experienced architect (Since you have not become an architect in 21 days)  the people in your generation are likely to be your managers or other peers. The people in your team who you lead technically will be in the next generation. It is natural that you hang around with people from your age of development, generation of development (Those are the people with whom you can have discussions like – When we were programming in ASP / COBOL yada yada yada). This widens the generation gap further and alienates you. Connect across generations. As an architect you have no other option. I always used to see earlier generation people as perfectionists (old school), There is every probability that my team is thinking the same way about me and your team about you.

Expect that you will make a lot of mistakes, forgive yourselves

The life of a software architect as a long and rapid succession suboptimal design decisions  taken – Philip Krutchen

And live to guide the aspiring architects, make a difference.

Happy Architecting, And do not  pee on the electric fence, read the books, learn the concepts, observe practicing architects / tech leads / lead programmers.

Thank you

I am completing 4 years in my current job today. It was a memorable year in terms of experience gained / lessons learnt.

Good judgment comes from experience, and often experience comes from bad judgment.  ~Rita Mae Brown

That’s right I judged quite a few things wrong this year, but the overall result is that I learnt a lot this year than the rest of the years put together. The most important thing is that I survived and I am doing well enough to tell the tale. It would not be possible without help from the team I am working with. Specially I would like to thank Prakash J and Razak.

The highlights of the year

• I had the privilege and honor of working directly with Prakash J for a couple of weeks in a short business trip to Kettering. I gave Prakash a tough time, but over all in the end I enjoyed the time and it helped me realize what I was missing. I also had the luxury of meeting one of the best product teams in Kettering. It was an inspired lot and enjoyed interacting with them. Special thanks to Naresh who hosted us really well and lead the interactions.
• I was developing in full steam (uninterrupted) for a decent time to get a delayed project on track. Thanks to Razak for giving me the opportunity.
• I spent a couple of days developing in full throttle for a client demo. Yeah it was a metadata driven system.

Directions to Sri Ganapathi Sachidananda Ashrama / Karya Siddhi Hanuman Temple in Girinagar, Bangalore

I was searching directions to the Karya Siddhi Hanuman Temple in Sri Ganapathi Sachidananda Ashrama – Girinagar, Bangalore. I thought of providing the links to the google maps directions from Vidyapeeta Circle (which is nearby to where I stay) and from Outer ring road. You basically reach Seeta Circle and take a right or left depending on where you are coming from and get into Girinagar.

Google maps Directions From vidyapeeta circle – Click here

Google maps Directions From outer ring road – Click here

Once you get to Seeta Circle these micro level directions should help

Google maps Directions from Seeta Circle – Click here

Hope

 

Image courtesy: http://khollandsblog.wordpress.com

Happy New Year 2011

Friends,

Wish you all a happy and prosperous 2011.