The Church of Using

One my latest project working for Citigroup, I've been working with an Open Source component named PdfSharp.This wonderful little component lets you create and modify Pdf documents and has the advantage of behaving much more like a .NET component than the popular ITextSharp, which is a port of a Java PDF library.One of the things I needed to do was put a GIF image into the bottom half of a PDF document.Simple enough using PdfSharp, just get a set of PdfDocument, XGraphic and XImage objects and do some math for the placement.All was happiness and light until we decided we needed to clean-up the created Pdf after we were done with it.Suddenly we would sometimes get Sharing Violations on deleting the file.But only sometimes.Fortunately experience has taught me that "sometimes" errors can only be a few types of situations, and in this case one made the most sense ... Garbage Collection.I went pouring over every piece of code looking for where I missed an object that, I hoped, implemented IDisposable and sure enough discovered that PdfDocument, XGraphic and XImage all implemented IDisposable but did not have a public Dispose method.This is perfectly fine, but does make it harder to know when you should use IDisposable.In the end, the error was of course mine.As such I have done 50 "Hail Using"s (in VB since they now support it) and lit a candle in rememberance of lost productivity.

Important guidance for development

Of recent I've been reminded for how uncommon "Common Sense" truly is.  To that end, I submit a list of rules which every company engaged in software development should adopt. Titles Should Be MeaninglessFar to often titles are used in modern Corporate America to give an inflated view of importance or responsibility.  What someone's title in an organization is should be meaningless.  What should be important is what value they bring to the organization. Team Cohesiveness Should RuleA team should be composed of people who respect one another's opinions and contributions.  Far to often I've seen a team dragged through the mud by one person's whose attitude towards the work has become bitter.  These people are poison to everyone around them.  With understanding to personal life issues, they should be moved away from the team until they can return with a positive attitude towards the work. Teams Should Be DynamicA team should consist of those needed to perform the work at the moment. If someone is not necessary for this phase of a project, then they shouldn't be on the team until they are needed.  Hording talented resources makes them bored.  Bored talented people get employed by your competitors. Cut Down BureacracyManagers should exist to cut through red-tape, not create it.  If your job is to manage development resources you should spend most of your time each day allowing them to be creative and solve problems.  Your team should feel comfortable calling you with the smallest concerns and knowing you will get things done in a timely manner.  Your a member of the team to. Be Honest And Keep Your PromisesTry to straight forward in all your communications.  If there is change coming, tell people as soon as you can.  Make certain that you avoid obfuscation whenever possible.  The more open communications are, the more powerful the organization will be because little known talents can be taken advantage of.  Consistantly Reward PerformanceEven the most talent people need motivations to keep going and giving their best.  Look for oppurtunities to reward excellence outside of a paycheck.  Budget for such things as needed, but make them spontaneous as you can. Keep Talent And Cut ChaffTalented people in development are creative, outside of the box thinkers.  These people thrive when you gather many of them in the same place.  You need only look at the output of Xerox's famed Palo Alto Research Center (XEROX PARC) to know that a group of talented creative people can change the world, not just an organization provided that management believes in them.  Likewise people who aren't producing are a drain on such creativity.  You'll get more done with 10 talented people than you will with 10 talented people and 10 under-producers. Focus On Small ProblemsAttempting to solve "Big Problems" in a single large project has been the doom of almost every project that has tried it.  Focus on small solutions that build towards a solving big problems.  This path may seem to have many hills and valleys and be less grandeous, but the highway of large projects is littered with failed deliverables and maintenance nightmares just out of sight over the horizon. Expect ExcellenceIt is important to have high expectations of your people, but it is doom to expect the impossible.  It is key that you speak with your first layer of leadership, not necessarily management, on a regular basis about the reality of your goals.  They should feel free to tell you when what being asked is simply not possible.  Creative and talented people will consistantly rise to meet the challenge which is difficult, but they will just as consistantly shut down and stop performing when asked to perform the impossible.  Strive To HumanizeThis runs contrary to so much of what is out there today about management, but it is vitally important that management over development efforts deliberately humanize themselves to their team on a regular basis.  Have lunch out with your team on a regular basis, talk about the things which people talk about at lunch.  Remember that "Titles Should Be Meaningless" and strive to reinforce that YOU know they are with your team. Trust Your PeoplePerhaps the most important rule of all of these, trust your people.  Developers are writing code which will be deployed into the most fragile places in your enterprise.  These men and women write programs for a living, they create solutions from nothing.  Give them the environment necessary to be creative and you will get excellence.  This goes from the physical environments (personalized work spaces comfortable to that person) to the technical environments (rights sufficient to install and try new software).  Far to often developers are placed in small, unpersonalized cubicles in the dark corner of the office complex and saddled with authoritarian policies regarding the installation of software.  Creative environments create creative results.

CodeRush Love...

I've recently acquired a CodeRush license for my personal use, and all I can say is ... I LOVE CODERUSH! You may be asking, "Why do you love CodeRush, Tim?" Here's why. By using the following sequence : C Space P E R S O NClick to the end of constructor blockEnter P S Space F I R S T N A M EClick to the end of the property blockEnter P S Space L A S T N A M EClick on class nameCtrl-CClick outside of the classcoll SpaceProduces all of the following code:     public class Person    {         public Person(string myFileName)        {        }        private string _FirstName;        public string FirstName        {            get            {                return _FirstName;            }            set            {                _FirstName = value;            }        }        private string _LastName;        public string LastName        {            get            {                return _LastName;            }            set            {                _LastName = value;            }        }    }     public class PersonCollection : CollectionBase    {        // public methods...        #region Add        public int Add(Person person)        {            return List.Add(person);        }        #endregion        #region IndexOf        public int IndexOf(Person person)        {            for (int i = 0; i < List.Count; i++)                if (this[i] == person)    // Found it                    return i;            return -1;        }        #endregion        #region Insert        public void Insert(int index, Person person)        {            List.Insert(index, person);        }        #endregion        #region Remove        public void Remove(Person person)        {            List.Remove(person);        }        #endregion        #region Find        // TODO: If desired, change parameters to Find method to search based on a property of Person.        public Person Find(Person person)        {            foreach (Person lPersonItem in this)                if (lPersonItem == person)    // Found it                    return lPersonItem;            return null;    // Not found        }        #endregion        #region Contains        // TODO: If you changed the parameters to Find (above), change them here as well.        public bool Contains(Person person)        {            return (Find(person) != null);        }        #endregion        // public properties...        #region this[int aIndex]        public Person this[int index]        {            get            {                return (Person)List[index];            }            set            {                List[index] = value;            }        }        #endregion    }