Team Dynamics!

Team dynamics play a large part in the success or failure of a project. Often time’s group dynamics play a bigger part than the collective skill set of a team. In my tenure as a software developer, I have had the opportunity to work on teams that have had both good dynamics and nasty dynamics. And as you may have guessed, the experiences are very, very different. A team that works well together and collaborates is far more motivated, excited, and concerned with the overall quality of the end product. Sadly, the opposite is true of the team with lousy dynamics. Team members will isolate themselves, quality will decrease exponentially, and team members simply stop caring because they are frustrated. At the end of the day, your chances of success in a situation like this are essentially, well… 0.

So, with team dynamics fresh in our minds, I thought it would be fun to write a not so technical blog post outlining the different personality types that I have seen as I have moved from one contract to another. I am starting with some of the negative types I have run into over time, and will publish a follow up post with the positive types. I am sure you the reader has many others that you could contribute and I certainly would appreciate hearing what you have to say on the subject!

The Cherry Picker

The cherry picker hunts and pecks his way at the requirement backlog only working on requirements he finds captivating or easy. What’s worse, the Cherry Picker will break down a given requirement into several smaller parts, again, only working on the aspects he finds simple or entertaining. A Cherry Picker will never complete a requirement, because his ‘definition of done’ is based upon him getting bored or confused. Because the Cherry Picker often quits working on a requirement when it becomes difficult, his behavior leads to the endless cycle of ‘defect ping pong’. Simply put, Cherry Pickers are bad. Don’t be a Cherry Picker.

The BA Developer

The BA Developer is one of the most frustrating personality types to work with. A BA Developer will find things he believes are shortcomings in a system and decide that they need to be worked on right now. Of course, they do this work without consulting the other team members and with no defect or requirement to track the work against. Because the BA Developer knows that the actions he is taking will be looked down upon, there are no design discussions or collaboration involved. In the end resulting in fragile implementations of ‘features’ that may or may not be needed. Once the BA Developer completes his ‘enhancement’, the BA Developer will contact the team member he feels will be least appalled by his actions. The BA Developer will then show the perceived weak team member the changes that were made. If a BA Developer if confronted, he will claim things like, ‘I have not checked anything in, I just wanted to see how it would look’. The BA Developer cares remarkably little about the wasted time that brings down the overall velocity of a team. A BA Developer is one of the most dangerous personality types to have on a team. Trumped only by the Sneaker.

The Sneaker

The Sneaker does not care about process, teamwork, standards, patterns, requirements or quality. You may be totally unaware that a Sneaker is among you until you see their handy work with your own eyes. The Sneaker is much like BA Developer, with one key infuriating difference. The Sneaker skips the showing part, and checks in code changes without mentioning a thing! When source control fingers The Sneaker as a build breaker, and he is confronted with the problem, The Sneaker will say things like ‘well I mentioned it’, or ‘I talked to this person or that person’. You should fear above all other personality types The Sneaker.

The No Google-er

The No Google-er seems harmless at first, even though they are very annoying. When faced with a problem, the first instinct of a No Google-er is to ask whoever is close by. Overtime, if other developers allow this to continue, The No Google-er actually forgets about the vast resources available to us by simply using www.google.com. Almost as if they are in complete denial that a thing called the ‘internet’ exists. The No Google-er not only wastes other team members time he is responsible for a disproportionate percentage of defects reported, a problem that is seriously compounded around holiday season when their human search engines are out of town.

The Watcher

The Watcher is a strange personality type whose motivation is as elusive as it is unpredictable. The single trait that all Watchers have in common is that they will hold others up to standard they  refuse to follow. A Watcher is the first to comment about other developers non-standard development practices while ignoring broken build notifications they caused. Those who can do, those who can’t watch.

The Waiter

The Waiter is harmless enough though they are terribly frustrating. Waiters are extraordinarily common and come full of delightful catch phrases like, ‘we are kind of low on work, so I did some online reading’, or the classic, ‘I am waiting on ______’. Oh and I would be remiss if I forgot the common statement of, ‘I am ready to take on something new’. The Waiter is good in that they do not do too much work thus limiting the damage they can do. However, they often times pass on work to more advanced team members out of sheer laziness by stating that the work is above their skill level.

So there it is! The most common negative personality types I have run into. To be fair, I am sure I have fallen into at least one of these in from time to time.

Stay tuned for the followup outlining some positive types.

AcroRd32.exe I hate you (well kinda).

The WebBrowser control is a pretty cool thing. You can use it to host many different document types allowing the user to work with a specific type of document in its most common user interface, at the same time the WebBrowser control frees the developer from writing much of the interop code that would be needed otherwise. And that is always a plus!

However as with any kind of inter-operation between disparate technologies you run into hiccups. A good example of this is what happens when you use the WebBrowser control as a container for AcroRd32.exe to view PDF documents. To understand this ‘hiccup’ we can look to Adobe knowledge base for some guidance.

Adobe Acrobat and Adobe Reader are designed to continue running for a few minutes after you close the browser window in which you viewed PDF files.

If you are interested in a more detailed description take take a gander at this KB.

Adobes ‘Design’ decisions present several challenges when working with PDF documents in a WebBrowser control. The following use case illustrates it best.

1. User searches for a document.
2. User views document (Presumably in a WebBrowser control).
3. User closes document.
4. User attempts to delete the document after closing it.

A issue arises when the user attempts to delete the document upon closing it. Because AcroRd32.exe will hang on to your precious PDF document for ‘few minutes’ upon closure any attempt to delete said document will result in the following error.

The process cannot access the file ‘YourPdf.pdf’ because it is being used by another process. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)

This is a problem. Adobe is holding our document hostage. This aggression will not stand man! Outside of killing the AcroRd32 process (an option that results in all open PDF documents being closed) we have very little recourse against Adobe’s design decision. Getting around this little hiccup ends up being pretty simple and involves always loading a ‘working’ version of the file. Or simply stated every document you load with the WebBrowser control should be a copy of actual document you want to work with. So how do we manage that copy? I suppose there are several ways to do this. However one I found particularly interesting was to use the use the TempFileCollection in the System.CodeDom.Compiler namespace. This was interesting to me for one major reason,  when adding a file to this collection you can supply a flag to indicated that it should be removed upon garbage collection. This is perfect when you truly want a working file and you want it to be gone when you are done with it. Lets take a look at some code that might do this.

<Window x:Class="PDFSample.Window1"
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Title="Window1">
 <Grid>
 <Grid.ColumnDefinitions>
 <ColumnDefinition />
 </Grid.ColumnDefinitions>
 <WebBrowser x:Name="wbPdfViewer"
 Grid.Column="0" />
 </Grid>

</Window>

and the code behind….

using System;
using System.CodeDom.Compiler;
using System.Windows;

namespace PDFSample
{
    /// <summary>
    /// Interaction logic for Window1.xaml
    /// </summary>
    public partial class Window1 : Window
    {
        #region Private Data Members

        private readonly TempFileCollection mTempFile = new TempFileCollection();

        #endregion

        #region Constructor

        /// <summary>
        /// Initializes a new instance of the <see cref="Window1"/> class.
        /// </summary>
        public Window1()
        {
            InitializeComponent();
            wbPdfViewer.Source = new Uri(GetWorkingDocumentPath());
        }

        #endregion

        /// <summary>
        /// Gets the working document path.
        /// </summary>
        /// <returns></returns>
        private string GetWorkingDocumentPath()
        {
            string workingFile = string.Concat(System.IO.Path.GetTempPath(), "MySampleApp_", Guid.NewGuid(),".pdf");
            System.IO.File.Copy(@"C:\Unity-v1p2-October08.pdf", workingFile);
            mTempFile.AddFile(workingFile, false);
            return workingFile;
        }
    }
}

Enjoy!

I Hate Trees

