tsJensen

A quest for software excellence...

Be a Software Development Mentor

I like many aspects of my job but one stands out above all others: helping other developers. Nothing gives me as much satisfaction as hooking up the mental chains and pulling a fellow developer out of the code mud in which she or he is stuck.

I grew up on a small farm where there was never any lack for work to do, much of which was tedious and boring. But it was always exciting to get a call from a neighbor asking us to come pull them out of the mud or jump start a car or rescue an animal from some odd predicament. It never took much time, but the simple gratitude of the person helped was the best compensation I’d ever known as a child.

Now my tractor is my brain and my software tools and the chains are made of thousands of hours of experience forging one experience into another and storing these up, mostly for my own work, but also for those enjoyable moments when I take a call from a colleague who is just stuck and needs a little guidance.

My tractor and chain is not better than anyone else’s really. But sometimes I’m in the right place at the right time to help another developer and this aspect of my job is my favorite. Spinning up a GotoMeeting session and helping another developer find and solve a problem may sound dull and boring to some, but it gives me a boost.

Sometimes my colleagues are reluctant to call. (I work remotely.) Perhaps this is because they don’t want to waste my time or because they feel the need to solve the problem on their own. That’s okay. It’s good to solve problems on your own but I do appreciate the opportunity to help when I can.

And that is one of the main reasons I get up in the morning and make the 30 second commute to my basement office. Today, I might get to hook up the chains to the tractor and pull a friend or a neighbor out of the mud.

Hook up your chains to your tractor and become a software development mentor.

C# Basics: Beware of Catch (Exception e)

In this third installment of C# Basics, let's take a look at exception handling. It is one the easiest things to do poorly in an application. In C# you can capture an error and do something with it as easily as this:

try
{
  //do something that may raise an exception
}
catch (Exception e)
{
  //do something with e--log it, modify a return value, etc.
  //if you want the caller of your code to have a crack at the same exception
  throw; //raise the exception again with throw; (almost NEVER throw e;)
}

But do try your best to NEVER catch the base Exception class. Be more specific, especially where you have to do something specific with a particular type of exception and allows others to rise up the call stack. Here’s just one example of being a bit more specific:

try
{
  //call a service that reads data from SQL Server
}
catch (SqlException se)
{
  if (se.Message.Contains("Timeout"))
  {
    //send a timeout log message to the DBA service
  }
  throw; //raise it up the stack to be handled by the caller
}

Of course, you can and ought to handle different exceptions differently where required. Here’s a brief example:

try
{
  //call a service that reads data from SQL Server
  //call another service that writes to a file
}
catch (SqlException se)
{
  if (se.Message.Contains("Timeout"))
  {
    //send a timeout log message to the DBA service
  }
  throw; //raise it up the stack to be handled by the caller
}
catch (IOException iox)
{
  //special handling or logging of IO exceptions
  Console.WriteLine(iox.Message);
}
catch (Exception e)
{
  //log a general exception and rethrow
  throw;
}

And don’t forget, you can create your own specialized exception classes. In fact, with Visual Studio you can use the code snippet for Exception. Just put your cursor in a C# file, outside of a class declaration, and start typing Exception and when you see the Intellisense prompt just hit TAB TAB. And you will have the following:

[Serializable]
public class MyException : Exception
{
	public MyException() { }
	public MyException(string message) : base(message) { }
	public MyException(string message, Exception inner) : base(message, inner) { }
	protected MyException(
	 System.Runtime.Serialization.SerializationInfo info,
	 System.Runtime.Serialization.StreamingContext context)
		: base(info, context) { }
}

Flesh out your own custom exception and raise and catch it just like a pro.

public void ShowExample(int count)
{
  if (count < 0) throw new MyException("Count cannot be less than zero.");
  // . . .
}

public void CallExample()
{
  try
  {
    ShowExample(-4);
  }
  catch (MyException me)
  {
    Console.WriteLine(me.Message);
  }
}

Of course, in the above example, you would more likely want to just throw a new ArgumentException. There is a very long list of commonly used exception classes in the .NET base class libraries. Spend some time on MSDN and get familiar with them. Here’s a brief but incomplete list of common exception classes you may want to catch or throw and then catch.

  • System.ArgumentException  
  • System.ArgumentNullException  
  • System.ArgumentOutOfRangeException  
  • System.ArithmeticException  
  • System.DivideByZeroException  
  • System.FormatException  
  • System.IndexOutOfRangeException  
  • System.InvalidOperationException  
  • System.IO.IOException  
  • System.IO.DirectoryNotFoundException  
  • System.IO.EndOfStreamException  
  • System.IO.FileLoadException  
  • System.IO.FileNotFoundException  
  • System.IO.PathTooLongException  
  • System.NotImplementedException  
  • System.NotSupportedException  
  • System.NullReferenceException  
  • System.OutOfMemoryException  
  • System.Security.SecurityException  
  • System.Security.VerificationException  
  • System.StackOverflowException  
  • System.Threading.SynchronizationLockException  
  • System.Threading.ThreadAbortException  
  • System.Threading.ThreadStateException  
  • System.TypeInitializationException  
  • System.UnauthorizedAccessException

Small and Simple: The Keys to Enterprise Software Success

Someone once said, “By small and simple things are great things brought to pass.” The context was certainly not enterprise software development but I have come to believe that these words are profound in this context as well.

Every enterprise, medium and large, is challenged with complexity. Their systems and businesses are complex. Their politics and personnel and departments are complex. Their business models and markets and product lines are complex.

And their software is complex. But why?

Because we make it complex. We accept the notion that one application must accomplish all the wants and wishes of the management for whom we work, either because we are afraid to say, “This is a bad idea,” or because we are arrogant enough to think we’re up to the challenge. So we create large teams and build complex, confusing and unmanageable software that eventually fulfills those wants and wishes, sometimes years later—that is, if the project is not cancelled because the same management team loses patience and/or budget to see it through.

Some companies have made a very large business from selling such very large and complex software. They sell it for a very large “enterprise class” price to a business who wants all those nice shiny features but doesn’t want to take the risk of building it for themselves. And then they buy the very large enterprise software system and find that they must spend the next six to twenty months configuring and customizing the software or changing their own business processes and rules to fit the strictures of the software they have purchased.

The most successful enterprise projects I’ve worked on have all shared certain qualities. These projects have produced workable, usable and nearly trouble-free service all because they shared these qualities. The are:

  • A small team consisting of:
    • A senior lead developer or architect
    • Two mid-senior level developers
    • A project manager (part time)
    • And a strong product owner (part time)
  • A short but intense requirements gathering and design period with earnest customer involvement.
  • Regular interaction with product owner with a demo of the software every week.
  • Strong communication and coordination by the project manager, assuring the team and the customer understands all aspects of project status and progress.

The challenge in the enterprise is to find the will and means to take the more successful approach of “small and simple.”

You may say, “Well, that’s all fine and good in some perfect world, but we have real, hard and complex problems to solve with our software.” And that may be true. Software, no matter how good, cannot remove the complexity from the enterprise. But there is, in my opinion, no reason that software should add to it.

The real genius of any enterprise software architect, if she has any genius at all, is to find a way to break down complex business processes and systems into singular application parts that can be built by small, agile teams like I’ve described, and where necessary, to carefully define and control the service and API boundaries between them.

Must a single web application provide every user with every function and feature they might need? No. But we often try for that nirvana and we often fail or take so long to deliver that delivery does not feel like success.

Must a single database contain all the data that the enterprise will need to perform a certain business function or fulfill a specific book of business? No. But we often work toward that goal, ending up with a database that is so complex and so flawed that we cannot hope to maintain or understand it without continuous and never ending vigilance.

When your project complexity grows, your team grows, your communication challenges grow and your requirements become unwieldy and unknowable. When you take on the complex all in one with an army, you cannot sufficiently focus your energy and your strength and collectively you will accomplish less and less with each addition to your team until your project is awash is cost and time overruns, the entire team collectively marching to delivery or cancellation. And in the end either outcome, delivery or cancellation, feels the same.

