Shaking IT Up: 10 Ways Management Can Ruin Your Day

Shaking IT Up: 10 Ways Management Can Ruin Your Day

Here :http://www.itjungle.com/tfh/tfh051004-story04.html

by Kevin Vandever

My last column listed 10 ways a programmer can ruin your day. Knowing the state of IT these days, I realize that, through my article, I had declared open season on programmers. I made it very easy to blame the programmers for all IT woes. Well, hunting season on programmers is over. It's time to take aim at management. So here's my list of the 10 ways that management can ruin your day.

Just as the application development staff can determine how smooth a company's operations run, so can the management and leadership teams. These people manage projects, set priorities, supervise employees, negotiate with vendors, beg for their budgets, and sometimes find time to strategize and plan for growth and positive change. They do all of this in spite of all the meetings they have to attend. I know this because I write from experience. I also know that, mixed in with all this productive stuff that managers do, they also know how to ruin your day. The following are 10 ways that come to mind, in no particular order.

NO. 1: OUTSOURCING IT SERVICES

You've heard the rumors: millions of programmers and help desk specialists in China and India frothing at the mouth to take IT jobs from some poor, unsuspecting souls in America. Well, it might not be that dramatic, but the fact remains that managers look at ways to reduce IT costs, and one way is to outsource technical jobs to overseas companies that can do the work cheaper and just as effectively. Now, I am not here to debate the pros and cons of outsourcing--that's fodder for another time--but I am here to say that management determines whether IT jobs will be farmed out to our neighbors in other lands, and that decision can leave someone with a less-than-desirable day, spending his time pondering what housing prices are like in China or India.

NO. 2: MICROMANAGING

Everybody hates this, right? I have never heard anyone say, "Gee, I wish I could be micromanaged more." Talk about potential for a ruined day. The good news is that I see this less in IT than in other departments, but I still see it, and it still usually leads to a mad dash to the medicine cabinet and, in better economic times, a dash to the door. Many times, this is caused by insecure or power-hungry managers (see number 8) who think that nothing can get done unless they're watching every detail. Little do these managers know that the more they let go, the more success their teams would have and the less stress they would endure and inflict on others. These managers would then have more time to perform more meaningful duties, like negotiating our raises. But until they learn this valuable lesson, they will continue to be consistently successful at one thing: ruining your day.

NO. 3: MACROMANAGING

You probably love this, right? No one looking over your shoulder all the time, directing your every move. On the surface, this may sound like a good thing, but as bad as micromanagement is, the opposite--call it "macromanagement"--can actually be worse, but in more subtle ways. At least with micromanagement, things are usually under control, albeit in a stressful environment. The staff may have to report their every move, but in most cases decisions are being made.

Most non-management IT types like and need some direction. They need to know what to do in a tight spot or feel comfortable that they can escalate an issue without retribution. Without management support, these folks will procrastinate and wallow in ineffectiveness. A manager who thinks it's cool to give his department ultimate freedom, or who does so out of fear of making a decision, may be easy to work for in the short term, but eventually you will start to become ineffective and unresponsive. That's why this problem is one of the most dangerous, along with number 5, because often the symptoms are not noticeable until it's too late.

NO. 4: SETTING UNREALISTIC DEADLINES

This one bothers me the most. If I had a nickel for every day ruined over this issue, I'd probably be as rich as Bill Gates. Management never seems to learn. They constantly agree to a major undertaking, picking a date out of the air, and hold the rest of IT to that date as if it were the Gospel. Then you work like crazy to meet that date, adding scope, redoing work after testing, and putting in hellacious hours, with the only constant being that the date doesn't move. All of this because a deadline was magically established with no knowledge of the effort that is necessary to accomplish the project.

And we don't fight back anymore. We are either ignorant of the issue or we are so used to this culture that we don't even ask them to justify the deadlines anymore. We just accept them. And forget moving the date if something slips or requirements are added. Just work harder and longer to get the project done. This mentality ruins weeks, month, years, and even careers.

NO. 5: PASSIVE-AGRESSIVE BEHAVIOR

This one is as hard to peg as macromanagement (number 3), but it lingers, and if you're not careful it will not only ruin one day, but, like many others on the list, it will ruin a whole string of them faster than you can type www.monster.com. So what is passive-aggressive behavior? This is a culture in which, from an outsider's point of view, everyone seems to get along. Meetings are run without conflict, managers' decisions aren't debated, and any problems in the department seems to be a natural part of the normal IT environment.

But on closer examination, you'll notice that meetings are run without conflict because conflict, or appropriate debate, is not allowed. No one debates the manager because the manager is insecure or power hungry and will not be questioned. The problems in the department exist because people are afraid to question them. This is not healthy and will stunt all growth and innovative thought in an IT department.

These managers often play an adversarial role with their staff, as opposed to a cooperative one. They don't necessarily act as tyrants (number 8) or micromanage anyone (number 2), and they may seem pleasant to work for, but underneath it all, everyone knows that their authority is not to be questioned, even when actions and decisions are inconsistent or contradictory. When this happens, and no one openly talks about it, a day-ruining cancer starts to form inside your department that will eventually lead to its downfall.

NO. 6: SHORT-SIGHTED BUDGET CONSTRAINTS

This one comes in many disguises and could probably fit under one of the other categories on this list, but this is a serious issue. I understand the need for budgets, of both dollars and time, but we often spend more money and more time by not doing something upfront.

The two budget cuts that come to mind are training and proper analysis. We often sacrifice proper analysis and testing in order to meet deadlines. You don't have the time to do it right, but you have time to do it over or to do it forever.

This also holds true for financial budgets, especially where training is concerned. Management doesn't want to spend to money to send people to training or to allow them to train at work, but there is money to redesign and rewrite applications because the staff may not have correctly done it the first time. I understand the budget process, and I understand that users need their software in a timely manner, but just because we save some money or get something done within the user's expectations doesn't necessarily mean that we have budgeted that money or time correctly. Both could come back to haunt us in the long run. Look at it as a bank of ruined days.

NO. 7: SCHEDULING TOO MANY MEETINGS

At least this phenomenon can ruin a manager's day, too, although he may not realize it. Most meetings are a waste of time. Period. You don't need meetings to communicate effectively. You need communication to communicate effectively. And there are plenty of other forms of communication that are more direct and come without all the baggage associated with meetings.

Meetings are usually a time for managers to posture and play political games. That posturing and those political games give birth to many other day-ruiners on this list, like unrealistic deadlines (number 4), passive-aggressive behavior (number 5), or taking credit and passing along the blame (number 10).

And those meetings that actually bring about some good often run too long. Meetings are usually scheduled for some arbitrary, but easily manageable, length of time. For example, most meetings are scheduled for an hour and, amazingly, usually last an hour. Does this happen because we are so good at knowing how much time it will take to discuss an issue? No. It happens because we figure out a way to take up the whole hour, and that is usually done by rehashing issues, slipping into company gossip, or discussing topics that aren't related to our work--the latter might be the most productive time spent in a meeting. So if your manager is either attending or scheduling you for too many meetings, chances are there is a ruined day in your near future.

NO. 8: HOLIER-THAN-THOU ATTITUDES AND TYRANNY

Some managers think that, because they are managers, they are better and more important that the rest of the staff. What can I say about this behavior that you don't already know? If you work for this type of manager, most days are ruined before you even walk through the door.

This issue is a close relative to number 10, as you can be sure that when your manager is in a meeting or is talking with other managers, he is either taking credit for something that his staff accomplished or blaming you for something he could have managed better. But there's more to this behavior, and it usually comes with a condescending attitude that leads to dissention or a lack of confidence. These managers have forgotten where they came from and usually stamp the life out of a department, then blame the department for the failures. There is no hope for recovery if you work for this type of manager. The good news is that you'll be so used to ruined days that you'll desensitize yourself and soon it won't matter. (That is actually very bad news.)

NO. 9: MANAGING INSTEAD OF LEADING

This is one of the more subtle ways a manager can ruin your day. You may be perfectly happy with your job and your manager, but soon things start to deteriorate. The problems arise from unhappy employees who don't see a career path or a department direction. These managers may be great at managing people and projects, but what about leading people? What about motivating staff, painting a clear vision of the future, setting goals and working toward them? This is what leading is about, but many managers lack this skill or don't have the time for it.

However, too much of this behavior can take its toll. This happens a lot in IT because of the Peter Principle, which states that people are promoted to their level of incompetence. Skilled technical people are often promoted into management positions because that's how they can make more money and climb the corporate ladder, not because they are great leaders. We don't train, groom, or hire leaders who may not be technical but know how to lead a team and manage projects.

This is another one of those issues that can ruin the manager's and the subordinate's day, and probably will take a complete corporate culture shift before there's an improvement. This is not to say that one can't rise from the technical ranks and become a great leader. I've seen this work well, but we usually don't give it much thought when promoting people. We usually see that someone has reached a ceiling in his salary and the only way to bump him up is by promoting him, regardless of his leadership abilities.

NUMBER 10: TAKING CREDIT, PASSING ALONG BLAME

This is tied very closely to number 8, and you may notice that this type of manager loves meetings and face time with upper management, because he usually engages in undermining his staff in order to make himself look good. He may not carry the traits of the manager described in number 8, but he can be deadly behind closed doors.

This type of manager can ruin your day by spreading false information about his staff when things don't go right, and not giving enough credit to the staff when things go well. Sometimes a strong management team can root out this type of manager; if not, you may be spending more time trying the dispel rumors and defend your staff than you will performing productive work. The good news is that this type of manager is eventually discovered and is either appropriately dealt with or not taken very seriously. But if that doesn't happen, watch out.

Well, there you have it. Ten ways that management can ruin your day. Some of these are more obvious and easy to handle than others, but they all can ruin your day. All managers, even the great ones, may display some of these traits, but not enough to warrant any concern. I didn't talk about how to combat these issues, but I will do so in a future column. For now, if you find yourself in one of these situations, the best thing to do is understand the situation so you can then make an informed decision about what to do. Good luck.


Sponsored By
ITERA

And here :http://www.itjungle.com/tfh/tfh030804-story04.html


by Kevin Vandever

Programmers are unique and remarkable beings. They work their technical magic to bring efficiency, consistency, and overall happiness to a company's workforce. I know all this because I am one of them, or used to be. I now help ensure that happiness, efficiency, and consistency are what the programmers are producing. And most of the time, they do their jobs well. But then there are times when one programmer can ruin someone's day. It is these times, not the good ones, that are remembered the most.

So how can we fix this problem? How can we make it so programmers use their powers for good instead of evil? No one in your company can ignore this issue. You can be a user, manager, or another programmer. It does not matter. Whoever you are, a programmer can ruin your day. I've listed 10 ways that a programmer can ruin your day. There are certainly more than 10, but I stopped there so that it would be easier to focus on the solutions, which, by the way, are very simple: Make your programmers stop doing these 10 things! It's simple.

What's not simple is knowing what the issues are and actually getting your programmers interested enough to change their ways. I'll help you with the former, but you'll have to do the latter. The following day-ruining exercises are not listed in any particular order. One is not any more important than another, with the exception of number 10. You'll also notice that I only cover technical issues. This is not meant to be a technical article (you don't have to be technical to understand the issue and help the programmer)--just knowing that these issues exist is half the battle. If you're not technical, you can find someone who is, to help diagnose the problem. With that in mind, I give you 10 ways a programmer can ruin your day.

1. Writing programs with little or no comments in the code.

Everyone's seen this type of code. Heck, we've all written it. We're too busy to put the comments in as we're coding, so we just don't do it. We say things like, "I'll go back and add the comments later." Like that ever happens.

Poorly commented code is like a time bomb. It won't really hurt you when the code is first written. It's only later, when a modification needs to be made and the original author has moved on to greener pastures, that this issue will raise its ugly head. Then there are those programmers who do indeed comment in their code, but the comments are nothing more than a duplicate of the programming language syntax that was written. The comment is as cryptic as the code, and is now listed twice to double the confusion.

It seems that just as men don't like to ask for directions, they don't like to write them, either. Just as we'll drive around for hours looking for a destination, we'll aimlessly wander through code trying to find our way around it, too. The analogy stops there, though, as women, too, don't like to write commented code. So the good news is that men and women finally agree on something. The bad news is that both sides are wrong.

2. Hard-coding data and devices in the code.

My day was recently ruined because of this very issue. Much analysis had been done to determine the necessary data changes that would have to be made to handle a modification in the commission structure. We were smart, we thought, years ago when we put the logic in the database and made everything table driven. When changes needed to be made, we made them in the appropriate tables and no code was touched. Everything worked out just fine; the sales reports were printing properly and we were even congratulated by the sales department for a job well done.

Well, much to my dismay, the month-end sales reports that ran a few weeks later were not doing so well. In fact, the numbers were ridiculously wrong (that's right, not just wrong). We immediately put the original programmer on the prowl for the problem (because of issue 1 above and issue 9 below), along with a few of our senior programmers, because the issue was so hot and so visible. After hours of investigation, it turned out that much of the data that was so nicely stored in the database was also hard-coded inside a couple of the month-end sales reports. This type of thing happens more than you might think, and I challenge programmers and managers alike to randomly take a look at some of your programs and discover how much data is actually hard-coded in those programs. It will manifest itself in many forms, such as hard-coded printer devices or data stored in arrays that is also stored in the database, but it is there and ruin will strike you soon.

3. Not letting the database engine do its work.

OS/400 is integrated very nicely with the DB2/400 database. This was not always well known, but it has been the case since its inception. The DB2/400 database is very powerful and can be used for much more than simply storing data. But most programmers don't use it properly. Instead, we force our programs to do all the work. No big deal, right? Why not select the data we want in our RPG programs and give the database a break?

Well, for one, by doing the data selection and filtering in our programs, we do so by hard-coding (see issue 2) and, as I just mentioned, hard-coding will end up ruining your day at some point. Another reason we should let the database do its own work is that it is really good at it, and does it much faster than our programs. So this issue might ruin your day twice. Once because it turns out that a simple change in selection criteria ends up being a major program modification and, again, because the application takes too long to get the data, therefore causing the user to take a 30 minute coffee break every hour as he waits for his screen to fill with data.

Spread the word: Let the database do the work it was meant to do. Get that stuff out of the programs. Of course, this particular issue is for OS/400 programmers only. Some three-tiered architecture systems, such as SAP, actually develop their own language so that it can do the database's work for it and let the database simply store the data. If you are on that system, what are you doing reading this newsletter?

4. Reinventing the wheel.

Programmers can be creative, and that's a good thing, but if something has already been written, don't write it again. Your day will be ruined when a user asks you to change how something is calculated and naively believe that your staff will have the change done in a few hours, but are later told that 92 different programs have that calculation logic embedded in it and it will take a few weeks to get them all coded and tested. Teach your staff to re-use routines, share code, and research for the existence of something before they go off and write it again.

5. Not using modular coding techniques.

This issue might ruin a week, a month, or even a year. It's the program that keeps on ruining. How many shops out there have a program with more than 20,000 lines of code? Probably most of you, right? Then you know how difficult it is to fix or modify a program of this nature. Business logic is mixed with presentation logic, which is mixed in with more, unrelated business logic. About 80 percent of the programming backlog is tied to this program, and it is the hardest program to fix. Worse, because it is such a house of cards, you can be sure that any modification made to this program will create more issues. The program is nothing more than a random bug generator. Keep the Advil, Mylanta, and scotch all handy for this doozy.

6. Poor or no testing.

Enough said.

7. Writing programs with little or no error handling.

Programmers love to assume that either the data is correct in the database or that the users are going to enter what is expected of them on their data entry screens. For this reason, we code without worrying about what will happen when that data is not perfect. The problem is that data in our databases is sometimes invalid, and users, given the chance, will always enter bad data over good (okay, only sometimes, to be fair, but it feels like always). Because our programs don't catch, trap, or even fix data entry and integrity issues, they become the path to even more data problems. Soon our database is a mess and we are blaming the users. RPG, COBOL, Java, and CL have very good methods for handling errors. Yes, it takes a little more time to code these routines, but if you document well (see issue 1) and re-use code (see issue 4), the upfront work in designing these routines will be returned many times over as your application matures.

This issue might ruin more than just one day because by the time you realize that your data is bad, because of holes in your applications, it may be weeks or months before it can be fixed, both in the code and in the data. The best thing that can happen is that your programs bomb. This may be ugly, and can certainly ruin your day, but at least you will know about the issue right when it happens. I take back my earlier statement that these issues are all of equal value. This one might be just as bad as number 10, or at least will aid number 10 in ruining as many days as possible.

8. Writing spaghetti code.

Spaghetti code goes hand in hand with the modularization issue (see issue 5), but I made it its own issue because even modularized code can be poorly written. Spaghetti code is code that goes all over the place, with no rhyme or reason. It contains no structure and seemingly no thought. It's as if you asked 100 programmers to pick a random spot in the program, add his unrelated business logic, make sure it compiles, then slam it into production. Maintaining or reading spaghetti code is nearly impossible and, just like poorly modularized code, the more you maintain a spaghetti-coded program, the more problems you add to the program. Your best bet is to stop maintaining this type of program and train the users on the current bugs that exist. Call them features. Either that or completely rewrite the program, keeping this article close at hand to help you with what not to do.

9. Doing in 100 statements what can be done in 10.

I wasn't sure that I was going to add this one at first, because if the code works, should one care about the method used to get it to work? The answer is an emphatic yes. It's not enough to get the code to work; it must work efficiently and be easy to read and maintain, as well. This way to ruin your day is closely related to poor or no comments, and that is why I added it. I see this happen a lot, and it leads to a much bigger problem. You've probably heard this statement a million times: "Let Joe work on that program because he knows that application." That always leaves me perplexed. Why is it that only Joe can work on the program? Is it really because he is the expert in whatever business problem the program is attempting to solve? Or is the program written so poorly that Joe, who happens to be the original author, is the only one who can read it? Either way, your programmers must learn the proper techniques to accomplish a task. Sure there are many ways to do something, but there are usually only a few best ways to do it, and in order to limit the number of ruined days, we should strive to learn and then use the best way.

10. Writing programs that contain bugs.

This issue is rather obvious, but the fact is that your programmers can fail at the other nine issues and still produce bug-free applications that meet users' expectations. They can also write the most well documented and efficient code known to man, properly avoiding all the traps mentioned in this article, and still write a program full of bugs. Nothing will ruin your day more than programs filled with bugs, and as plain and simple as that is, it still happens to us many times every day. Avoiding the first nine issues will go a long way toward limiting the number of bugs in your applications, but that is not enough. You also must understand the business issue at hand and then understand how to properly transfer that business issue into your programming language to best fit users' needs.

There you have it. You are now armed with the knowledge that will not only make your programmers better but also keep the ruined days down to a minimum. As I said, there are more than 10 issues, and there are also other issues that don't have anything to do with technical skills. However, this is a good starting point for some coding standards and templates in your shop. Programmers with good intentions and some well-written standards, templates, and procedures, can do great things. But with great power comes great responsibility, and we must all do our part to see that this responsibility is upheld, or guess what? We will all be outsourced.

All official surveys on large IT projects show a very high failure rate (greater than 70% on average) regardless of the country, company, platform culture or methodology used.

I have long suspected that this indicates that the core approach to software development is wrong. How else can you explain such a massive rate of failure across all situations for large enterprise projects.

The simple fact of the matter is that what are often given as reasons for failure, are in fact themselves just the symptoms of a deeper set of issues.

I think you will find that it all boils down to the fact that, with all current approaches to software development, the COMPLEXITY of the developed system very quickly becomes unmanageable.

This provides the environment for key programmer dependencies to be abused, and for managers to start shifting goal-posts to be able to claim success.

The complexity quickly reaches a point where the gap between the original anaysis and development plans that management were working too and the actual implemented code have very little relationship.

This makes it difficult for management to even discuss the problem.

This provides a fertile environment for the consultants to come in and charge on a time and materials basis and make a killing, leaving the clients high and dry.

You can't fix a problem until you correctly identify its root cause. It is no good dealing with the symptoms as that just leads to a fire-fighting exercise.

In my opinion, the problem between management and IT is unmanageable complexity.

This problem has to be identified and understood before suitable solutions can be put forward.