So not really. I don’t particularly mind trees. Tree controls on the other hand I hate. Take for example a simple requirement of launching a new window each time a tree item is selected. Simple right? Well not in WPF. Lets look at a quick example.

<Window x:Class="WpfApplication1.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Grid>
        <TreeView>
            <TreeViewItem Header="Root">
                <TreeViewItem Header="Parent" >
                    <TreeViewItem Header="Child" Selected="ChildTreeViewItem_Selected"></TreeViewItem>
                </TreeViewItem>
            </TreeViewItem>
        </TreeView>
    </Grid>
</Window>

Pile!

The idea here is simple. I want to click on the TreeViewItem labeled ‘child’ and launch a new Window when the its Selected event is raised.

namespace WpfApplication1
{
    /// <summary>
    /// Interaction logic for Window1.xaml
    /// </summary>
    public partial class Window1 : Window
    {
        public Window1()
        {
            InitializeComponent();
        }

        private void ChildTreeViewItem_Selected(object sender, RoutedEventArgs e)
        {
            new Window().Show();
        }
    }
}

Ok so maybe that is not all want. Along with a new window launching, I want it to have focus, and I want the TreeViewItem clicked to turn gray indicating the selection made. Sadly however, this is not what I get. Instead the window is launched *not to bad*, however the new window does not have focus after it is activated *who needs focus*. If that is not bad enough adding insult to injury the TreeViewControl in what I can only imagine is a last ditch effort to handle focus raises a second Selection event on the the TreeViewItem labeled Parent. This *bonus* event sets focus back to the TreeViewControl, showing the incorrect TreeViewItem selected. Like so.

HATE YOU

Humm this image is not so clear how is this.

Pile

In the image above you will see that the ‘Parent’ node is selected. That would be fine if that is what I clicked!

Okay okay rant done. How to fix this? Well I spent a day on this sadly, hence the blog posting. Turns out in order to get this to work you need to use the dispatcher. I am not sure why but when I use a simple Action delegate to launch the window using the Dispatcher it all works just fine. Here is the code.

namespace WpfApplication1
{
    /// <summary>
    /// Interaction logic for Window1.xaml
    /// </summary>
    public partial class Window1 : Window
    {
        public Window1()
        {
            InitializeComponent();
        }

        private void ChildTreeViewItem_Selected(object sender, RoutedEventArgs e)
        {
            Dispatcher.BeginInvoke(DispatcherPriority.Background, new Action(() => new Window().Show()));
        }
    }
}

Anyone care to comment on why this works? Well at least it does!

Enjoy!

Oracle AntHills

So anyone who knows me knows that I am not one to make mountains out of anthills. I never jump to conclusions or make sweeping generalizations. I am always a middle of the road kind of guy. Honest! Just ask my wife!

Just needed to get that out of the way. On to the ‘rant’.

First let me state firmly that given the choice I would never use Oracle when doing .Net development for many obvious reasons such as poor Visual Studio integration yadda yadda. Sure it may be great and all powerful but when it comes to being productive in .Net it is a hinderence. But since I am fair and balanced just like NPR and Fox News let’s for a minute assume all the Oracle advocates are correct.

They Say
Oracle is highly scalable and the best darn thing since the FlowBee.

If the above is correct, why on earth does it puke error messages like this?

PLS-00306: wrong number or types of arguments in call to ‘SOMEPROCNAME’

I am not even sure how to respond to that message. Clearly passing the wrong number of parameters to a procedure is vastly different the passing a parameter of the incorrect type. So which is it all knowing Oracle God! Help a brother out!

For a database that has been around for as long as I have been in IT you would think they could make this bit more clear. Sigh…

GhostDoc Ate My KeyBinding!

Loaded up Visual Studio today and sure enough good old ctrl+shift+D did not work. It was very sad. In case you find yourself with the same problem follow these steps to get it back!

Tools -> Options -> Environment-> Keyboard see below

Hope this saves you a few mins!

Admitting Idiocy

