Had a discussion earlier today about  ArrayList versus List<T> and whether or not there was a performance gain to using List<T> when you're dealing with value types. The jury is still out on that but i'm pretty sure a List<int> will not have to box/unbox the variables and you will have to box/unbox the variables when dealing with an ArrayList... to be continued.

However, a co-worker brought up an interesting overload on the sort() and FindAll() methods of a List<T> that i wasn't aware of! The ability to send in a Predicate<T> with the FindAll() and send in a Comparison<T> with the the Sort()!

my experiment started with this bit of code, sorting a list of people, then filtering out anyone that had a certain last name. It looked like this using anonymous delegates:

using System;
using System.Collections.Generic;
using System.Text;

namespace Sorting
{
    class Program
    {
        static void Main(string[] args)
        {
            List<Person> people = new List<Person>();
            people.Add(new Person("Mike", "Mayer"));
            people.Add(new Person("Ben", "Johnson"));
            people.Add(new Person("Mark", "Baldwin"));
            people.Add(new Person("Ross", "Jackson"));
            people.Add(new Person("James", "Turner"));
            Console.WriteLine("===People UnSorted===");
            DisplayPeople(people);
            Console.WriteLine();
           
            //compare by last name
           
            people.Sort(
                            delegate(Person one, Person two)
                            {
                                return one.Lastname.CompareTo(two.Lastname);
                            }
                       );
            Console.WriteLine("===People Sorted===");
            DisplayPeople(people);
            Console.WriteLine();
           
            //filter by 'is peckham'
           
            List<Person> peopleFiltered =
                people.FindAll(
                                    delegate(Person P)
                                    {
                                        return P.Lastname.ToLower() == "johnson";
                                    }
                              );
           
            Console.WriteLine("===People who are peckham===");
            DisplayPeople(peopleFiltered);

            Console.WriteLine("press any key to exit");
            Console.ReadKey();
           

        }
        static void DisplayPeople(IEnumerable<Person> people)
        {
            foreach (Person p in people)
            {
                Console.WriteLine("{0}, {1}", p.Lastname, p.FirstName);
            }
        }
    }
    public class Person
    {
        public Person(string first, string last)
        {
            this.FirstName = first;
            this.Lastname = last;
        }

        private string _lastname;

        public string Lastname
        {
            get { return _lastname; }
            set { _lastname = value; }
        }
        private string _firstName;

        public string FirstName
        {
            get { return _firstName; }
            set { _firstName = value; }
        }

    }
}

it's important to note that

delegate(Person P)
                                    {
                                        return P.Lastname.ToLower() == "johnson";
                                    }

is the same as saying:

Predicate<Person> pred = new Predicate<Person>(IsJohnson);

where the IsJohnson method looks like this:

static bool IsJohnson(Person P){return P.Lastname.ToLower() == "johnson";
}

So, some of you may know that i'm now a part of what some call a "Top Down" scrum. This means that someone in the development organization or the business organization heard the word scrum or agile and said "Man, we should be doing that" then they told someone below them, and that person told the person below them, and eventually a developer was told "Be more agile".

Now what?

Well, first, you need a prioritized list of work for the product. No not 3 lists and not a 50 page requirements document. One single prioritized list of high level things that you want the product to do.

This is hard.

As an organization that comes from waterfall, we seem to be accustomed to having a business analyst talk to the product manager who talks to users, stakholders, etc and comes up with a vision for the product. This business analyst talks to them about use cases and test cases and creates elaborate diagrams and screenshots and every gizmo and gadget that could possibly be thought of. ALL of it must be captured before passing on that document over to the developers to start working.

So we just take that requirements document and that is our product backlog right?

(makes buzzer sound) NO... why?

This is ridiculous james, why wouldn't i create my 50 page requirements document for these 8 feature functionalities for this planned release that we want to do.

well, for one, by the time you actually finish that document the opportunity for a market share may already be gone.  poof, you just missed out!

for two, your one single business analyst becomes your one single chokepoint of functionality! yikes!

Well, what can we do?

Scrum says, get a product owner. Make it your product manager person, they're already doing half the work (or more) of what a product owner should be doing. (talkin to stakeholders, customers, users, friends, their cat about how the software SHOULD be).

well, where do i put this business analyst then?

Put them in the team, with the developers!

this goes back to my diagram

there's a list of high level ideas, that's the product backlog. All detail is created Just in Time and just enough to get started. Everything else is waste!

let me just be very very very specific.

here's my product backlog:

1. customers can login to their account
2. customers can edit their login info once logged in
3. customers can create a new account
4. customers can browse items for sale
5. customers can purchase an item
6. customers can add an item to their cart for purchasing later
7. customers can print an old invoice

Anyhow, let's say our planned release is items 1-4. If we have a BA go off and detail items 1-4, it's going to take them probably 3, 4, 5, maybe 7 weeks... meanwhile the developers are doing god knows what while customers are going to some other company for their business. UNACCEPTABLE!

Step 1, get the above list.

Step 2, take the first item and sit with your developers, and break everything down into very low level "Deliverable" tasks. ... ie

1. specs/requirements
2. test cases
3. login page UI layout
4. login page UI logic
5. login logic object
6. accounts table
7. accounts mock data
8. UAT

step 3, estimate all of these tasks as a group.

step 4, team members choose the tasks they are going to do (business analyst, tech writer, qa person, everyone)

step 5, go do those tasks, when something outside the team keeps you from doing a tasks, inform the team of an impediment (the whole team! including your product owner), every day have a scrum meeting(or standup) and make sure EVERYONE on the team says what they did, what they will do, and what is in their way. Keep in mind, those things they are doing should match the sprint backlog. Scrum master watch for this. -This part is hard-

step 6, demo your potentially shippable products (anything that is "Done"). The rest of it put back on the product backlog for next sprint.

Step 7, have a retrospective, talk about what you did well, what you didn't do well. Make actionable items - Put them on the product backlog. Make sure the WHOLE team is there. -Again, this is hard-

repeat steps 1-7 with a rythmic and concise timing over and over.

of course, there is no cookbook for scrum... this is just how i hope to see it happening :)

I was sitting with my team lead the other day and we were discussing how to work with our multiple lines of business effectively. (I repeatedly am trying to explain that we just need 1 product owner to speak for all of them.)  

   Currently we're getting two product backlogs for 1 single product. His thinking is that we just run two different sprints with two different sets of functionality at the same time. Simply branch the code base.

My thinking is, "When are you going to do the integration in that?" because you certainly aren't going to be able to do it continously. He says well we'll have 2 builds, 2 continuous integrations going, and then when we go to put in sprint X with the trunk of production code we'll just merge all of that.

UH, that IS integration. How can it be continous if you're doing it at the end?

I was being sortof stubborn at this point because i was becoming irritated. How can someone not clearly see: One product, One Product backlog, One product owner, One Sprint at a time, One Team on that Sprint, One finished set of Functionality at the end "Potentially" ready to ship.

Let's take a look at the scrum framework diagram:

If you look at this diagram you see the blue boxes on the left. Those represent everything you're going to do in the project (that you currently know about). The white box on the far right, that's the product, finished, potentially ready to ship. Now, if you have to integrate (merge two different lines of code) you have to do that somewhere in between those 2 things, and you have to do it often (as prescribed by the makers of SVN, VSS, etc you should always merge and resolve conflicts as often as possible). Anyhow, if you're merging and resolving, and fighting all of these integration issues during your sprint that leaves little time for actual product development. Keep in mind you have to do this in EACH team not just one team. Unless you want a whole team dedicated to integrating everyone elses code... (oh god don't even think about, james).

Anyhow, as with EVERYTHING in scrum... try it, if it isn't working for you, it'll show up as an impediment. (if you have the right team and the framework is in place)!

