posts - 293 , comments - 426 , trackbacks - 0

My Links

News

View Steve Michelotti's profile on LinkedIn

Twitter












Tag Cloud

Archives

Post Categories

My Online Presence

Wednesday, November 21, 2012

Strangling the life out of Software Testing

 

I recently did a course at the local university on Software Engineering. At the beginning of the course I looked over the outline of the subject and there seemed to be some really good content. It covered traditional & agile project methodologies, some general communication and modelling chapters and finished off with testing. I was particularly excited to see the section on testing as this was something I learnt on my own and see great value in.

The course has now just ended and I am very disappointed. I now know one of the reasons why so few people i.e. in my region do Test Driven Development, or perform even basic testing methodologies. The topic was to academic! Yes, you might be able to list 4 different types of black box test approaches vs. white box test approaches and describe the characteristics of Smoke Tests, but never during course did we see an example of an actual test or how it might be implemented! In fact, if I did not have personal experience of applying testing in actual projects, I wouldn’t even know what a unit test looked like.

Now, what worries me is the following…

It took us 6 months to cover the course material, other students more than likely came out of that course with little appreciation of the subject – in fact they now have a very complex view of what a test is – so complex that I think most of them will never attempt it again on their own.

Secondly, imagine studying to be a dentist without ever actually seeing a tooth? Yes, you might be able to describe a tooth, and know what it is made out of – but nobody would want a dentist who has never seen a tooth to operate on them. Yet somehow we expect people studying software engineering to do the same? This is not right.