By small and simple things, great enterprise software can be brought to pass. Sooner rather than later. Delivering solid, workable, maintainable, supportable solutions. Put one small thing together with another, win the war on complexity and provide real value to your management team. Do this again and again and you’ll have a team that will never want another job because they will have become all too familiar with real success.

What’s Wrong with Technical Recruiters

I’ve had a series of ongoing discussions with a friend who is also a senior software architect. In recent months he’s become quite dissatisfied with his manager specifically and employer generally. He has put his resume out on the typical job search sites, Dice, Monster, TheLadders, LinkedIn and others, and has been sorely disappointed with the result. Technical recruiters seem to be, with rare exceptions, a sorry lot of would-be telemarketers rejected for lack of integrity by the local call-center-for-hire.

On a daily basis this friend of mine receives emails and calls with a hot job listing that do not generally match his skills or experience like the one that he forwarded to me today, not because he might really be a match but in hopes of sparking a conversation that goes something like this:

  • Recruiter: “I know you may not be a good fit for this job, but do you know anyone who is?”
  • Candidate: “No. I do not know anyone with this skill set and experience level interested in a 6 month contract.”
  • Recruiter: “Okay. I’d like to keep in touch with you and I will definitely call you if something comes through that is a better match for what you’re looking for.”
  • Candidate: “Okay, sure. Thanks for the call.”

My friend reports that he has at least three of those conversations per week and at least two or three such emails as the one below per day. I’ve changed the company names and the place to avoid the chance of embarrassing any of them, especially since one or two of them is a household brand name.

Hello,

I am Recruiter with XYZConsulting (formerly ABCConsulting), a dedicated QRS contractor sourcing service, managed by TenCharms. We recruit solely for QRS Contract Positions. Should you accept a contract position, it will be through our preferred partner TenCharms, an independent vendor chosen to manage this program for QRS.

I saw your resume on a job board. I am currently recruiting .net Consultant for a 12 months contract project with QRS – Chicago, IL.

Email me a copy of WORD formatted resume, along with these details:

  • Best time & number to speak to you:
  • Location:
  • Visa Status:
  • How soon you can start:
  • Work mode, W2, C2C (if self-incorporated):
  • Expectations on Compensation:

Position’s name: .net Consultant

Assignment period: 12 months
Location: Chicago, IL

Required skills
Primary Skills: asp.net, vb.net, Oracle / SQL Server, SQL. Secondary Skills: C#.net, MS Access / VBA

As this is an urgent requirement, kindly respond to it at earliest possible.

Best Regards,
Bad Excuse (name changed to protect the guilty)

Recruiter | XYZConsulting (formerly ABCConsulting)
A TenCharms Solution
Dedicated QRS Contractor Sourcing Services

My friend has shown me many other emails that are far worse than this one. Many of them are poorly written, lacking proper grammar and teeming with spelling errors, yet they claim to represent well known companies. I wonder if these companies for whom these recruiters work ever bother to review the practices and general quality of the communications of their agents. Somehow I doubt it.

In some of the emails my friend has forwarded to me, it becomes clear that the recruiting company has employed some shoddy keyword matching algorithm to select from a list of candidates who have put their resumes out into the swamp of job sites (see above mentioned sites). In some of these I have been able to identify one or two specific keywords that match my friend’s resume. I should know. I helped him write it.

Sometimes the keyword match is even close, such as, “architect” or “jQuery.” But since my friend is a .NET architect and the job is for a J2EE architect who also knows jQuery and PHP and Oracle while my friend does not mention Oracle or PHP on his resume at all, it is clear that the recruiter’s matching algorithm, whether it is their own or provided by one of the job sites, is severely lacking in even the most basic intelligence.

Either that or the recruiter is far more interested in spamming the candidate with a job posting that is clearly not a fit in hopes that the candidate will do the job of the recruiter for him or her or it.

To all such recruiters, please for the love of Pete, what’s wrong with you? Stop wasting my friend’s time!

C# Basics: The Conditional or Ternary Operator

For the second installment of C# Basics, let’s take a look at the conditional operator, sometimes known as the ternary operator. How many times have you written code like this:

if (a == b)
{
  x = y;
}
else
{
  x = z;
}

Probably never, at least not quite this simplistic or with such ancient style variable names, or one would hope anyway. But the example serves its purpose. Now use the conditional operator and convert that code to this:

x = (a == b) ? y : z;

You can read more about the conditional operator on MSDN here.

Ruck Software Development Process

I have worked in several development teams that have a Scrum-like development process where the team has adapted Scrum to their own team dynamics and organizational needs. I was intrigued by a recent MSDN article called Visual Studio ALM Rangers—Reflections on Virtual Teams that formalizes one of these this Scrum-but-not-Scrum processes and calls it Ruck. Here is the authors’ loose definition:

“To ensure that we don’t confuse anyone in terms of the methodologies or annoy process zealots, we provisionally chose to call our customized process ‘Ruck,’ which, in the rugby world, means ‘loose scrum.’”

The article authors share their experience in Microsoft’s ALM Rangers team and “provide guidance for working with teams in less-than-ideal distributed and virtual environments.” I found this introduction compelling and I wanted to try to restate their approach here with a few of my own thoughts mixed in.

The ALM Rangers’ Ruck process is very specific to their needs and team: a highly distributed team and a high degree of variability in team member availability where team members have multiple professional obligations that take higher priority than their work on the team. This is a very challenging situation for a team trying to be Scrum-like and may be closer to many popular open source projects with multiple contributors from around the world, with one very important exception: a fixed ship date.

I’m not advocating that any specific team adopt the ALM Rangers’ Ruck, but the choices and approach taken by this team could be very valuable to other teams faced with creating their own Ruck because they cannot, for whatever reason, get close enough to Scrum to really call their process Scrum.

One of the most important points I found the authors making had to do with adhering to the agile principle of self-organizing teams. They found that their “belief in letting developers choose work from areas in which they have interest” required that they allow teams to self-organize around these areas of interest rather than specific geographies or time zones.

One of the most difficult challenges facing enterprise software development projects is team size and how to break up larger projects into smaller chunks that can be addressed by smaller, more agile teams. The authors observe:

“We’ve learned that smaller projects and smaller team sizes enable better execution, proper cadence and deeper team member commitment. Also, it seems it’s more difficult for someone to abandon a small team than a larger team.”

Another interesting area the authors cover is that of project artifacts used to manage and break down the project into actionable tasks. The particular names of these seem less important than the fact that they are well defined and communicated and used consistently within their Ruck. In creating your own Ruck process, do not skip this important element.

Roles are also well defined. Knowing what position you play on the team at any one given moment can eliminate the need for over-the-shoulder management because each team member knows what their responsibility is. The task of the manager becomes one of coach rather than hall monitor, communicating these roles and responsibilities to team members rather than asking the question, “so what are you working on today?”

One more critical area to define is meetings. Don’s skimp on structuring meetings to achieve what you need to achieve without wasting too much time. As my brother tells me, “It takes a really good meeting to beat no meeting at all.”

And finally, I want to share one more brief excerpt from the authors. Their top recommendations:

“There are many recommendations, skills and practices that will help you improve the virtual team environment, the collaboration and effectiveness of each team member, and the quality of the deliverables. For us, the seven top recommendations include:

  1. Clearly define and foster a team identity and vision.
  2. Clearly define the process, such as the Ruck process.
  3. Clearly define the communication guidelines and protocols.
  4. Clearly define milestones, share status and celebrate the deliverables.
  5. Implement an ALM infrastructure that allows the team to collaborate effectively, such as TFS and associated technology.
  6. Promote visibility and complete transparency on a regular cadence.
  7. Choose your teams wisely, asking members to volunteer and promoting passionate and get-it-done individuals.”

C# Basics: The Proper Use of a Constructor

This is the first in what I hope will be a long series of quick posts covering the basics of programming in C#. For this first installment, I’ll review the proper use and improper use of a class or struct constructor.

What is a Constructor
In a C# class, a constructor is a special code block for a class or struct called when an instance of that class or struct is created. If a constructor is not defined in code, the compiler will create a default constructor without parameters. Constructors can be overridden and can call a base class constructor.

Proper Use of a Constructor
Use a constructor to set or initialize class or struct fields. If this initialization code is lengthy, such as in the construction of a Windows Form class, move the initialization code to a partial class file and call it something like InitializeComponents. Here are a few examples:

public partial class Apple : Fruit
{
  //same as a default constructor if not constructor defined
  public Apple()
  {
  }
  
  //initialize a local class member
  public Apple(string name)
  {
    _name = name;
  }
  
  //initialize and call base class constructor
  public Apple(string name, double weight) : base(weight)
  {
    _name = name;
  }

  //constructor with conditional param to control construction behavior
  public Apple(bool initializeAll)
  {
    if (initializeAll) InitializeComponents();
  }

  //shown here but often hidden away in another file of defining the partial class
  void InitializeComponents()
  {
    //do some lengthy but simple initialization of class members
  }  
  
  private string _name;
}

Improper Use of a Constructor
Do not use a constructor for error prone or complex code. Do not use a constructor to execute tasks, business logic. I’m not going to include code examples of bad constructors but here are a few anti-patterns I’ve seen in my travels:

  • The constructor makes a call to an external service or database – BAD
  • The constructor creates child objects and calls methods on those objects to perform some business function – BAD BAD
  • The constructor asks for user input or reads from a file – BAD BAD BAD

Alternatives to a Constructor
If you require lengthy, long running or potentially error prone code to produce an instance object of a class or struct, use either a factory class or a static create method. Here’s how:

public class BookService : IBookService
{
  //a private default construtor prevents use of it outside of the class itself
  private BookService()
  {
  }
  
  public static BookService Create()
  {
    BookService instance = new BookService(); //calls private constructor
	
	//put lenghty or error prone code here that sets up the service
	
	return instance;
  }  
}

//use a factory for even more complex object creation
public static class BookServiceFactory
{
  public static IBookService Create(BookOptions options)
  {
    IBookService instance;
	
	//based on the BookOptions provide create the proper
	//concrete instance of an IBookService interface
	
	return instance;
  } 
}

Of course this is not a comprehensive treatment. It’s a blog post. If you want more, buy a book. If you have topics you would like to see addressed in future installments, please let me know.

Thoughts on 9/11

I normally use this blog to write of technology but today is a justifiable exception. Today I am reminded of and enjoyed reading again the words of a Prophet of God, Gordon B. Hinckley, spoken in a conference just a few short weeks after the fateful day ten years ago. I invite you to read his entire address, but here are a few excerpts:

You are acutely aware of the events of September 11, less than a month ago. Out of that vicious and ugly attack we are plunged into a state of war. It is the first war of the 21st century... But this was not an attack on the United States alone. It was an attack on men and nations of goodwill everywhere.
...
Religion offers no shield for wickedness, for evil, for those kinds of things. The God in whom I believe does not foster this kind of action. He is a God of mercy. He is a God of love. He is a God of peace and reassurance, and I look to Him in times such as this as a comfort and a source of strength.
...
Now, all of us know that war, contention, hatred, suffering of the worst kind are not new. The conflict we see today is but another expression of the conflict that began with the War in Heaven. I quote from the book of Revelation:

“And there was war in heaven: Michael and his angels fought against the dragon; and the dragon fought and his angels,

“And prevailed not; neither was their place found any more in heaven.

“And the great dragon was cast out, that old serpent, called the Devil, and Satan, which deceiveth the whole world: he was cast out into the earth, and his angels were cast out with him." KJV, Rev. 12:7-9

From the day of Cain to the present, the adversary has been the great mastermind of the terrible conflicts that have brought so much suffering. Treachery and terrorism began with him. And they will continue until the Son of God returns to rule and reign with peace and righteousness among the sons and daughters of God.
...
Are these perilous times? They are. But there is no need to fear. We can have peace in our hearts and peace in our homes. We can be an influence for good in this world, every one of us.

May the God of heaven, the Almighty, bless us, help us, as we walk our various ways in the uncertain days that lie ahead. May we look to Him with unfailing faith. May we worthily place our reliance on His Beloved Son who is our great Redeemer, whether it be in life or in death, is my prayer in His holy name, even the name of Jesus Christ, amen.

Update: Please read commentary posted by Thomas S. Monson, a living Prophet of God, in the Washington Post.