Try Catch Nothing Worst Code Ever

Tracking down a problem in a commercial .NET library today, I found this little gem (identifying code in the try removed):

try
{
   //any code that could fail in any way here
}
catch (Exception)
{
}

Not only should this construct not compile, any attempt to do so should cause your computer to explode.

Extend IEnumerable<T> with ForEach<T> and Once<T> Methods

A few days ago, a fellow programmer asked me a common question. How do you print odd numbers between one integer value and another. It's a common question and the quickest solution that came to mind is the common for loop with a simple if and the mod operator.

Later I began toying with the question and in combination wanted to experiment with an alternative to the limited ForEach extension method on IList<T>. What you see below is the result of a little tinkering and tweaking along with some fluent goodness.

I considered naming my custom extesion method ForEach but decided to use something different to remind myself that it is not your grandfather's ForEach extension method. So I named it ForEvery and in the middle of playing with that, I ended up creating the Once extension method on IEnumerable<T>.

class Program
{
   static void Main(string[] args)
   {
      PrintOdds(1, 100);
      Console.ReadLine();
   }

   static void PrintOdds(int x, int y)
   {
      Console.WriteLine("Odds with traditional for and if");
      for (int i = x; i <= y; i++)
      {
         if (i % 2 != 0) Console.Write("{0}, ", i);
      }

      Console.WriteLine();
      Console.WriteLine();
      Console.WriteLine("Odds with ToList and ForEach with if");
      Enumerable.Range(x, y - x + 1)
         .ToList()
         .ForEach(i =>
         {
            if (i % 2 != 0) Console.Write("{0}, ", i);
         });

      Console.WriteLine();
      Console.WriteLine();
      Console.WriteLine("Odds with Where then ToList and ForEach");

      Enumerable.Range(x, y - x + 1).Where(n => n % 2 != 0)
         .ToList().ForEach(i =>
         {
            Console.Write("{0}, ", i);
         });

      Console.WriteLine();
      Console.WriteLine();
      Console.WriteLine("Odds with Where and custom ForEach");

      Enumerable.Range(x, y - x + 1)
         .Where(n => n % 2 != 0)
         .ForEach(i =>
         {
            Console.Write("{0}, ", i);
         });

      Console.WriteLine();
      Console.WriteLine();
      Console.WriteLine("Odds with custom ForEvery fluent");

      Enumerable.Range(x, y - x + 1)
         .ForEvery(n => n % 2 != 0, i => 
         { 
            Console.Write("{0}, ", i);
         })
         .Once(n => n.Count() > 99, i =>
         {
            Console.WriteLine();
            Console.WriteLine("Once fluent");
            Console.WriteLine();
            Console.WriteLine("Evens with ForEvery fluent from {0} to {1}", i.Min(), i.Max());
         })
         .ForEvery(n => n % 2 == 0, i =>
         {
            Console.Write("{0}, ", i);
         });
   }
}

public static class EnumerableExtensions
{
   public static void ForEach<T>(this IEnumerable<T> collection, Action<T> action)
   {
      foreach (var item in collection)
      {
         action(item);
      }
   }

   public static IEnumerable<T> Once<T>(this IEnumerable<T> collection, 
      Func<IEnumerable<T>, bool> predicate, Action<IEnumerable<T>> action)
   {
      if (predicate(collection)) action(collection);
      return collection;
   }

   public static IEnumerable<T> ForEvery<T>(this IEnumerable<T> collection, 
      Func<T, bool> predicate, Action<T> action)
   {
      foreach (var item in collection)
      {
         if (predicate(item)) action(item);
      }
      return collection;
   }
}

Drop the code into a console app and run it. If you like these little extensions, I'd love to hear from you.

The 4 Keys to Effective Management

Effective management is simply pushing the right buttons and pulling the right levers at the right time. This requires sufficient information, analytic thought, rational decision, and consequential action. Asking questions and thoughtful contemplation are not enough. If you cannot make decisions and act upon them, you are a researcher; you are not a manager.

  1. Sufficient Information
     
  2. Analytic Thought
     
  3. Rational Decision
     
  4. Consequential Action

Every healthy human being manages something. You wake up hungry (information) and you think about bacon (thought) and you decide to limit yourself to two pieces (rational decision) and you throw three pieces in the pan (consequential action) just in case one of them burns even though you know you’ll eat it anyway. Okay, we’re not all perfect managers. Actually, I’ve never met one, so I’m not sure there is such a thing. Excuse me while I take a break to finish that third piece of bacon…

How to Manage Software Development

What the world needs is yet another blog post on how to manage software development, so why not write it myself I ask. Unable to find a good reason to stop here, I’ll give it a shot. If you continue to read, you and you alone will be responsible for anything you might learn.