As developers we spend a lot of time in the abstract. We design frameworks, we design systems that can scale and perform in conditions that admittedly they may never have to perform in. We also spend a fair amount on ‘Auto Pilot’. We do things rightly or wrongly simply because they have been ingrained in our brains from sheer repetition. This kind of ‘auto pilot programming’ works to a degree. Overtime you learn what works, and you repeat. However the down side of this is that you may miss opportunities to make your code better, more efficient. I am guilty of this as I suspect most of us are. Take what happened to me today for an example. A fellow coworker was working on removing items from a collection based on some criteria. He had written some code similar to the code below.

class Program
{
    static void Main(string[] args)
    {
        var strings = new List<string> {"0", "1", "2", "3", "4"};
        foreach(string str in strings)
        {
            if (strings[i].Equals("1", StringComparison.OrdinalIgnoreCase)
                || strings[i].Equals("2", StringComparison.OrdinalIgnoreCase))
            {
                strings.Remove(str);
            }
        }
    }
}

Now of course we all know what happens here. Collection was modified; enumeration operation may not execute. My advice to him was to use the for loop approach.

class Program
{
    static void Main(string[] args)
    {
        var strings = new List<string> {"0", "1", "2", "3", "4"};
        for (int i = 0; i < strings.Count; i++ )
        {
            if (strings[i].Equals("1", StringComparison.OrdinalIgnoreCase)
                || strings[i].Equals("2", StringComparison.OrdinalIgnoreCase))
            {
                strings.RemoveAt(i);
            }
        }
    }
}

This will get around the InvalidOperationException but there is a pretty obvious logical error here. When “1” is found and removed from the list the collection count shrinks by 1. Because of this “2” will be missed, therefore never removed.

Enter Auto Pilot

My ‘Auto Pilot’ switch kicked in and I said after you remove the item simply decrement the loop counter.

class Program
{
    static void Main(string[] args)
    {
        var strings = new List<string> {"0", "1", "2", "3", "4"};
        for (int i = 0; i < strings.Count; i++ )
        {
            if (strings[i].Equals("1", StringComparison.OrdinalIgnoreCase)
                || strings[i].Equals("2", StringComparison.OrdinalIgnoreCase))
            {
                strings.RemoveAt(i);
                i--;
            }
        }
    }
}

His response was something like “Are you crazy that could get you in all kinds of trouble.” I asked how he would solve it. What he showed me was something I have never thought of and I am 100% ashamed to admit it. Apparently his approach was common knowledge to the entire programming world but me.

class Program
{
    static void Main(string[] args)
    {
        var strings = new List<string> {"0", "1", "2", "3", "4"};
        for (int i = strings.Count - 1; i >= 0; i--)
        {
            if (strings[i].Equals("1", StringComparison.OrdinalIgnoreCase)
                || strings[i].Equals("2", StringComparison.OrdinalIgnoreCase))
            {
                strings.RemoveAt(i);
            }
        }
    }
}

This is a much more ‘elegant’ way to solve both the InvalidOperationException as well as the index issues my for loop approach caused. It is also much cleaner the messing with the loop counter. So back to the point. ‘Auto Pilot Programming’ got me. I never questioned my approach because I never needed to. My approach has and would continue to work but it is not the best way to do the job. This is why we as developers we have to be always looking at what we can do to make our code better. So next time you are hacking away loading collections, looping, or doing any other trivial things we do over and over, stop and look at what you are doing you may be missing a chance to make it better.

Don’t Step Over! Step Into!

OK so Visual Studio SP11 made me very very angry. Apparently they think the default debugging behavior should step over properties and methods calls even if you you tell the debugger to step into a property or method call! I spent about 20 mins trying to figure this out yesterday. Service Pack 1 you owe me 20 mins with interest! Anyway if anyone else is having issues with this here is the fix.

Tools -> Options -> Debugging -> General

I hate you SP1!

Notice the option ‘Step over properties and operators(Managed Only) SP1 checks this by default! Uncheck this and debugging will start stepping into things like it should when asked!

Serenity Now!!!