As Ken Schwaber is reknowned for saying..."This(scrum) is hard"

I had to activate a new phone today because my current one keeps locking up so they replaced it. I called sprint, and the lady was speaking english words but wasn't understanding my simple grammar of "i want to swap phones". Somehow through the conversation she said that i would need to provider her an alternate number for her to contact me to continue the ESN swap. I said that wasn't possible, she said there was nothing she could do for me.

After some self exploration on their website, i found they had a webtool (that the CSR should have told me about instead of saying she couldn't help me) and i went into that. Joined a chat session with a CSR and had the following, comical but aggravating conversation with yet another inept CSR.

In case you're new to customer service, the single most important rule that i was taught is: Never ever say you cannot do something, but instead focus on what you CAN do for the customer.

In both of these situations the CSR should have said what they could do for me instead of being unwilling to offer any assistance at all.

The first should have responded to my lack of additional phone by saying "Well an alternative to the phone activation via phone is available, just go to sprintpcs.com and click on the activate phone link"

the second rep when i asked for a phone swpa should have said "sir, i'm actually not a chat rep who can perform an activation and i'm unable to transfer you to one directly, however you could disconnect from this session and open another until you get a chat rep who can help you."

There sprint, enjoy your CSR lesson.

I went to sign into biztalk.net today and ran into a problem with it:

It said “An information card selector was not detected” and when I tried to associate a card to my account, I had a few other problems:

I got this error when I tried to select a card to associate:

Funny thing is, I have .net 3.5 installed and .net 3.0 since I’m using Vista home premium. So being the modest hacker I am, I started fooling around in msdn to find out where the registry keys were. I stumbled upon this link:

http://msdn2.microsoft.com/en-us/library/bb924465.aspx

and this one helped find the key too:

http://msdn.microsoft.com/msdnmag/issues/07/04/Identity/

When I searched my machine, I found out I didn’t have this registry key so I went to my other machine. It did. I copied the key out to a reg file and installed it. This fixed my problem.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\InformationCard Token Provider]

@="{D978F0CB-DEBA-4388-83BE-D3E106E02A4F}"

<Link to the .reg file>

the fix seems to be the same for .net 3.5 and 3.0 who are missing the key. Basically it just points to the CLSID of the .net Cardspace provider :) so if your card provider isn't cardspace it'll be different.

*I will not support this registry file nor be responsible for any damages to your machine caused by editing the registry.

I have to admit, i'm such a Mike Cohn fanboy lately, but this particular article was definitely a good read.

I just came on board with an organization that's doing the 'start slow' approach, from top-down. There's definitely one or two groups that have had success with agile and now it's our group's turn and we're having issues. Maybe we're too high profile, maybe our architecture is too laden with overcomplexity and brittleness, maybe the team is too big for it... who knows.

If you're going to do it, make sure you have full support from high up in the organization. Get yourself a champion for the cause who will fend off the naysayers to allow you to improve the process. Once the old practices of doubting and hiding come back into play it's hard to keep moving forward as people backtrack on promises, skulk in corners, and belittle others to stave off humiliation or loss of their job.

Most importantly, make sure your customers want what agile is going to give them: High visibility, truth, incremental delivery, a hand in the work. In the end it's about giving the customer what they want.

edit:

as i was reading tonight i stumbled on this very interesting set of articles:

http://kw-agiledevelopment.blogspot.com/2007/09/how-to-implement-scrum-in-10-easy-steps.html

We're using scrumworks (a scrum backlog tool) at my current assignment, and i have to say i'm honestly really impressed with it. BUT...

If you don't understand agile and are told to 'burn down' your hours on a daily basis you'll find most people think that means "i worked 8 hours so i burn off 8 hours on this task"

WRONG

Here's why in two parts.

One, in scrum, things are either done or they're not. I am a purist in this regard...this is a binary operation. It's either done or it's not. (See defining done in ken's book). If you're having to 'burn 8 hours' off a single task... your problem is your tasks are too damn big to be managable! Try decomposing further!