There are books, graduate courses, and no end to rambling blogs, so I’ll shoot for brevity and clarity here in Part 1.

  1. Know Your Team
    Computers do not yet write software all that well by themselves, so you’re stuck managing the people. Your process or you dictate what they will work on and, by virtue of time constraints imposed, how they will work on it; this is the essence of management.
     
  2. Be Decisive and Take Action
    Collaboration is a meaningless waste of time unless it is followed by real decision and actions that lead to positive results. If you cannot make decisions and act upon them, you are a researcher; you are not a manager.
     
  3. Be Honest and Fair
    If you say one thing to your team on one day and deny having said it the next day, your team will lose confidence in you and rebuilding that trust may not be possible, so choose your words and promises carefully. And if you make a mistake, admit it readily and apologize where appropriate. Your team will see this as a mark of a true leader.
     
  4. Demand Accountability
    When you assert a process rule, enforce it. Hold team members accountable. Start with gentle reminders and further training but do not allow repeat offenders to skate without consequence. If you do, your process is not a process and it will fail.
     
  5. Eliminate Needless Meetings
    Developers generally hate meetings with good reason. Most meetings lack an agenda, lead to no discernable action items, and there is rarely a copy of the minutes minutes and action items distributed to attendees. Most software development requires long, uninterrupted periods of time to effectively solve problems and complete complex tasks. Useless meetings in the middle of the day can ruin a developer’s entire day, throwing his productivity into a spiral, so group meetings into a single day where possible to eliminate or reduce the disruptive effects.
     
  6. Review Everyone’s Work
    You may not understand the code, but having a developer walk you through the code, discussing the decisions made and showing off just a little will go a long way toward educating you and inspiring your developer. Review and discuss documentation, designs and test plans with interest. Spend the time to learn from and guide your team.
     
  7. Get Yourself Out of the Meetings Cyclone
    Decline a leadership training or management committee meeting from time to time in order to do some real managing. Remember, the word “manage” has its root in manus (hand). If you don’t put your hands on it, you can’t possibly manage it.
     
  8. Create and Shepherd Processes
    Everyone knows how to manage and can do so if you give them a process that establishes guidelines for what information should be considered, what decision making process should result, and how those decisions will become actions within the constructs of the process you have created.

Well, that’s enough for part one. More on the same topic later.

How One Meeting Can Blow A Programmer’s Whole Day

This morning I read a post by Seth Godin, a favorite of mine, which presented and discussed an essay written by Paul Graham of Y-Combinator called Maker’s Schedule, Manager’s Schedule.

I regret that this cogent essay and essayist have escaped my notice until now. It reveals what every programmer knows and has experienced with regard to meetings, and I’ve never found a better treatment of the subject.

It confirms with clarity that programming is a creative art, an act of creation or making. Such work cannot be effective and productive with multiple disruptive meetings every day. And sometimes it only takes one meeting, even a short one, to blow your whole day.

Why?

The content and contention in a single meeting can serve to distract a programmer to the point of rendering him effectively useless for the remainder of the day. This is true not only for the programmer but for anyone whose primary function is to make things of complexity.

Consider preventing the daily standup from becoming a meeting in which the resolution of identified impediments is attempted. And never allow the standup to devolve into an ad hoc project status review and planning meeting with the question, “When will you have X feature done?” being asked.

Consider piling all such meetings to which makers must be in attendance into one single day of the week, perhaps Friday or Monday to ensure the largest contiguous uninterrupted period for making, preferably in the late afternoon, so that we get every ounce of making from our makers that the company’s hard won cash can buy.

It’s more than something to think about. It’s something a manager could manage if the manager simply chose to do so, and it’s something a maker would appreciate more than can be expressed in written word.

Office Outlook Add-In Development

I’ve long been interested in building add-ins for Microsoft Office but every time I’ve started to dive into it, I’ve been repelled by the challenges of understanding the Office COM interfaces and dealing with multiple versions of Office, especially for Outlook add-ins.

All of that may be about to change. I just ran into Add-In-Express.com, a tool vendor that for whatever reason I’ve not come across until now. From what I’ve seen on their web site, I’m very impressed.

With a single VS 2010 project template, you can now create an Office add-in with wrapper support for multiple Office products and multiple versions all from one unified library.

image

They do not offer a 30-day trial, so this is a blatant attempt to convince them to give me a reviewer’s copy to install and experiment on.

My primary attraction to this toolset is that I’m not a fan of writing tedious routine plumbing code to deal with multiple versions of a product upon which my software will need to be used. This is also the primary reason I’ve avoided delving into Office add-in development beyond reaching that initial level of prohibitive frustration.

I’m particularly interested in the following feature sets and should I be granted an reviewer’s license or if not and I can scrounge up the scratch for a license, I will be putting these to the test in a rewrite and expansion of a time tracking tool that I wrote as a stand alone WinForms app about nine years ago.

Features to check out list:

  • Version neutrality—many of the users for whom I write software are institutionally stuck on old versions of Microsoft Office. They have no choice but I still need to deliver a solution to them.
  • Context sensitive toolbars and ribbons for Outlook—my primary target for an add-in host, every time I’ve read about or talked with developers who deal with writing their own multi-version plumbing, I walk away from the notion of writing the Outlook add-in I’m thinking of. I really want to see if this tool can help me overcome my fears.
  • Visual designers—one of the most exciting aspects that I want to explore in this product is the visual designers for the ribbon UI, toolbars, options and folders properties dialogs, and especially the form and view regions for Outlook.
  • Smart Tags designer—I am keenly interested in natural language processing and enhancing the utility of email by analyzing text for keywords and other language constructs and then providing context aware actions directly from the Smart Tag to allow the user to take an action that might otherwise require multiple steps from multiple applications.

If you have had any experience with this toolset, I’d like to hear from you. As soon as I’m able to get my hands on it, I will begin posting my experiences with the tool as well as deployable examples from my evaluation and experimentation.

Software Crashing

A project manager, a software architect and a programmer are on a plane heading to nowhere in particular.

Suddenly the pilots (testers of course) leave the cockpit, don the only parachutes, and jump out of the plane.

The project manager schedules an emergency landing planning meeting.

The software architect suggests the team follow a new process to avoid crashing.

The programmer disclaims responsibility and points out that automated landing was not in the requirements.

Which of these survive?

(scroll down for the answer)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

All of them. Apart from some scrapes and bruises for the testers, who take it like troopers as always, everyone is fine. The plane never left the ground. Are you kidding? No software takes off without crashing a few times first.

And sometimes, the plane really does take off. And that is why I do this.

Myth: Product Owners Can’t Handle the Truth

I’ve long been taught and believed that the truth will set you free. But fear is a powerful counter to belief, especially when that fear is rooted in the compellingly powerful human instinct to survive, to preserve your livelihood.

I was reading Ken Schwaber’s The Enterprise and Scrum today and came across the following passage which I deeply appreciated. Ken is writing about to the development team’s fear of telling the Product Owner that they cannot deliver on their commitments for a Sprint.

When I discuss this kind of fear at the courses I teach, the attendees’ own fear is palpable. The soon-to-be Scrum users don’t think that the transparency, or truth, is acceptable where they work. They tell me that they will be fired if they tell the truth. Truth isn’t what their customers want to hear. They tell me their customers will find someone else who will lie to the them if they don’t. I have seen this in class after class for five years. People in product development think that their customers want to hear news only if it is good news and would rather hear a lie than the truth. “Lying” is a harsh word. But what else do you call saying that something is true when you know it not to be true? What else do you call misleading someone with information or holding back information that would have led them to better decisions? The Product Owners want to believe in magic, and the developers support their belief by lying. “Can you do this project by this date?” “Sure, no problem.”

The developers are aware of the complexities that cause changes to their original estimates. They are aware that the customer is unhappy. If a project manager is approached by a customer 60 percent of the way through a project and asked how the project is going, the project manager doesn’t really know. She knows that some things are going well. She also knows that some things are not going so well. She also knows that she hasn’t checked up on some things that could prove critical. However, saying “I don’t’ know” is unacceptable, so project managers have learned to say, “Right on,” “Right on target,” “Piece of cake,” or anything equivalent that will get the customer to go away and leave them to try to get everything on time, on cost. Basically, they lie. It is simpler than exposing all the nuances and complexities that add up to “I don’t know.”

Project managers might also believe that lying saves time. But because Scrum relies on transparency, misrepresentation undercuts the entire application of Scrum. If the Product Owners do not know exactly where things stand at any point in time, they will be unable to make the best decisions possible about how to achieve their goals. They need the best information possible, whether they view it as good or bad.

I don’t know anyone in this business who cannot relate to Ken’s assessment. I am coming to the conclusion with every additional year I spend in the role of code monkey that anyone, with proper preparation and context, can handle the truth, even non-technical folk. I am learning to reject the often held notion that these people are just not able to appreciate the nature of complexity.

Yes, Product Owners not only must have the truth but in fact they can handle the truth even when the truth is not welcome news. I have seen Product Owners ignore the truth but I have never been fired because I told the truth. What Product Owners have a very difficult time handling is the sudden discovery of the truth after having been lied to for long periods of time.

Whether we choose to tell the truth from the start or to lie to ourselves and our Product Owners, eventually, as the Bard would be wont say, the truth will out.

So I still believe that the truth will set you free. Fear will leave you miserable and in chains with the secret knowledge that the truth will be discovered sooner or later by those from whom you’ve hidden it. Freedom is so much easier than we sometimes think.