Monday, September 13, 2010

Dealing with Envy In the Workplace

I came across this article when thinking about the role of envy and competition in the workplace: Envy in the workplace: Jealous guise. The Harvard Business Review article that it is cited in this article is also worth finding and reading. It’s noteworthy that IT firms were some of the companies cited in the articles. One of the problems that managers do need to watch out for is the situation when one worker tries to sabotage and hold back another person because of the green eyed monster. This can have tremendous negative impact on an organization and sink or delay critical projects if one person tries to keep another from receiving due credit.

Wednesday, August 18, 2010

Troubleshooting the Generic Error Message

A few years ago some Visual Basic 6 code that I had written returned the following error code: Microsoft Oracle Driver: ODBC/OLE DB error –2147217900. I was adding an update to some legacy code at the time; prior to that time and since then I’ve written code primarily in C# and VB.NET. Yet sometimes the errors that can come up in .NET can easily be as difficult to troubleshoot as this one. The result when the solution is found can be not only that the application is made properly functional and robust, but that as a professional developer one can learn more about the code, the application as a whole and the application’s underlying environment and architecture than otherwise, So, taking the troubleshooting to its conclusion can actually be a valuable learning experience and step forward in one’s own professional development.

The first step that I took was to find out as much as I could about what the error message means. Researching the meaning of the error  is the step that many inexperienced programmers do not take or do not pursue as thoroughly as they could. It’s sometimes been painfully difficult for me to get them to look up the error code and message in the MSDN documentation, Google or Bing. Yet that’s often the quickest way to understand what the error is and why it occurred. A developer who does this will often find a quick and immediate solution as well, such as a missing configuration file entry. But in my case, all I could come up with was this meaning for the message: “Syntax error or access violation.”

The code compiled and ran correctly until it tried to execute a SQL statement to access the database. The SQL statement was actually calling a stored procedure with parameters. It ran correctly on the development machine when it accessed the development database. So, my troubleshooting steps went along the lines of investigating whether there were problems with the syntax of the SQL statement when it was being executed or the access rights of the identities which the application used to access the database.

My steps included:

  • Checking the access level on database tables and the Oracle stored procedure.
  • Double-checking the execution of the stored procedure under the actual client ID that the application was using to access the database.
  • Upgrading MDAC when MSDN documentation suggested that a later version would be beneficial.
  • Adding debugging code to print out to a local file the values assigned to the parameters of the stored procedure before the procedure was executed to make sure that they were being assigned correctly.
  • Double-checked the call to the stored procedure that was in the ODBC syntax: “{ call <procedure> ( {?, ?, ?} ) }”.
  • Double-checked the parameter names even though it was clear that ODBC was using the ordinals for database table column access.
  • Used the debugger and immediate window inside Visual Studio to research the successfully executing syntax as much as possible.

As it turned out, there was an obscure permissions problem with the generic user id that the application normally ran under on the application server. When this was corrected, the error message disappeared.

The reason that I’m able to reproduce the steps that I took to troubleshoot and resolve this error is because I started a troubleshooting log when it became clear to me that this error had no immediate and obvious solution. This is also a troubleshooting method which many inexperienced programmers do not take. This involves writing down each possible cause and solution that is researched, attempted and the result. This includes such things as code modifications, environmental modifications and configuration modifications. This helps not only to find the cause of the problem, but also to be able to roll back attempted solutions which do not resolve the problem – something which is as important as solving the problem itself.

.NET Refactoring Opportunities: Synchronization Locks

This post will begin a series of posts on common coding problems that I’ve seen in .NET applications over the years. Most of these are documented problems or best practices, yet many times these can be found in source code. Understanding and correcting these can often provide dramatic differences in existing applications in performance, maintenance and robustness.The first one deals with a problem that I’ve seen even in sample code included in corporate standards documents.

What’s wrong with this C# code?

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace DaleWare.BlogDemo.CSharpDemoLibrary
{
    public class BadLock1
    {
        public static void DoSomethingMethod()
        {
            lock (typeof(BadLock1))
            {
                // something I want to synchronize goes here
            }
        }
    }
}


Or the equivalent Visual Basic code?



Public Class BadLock1
    Public Shared Sub DoSomething()
        SyncLock (GetType(BadLock1))
            ' Something that I want to synchronize goes here
        End SyncLock
    End Sub
End Class


Or this C# code?



using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace DaleWare.BlogDemo.CSharpDemoLibrary
{
    public class BadLock2
    {
        public void DoSomethingMethod()
        {
            lock (this)
            {
                // something I want to synchronize goes here
            }
        }

    }
}


Or this equivalent Visual Basic code?



Public Class BadLock2
    Public Sub DoSomething()
        SyncLock (Me)
            ' Something that I want to synchronize goes here
        End SyncLock
    End Sub
End Class


All of these examples do something that appears in Microsoft documentation as a worst practice: locking on a type (C# typeof(class) or Visual Basic GetType(class)) or on an object (Visual Basic Me or C# this) itself. This is a known problem that can cause deadlocks or unnecessary delays in execution. Searching on Google or Bing can produce a number of developers who’ve run into these problems and Microsoft documentation warning not to lock on the type or the object instance.The recommendation is now, and has been for some time, to lock rather on a private object variable on each class.



Here is an example in C#:



using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace DaleWare.BlogDemo.CSharpDemoLibrary
{
    public class CorrectLock
    {
        private object _syncObject = new object();

        public void DoSomethingMethod()
        {
            lock (_syncObject)
            {
                // something I want to synchronize goes here
            }
        }
    }
}


And here is an example in Visual Basic:



Public Class CorrectLock
    Private Shared _syncObject As New Object

    Public Shared Sub DoSomething()
        SyncLock (_syncObject)
            ' Something that I want to synchronize goes here
        End SyncLock
    End Sub
End Class


This is a simple change that can be made during refactoring source code, code inspections and standards documentation and revision. And it is worth it to avoid possible deadlocks and other synchronization problems in a corporate .NET application.



Tuesday, August 17, 2010

PeopleWare Issues: Professional Culture and Party Culture

In a previous post, I mentioned departmental ‘happy hour’ get togethers in IT organizations. I’m not out to eliminate them totally, but I think that managers and team leaders do need to be more aware of the issues that can happen.

The first issue is that some IT organizations may have some ‘party animals’ who may pressure others to drink, to drink heavily and to get drunk. I’m not sure that managers and HR people are cognizant of the issues that this could cause with the lives of coworkers and the possible issues of harassment, litigation and liability that might happen. I myself simply refuse to go along and don’t want even to be seen as implying or threatening any kind of lawsuits on my own behalf, but I’m simply sharing information that may be overlooked and seeking to make some constructive suggestions.

There are a number of people in IT who do not drink because of moral and religious convictions, and I’m not unique in that regard. For instance, many Christians, and Muslims and Mormons in general, do not drink because of religious convictions. Moreover, a person going through an addiction recovery program such as Alcoholics Anonymous will not drink because that person has the conviction that, for that person, “One drink is too many.” Those of us who do not drink because of our convictions simply should not come under undue pressure to do so at a get together under the auspices of our place of employment. To allow this to happen could cause issues of corporate liability and litigation for anti-religious harassment and failure to accommodate an employee’s strongly held religious beliefs.

There is a possible issue of corporate litigation and liability as well if there is pressure to drink heavily and to get drunk at a corporate social gathering if someone ends up driving home under the influence of alcohol. This could result in that person being charged with a civil crime, and if there is an accident or death involved, the corporation has been named in civil lawsuits in these cases in the past. I’ve worked with corporations who did provide taxi rides home for anyone who felt the need of one, and that is a policy which I also support.

Here are several suggestions that I would make:

  • Seek to provide other social activities besides ‘happy hour’ get togethers. Lunch get togethers usually work well, and these often provide the opportunity for coworkers to attend who could not attend an after hours ‘happy hour’ get together because of family priorities. Single parents who need to pick up their children from day care and parents who need to be home when their children come home from school are also often left out for after hours ‘happy hour’ activities.
  • Managers and supervisors need to be aware of and correct anyone that is trying to put undue pressure on someone else to drink and get drunk. A simple, “Knock it off” or “Drop it” would usually be sufficient.
  • Managers and supervisors should consider whether someone who is getting consistently drunk and pressuring others to drink at these gatherings is in fact an alcoholic. Many corporations offer employee assistance programs to deal with this issue, and this may be something that a manager needs to speak to an employee about with the assistance of HR.
  • Managers and supervisors need to understand how embarrassing and difficult it could be for someone to bring up the issue of being pressured to drink against one’s convictions can be. It’s something that a person may simply want to go away and not make an issue about, and not appear to be trying to play a victim. If someone does approach with this concern, be prepared to deal with the issue sensitively with all concerned parties and to prevent any kind of retaliation.

Monday, August 16, 2010

PeopleWare Issues: New Employee Orientation and Cross Training in IT

Over the years I’ve done a great deal of bringing new employees up to speed and cross training others as a part of my responsibilities; I’ve also served as a team lead on jobs and trained others even before I entered IT. I’ve been seeing some common tendencies that happen when others in IT try to train new hires and colleagues. I think that understanding and dealing with these tendencies will help our IT organizations to bring new hires to consistency and productivity much more quickly and help to make sure that orientation and cross training really does deliver IT employees the information that that they need to perform their responsibilities.

Here are the tendencies I’ve seen, with their IT-appropriate acronyms:

  • TMITQ: Too Much Information Too Quickly: The person doing the training has a motor-mouth delivery that throws out a lot of technical information all at once.
  • TMT: Too Much Talking: The person doing the training indulges in a one sided lecture to the other employee as a captive audience.
  • TMA: Too Many Assumptions: The person doing the training makes too many assumptions about what the other person already knows or doesn’t know or comes to know as a result of the training.
  • NGP: New Guy (or Gal) Paranoia: The person doing the training has some kind of misgivings about the other person’s qualification or something else about the new person.

Here are my suggestions for anyone helping to bring a new person up to speed or doing any kind of cross training:

  • Understand the purpose of orientation and training. It is to give the other person the information that he or she needs to do his or her job and the tasks that are a part of the job. It is not to try to impress a captive audience with a display of your knowledge.
  • Get to know enough about the other person’s educational and work experience at the start of training so that you can tailor the training to the person’s level of understanding. Remember that it’s a great waste of time to belabor the basics with senior people who come in with a great deal of experience.
  • Don’t make the training just technical, but include positive things about company culture, goals and objectives. Avoid any complaining about anything or anyone.
  • Do not rush through the training, but pace the training to what is comfortable for the other person. Speak slowly and clearly enough so that you see the ‘wheels turning’ as the other person digests what is being communicated, and be ready to stop and clarify if you sense that the other person is getting confused.
  • Give the other person a chance to take notes and ask questions. In fact, regularly stop, ask if there are any questions and provide the best answers that you can. It should be a regular understanding that there are no stupid questions in IT, but rather conscientious people trying to get the information they need to do their jobs.
  • If possible, do the training on the other person’s computer, and allow the other person to use the mouse and keyboard as much as possible. If the training involves using a browser, give the other person a chance to bookmark sites.
  • Provide the other person with as much application and infrastructure information, diagrams and documentation as necessary to do the job. It’s reasonable to give the other person the names of any relevant servers, websites or applications, and to write these down if they do not appear on any documentation.
  • Repeat things if necessary, since repetition is often necessary to retain information. If someone asks a question that requires repetition of something that was previously discussed, don’t assume that the other person wasn’t paying attention. Rather, the other person may simply need to make connections with the different kinds of information that were provided earlier. Simply backtrack to what had been previously discussed, and take it forward to where the current focus of the training is.
  • If the training includes modifying and checking in code or fixing bugs – and it should in a software development job – go through fairly simple examples at first, and allow the other person to see the source code and development environment.
  • If there are internally developed utilities or libraries, or utilities and libraries which with the other is unfamiliar used in the software development process in your organization, provide any documentation, cheatsheets, support websites and anything else helpful to be able to use these utilities and libraries. Inexperience or unfamiliarity here does not mean that the other person does not have the qualifications, experience or capabilities to do the job; it usually means that the other person has worked in another environment or hasn’t had to use them.
  • If the other person makes mistakes, provide correction and help to resolve any problems without humiliating the other person. Treat each one as a learning experience.

One of the biggest financial investments that IT organizations make is in hiring new employees and in bringing in contractors and consultants to provide additional skills and help shoulder the workload. Simply making sure that new employee orientation and cross training is effective is a great part of making sure that that investment pays off quickly and completely.

What My ‘NonTraditional’ IT Background Really Means

Over a decade ago, during an interview, a hiring manager whom I greatly respect remarked about my resume, that it was one of the most unique ones in IT. I found that to be an entertaining and tactful way to put it.

Here’s what’s different about it. I have a Master of Divinity degree, and served as a pastor in the Christian and Missionary Alliance from 1985-1993. That’s not where most people in IT come from. What’s more, my undergraduate degree is in Classics -– Greek and Roman language, literature and culture. That’s not the Computer Science or Engineering degree that many of my colleagues have earned.

So, what does this mean as far as my qualifications for IT, and specifically, for software development? Well, on the one hand, that’s not all that there is about my background, skills and qualifications, and on the other hand, there are some things from that part of my background that have some relevancy.

First, there are some false preconceptions that others have about what it has meant for me to be a pastor and what it means for me now.

  • As a pastor, I wasn’t some kind of political operative. Political indoctrination wasn’t and isn’t part of the mission of a church nor the responsibilities of a pastor. In fact, the IRS will easily revoke the tax exempt status of a church, and in the process, probably get the pastor fired and blacklisted from his denomination if the pastor undertakes these kinds of activities as a church activity and the church facilities are used for political activities.
  • My background as pastor does not mean that I will come in and try to be the ‘moral policeman’ of a department or an organization. There will be activities that I may decide not to participate in, such as departmental ‘happy hour’ get-togethers, depending on how much pressure there is before and during the activity to drink and to get drunk. (I would add that managers need to be aware of the issues with liability and litigation that can result from these situations.) Nor am I a prohibitionist who goes around trying to reform the ‘party animals’ in an organization. In other words, I will seek to live in accordance with my own convictions, and that can be an asset to an organization, because those convictions include working with foresight, skill and integrity.
  • My background as pastor does not mean that I will try to do ‘churchy’ things during the course of a work day. As far as me doing things like stopping my work, standing up and delivering impromptu sermons during the middle of the work day, or trying to perform weddings for others in the organization, or badgering people about attending my church – those things simply aren’t going to happen.
  • I’m not a part of some paramilitary militia or anything like that. I’ve served in a respected denomination that’s been around for over a century with a publicly available website and statement of faith on that website.
  • I’m not a Catholic priest, nor have I ever been a part of the Roman Catholic Church; I’m a Protestant minister, and no one ever has to call me, ‘Father’, ‘Pastor’ or ‘Reverend.’ I’ve actually always preferred simply to be called ‘Dale.’
  • I didn’t leave the pastorate because of being connected with any kind of scandal.

Second, the course of my education and background has provided considerable skills and capabilities that proved to be transferable to IT:

  • As a pastor, I was responsible for public speaking two to three times per week. This transfers into being comfortable in front of audiences and being able to deliver presentations.
  • As a pastor, sermon preparation called for a great deal of self study and self initiative to get things done each week. So I’ve been proactive outside the pastorate in finding and getting the training that I’ve needed, reading the manuals and documentation, and getting things accomplished without a great deal of supervision and micromanagement.
  • During my high school, college and seminary education, I gained fluency in Latin, ancient Greek and Biblical Hebrew – three languages which no one speaks. This gave me experience in working with human languages no one speaks, which transfers to working with programming languages no one speaks, and a prior understanding of different fonts and alphabets. Unicode, anyone?
  • My math and philosophy education included symbolic logic, pre-calculus and calculus, and I understood and was easily able to work with things like Boolean logic, sets, functions and coordinate systems.
  • During my education, writing played a major part in achieving my degrees, and my ability to write clearly has helped me with preparing technical documentation and with other areas of my work that called for expressing my thoughts and communicating to others clearly through the written word.
  • My business experience outside IT and the pastorate included call center, business process documentation, financial accounting and operations research experience, and helped me to understand business beyond IT. Moreover, it gave me some ideas and convictions about what efficiency, profitability and customer service mean to a business as a whole.

Third, since I left the pastorate in 1993, I’ve definitely sought to gain whatever training and education that I’ve needed. Here are some things that I’ve done:

  • I’ve had a personal Microsoft Developer Network (MSDN) license pretty much since 1998, and I first learned classic ASP and MS SQL Server primarily through going through the MSDN documentation.
  • I’ve taken internal employer provided training wherever possible, and this has included classroom training on Visual C++, DB2, Mercury WinRunner, LoadRunner and TestDirector, quality assurance for IT, and project management, among others, computer based training on C, C++, Visual Basic, HTML, and COBOL, among others.
  • I’ve taken classes in the Master of Business Administration program at the Weatherhead School of Management at Case Western Reserve University, which included a class on object oriented development and the Unified Modeling Language.
  • I’ve attended outside special interest groups and seminars where available, and count myself quite fortunate to have heard such technical lights as Juval Lowy, Kathleen Dollard, Julie Lerman and Steve Smith in person.
  • I’ve acquired a number of manuals over the years, and read as much as possible from classic literature. Recommended reading lists such as that in Steve McConnell’s Code Complete had a considerable influence on the personal IT library that I’ve collected over the years.
  • I’ve subscribed to a number of magazines over the years, such as Software Development (now a part of Dr. Dobb’s Journal), C/C++ User’s Journal, Visual Studio Magazine and MSDN Journal.

Moreover, to corroborate what I’ve learned, I’ve also put in the time, expense and effort to earn these IT certifications:

  • Microsoft Certified Developer (MCSD) in C# .NET.
  • Microsoft Certified Professional Developer (MCPD) Enterprise Developer in C# .NET.
  • Microsoft Certified IT Professional (MCITP) in MS SQL Server Database Development.

What I’ve learned and put into practice without having a Computer Science or Engineering degree has been more than sufficient for me to fulfill of my work responsibilities, to make significant contributions over the years to many projects completed on time and within budget, and to provide creative and innovative solutions to specifications, requirements and wicked and difficult problems. So, my ‘non-traditional’ background did mean some difficulties in getting established in IT, but it’s made me work harder to keep my capabilities current and to provide solid contributions where I’ve worked.

Over the years, I’ve come into contact with others who have had ‘non-traditional’ backgrounds and who have been working in IT and quite productive and valuable employees, contractors and consultants. When it comes down to it, no one has to understand or approve everything in the background, work experience or off-hours activities of a colleague to work effectively with that person on a team or in a project. Rather, IT provides many opportunities to work with and understand others who are different than we are, and to learn how to work effectively with them.

PeopleWare Issues: The Impending Personal Evaluation

As a contractor/consultant, I’ve learned that when the developers who are permanent employees suddenly start doing irrational things on a project, it’s often because personal evaluations are due within a week or two. What happens are things like these:

  • Developers suddenly start pushing possibly unproven, retrograde and even bug ridden code that they wrote into a project, so they can beef up the accomplishments section of their personal evaluation.
  • Developers start adding unproven, retrograde and even bug ridden external libraries into a project, so they can beef up the accomplishments section of their personal evaluation.
  • Developers suddenly start finding long unacknowledged problems for which they can claim implementing fixes on their evaluations.
  • People who were difficult to work with suddenly start acting nice, so that they can claim that personal conflicts which may have been mentioned on previous evaluations have been resolved.
  • Coworkers suddenly start sending each other complimentary emails which can be copied and pasted into evaluations.

And so on. There are a lot of things that happen when the personal evaluation is due which can cause problems in IT projects and infrastructure down the line. In addition, the material in the personal evaluation is used extensively to determine promotions, salary increases, bonuses and retention, so skewed data can result in people going into responsibilities for which they are less than qualified in terms of their skills, capabilities, work ethic and teamwork, and perhaps even holding back more qualified people. So, there’s a need to make sure that tasks which seem to being undertaken to beef up the evaluation are evaluated on their own merits and done within established procedures and within quality guidelines. There’s also a need to make sure that the evaluation represents a genuine, solid contribution to the department that has occurred over the evaluation period, and not a flurry of last minute activity nor a parasitical hijacking of credit for the contributions of others.

Here are some suggestions for working through and improving the process:

  • For managers: Make as clear as possible the goals of the personal evaluation process both when personal evaluations are done and personal performance goals are approved for the time to come.
  • For managers: Ask for and suggest revisions to provide clarification in standard forms if you find a lack of clarity and that your people are consistently being confused by what standard forms mean. If you cannot do that, go over the forms and develop a list of clarifications as to what the requirements stated on the forms mean in your department  -- without contradicting anything set forth by upper management, HR or the legal department, of course.
  • For managers: Be aware that some people will try to ‘game’ the process and ‘play the system’ to gain undeserved credit for themselves and sometimes at the expense of others in the department and the organization. Get ideas on how to handle these situations from HR, upper level managers and more experienced managers. It is a knock against your own reputation and other’s perception of your competence, integrity and ability if you allow people in your organization to get away with this consistently. Revisions and deletions are appropriate where the depiction of the performance on the evaluation greatly exceeds the actual performance.
  • For upper managers and HR: Understand that some managers will likewise exaggerate the performance of their direct reports as their way of ‘gaming the system’ to gain undeserved credit for themselves and their department. While some departments really do have a high number of high performers, others may not, though they may try to give the impression that they do. It’s really not fair to downgrade the rewards available to a manager who really manages and develops a high performing team and the members of his or her team, especially if that results from undeserved credit to a manager and team which has actually performed less.
  • For managers: Make it clear that you’re willing to clarify personal performance goals during the evaluation period. Renegotiation may be necessary in some cases.
  • For managers: If you are adding project leadership or supervisory responsibilities to someone’s developmental goals, communicate your expectations clearly for how you expect team members to be treated and add on some kind of goals for supervisory and leadership training and enrichment.
  • For IT personnel: Read the directions carefully for the setting of personal performance goals and the personal evaluation process beforehand.
  • For IT personnel: Take enough time to put in your part of the personal performance goals for the coming evaluation period and the evaluation itself. Do what you need to do to guard your privacy and avoid interruptions during this time. When I did mine, I usually worked after regular working hours, especially when my cubicle was adjacent to an aisle where my computer screen could be easily seen by everyone who passed by.
  • For newly hired and entry level IT personnel: Go over the process with an experienced, trustworthy person, and be ready to ask your manager and HR representative any questions. Make sure that this is done as requesting clarification and not criticism of the process – the first will mark you as a conscientious employee and the latter as a potential problem person.
  • For IT personnel: Take some time – maybe a half hour to an hour every month or every two weeks – to re-read your goals for the evaluation time period, and evaluate your current activities in light of that.
  • For IT personnel: Keep a running list of how you’ve accomplished the established performance goals throughout the year, rather than trying to think back at the last minute at what you did since the performance goals were handed out.
  • For IT personnel: Address areas with the manager where things didn’t work out on projects and tasks well before the evaluation deadline. Find also some genuine lessons that you can sincerely say that you’ve learned from the experience, and which you can say that you will do better in the future.
  • For IT personnel: Step back, consider the whole experience in light of your career and long term goals, and take in the whole experience as relating to building your professional experience and long term qualifications for the future. Take the initiative to deepen and broaden your own professional skills, capabilities, teamwork and integrity, not just accomplish tasks on the list. This process can aid your own development and corroboration of your professional skills, capabilities, teamwork and integrity when the time comes for you to move on to greater professional responsibilities and the concomitant professional rewards.