second, your goal isn't to create a perfect looking burndown... your goal is to represent the work you're actually doing in the best means possible. This means always putting in the number of hours that you have remaining. This means that if your task said 4 hours this morning, but at the end of the day you think it has 4 hours left to go, you leave it at 4 hours. Basically every time you estimate a task you need to be estimating how much time is left to do.

You may have learned something new today that you didn't know about the day before on that task.  Just today for example i was suppose to be adding some account detail information on to an asp.net page and i figured "this is going to be a simple update, some format, some text changing... NO! i was wrong. What i thought was going to be 15 hours of work was actually many many tasks with 4 hours each.

Now as management, you have to do the right thing here and not come down on the developers for 'finding' out this change in information. you have to use the information to your benefit by figuring out what happened and addressing it properly. Maybe you need to remove some items off the sprint to bring the burndown back in line with your sprint end date? Maybe you actually have to bring more items in from the product backlog?

I've previously felt that becoming agile was taking 'best' practices from all of these books i've read and trying to apply them.

If we use TDD we'll have less defects, if we use planning poker we'll get quicker and better estimates, if we use automated integration scripts we'll have the fastest deploy time.

Maybe those are all true, but as soon as we're doing the 'best' practice that we read in some book, we've stopped caring to improve. _That_ is what agile is all about.

To me, an agile team is a team that is empowered to make changes for the better and is wise enough to keep good metrics to compare themselves now to their previous selves.

If we have 8 defects per iteration and we implement TDD and our defect rate drops to 5 in the first week... it might be working, but don't change anything for a couple weeks... see if it continues to drop or if it pops right back to 8.

If we change how we do estimating, keep track of our velocity and see how/if it changes. Analyze those differences and make tweaks accordingly!

If there is no clear direction for the team... you may be the problem! The team needs to get together and decide what it's going to do. The time for being political and playing mind games is over. Take the reigns of yourself and say what you think needs be done... and then take action.

The point is, if your managers have become hands-off.. and you've been told you're doing scrum,dsdm,fdd,xp,etc... then YOU are in charge of your own development. So step up and help out.

Right now i'm working on how to take good metrics of our team. I'll blog about it soon i hope.

"I have a friend" who is using a tool called scrumworks to assist them in reporting for their scrum process. It's a very nice tool, and I honestly cannot say there isn't a feature I wish it had or a feature I wish that it didn't have. At the very worst, I dislike it's inability to let me my friend put in a "?" for an estimate of hours (for unknown), but I'll live with that because you CAN put it as "Impeded" and just say that you don't know how to estimate it properly.

Anyhow, the issue at hand is this: The agile manifesto states:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.
http://www.agilemanifesto.org/

This brings me to "Individuals and interactions over processes and tools " and the importance of this statement. It does NOT mean that we do not use tools or processes. We hold on to the ones that allow us to favor individuals and interactions and those that impeded interactivity and individuals we try to get rid of.

So let's talk about what happens when people get a tool such as scrumworks (again, a very good tool).

First, developers may not understand scrum, so now instead of learning scrum they're learning the tool and how to 'update their widgets and doo-dads' instead of figuring out what's important about scrum and why it works.They may result to using the integrated help or reading manuals instead of working with their team on the scrum framework.

Second, The tool is all or nothing in most cases. You can't modify X feature in the tool to suppory your way of doing things. Granted, Ken Schwaber would probably say "if you're modifying scrum then you're trying to hide something ugly", however I'm going to guess that 99% of organizations using agile modify it in some way... I sure haven't been in one that didn't.

thirdly, and most importantly in my opinion: Instead of having to stand up in the daily scrum and say what's impeding you, you can stick it into the tool and no longer are required to muster the courage to point it out to everyone (thusly circumventing the personal interactions and the empowerment that scrums give the team!)