Now, before I finish my rant let me say that I know this is not the same everywhere in the world, and that there needs to be a balance on practical implementation and academic understanding – I am just disappointed that this does not seem to be happening at the institution that I am currently studying at ;-(

Please, if you happen to be a lecturer or teacher reading this post – a combination of theory and practical's goes a long way. We need to up the quality of software being produced and that starts at learner level!

Posted On Wednesday, November 21, 2012 1:24 PM | Comments (12) | Filed Under [ Misc ]

Friday, November 2, 2012

Incentivizing Work with Development Teams

 

Recently I saw someone on twitter asking about incentives and if anyone had past experience with incentivizing work. I promised to respond with some of the experiences I have had in the past so here goes...

**Disclaimer** - these are my experiences with incentives, generally in software development - in some other industries this may not be applicable – this is also my thinking at this point in time, with more experience my opinion may change.

Incentivize at the level that you want people to group at

If you are wanting to promote a team mentality, incentivize teams. If you want to promote an individual mentality, incentivize individuals. There is nothing worse than mixing this up. Some organizations put a lot of effort in establishing teams and team mentalities but reward individuals. This has a counter effect on the resources they have put towards establishing a team mentality.

In the software projects that I work with we want promote cross functional teams that collaborate. Personally, if I was on a team and knew that there was an opportunity to work on a critical component of the system, and that by doing so I would get a bigger bonus, then I would be hesitant to include other people in solving that problem. Thus, I would hinder the teams efforts in being cross functional and reduce collaboration levels.

Does that mean everyone in the team should get an even share of an incentive? In most situations I would say yes - even though this may feel counter-intuitive. I have heard arguments put forward that if “person x contributed more than person Y then they should be rewarded more” – This may sound controversial but I would rather treat people how would you like them to perform, not where they currently are at. To add to this approach, if someone is free loading, you bet your bottom dollar that the team is going to make this a lot more transparent if they feel that individual is going to be rewarded at the same level that everyone else is.

Bad incentives promote destructive work

If you are going to incentivize people, pick you incentives very carefully. I had an experience once with a sales person who was told they would get a bonus provided that they met an ordering target with a particular supplier. What did this person do? They sold everything at cost for the next month or so. They reached the goal, but the company didn't gain anything from it. It was a bad incentive.

Expect the same with development teams, if you incentivize zero bug levels, you will get zero code committed to the solution. If you incentivize lines of code, you will get many many lines of bad code.

Is there such a thing as a good incentives?

Monetary wise, I am not sure there is. I would much rather encourage organizations to pay their people what they are worth upfront. I would also advise against paying money to teams as an incentive or even a bonus or reward for reaching a milestone. Rather have a breakaway for the team that promotes team building as a reward if they reach a milestone than pay them more money.

I would also advise against making the incentive the reason for them to reach the milestone. If this becomes the norm it promotes people to begin to only do their job if there is an incentive at the end of the line. This is not a behaviour one wants to encourage. If the team or individual is in the right mind-set, they should not work any harder than they are right now with normal pay.

Posted On Friday, November 2, 2012 7:47 AM | Comments (1) | Filed Under [ Misc ]

Monday, October 15, 2012

Refactoring FizzBuzz

 

A few years ago I blogged about FizzBuzz, at the time the post was prompted by Scott Hanselman who had podcasted about how surprized he was that some programmers could not even solve the FizzBuzz problem within a reasonable period of time during a job interview.

Originally I thought I would give the problem a go in F# and sure enough the solution was fairly simple – I then also did a basic solution in C# but never posted it. Since then I have learned that being able to solve a problem and how you solve the problem are two totally different things. Today I decided to give the problem a retry and see if I had learnt anything new in the last year or so. Here is how my solution looked after refactoring…

Solution 1 – Cheap and Nasty

public class FizzBuzzCalculator
{

    public string NumberFormat(int number)
    {
        var numDivisibleBy3 = (number % 3) == 0;
        var numDivisibleBy5 = (number % 5) == 0;

        if (numDivisibleBy3 && numDivisibleBy5) return String.Format("{0} FizzBuz", number);
        else if (numDivisibleBy3) return String.Format("{0} Fizz", number);
        else if (numDivisibleBy5) return String.Format("{0} Buz", number);

        return number.ToString();
    }

}

class Program
{
    static void Main(string[] args)
    {
        var fizzBuzz = new FizzBuzzCalculator();

        for (int i = 0; i < 100; i++)
        {
            Console.WriteLine(fizzBuzz.NumberFormat(i));
        }        
    }
}

My first attempt I just looked at solving the problem – it works, and could be an acceptable solution but tonight I thought I would see how far  I could refactor it… The section I decided to focus on was the mass of if..else code in the NumberFormat method.

Solution 2 – Replacing If…Else with a Dictionary

public class FizzBuzzCalculator
{
    private readonly Dictionary<Tuple<bool, bool>, string> _mappings;

    public FizzBuzzCalculator(Dictionary<Tuple<bool, bool>, string> mappings)
    {
        _mappings = mappings;
    }

    public string NumberFormat(int number)
    {
        var numDivisibleBy3 = (number % 3) == 0;
        var numDivisibleBy5 = (number % 5) == 0;

        var mappedKey = new Tuple<bool, bool>(numDivisibleBy3, numDivisibleBy5);

        return String.Format("{0} {1}", number, _mappings[mappedKey]);
    }
}

class Program
{
    static void Main(string[] args)
    {
        var mappings = new Dictionary<Tuple<bool, bool>, string>
                {
                    { new Tuple<bool, bool>(true, true), "- FizzBuzz"},
                    { new Tuple<bool, bool>(true, false), "- Fizz"},
                    { new Tuple<bool, bool>(false, true), "- Buzz"},
                    { new Tuple<bool, bool>(false, false), ""}
                };

        var fizzBuzz = new FizzBuzzCalculator(mappings);

        for (int i = 0; i < 100; i++)
        {
            Console.WriteLine(fizzBuzz.NumberFormat(i));
        }

        Console.ReadLine();
    }
}

In my second attempt I looked at removing the if else in the NumberFormat method. A dictionary proved to be useful for this – I added a constructor to the class and injected the dictionary mapping. One could argue that this is totally overkill, but if I was going to use this code in a large system an approach like this makes it easy to put this data in a configuration file, which would up its OC (Open for extensibility, closed for modification principle).

I could of course take the OC principle even further – the check for divisibility by 3 and 5 is tightly coupled to this class. If I wanted to make it 4 instead of 3, I would need to adjust this class. This introduces my third refactoring.

Solution 3 – Introducing Delegates and Injecting them into the class

public delegate bool FizzBuzzComparison(int number);

public class FizzBuzzCalculator
{
    private readonly Dictionary<Tuple<bool, bool>, string> _mappings;
    private readonly FizzBuzzComparison _comparison1;
    private readonly FizzBuzzComparison _comparison2;

    public FizzBuzzCalculator(Dictionary<Tuple<bool, bool>, string> mappings, FizzBuzzComparison comparison1, FizzBuzzComparison comparison2)
    {
        _mappings = mappings;
        _comparison1 = comparison1;
        _comparison2 = comparison2;
    }

    public string NumberFormat(int number)
    {
        var mappedKey = new Tuple<bool, bool>(_comparison1(number), _comparison2(number));

        return String.Format("{0} {1}", number, _mappings[mappedKey]);
    }

}

class Program
{
    private static bool DivisibleByNum(int number, int divisor)
    {
        return number % divisor == 0;
    }

    public static bool Divisibleby3(int number)
    {
        return number % 3 == 0;
    }

    public static bool Divisibleby5(int number)
    {
        return number % 5 == 0;
    }

    static void Main(string[] args)
    {
        var mappings = new Dictionary<Tuple<bool, bool>, string>
                {
                    { new Tuple<bool, bool>(true, true), "- FizzBuzz"},
                    { new Tuple<bool, bool>(true, false), "- Fizz"},
                    { new Tuple<bool, bool>(false, true), "- Buzz"},
                    { new Tuple<bool, bool>(false, false), ""}
                };

        var fizzBuzz = new FizzBuzzCalculator(mappings, Divisibleby3, Divisibleby5);

        for (int i = 0; i < 100; i++)
        {
            Console.WriteLine(fizzBuzz.NumberFormat(i));
        }

        Console.ReadLine();
    }
}

I have taken this one step further and introduced delegates that are injected into the FizzBuzz Calculator class, from an OC principle perspective it has probably made it more compliant than the previous Solution 2, but there seems to be a lot of noise. Anonymous Delegates increase the readability level, which is what I have done in Solution 4.

Solution 4 – Anon Delegates

    public delegate bool FizzBuzzComparison(int number);

    public class FizzBuzzCalculator
    {
        private readonly Dictionary<Tuple<bool, bool>, string> _mappings;
        private readonly FizzBuzzComparison _comparison1;
        private readonly FizzBuzzComparison _comparison2;

        public FizzBuzzCalculator(Dictionary<Tuple<bool, bool>, string> mappings, FizzBuzzComparison comparison1, FizzBuzzComparison comparison2)
        {
            _mappings = mappings;
            _comparison1 = comparison1;
            _comparison2 = comparison2;
        }

        public string NumberFormat(int number)
        {
            var mappedKey = new Tuple<bool, bool>(_comparison1(number), _comparison2(number));
            return String.Format("{0} {1}", number, _mappings[mappedKey]);
        }

    }

    class Program
    {
        static void Main(string[] args)
        {
            var mappings = new Dictionary<Tuple<bool, bool>, string>
                {
                    { new Tuple<bool, bool>(true, true), "- FizzBuzz"},
                    { new Tuple<bool, bool>(true, false), "- Fizz"},
                    { new Tuple<bool, bool>(false, true), "- Buzz"},
                    { new Tuple<bool, bool>(false, false), ""}
                };

            var fizzBuzz = new FizzBuzzCalculator(mappings, (n) => n % 3 == 0, (n) => n % 5 == 0);

            for (int i = 0; i < 100; i++)
            {
                Console.WriteLine(fizzBuzz.NumberFormat(i));
            }

            Console.ReadLine();
        }
    }

 

Using the anonymous delegates I think the noise level has now been reduced. This is where I am going to end this post, I have gone through 4 iterations of the code from the initial solution using If..Else to delegates and dictionaries. I think each approach would have it’s pro’s and con’s and depending on the intention of where the code would be used would be a large determining factor. If you can think of an alternative way to do FizzBuzz, add a comment!

Posted On Monday, October 15, 2012 7:58 PM | Comments (30) |

Sunday, September 30, 2012

The cost of Programmer Team Clustering

 

I recently was involved in a conversation about the productivity of programmers and the seemingly wide range in abilities that different programmers have in this industry. Some of the comments made were reiterated a few days later when I came across a chapter in Code Complete (v2) where it says "In programming specifically, many studies have shown order-of-magnitude differences in the quality of the programs written, the sizes of the programs written, and the productivity of programmers". In line with this is another comment presented by Code Complete when discussing teams - "Good programmers tend to cluster, as do bad programmers".

This is something I can personally relate to. I have come across some really good and bad programmers and 99% of the time it turns out the team they work in is the same - really good or really bad. When I have found a mismatch, it hasn't stayed that way for long - the person has moved on, or the team has ejected the individual.

Keeping this in mind I would like to comment on the risks an organization faces when forcing teams to remain together regardless of the mix. When you have the situation where someone is not willing to be part of the team but still wants to get a pay check at the end of each month, it presents some interesting challenges and hard decisions to make.

First of all, when this occurs you need to give them an opportunity to change - for someone to change, they need to know what the problem is and what is expected. It is unreasonable to expect someone to change but have not indicated what they need to change and the consequences of not changing.

If after a reasonable time of an individual being aware of the problem and not making an effort to improve you need to do two things...

  • Follow through with the consequences of not changing.
  • Consider the impact that this behaviour will have on the rest of the team.

What is the cost of not following through with the consequences?

If there is no follow through, it is often an indication to the individual that they can continue their behaviour. Why should they change if you don't care enough to keep your end of the agreement? In many ways I think it is very similar to the "Broken Windows" principles – if you allow the windows to break and don’t fix them, more will get broken.

What is the cost of keeping them on?

When keeping a disruptive influence in a team you risk loosing the good in the team. As Code Complete says, good and bad programmers tend to cluster - they have a tendency to keep this balance - if you are not going to help keep the balance they will. The cost of not removing a disruptive influence is that the good in the team will eventually help you maintain the clustering themselves by leaving.

Posted On Sunday, September 30, 2012 9:30 AM | Comments (1) |

Wednesday, September 19, 2012

It is not quantifiably better

 

An interesting statement I have heard recently in one of the organizations that I have been working with is that some of the agile processes that we are implementing are not quanitfiably better than the traditional processes they had before. This seemed to be the motivation for not moving the new process to the rest of the organization or expanding it.

They would say, “the team seems to be happier than they were before but the improvement is not quanitifiable and until we can quantify it on paper we cannot make any further changes”.

Up till recently I thought this was a problem until it dawned on me that their existing system was not being quantified, meaning even if I managed to quantify what we were doing (which I can), what would we be comparing it to?

An appropriate response to someone when they give this reasoning is - "That's a very good point, let's go over the quantifiable attributes of your existing processes and see if we can get some common metric that we can compare them on?"

If they then are able to produce some quantifiable metrics, you win because you now have something to compare it to, and if they don't then you can politely point the logic of that out as well.

Posted On Wednesday, September 19, 2012 7:11 AM | Comments (0) |

Monday, September 17, 2012

Principles vs. Process

 

I recently had an interesting experience with a new team learning Scrum. The team came from a hierarchical background where they were very process oriented. For the first few sprints of scrum the team went through the normal forming stage and then all of a sudden it all began to fall apart.

In dissecting what went wrong with the team various feedback was received but overwhelmingly the feeling from my side was that the Process of Scrum had taken priority over the principles of Agile.

For example...

  • The "Product Owner" was not happy with the progress of the team but felt he could not verbalize this with the team because he did not want to be seen as "managing" the team. Instead he felt that the demo with the client was the best place to verbalize his concerns.
  • A team member was very concerned about how some of the team were working together, but felt he had to wait a week and a half before bringing it up with the team because this type of communication was meant for the retrospective.

For me these are classic examples of someone learning the process, but not learning the principles behind the process.

The agile manifesto outlines the principles quite clearly...

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

In both examples what came across strongly with both examples was that these individuals were putting processes and tools over individuals and interactions.

For instance, the Product Owner was correct, the process is not to "manage" the team in a command and control structure and the demo is a place where concerns about the progress of the project can be verbalized BUT what was missed was if you are part of the team (which the product owner is) and you feel your fellow team members are off track and not going to deliver you have every right to bring this up in a respectful way to the team and address it asap. This is not managing, this is called being a team player. You would be doing your fellow team a disservice leaving this.

This was highlighted even more with the team member waiting a week and a half to verbalize their concern of a process because it was retrospective "stuff". The retrospective is definitely a good place to bring up process adjustments, BUT it is not the only place! If there is a major issue and it has to be dealt with now then now is probably a good time to deal with it (Provided it is urgent). If it is not urgent and can wait a week and a half then the retrospective would be the better place to bring it up.

The rule of thumb... process is a good thing and having a solid process is a good base for a well performing team, but understanding the principles behind the process ultimately leads to a team being really effective.

Posted On Monday, September 17, 2012 5:20 PM | Comments (0) |

Friday, September 7, 2012

The challenge of giving a positive No

 

I find it ironic that the more I am involved in the software industry, the more apparent it becomes that soft skills are just as if not more important than the technical abilities of a developer. One of the biggest challenges I have faced in my career is in managing client expectations to what one can deliver and being able to work with multiple clients. If I look at where things commonly go pear shaped, one area features a lot is where I should have said "No" to a request, but because of the way the request was made I ended up saying yes. Time and time again this has caused immense pain.

Thus, when I saw on Amazon that they had a book titled "The power of a positive no" by William Ury I had to buy it and read it. In William's book he explains an approach to saying No that while extremely simple does change the way a No is presented.

In essence he talks of a pattern the Yes! > No > Yes? Pattern.

1. Yes! -> positively and concretely describing your core interests and values
2. No. -> explicitly link your no to this YES!
3. Yes? -> suggest another positive outcome or agreement to the other person

Let me explain how I understood it.

If you are working on a really important project and someone asks you to do add a quick feature to another project, your Yes! would be to the more important project, which would mean a No to the quick feature, and an option for your Yes? may be an alternative time when you can look at it..

An example of an appropriate response would be...

It is really important that I keep to the commitment that I made to this customer to finish his project on time so I cannot work on your feature right now but I am available to help you in a weeks time.

William then goes on to explain the type of behaviour a person may display when the no is received. He illustrates this with a diagram called the curve of acceptance.

Curve of Acceptance


William points out that if you are aware of the type of behaviour you can expect it empowers you to stay true to your no.

Personally I think reading and having an understanding of the “soft” side of things like saying no is invaluable to a developer.

Posted On Friday, September 7, 2012 9:19 AM | Comments (0) |

Tuesday, September 4, 2012

Lessons learnt in implementing Scrum in a Large Organization that has traditional values

 

I recently had the experience of being involved in a “test” scrum implementation in a large organization that was used to a traditional project management approach. Here are some lessons that I learnt from it.

Don’t let the Project Manager be the Product Owner

First lesson learnt is to identify the correct product owner – in this instance the product manager assumed the role of the product owner which was a mistake. The product owner is the one who has the most to loose if the project fails. With a methodology that advocates removing the role of the project manager from the process then it is not in the interests of the person who is employed as a project manager to be the product owner – in fact they have the most to gain should the project fail.

Know the time commitments of team members to the Project

Second lesson learnt is to get a firm time commitment of the members on a team for the sprint and to hold them to it. In this project instance many of the issues we faced were with team members having to double up on supporting existing projects/systems and the scrum project. In many situations they just didn’t get round to doing any work on the scrum project for several days while they tried to meet other commitments. Initially this was not made transparent to the team – in stand up team members would say that had done some work but would be very vague on how much time they had actually spent using the blackhole of their other legacy projects as an excuse – putting up a time burn down chart made time allocations transparent and easy to hold the team to.

In addition, how can you plan for a sprint without knowing the actual time available of the members – when I mean actual time, the exercise of getting them to go through all their appointments and lunch times and breaks and removing them from their time commitment helps get you to a realistic time that they can dedicate.

Make sure you meet your minimum team sizes

In a recent post I wrote about the difference between a partnership and a team. If you are going to do scrum in a large organization make sure you have a minimum team size of at least 3 developers. My experience with larger organizations is that people have a tendency to be sick more, take more leave and generally not be around – if you have a team size of two it is so easy to loose momentum on the project – the more people you have in the team (up to about 9) the more the momentum the project will have when people are not around.

Swapping from one methodology to another can seem as waste to the customer

It sounds bad, but most customers don’t care what methodology you use. Often they have bought into the “big plan upfront”. If you can, avoid taking a project on midstream from a traditional approach unless the customer has not bought into the process – with this particular project they had a detailed upfront planning breakaway with the customer using the traditional approach and then before the project started we moved onto a scrum implementation – this seemed as waste to the customer. We should have managed the customers expectation properly.

Don’t play the role of the scrum master if you can’t be the scrum master

With this particular implementation I was the “scrum master”. But all I did was go through the process of the formal meetings of scrum – I attended stand up, retrospectives and planning – but I was not hands on the ground. I was not performing the most important role of removing blockages – and by the end of the project there were a number of blockages “cropping up”. What could have been a better approach was to take someone on the team and train them to be the scrum master and be present to coach them. Alternatively actually be on the team on a fulltime basis and be the scrum master. By just going through the meetings of scrum didn’t mean we were doing scrum.

So we failed with this one, if you fail look at it from an agile perspective

As this particular project drew to a close and it became more and more apparent that it was not going to succeed the failure of it became depressing. Emotions were expressed by various people on the team that we not encouraging and enforced the failure.

Embracing the failure and looking at it for what it is instead of taking it as the end of the world can change how you grow from the experience. Acknowledging that it failed and then focussing on learning from why and how to avoid the failure in the future can change how you feel emotionally about the team, the project and the organization.

Posted On Tuesday, September 4, 2012 10:03 PM | Comments (0) |

Wednesday, August 29, 2012

Minimum team development sizes

Disclaimer - these are observations that I have had, I am not sure if this follows the philosophy of scrum, agile or whatever, but most of these insights were gained while implementing a scrum scenario.

Two is a partnership, three starts a team

For a while I thought that a team was anything more than one and that scrum could be effective methodology with even two people. I have recently adjusted my thinking to a scrum team being a minimum of three, so what happened to two and what do you call it?

For me I consider a group of two people working together a partnership - there is value in having a partnership, but some of the dynamics and value that you get from having a team is lost with a partnership.

Avoidance of a one on one confrontation

The first dynamic I see missing in a partnership is the team motivation to do better and how this is delivered to individuals that are not performing. Take two highly motivated individuals and put them together and you will typically see them continue to perform.

Now take a situation where you have two individuals, one performing and one not and the behaviour is totally different compared to a team of three or more individuals. With two people, if one feels the other is not performing it becomes a one on one confrontation. Most people avoid confrontations and so nothing changes.

Compare this to a situation where you have three people in a team, 2 performing and 1 not the dynamic is totally different, it is no longer a personal one on one confrontation but a team concern and people seem more willing to encourage the individual not performing and express their dissatisfaction as a team if they do not improve.

Avoiding the effects of Tuckman’s Group Development Theory

If you are not familiar with Tuckman’s group development theory give it a read (http://en.wikipedia.org/wiki/Tuckman's_stages_of_group_development)

In a nutshell with Tuckman’s theory teams go through these stages of Forming, Storming, Norming & Performing. You want your team to reach and remain in the Performing stage for as long as possible - this is where you get the most value.

When you have a partnership of two and you change the individuals in the partnership you basically do a hard reset on the partnership and go back to the beginning of Tuckman’s model each time. This has a major effect on the performance of a team and what they can deliver.

What I have seen is that you reduce the effects of Tuckman's theory the more individuals you have in the team (until you hit the maximum team size in which other problems kick in). While you will still experience Tuckman's theory with a team of three, the impact will be greatly reduced compared to two where it is guaranteed every time a change occurs.

It's not just in the numbers, it's in the people

One final comment - while the actual numbers of a team do play a role, the individuals in the team are even more important - ideally you want to keep individuals working together for an extended period. That doesn't mean that you never change the individuals in a team, or that once someone joins a team they are stuck there - there is value in an individual moving from team to team and getting cross pollination, but the period of time that an individual moves should be in month's or years, not days or weeks.

Why?

So why is it important to know this? Why is it important to know how a team works and what motivates them? I have been asking myself this question for a while and where I am at right now is this… the aim is to achieve the stage where the sum of the total (team) is greater than the sum of the parts (team members).

This is why we form teams and why understanding how they work is a challenge and also extremely stimulating.

Posted On Wednesday, August 29, 2012 3:25 PM | Comments (0) |

Monday, August 27, 2012

Legacy Code Retreat Questions

 

I recently heard of the concept of a Legacy Code Retreat. Since I have attended and helped facilitate some normal Code Retreats I thought it might be interesting in trying a Legacy Code Retreat, but I have a few questions on how a legacy CR differs from a normal one. If anyone has attended a Legacy CR and has some suggestions on how best to host these event’s please leave a comment on what has worked for you in the past or if you have any answers to my questions below…

Should you restrict the languages that people can do the sessions in?

In the normal CR’s I have been involved in the past we have had people attend and code in their programming language of choice. A normal CR lends itself to  this because each session starts with no code. With a legacy CR each session seems to start with an existing code base.

Is there some sort of limitation on the languages that people can work in during the sessions? If not, how do you give them a base to start from?

What happens as the beginning of each session?

In the normal CR that I have attended each session would have a constraint set on it – i.e. no if statements used, no primitives, etc. With a legacy CR it seems more like patterns for refactoring are learned.

Does the facilitator explain the pattern used before the session starts or are they just given a code base to start from and an objective to achieve

Posted On Monday, August 27, 2012 12:02 PM | Comments (3) |

Powered by: