MORE ENTRIES
- Making architecture happen
- When you step into a kludge/Who or what do you go nudge?
- How to handle a too-influential outside consultant
- Alternatives to the chain of command?
- The kludge index
- Fixing an interface kludge ... or not
- About kludges
- Why doctors and nurses won't use IT
- How to promote good project management
- What "waterfall" means
Advice Line | Bob Lewis »
June 2006
Enough already! You've written a lot recently about good architecture and bad kludges. We all know that good architecture is important and that kludges are bad. That doesn't help very much without some practical advice for CIOs who want to encourage the former and discourage the latter.
What, exactly, should we be doing about it?
- Architecturally inclined
Dear Canted ...
The two best steps you can take (that I can think of right now, at least) are to (1) establish a core set of architectural principles, building an architecture review process into your applications methodologies; and (2) build code reviews into your applications and SQA (software quality assurance) methodologies as well.
Architectural principles are the core set of design standards that define good architecture in your company. The key to their success is to ground them in the realities of your situation. That means that "eliminate data redundancy except in the keys and backups" is a valid principle if you build everything, but meaningless if you buy when you can and build when you have to (another candidate architectural principle, by the way).
That's because, if you buy applications, of necessity you'll have the same data living in multiple applications, so you'll need a different principle to guide developers then: "Manage redundancy by establishing which data repository is the source of truth for each category of information, and using data synchronization techniques to coordinate the other repositories that contain the redundant versions of the same data." Or something - whataver is most appropriate for your company.
Application methodologies should include an "architecture impact statement" created by the software designers that feeds an architectural design review that precedes coding. They should also include a final architectural review built into the SQA process prior to roll-out.
The notion of having code reviews isn't new, and I trust requires no additional explanation.
The tricky part in all this is making sure the discipline of managing architecture doesn't turn into a bureaucratic tangle. It can easily happen. The best solution I know is to rotate developers into and out of this responsibility, rather than to create a permanent organization that can easily become an ivory tower.
- Bob
I really enjoyed your article on kludges ("The Kludge Index," Keep the Joint Running, June 26, 2006). But I have a question: what do you do when you step in someone else's kludge? I'm a junior member on a team that's been kludging along for about a year and a half on a project.
I've been here for three months. I'm examing source code and finding comments like "DO NOT MODIFY UNDER PAIN OF MUTILATION OR A MONTH OF COFFEE DUTY" with no explanation about what the following block actually accomplishes. The system is a pieced together mess that hasn't been properly tested against any cases, let alone corner cases. Every time we try to use the system it's a labyrinth of steps involving way too many tools.
But of course, the people who have been here longer, the ones responsible for devoting so many company resources to developing the kludge, have a vested interest in NOT scrapping the thing and starting over. They can't admit that the work they've done so far needs to be thrown away. (In fact, they don't even really want to admit that it's a software development project that requires some kind (any kind!) of methodology...)
I'm "managing up" as much as I can (I just convinced everyone that we need to start using a revision control system) but is it really worth it?
- New kid on the block
Dear Newbie ...
The "right thing to do" depends on how the project is being managed. When we teach project management, one of the techniques we, along with just about everyone else, recommend is to maintain a formal list of project risks and issues. Part of project management is developing contingency plans for risks and making decisions about issues.
Generally, the project team reviews the list during the project's weekly status meeting. If this project is being managed that way, I'd recommend adding your concerns as a risk or issue and letting the process run its course.
Otherwise, you might consider sitting down with the project manager to inform him of your concerns, ask what the plan is for cleaning up the system's internals and otherwise moving it from proof-of-concept to a production-grade system, and accept whatever answer he gives you. In the end, it's his baby and you are the new kid on the block.
You'll have to use your judgment in deciding whether this would be a productive course of action or just get you labeled as a troublemaker. That depends entirely on the personality and competence of the project manager.
If your organization has a separate architecture group you might consider discreetly dropping a quiet word in the right ear. I don't love this approach, though. In some, politically ugly companies it's about the only thing you can do, but you end up getting a reputation for being a junior G-man, as it were, and very quickly, nobody is willing to trust you any more.
I'll also say this: My comment about hiding ugly code inside a "box" where nobody can see anything except its interfaces was sincere. Not all code is beautiful; sometimes the only way to accomplish the job is a nasty little hack that you hope nobody ever looks at very closely.
That shouldn't apply to a whole system, of course, but it usually does apply to a callable module or three.
Anyway, as junior team member your options are more limited than if you'd been around longer, so my last piece of advice is to remember that relationships outlive transactions. That is to say, know when to stop pushing the point. Even if you win every battle you fight (to pick an overly harsh metaphor), eventually you'll end up alienating so many people that you won't be able to win any battles at all.
I hope this helps.
- Bob
I've been on my job for ten years as a one-man IT department -- official title is Systems Administrator. Been great, people are good, pay is reasonable, love my job. A year ago we were 'blessed' with a new management person, brought in to straighten out some operational shortcomings (almost entirely in other areas of the company, not mine). Our general business is financial, so we have operational issues, regulatory issues, compliance issues, and frankly we did need some re-organizing before we were hit on by hungry auditors.
But our new management person, after talking with me and finding I did not share their views about numerous things (including oursourcing), apparently decided that along with everyone else here, I was incompetent and clueless. I say this because I was cut out of all strategic decision-making relating to IT -- this person brought in a local IT engineering firm to do an audit of my department, but subsequently bought into a whole slew of services - hiring them to put in a new backup system (at outrageous prices), disaster recovery planning, inventory, and now appears even headed for giving them management duties. All of which happened without any input from me.
We now have a very expensive backup system that produces an end result not substantially different than what I was doing previously. We are almost no further along on our business continuity plan than we were before, and won't get there without another whole wheelbarrow full of money. A penetration test revealed no critical flaws in our security, the test of my new firewall was essentially perfect. All in all, we've spent a whole bunch of money, not accomplished much. And I still have no input into disaster recovery, business continuity, and any strategic planning.
Our CEO has the final say, but it appears to our employees that out of fear of being too far out of compliance, he has given this person total control over the company. And along with other employees, I'm frustrated and uncertain what to do. This new person seems obsessed with being in control; always has an answer for everything, even if wrong; can fly into a rage when questioned about a decision; and generally is seen as cold-hearted and ruthless. Most importantly to our staff, the person's HR skills seem to have been gained at the Marquis de Sade School of Business.
What to do? I'm well over 50, few certs to my name, and the question I've tossed over recently is whether to look for a different job or try to hang on long enough to outlast this person and hope life may return to normal?
In some ways, I know I'm just whining, but sign me,
- Frustrated
Dear Frustrated ...
The best course of action depends almost entirely on the quality of your relationship with the CEO.
If the two of you have a reasonably strong relationship I'd recommend handling this the straightforward way - sit down with him, point out that the consultant found no material weaknesses in IT and that the company is spending a more money on the externally supplied solutions and getting far less in return than it would get by hiring a second IT staff member. Also point out that since he (the CEO that is) has taken away your authority to make IT decisions and reassigned it to the consultant, you can't take responsibility for the results any more. (In the it-goes-without-saying department, prepare for the meeting with a list of specifics - all the subject areas where you were reviewed and your performance was found to be satisfactory.)
One other point you might consider making: There seems to be, to me at least, a strong possibility that the consultant is double-dipping - making money through referral fees received from the outside vendors. You might suggest that the CEO exercise the audit rights that are usually written into consulting contracts for just this reason.
If you don't have a strong relationship with the CEO, let me first just say ... why don't you? That's a big red warning sign. But if that is the case, you have a much more difficult challenge in front of you. Your first step is to thoroughly document the specific misdeeds of the outside consultant - dates, times, and facts. Do so until you think you have a compelling case that will demonstrate the harm being done to the company.
Then schedule a formal meeting with the CEO, lay it all out, and recommend that the consultant has outlived his or her usefulness.
Or ... if neither of these courses of action seem to have a good risk/reward ratio, keep your head down and just wait it out. There are some consultants who do develop permanent "positions" with their clients and whose "projects" become eternal. Usually, these are individuals whose advice and counsel have proven to be useful to the CEO, and so are engaged to be ongoing confidantes and advisors. Unless you think this will be the case with Mr. de Sade, gritting it out just might be your best course of action.
- Bob
A semi-theoretical question about how to organize IT: Does the chain of command pyramid have an alternative? The best teams I've worked on were relatively flat and they were silent because everyone knew what they had to do. Maybe that just means that at a certain size, a flat model is no longer practical and the only known alternative is a chain of command hierarchy. Maybe there are companies out there that do have an alternative that they think works, dunno.
- Reorganizing
Dear Reorganizing ...
I've heard of lots of experiments, matrix management being the best known. In the end, they all seem to break down because there always comes a time when someone has to make a decision.
The question isn't whether you have a chain of command. The questions that matter are:
- Bob
Since Kludging could (in theory) hire someone to write a single replacement for the two systems, this *has* to be seen as a workaround, doesn't it?
Which leads to an interesting question -- what's the difference between a kludge and an multi-step standard operating procedure like the above?
Is it documentation? Management approval?
A prohibitive price to build a system to avoid the kludge?
Unless we get some clear guidelines, Bob, it's beginning to seem like "kludge" = "SOP" much like "terrorist" = "freedom fighter".
Bounds makes a good point. It's all well and good to define a kludge as using a band-aid to attach a box to the side of the box that's affixed to the main system with chewing gum and duct tape, but that doesn't do much when the time comes to design a solution to a system problem.
I'll make a start here. Add your comments and I'll do what I can to turn the result into a future Keep the Joint Running.
I'm thinking in particular of some enterprise applications vendors that have extended their range through acquisitions, gluing the acquired pieces to their core system through middleware of some kind without ever harmonizing the underlying design assumptions. So long as it never becomes your problem, is it still a kludge?
- Bob
I happen to have something like your first example (in "Seven warning signs of bad architecture," Keep the Joint Running, June 5, 2006): two dissimilar systems that need data transferred from one to the other. I've written a program that reads the data in the one system, massages it, and puts it in the other, but because the two systems are so different in function and data formats, I always have to go back after the fact and fix what the automatic system couldn't handle.
So what is the proper way to deal with a kludge like that? I'd like to say that we should just have one system, but unfortunately, we haven't found one system that handles the two different functions of our two existing systems. I could refactor my code and make it better, but I KNOW that some of the data transfer is something that only a human intelligence can handle (or else, I KNOW that I'm not a good enough programmer to write that intelligence.) What other options are there?
- Kludging
Dear Kludging ...
While they're generally pricey, you might want to look into one of the commercial ETL (extract, transform and load) software packages. It's what they're for, and you might find they're able to handle some of the tricky cases that currently require human intervention.
Either way, you're probably handling this as well is possible: Automatically handle what computers can do, and kick out an exception list so humans can intervene where the computers can't handle the situation. To me, this isn't a kludge - it's SOP.
- Bob
Thanks for the recent KJR on architecture ("Seven warning signs of bad architecture," 6/5/2006).
I’d appreciate a more concrete explanation of why Kludges are bad (as a contingency were I to run into an ugly enterprise architect that chews gum)! I suspect that the reason might be very similar to the “too many interfaces� problem and you didn’t want to repeat it; in any event I need something non-IT executives can sink their teeth into.
Thanks!
- Blueprinter
Dear Blueprinter ...
Let's start with the nature of a kludge (or "kluge"; there are those who prefer to spell the word as it's pronounced; others delight that English spelling is, itself, a kludge): It's a Rube Goldberg-ish piece of work whose sole virtue is that it does work, more or less.
Kludges lead to two major problems. The first is that they're generally fragile, because they have too many moving parts. Change an input, fiddle with the data design of a core application and the kludge breaks.
The second problem is that they generally perform poorly, so scaling is a problem.
I'll illustrate the point by making up an example - an interface between two incompatible business applications. What I need to do is to extract data from one, reformat it, and pipe it into the second.
The first application only knows how to print reports, not how to output comma-delimited data (it's an old application). So I tell it to print the relevant report to a file.
Next, I open MS Word and record a macro that understands how to recognize and delete the page and column header text, a second macro that knows how to change the spaces that separate columns into commas, and a third that knows how to insert an opening and closing quotation mark around text fields. I also build an autoexecute macro so my data center can launch MS Word with a parameter and have it open the file, run the macros, and close MS Word again.
But I'm not done: Some of the data needs to be transformed in ways Word can't handle as easily as Excel - for example, parsing a name field into first and last names, or matching the first and second system's vendor numbers using a cross-reference table. So I next set up an Excel spreadsheet that can bring in the file, apply the relevant formulas, convert the formulas to values, and write out a comma delimited file for the second application to read and process.
I think you can see just how easy it would be to break this kludge. The slightest change to either of the main systems would do it. And in the meantime, if we're talking about data in any kind of volume, the length of time required to process the data translation is likely to be far longer than is desirable.
Or, use plumbing as a metaphor. If a pipe starts to leak, the first thing to do is to do whatever it takes to stop the leak. Use duct tape, use sheet metal and hose clamps, use whatever ... just stop the leak, because it doesn't take very much water to do serious damage, and small leaks turn into big leaks pretty quickly.
That doesn't mean that once you've stopped the leak that you're done. It means you now have the time to schedule maintenance to replace the section of pipe that leaked. If you don't, the patch won't hold. It isn't supposed to - it's a patch.
- Bob
I've read and enjoyed your columns for years. I'm in healthcare IS and have recently changed jobs to being a consultant for a large, hospital software provider.
My question is whether you've had any experience in the healthcare market? Why I ask is that despite everyone from President Bush down saying more I.S. is needed in healthcare to solve all the problems (yeah right), my experience is that clinicians (nurses mostly but also doctors, x-ray folks, etc.) look at using a computer as an optional activity. "I'm not a computer person - I take care of patients!".
The feds and hospitals can spend 11 quadrillion dollars on hardware and software but if the intended user base refuses to use it, why bother? The healthcare I.S. rags I read are in agreement that healthcare is behind the curve on implementing useful systems - - well, no kidding. It is a difficult area to automate and the primary clinical users won't use it. And management makes no more than a token effort to "force" them to. I've always wondered why the need to "force" them exists.
Having spent my entire working career in healthcare, I can only imagine manufacturing, banking, whatever-not-healthcare, don't perceive using their systems as an option. Am I right? I have theories about why healthcare is different - a study waiting to happen. Now that I'm working with different clients, I've found this to be a universal problem in healthcare (although not one writers appear to be willing to write about.) What's your (always well thought out) opinion?
- In the field
Dear Fielder ...
My opinion might be well-thought-out, but that doesn't mean it's well informed. For all I know it's neither - I'll let you be the judge.
There are quite a few pieces to the problem. The first is intrinsic to the discipline: Human beings vary widely in the symptoms they display to the same diseases, and in their response to medicines. Different strains of the same disease also respond differently to medicines. The practical impact on the medical profession is that it isn't going to be turned into a set of well-defined processes any time soon. It's the distinction between a practice and a process, if you're familiar with that terminology: You put as much intelligence as possible into a process, reducing the level of sophistication required of the people who participate in it. In a practice, following the steps gives you a chance of success - it doesn't drive success.
IT is most successful when it participates in processes. The steps are well defined and it's possible to establish clear specifications for what IT is supposed to do. Supporting practices is harder because practitioners don't always know what they're going to need from the system until they get there. I'm pretty sure this is an issue with the medical trade, just as it is in law.
Another challenge is the "rock star" syndrome. Also as with law, doctors - and to a lesser extent, nurses - go through a very long and arduous training program before they're allowed to practice, and it has a significant rate of failure. Along the way, many doctors (and lawyers, along with celebrities of all stripes) end up with, shall we say, egos of a size that's a bit larger than is the case with most of us. The focal point is the practitioner, not the process or the enterprise, so avoiding this outcome requires a strength of character that not everyone has.
What's the outcome here? In a sense, it gets back to the point of optimization. Remember that to optimize the whole you have to suboptimize the parts. Doctors, lawyers (and other celebrity professions) are unlikely to accept suboptimization on their part for the greater good of the organization. The organization exists to support them, not the other way around. This makes enforcing the use of standardized technology more difficult.
A third factor that I suspect comes into play is what I'll call the SFA problem. SFA stands for Sales Force Automation. Perhaps the single biggest factor leading to SFA failure is that too many systems have focused on supporting sales force management and too few on supporting the selling process. While I'm entirely unencumbered by facts, it wouldn't surprise me in the least to find out that many medical information systems are designed to support medical administration, as opposed to being designed to support the practice of medicine. If that is the case, it's hardly surprising that doctors and nurses, given any chance at all, will ignore them.
They should: Their job is to practice good medicine. Sacrificing that to support better medical administration isn't something I want them to do when I'm their patient.
So here's my advice, if you're in a position to take it. Start by asking the clinicians how computers could help them do their work more easily and effectively. Listen carefully. Map their insights to what the existing systems currently provide. If they do what they ought to do, a second conversation, in which you say, "I checked, and we can do what you said would be helpful to you. Let me show you how the system can make your life easier," should be productive.
If the systems don't do this, recognize that the doctors and nurses aren't being obstinate. They're being smart.
- Bob
Our company has a long history of lack of knowledge about project management. Many of the stories that are legend here harken back to a time when we were 1) much smaller, 2) most of our clients didn't care about project management, and 3) for those clients who did, the stories embody late nights and weekends getting things out the door for those awful people who didn't respect how much careful thought our work really took.
Having just read some advice about helping cultural change by emphasizing stories that feature the values and practices you'd like staff to adopt going forward, I'm at a loss as to how to make good project management exciting. Now we do have a number of projects here in any year that are in trouble, and have had some very successful "interventions," but those interventions aren't necessarily ones the project staff would like made public - "this project was really headed down the tubes until they started paying attention to project management!"
Anyway, any advice?
- PM Promoter
Dear Night-guy ...
You make an excellent point - communicating the value by holding up someone else's bad project as a poster child is bad form.
One popular strategy is to use statistics instead of anecdotes. While anecdotes have more persuasive power, statistics have the advantage of allowing the guilty to remain anonymous. I don't know where your company is in tracking project stats, though, and I suspect that for every failed project, there's another that squeaks through to "successful" completion through a combination of heroics, ingenuity, and redefinition of what "success" means.
Another is to start with one or two volunteers who are willing to try a new way of going about things, achieve success with them, and have them testify to the value of the new techniques to everyone else. In product terms, the organization will start with the pioneers, then persuade, in order, the early adopters, mainstream, and skeptics. The last hold-outs will either hold out until natural selection does its thing, or until they retire or are fired.
I don't know how to make good project management exciting, though. The whole point of it, after all, is to prevent excitement.
- Bob
In a recent Advice Line, ("Dealing with an autocratic change agent," May 31, 2006) the writer said, "...methodologies are waterfall.."
What does this phrase mean?
- Uninitiated
Dear Uninitiated ...
With luck, you're asking because you've never suffered through a project that used this sort of methodology.
Waterfall methodologies are those that progress in linear fashion through a series of stages - for example, Feasibility, Requirements, External Design, Program Specifications, Coding, Testing, Production.
The problem with waterfall methodologies is that they don't work all that well. Trying to create complete, perfect system specifications before you start any coding simply ensures you've wasted a bunch of effort, because once developers start coding, design flaws become evident and require that you revisit earlier stages.
Except that you can't, because that stage is complete and there's no budget for going back.
This isn't something that can be fixed by getting better at design and specification, because the more you try to design everything before you start coding anything, the longer the delay between requirements and production. That delay means some of the design "flaws" aren't flaws at all - they're changes that are the result of the future not looking exactly like the past.
It's the persistent failure of waterfall methodologies that has led to alternatives like prototyping, Agile, eXtreme, and Scrum - methodologies that use iterative techniques to allow project teams to "learn their way into" a highly usable design in small, manageable steps.
- Bob
This week's Keep the Joint Running ("Seven warning signs of bad architecture," June 5, 2006) was soooo timely! I did a presentation yesterday to a group of IT execs in our company where I recommended fixing a fundamental flaw in our data model, equivalent to the customer definition issues you described in your article. The question I got from the CIO was as follows: (Imagine him with a perplexed, pole axed look on his face when he asked): "Just how big an effort do you think it would be to implement these ideas? It seems to me it would be quite an undertaking."
The reason is because of all the "kludges" (your word, new to me, and I like it!) in our system today. For exercise and fun, I copied your example of the on-line clothing store, turned on revision tracking in Word and redlined in just one of the many examples of this kind of kludgy design we've got. I could hear my co-worker chuckling from the next office as she read my personalized version (which I doubt I'll share with the CIO)!
So, now for my question--What kind of wake-up call is necessary to change the "build a kludge fragile workaround" mentality to do the sometimes major redesign that will be required to fix all the old "solutions"? How does your advice play in the world of IT budgeting where there's almost always an incentive to "pay it later"? Will "later" ever come?
- De-kludger
Dear Dee ...
Very often, excess kludge accumulation (dare we coin the acronym "EKA"?) is one of the driving forces behind replacing legacy systems with an ERP suite. It's a chance to start clean - or at least as clean as the ERP suite's internal architecture; some are better than others.
It is relatively rare that a company decides to remediate its legacy systems once they suffer from EKA. Usually, by the time anyone is willing to acknowledge the problem, the hole is too deep to climb out of without a full system replacement. So the company either bites the bullet and does it, or it limps along as long as it can.
Or, it builds a data warehouse to provide a clean source of reporting truth. This doesn't fix anything in the transaction systems, of course, but at least managers can get reports without killing themselves.
So far as wake-up calls ... there are CIOs who recognize the importance of architecture and those who don't (usually the latter are the ones who bought the "CIOs need to be business people, not technology people" line). If yours were one of the former, your presentation would have been a wake-up call had one been needed. If yours isn't, several whacks by a 2x4 would be a minimum starting point.
At the risk of sounding like I'm trying to sell business, sometimes an outside consulting review can help get everyone's attention. This can only work, though, if someone with appropriate clout - usually either the CIO or someone the CIO reports to - wants an objective third-party to bring credibility to the issue. Otherwise it's just a waste of everyone's time and the company's money.
- Bob
Many years ago at an IT company I worked for, it had a mission statement that read...blah, blah...by maintaining a well educated work force...blah, bah. Our 5500 employee company fell on some slow times. I had planned on taking a class in the fall that the company agreed to pay previously. When I went to get them to sign off to pay for the course they refused, saying that the company was on hard times (paraphrasing of course).
I went and printed out the mission statement, highlighted the part about maintaining the educated work force. I talked to our director and assn't director till I was blue in the face to get them to pay. This was back when I was younger, single and had more gonads to do that kind of thing.
I think they admired my audacity. I never did get them to pay for it. My point - at my place the budget runs the mission statement. Kind of like mariage vows of until death do us part, unless we have financial troubles first.
- Mission driven
Dear Driven ...
Without having seen the company's financial statements I can't know one way or another, but it is possible you're being a bit harsh in your assessment. With all the best of intentions, companies still have to operate within the bounds of fiscal responsibility. Sometimes that means legitimate belt-tightening.
And sometimes, of course, it means using the budget as an excuse for being hypocritical.
One thing that does strike me: From your account, it appears your recollection of the Mission Statement is that the only item of substance in it was the educated workforce piece. Just my opinion: No company ever has "educated workforce" as part of its mission. Missions are about what the company exists to do. Maintaining an educated workforce might be, and often is, a very important aspect of how the company plans to achieve its mission, but that's a different matter entirely.
So I'm willing to bet the entire Mission Statement was severely lacking in meaning from start to finish.
- Bob
June 28, 2006 | Comments: (0)
Dear Bob ...Enough already! You've written a lot recently about good architecture and bad kludges. We all know that good architecture is important and that kludges are bad. That doesn't help very much without some practical advice for CIOs who want to encourage the former and discourage the latter.
What, exactly, should we be doing about it?
- Architecturally inclined
Dear Canted ...
The two best steps you can take (that I can think of right now, at least) are to (1) establish a core set of architectural principles, building an architecture review process into your applications methodologies; and (2) build code reviews into your applications and SQA (software quality assurance) methodologies as well.
Architectural principles are the core set of design standards that define good architecture in your company. The key to their success is to ground them in the realities of your situation. That means that "eliminate data redundancy except in the keys and backups" is a valid principle if you build everything, but meaningless if you buy when you can and build when you have to (another candidate architectural principle, by the way).
That's because, if you buy applications, of necessity you'll have the same data living in multiple applications, so you'll need a different principle to guide developers then: "Manage redundancy by establishing which data repository is the source of truth for each category of information, and using data synchronization techniques to coordinate the other repositories that contain the redundant versions of the same data." Or something - whataver is most appropriate for your company.
Application methodologies should include an "architecture impact statement" created by the software designers that feeds an architectural design review that precedes coding. They should also include a final architectural review built into the SQA process prior to roll-out.
The notion of having code reviews isn't new, and I trust requires no additional explanation.
The tricky part in all this is making sure the discipline of managing architecture doesn't turn into a bureaucratic tangle. It can easily happen. The best solution I know is to rotate developers into and out of this responsibility, rather than to create a permanent organization that can easily become an ivory tower.
- Bob
Posted by Bob Lewis on June 28, 2006 05:21 AM
June 27, 2006 | Comments: (0)
When you step into a kludge/Who or what do you go nudge?
Dear Bob ...I really enjoyed your article on kludges ("The Kludge Index," Keep the Joint Running, June 26, 2006). But I have a question: what do you do when you step in someone else's kludge? I'm a junior member on a team that's been kludging along for about a year and a half on a project.
I've been here for three months. I'm examing source code and finding comments like "DO NOT MODIFY UNDER PAIN OF MUTILATION OR A MONTH OF COFFEE DUTY" with no explanation about what the following block actually accomplishes. The system is a pieced together mess that hasn't been properly tested against any cases, let alone corner cases. Every time we try to use the system it's a labyrinth of steps involving way too many tools.
But of course, the people who have been here longer, the ones responsible for devoting so many company resources to developing the kludge, have a vested interest in NOT scrapping the thing and starting over. They can't admit that the work they've done so far needs to be thrown away. (In fact, they don't even really want to admit that it's a software development project that requires some kind (any kind!) of methodology...)
I'm "managing up" as much as I can (I just convinced everyone that we need to start using a revision control system) but is it really worth it?
- New kid on the block
Dear Newbie ...
The "right thing to do" depends on how the project is being managed. When we teach project management, one of the techniques we, along with just about everyone else, recommend is to maintain a formal list of project risks and issues. Part of project management is developing contingency plans for risks and making decisions about issues.
Generally, the project team reviews the list during the project's weekly status meeting. If this project is being managed that way, I'd recommend adding your concerns as a risk or issue and letting the process run its course.
Otherwise, you might consider sitting down with the project manager to inform him of your concerns, ask what the plan is for cleaning up the system's internals and otherwise moving it from proof-of-concept to a production-grade system, and accept whatever answer he gives you. In the end, it's his baby and you are the new kid on the block.
You'll have to use your judgment in deciding whether this would be a productive course of action or just get you labeled as a troublemaker. That depends entirely on the personality and competence of the project manager.
If your organization has a separate architecture group you might consider discreetly dropping a quiet word in the right ear. I don't love this approach, though. In some, politically ugly companies it's about the only thing you can do, but you end up getting a reputation for being a junior G-man, as it were, and very quickly, nobody is willing to trust you any more.
I'll also say this: My comment about hiding ugly code inside a "box" where nobody can see anything except its interfaces was sincere. Not all code is beautiful; sometimes the only way to accomplish the job is a nasty little hack that you hope nobody ever looks at very closely.
That shouldn't apply to a whole system, of course, but it usually does apply to a callable module or three.
Anyway, as junior team member your options are more limited than if you'd been around longer, so my last piece of advice is to remember that relationships outlive transactions. That is to say, know when to stop pushing the point. Even if you win every battle you fight (to pick an overly harsh metaphor), eventually you'll end up alienating so many people that you won't be able to win any battles at all.
I hope this helps.
- Bob
Posted by Bob Lewis on June 27, 2006 04:41 PM
June 24, 2006 | Comments: (0)
How to handle a too-influential outside consultant
Dear Bob ...I've been on my job for ten years as a one-man IT department -- official title is Systems Administrator. Been great, people are good, pay is reasonable, love my job. A year ago we were 'blessed' with a new management person, brought in to straighten out some operational shortcomings (almost entirely in other areas of the company, not mine). Our general business is financial, so we have operational issues, regulatory issues, compliance issues, and frankly we did need some re-organizing before we were hit on by hungry auditors.
But our new management person, after talking with me and finding I did not share their views about numerous things (including oursourcing), apparently decided that along with everyone else here, I was incompetent and clueless. I say this because I was cut out of all strategic decision-making relating to IT -- this person brought in a local IT engineering firm to do an audit of my department, but subsequently bought into a whole slew of services - hiring them to put in a new backup system (at outrageous prices), disaster recovery planning, inventory, and now appears even headed for giving them management duties. All of which happened without any input from me.
We now have a very expensive backup system that produces an end result not substantially different than what I was doing previously. We are almost no further along on our business continuity plan than we were before, and won't get there without another whole wheelbarrow full of money. A penetration test revealed no critical flaws in our security, the test of my new firewall was essentially perfect. All in all, we've spent a whole bunch of money, not accomplished much. And I still have no input into disaster recovery, business continuity, and any strategic planning.
Our CEO has the final say, but it appears to our employees that out of fear of being too far out of compliance, he has given this person total control over the company. And along with other employees, I'm frustrated and uncertain what to do. This new person seems obsessed with being in control; always has an answer for everything, even if wrong; can fly into a rage when questioned about a decision; and generally is seen as cold-hearted and ruthless. Most importantly to our staff, the person's HR skills seem to have been gained at the Marquis de Sade School of Business.
What to do? I'm well over 50, few certs to my name, and the question I've tossed over recently is whether to look for a different job or try to hang on long enough to outlast this person and hope life may return to normal?
In some ways, I know I'm just whining, but sign me,
- Frustrated
Dear Frustrated ...
The best course of action depends almost entirely on the quality of your relationship with the CEO.
If the two of you have a reasonably strong relationship I'd recommend handling this the straightforward way - sit down with him, point out that the consultant found no material weaknesses in IT and that the company is spending a more money on the externally supplied solutions and getting far less in return than it would get by hiring a second IT staff member. Also point out that since he (the CEO that is) has taken away your authority to make IT decisions and reassigned it to the consultant, you can't take responsibility for the results any more. (In the it-goes-without-saying department, prepare for the meeting with a list of specifics - all the subject areas where you were reviewed and your performance was found to be satisfactory.)
One other point you might consider making: There seems to be, to me at least, a strong possibility that the consultant is double-dipping - making money through referral fees received from the outside vendors. You might suggest that the CEO exercise the audit rights that are usually written into consulting contracts for just this reason.
If you don't have a strong relationship with the CEO, let me first just say ... why don't you? That's a big red warning sign. But if that is the case, you have a much more difficult challenge in front of you. Your first step is to thoroughly document the specific misdeeds of the outside consultant - dates, times, and facts. Do so until you think you have a compelling case that will demonstrate the harm being done to the company.
Then schedule a formal meeting with the CEO, lay it all out, and recommend that the consultant has outlived his or her usefulness.
Or ... if neither of these courses of action seem to have a good risk/reward ratio, keep your head down and just wait it out. There are some consultants who do develop permanent "positions" with their clients and whose "projects" become eternal. Usually, these are individuals whose advice and counsel have proven to be useful to the CEO, and so are engaged to be ongoing confidantes and advisors. Unless you think this will be the case with Mr. de Sade, gritting it out just might be your best course of action.
- Bob
Posted by Bob Lewis on June 24, 2006 08:52 AM
June 21, 2006 | Comments: (0)
Alternatives to the chain of command?
Dear Bob ...A semi-theoretical question about how to organize IT: Does the chain of command pyramid have an alternative? The best teams I've worked on were relatively flat and they were silent because everyone knew what they had to do. Maybe that just means that at a certain size, a flat model is no longer practical and the only known alternative is a chain of command hierarchy. Maybe there are companies out there that do have an alternative that they think works, dunno.
- Reorganizing
Dear Reorganizing ...
I've heard of lots of experiments, matrix management being the best known. In the end, they all seem to break down because there always comes a time when someone has to make a decision.
The question isn't whether you have a chain of command. The questions that matter are:
- How steep it is - how many layers separate the person at the top from the people at the bottom, and how many direct reports each layer has in between.
- How people view it - as a definition of what their job isn't, or as a description of everyone's primary focus.
- The philosophy of its construction - is it arranged functionally, by business segment, or in some other fashion.
- The extent to which leaders rely on it as an information conduit.
- Bob
Posted by Bob Lewis on June 21, 2006 07:27 AM
June 19, 2006 | Comments: (0)
In a comment posted on the kludging thread ("About kludging," June 14, 2006 and "Fixing an interface kludge ... or not," June 15, 2006) Stephen Bounds wrote:Since Kludging could (in theory) hire someone to write a single replacement for the two systems, this *has* to be seen as a workaround, doesn't it?
Which leads to an interesting question -- what's the difference between a kludge and an multi-step standard operating procedure like the above?
Is it documentation? Management approval?
A prohibitive price to build a system to avoid the kludge?
Unless we get some clear guidelines, Bob, it's beginning to seem like "kludge" = "SOP" much like "terrorist" = "freedom fighter".
Bounds makes a good point. It's all well and good to define a kludge as using a band-aid to attach a box to the side of the box that's affixed to the main system with chewing gum and duct tape, but that doesn't do much when the time comes to design a solution to a system problem.
I'll make a start here. Add your comments and I'll do what I can to turn the result into a future Keep the Joint Running.
- Kludginess isn't binary. There's a continuum that runs from elegant design at one extreme to Rube Goldberg at the other. The ideal would be to define a kludge index whose value ranges from, perhaps, 1 to 5. 1 is a thing of beauty and 5 is something you wouldn't want your mother to see.
- The more different technologies you include in a solution, the more of a kludge you've built. Solving a programming challenge with a combination of C++, Java, JavaScript and PERL is more of a kludge than solving the entire programming challenge in one language.
- The more steps required in the solution, the more of a kludge it is.
- The more fragile each step is in the solution (dependency on an exact data format is an example), the more of a kludge it is.
- Using tools to accomplish tasks for which they aren't designed or intended adds to the kludge index.
- If, when you diagram the solution, lots of lines have to cross each other, there's a pretty good chance you've designed a kludge.
I'm thinking in particular of some enterprise applications vendors that have extended their range through acquisitions, gluing the acquired pieces to their core system through middleware of some kind without ever harmonizing the underlying design assumptions. So long as it never becomes your problem, is it still a kludge?
- Bob
Posted by Bob Lewis on June 19, 2006 07:51 AM
June 15, 2006 | Comments: (0)
Fixing an interface kludge ... or not
Dear Bob ...I happen to have something like your first example (in "Seven warning signs of bad architecture," Keep the Joint Running, June 5, 2006): two dissimilar systems that need data transferred from one to the other. I've written a program that reads the data in the one system, massages it, and puts it in the other, but because the two systems are so different in function and data formats, I always have to go back after the fact and fix what the automatic system couldn't handle.
So what is the proper way to deal with a kludge like that? I'd like to say that we should just have one system, but unfortunately, we haven't found one system that handles the two different functions of our two existing systems. I could refactor my code and make it better, but I KNOW that some of the data transfer is something that only a human intelligence can handle (or else, I KNOW that I'm not a good enough programmer to write that intelligence.) What other options are there?
- Kludging
Dear Kludging ...
While they're generally pricey, you might want to look into one of the commercial ETL (extract, transform and load) software packages. It's what they're for, and you might find they're able to handle some of the tricky cases that currently require human intervention.
Either way, you're probably handling this as well is possible: Automatically handle what computers can do, and kick out an exception list so humans can intervene where the computers can't handle the situation. To me, this isn't a kludge - it's SOP.
- Bob
Posted by Bob Lewis on June 15, 2006 08:09 AM
June 14, 2006 | Comments: (0)
Bob ...Thanks for the recent KJR on architecture ("Seven warning signs of bad architecture," 6/5/2006).
I’d appreciate a more concrete explanation of why Kludges are bad (as a contingency were I to run into an ugly enterprise architect that chews gum)! I suspect that the reason might be very similar to the “too many interfaces� problem and you didn’t want to repeat it; in any event I need something non-IT executives can sink their teeth into.
Thanks!
- Blueprinter
Dear Blueprinter ...
Let's start with the nature of a kludge (or "kluge"; there are those who prefer to spell the word as it's pronounced; others delight that English spelling is, itself, a kludge): It's a Rube Goldberg-ish piece of work whose sole virtue is that it does work, more or less.
Kludges lead to two major problems. The first is that they're generally fragile, because they have too many moving parts. Change an input, fiddle with the data design of a core application and the kludge breaks.
The second problem is that they generally perform poorly, so scaling is a problem.
I'll illustrate the point by making up an example - an interface between two incompatible business applications. What I need to do is to extract data from one, reformat it, and pipe it into the second.
The first application only knows how to print reports, not how to output comma-delimited data (it's an old application). So I tell it to print the relevant report to a file.
Next, I open MS Word and record a macro that understands how to recognize and delete the page and column header text, a second macro that knows how to change the spaces that separate columns into commas, and a third that knows how to insert an opening and closing quotation mark around text fields. I also build an autoexecute macro so my data center can launch MS Word with a parameter and have it open the file, run the macros, and close MS Word again.
But I'm not done: Some of the data needs to be transformed in ways Word can't handle as easily as Excel - for example, parsing a name field into first and last names, or matching the first and second system's vendor numbers using a cross-reference table. So I next set up an Excel spreadsheet that can bring in the file, apply the relevant formulas, convert the formulas to values, and write out a comma delimited file for the second application to read and process.
I think you can see just how easy it would be to break this kludge. The slightest change to either of the main systems would do it. And in the meantime, if we're talking about data in any kind of volume, the length of time required to process the data translation is likely to be far longer than is desirable.
Or, use plumbing as a metaphor. If a pipe starts to leak, the first thing to do is to do whatever it takes to stop the leak. Use duct tape, use sheet metal and hose clamps, use whatever ... just stop the leak, because it doesn't take very much water to do serious damage, and small leaks turn into big leaks pretty quickly.
That doesn't mean that once you've stopped the leak that you're done. It means you now have the time to schedule maintenance to replace the section of pipe that leaked. If you don't, the patch won't hold. It isn't supposed to - it's a patch.
- Bob
Posted by Bob Lewis on June 14, 2006 08:28 AM
June 13, 2006 | Comments: (0)
Why doctors and nurses won't use IT
Dear Bob ...I've read and enjoyed your columns for years. I'm in healthcare IS and have recently changed jobs to being a consultant for a large, hospital software provider.
My question is whether you've had any experience in the healthcare market? Why I ask is that despite everyone from President Bush down saying more I.S. is needed in healthcare to solve all the problems (yeah right), my experience is that clinicians (nurses mostly but also doctors, x-ray folks, etc.) look at using a computer as an optional activity. "I'm not a computer person - I take care of patients!".
The feds and hospitals can spend 11 quadrillion dollars on hardware and software but if the intended user base refuses to use it, why bother? The healthcare I.S. rags I read are in agreement that healthcare is behind the curve on implementing useful systems - - well, no kidding. It is a difficult area to automate and the primary clinical users won't use it. And management makes no more than a token effort to "force" them to. I've always wondered why the need to "force" them exists.
Having spent my entire working career in healthcare, I can only imagine manufacturing, banking, whatever-not-healthcare, don't perceive using their systems as an option. Am I right? I have theories about why healthcare is different - a study waiting to happen. Now that I'm working with different clients, I've found this to be a universal problem in healthcare (although not one writers appear to be willing to write about.) What's your (always well thought out) opinion?
- In the field
Dear Fielder ...
My opinion might be well-thought-out, but that doesn't mean it's well informed. For all I know it's neither - I'll let you be the judge.
There are quite a few pieces to the problem. The first is intrinsic to the discipline: Human beings vary widely in the symptoms they display to the same diseases, and in their response to medicines. Different strains of the same disease also respond differently to medicines. The practical impact on the medical profession is that it isn't going to be turned into a set of well-defined processes any time soon. It's the distinction between a practice and a process, if you're familiar with that terminology: You put as much intelligence as possible into a process, reducing the level of sophistication required of the people who participate in it. In a practice, following the steps gives you a chance of success - it doesn't drive success.
IT is most successful when it participates in processes. The steps are well defined and it's possible to establish clear specifications for what IT is supposed to do. Supporting practices is harder because practitioners don't always know what they're going to need from the system until they get there. I'm pretty sure this is an issue with the medical trade, just as it is in law.
Another challenge is the "rock star" syndrome. Also as with law, doctors - and to a lesser extent, nurses - go through a very long and arduous training program before they're allowed to practice, and it has a significant rate of failure. Along the way, many doctors (and lawyers, along with celebrities of all stripes) end up with, shall we say, egos of a size that's a bit larger than is the case with most of us. The focal point is the practitioner, not the process or the enterprise, so avoiding this outcome requires a strength of character that not everyone has.
What's the outcome here? In a sense, it gets back to the point of optimization. Remember that to optimize the whole you have to suboptimize the parts. Doctors, lawyers (and other celebrity professions) are unlikely to accept suboptimization on their part for the greater good of the organization. The organization exists to support them, not the other way around. This makes enforcing the use of standardized technology more difficult.
A third factor that I suspect comes into play is what I'll call the SFA problem. SFA stands for Sales Force Automation. Perhaps the single biggest factor leading to SFA failure is that too many systems have focused on supporting sales force management and too few on supporting the selling process. While I'm entirely unencumbered by facts, it wouldn't surprise me in the least to find out that many medical information systems are designed to support medical administration, as opposed to being designed to support the practice of medicine. If that is the case, it's hardly surprising that doctors and nurses, given any chance at all, will ignore them.
They should: Their job is to practice good medicine. Sacrificing that to support better medical administration isn't something I want them to do when I'm their patient.
So here's my advice, if you're in a position to take it. Start by asking the clinicians how computers could help them do their work more easily and effectively. Listen carefully. Map their insights to what the existing systems currently provide. If they do what they ought to do, a second conversation, in which you say, "I checked, and we can do what you said would be helpful to you. Let me show you how the system can make your life easier," should be productive.
If the systems don't do this, recognize that the doctors and nurses aren't being obstinate. They're being smart.
- Bob
Posted by Bob Lewis on June 13, 2006 08:43 AM
June 09, 2006 | Comments: (0)
How to promote good project management
Dear Bob ...Our company has a long history of lack of knowledge about project management. Many of the stories that are legend here harken back to a time when we were 1) much smaller, 2) most of our clients didn't care about project management, and 3) for those clients who did, the stories embody late nights and weekends getting things out the door for those awful people who didn't respect how much careful thought our work really took.
Having just read some advice about helping cultural change by emphasizing stories that feature the values and practices you'd like staff to adopt going forward, I'm at a loss as to how to make good project management exciting. Now we do have a number of projects here in any year that are in trouble, and have had some very successful "interventions," but those interventions aren't necessarily ones the project staff would like made public - "this project was really headed down the tubes until they started paying attention to project management!"
Anyway, any advice?
- PM Promoter
Dear Night-guy ...
You make an excellent point - communicating the value by holding up someone else's bad project as a poster child is bad form.
One popular strategy is to use statistics instead of anecdotes. While anecdotes have more persuasive power, statistics have the advantage of allowing the guilty to remain anonymous. I don't know where your company is in tracking project stats, though, and I suspect that for every failed project, there's another that squeaks through to "successful" completion through a combination of heroics, ingenuity, and redefinition of what "success" means.
Another is to start with one or two volunteers who are willing to try a new way of going about things, achieve success with them, and have them testify to the value of the new techniques to everyone else. In product terms, the organization will start with the pioneers, then persuade, in order, the early adopters, mainstream, and skeptics. The last hold-outs will either hold out until natural selection does its thing, or until they retire or are fired.
I don't know how to make good project management exciting, though. The whole point of it, after all, is to prevent excitement.
- Bob
Posted by Bob Lewis on June 9, 2006 05:56 AM
June 07, 2006 | Comments: (0)
Dear Bob ...In a recent Advice Line, ("Dealing with an autocratic change agent," May 31, 2006) the writer said, "...methodologies are waterfall.."
What does this phrase mean?
- Uninitiated
Dear Uninitiated ...
With luck, you're asking because you've never suffered through a project that used this sort of methodology.
Waterfall methodologies are those that progress in linear fashion through a series of stages - for example, Feasibility, Requirements, External Design, Program Specifications, Coding, Testing, Production.
The problem with waterfall methodologies is that they don't work all that well. Trying to create complete, perfect system specifications before you start any coding simply ensures you've wasted a bunch of effort, because once developers start coding, design flaws become evident and require that you revisit earlier stages.
Except that you can't, because that stage is complete and there's no budget for going back.
This isn't something that can be fixed by getting better at design and specification, because the more you try to design everything before you start coding anything, the longer the delay between requirements and production. That delay means some of the design "flaws" aren't flaws at all - they're changes that are the result of the future not looking exactly like the past.
It's the persistent failure of waterfall methodologies that has led to alternatives like prototyping, Agile, eXtreme, and Scrum - methodologies that use iterative techniques to allow project teams to "learn their way into" a highly usable design in small, manageable steps.
- Bob
Posted by Bob Lewis on June 7, 2006 06:59 AM
June 06, 2006 | Comments: (0)
Getting a company to worry about kludges
Dear Bob ...This week's Keep the Joint Running ("Seven warning signs of bad architecture," June 5, 2006) was soooo timely! I did a presentation yesterday to a group of IT execs in our company where I recommended fixing a fundamental flaw in our data model, equivalent to the customer definition issues you described in your article. The question I got from the CIO was as follows: (Imagine him with a perplexed, pole axed look on his face when he asked): "Just how big an effort do you think it would be to implement these ideas? It seems to me it would be quite an undertaking."
The reason is because of all the "kludges" (your word, new to me, and I like it!) in our system today. For exercise and fun, I copied your example of the on-line clothing store, turned on revision tracking in Word and redlined in just one of the many examples of this kind of kludgy design we've got. I could hear my co-worker chuckling from the next office as she read my personalized version (which I doubt I'll share with the CIO)!
So, now for my question--What kind of wake-up call is necessary to change the "build a kludge fragile workaround" mentality to do the sometimes major redesign that will be required to fix all the old "solutions"? How does your advice play in the world of IT budgeting where there's almost always an incentive to "pay it later"? Will "later" ever come?
- De-kludger
Dear Dee ...
Very often, excess kludge accumulation (dare we coin the acronym "EKA"?) is one of the driving forces behind replacing legacy systems with an ERP suite. It's a chance to start clean - or at least as clean as the ERP suite's internal architecture; some are better than others.
It is relatively rare that a company decides to remediate its legacy systems once they suffer from EKA. Usually, by the time anyone is willing to acknowledge the problem, the hole is too deep to climb out of without a full system replacement. So the company either bites the bullet and does it, or it limps along as long as it can.
Or, it builds a data warehouse to provide a clean source of reporting truth. This doesn't fix anything in the transaction systems, of course, but at least managers can get reports without killing themselves.
So far as wake-up calls ... there are CIOs who recognize the importance of architecture and those who don't (usually the latter are the ones who bought the "CIOs need to be business people, not technology people" line). If yours were one of the former, your presentation would have been a wake-up call had one been needed. If yours isn't, several whacks by a 2x4 would be a minimum starting point.
At the risk of sounding like I'm trying to sell business, sometimes an outside consulting review can help get everyone's attention. This can only work, though, if someone with appropriate clout - usually either the CIO or someone the CIO reports to - wants an objective third-party to bring credibility to the issue. Otherwise it's just a waste of everyone's time and the company's money.
- Bob
Posted by Bob Lewis on June 6, 2006 01:53 PM
June 03, 2006 | Comments: (0)
Dear Bob ...Many years ago at an IT company I worked for, it had a mission statement that read...blah, blah...by maintaining a well educated work force...blah, bah. Our 5500 employee company fell on some slow times. I had planned on taking a class in the fall that the company agreed to pay previously. When I went to get them to sign off to pay for the course they refused, saying that the company was on hard times (paraphrasing of course).
I went and printed out the mission statement, highlighted the part about maintaining the educated work force. I talked to our director and assn't director till I was blue in the face to get them to pay. This was back when I was younger, single and had more gonads to do that kind of thing.
I think they admired my audacity. I never did get them to pay for it. My point - at my place the budget runs the mission statement. Kind of like mariage vows of until death do us part, unless we have financial troubles first.
- Mission driven
Dear Driven ...
Without having seen the company's financial statements I can't know one way or another, but it is possible you're being a bit harsh in your assessment. With all the best of intentions, companies still have to operate within the bounds of fiscal responsibility. Sometimes that means legitimate belt-tightening.
And sometimes, of course, it means using the budget as an excuse for being hypocritical.
One thing that does strike me: From your account, it appears your recollection of the Mission Statement is that the only item of substance in it was the educated workforce piece. Just my opinion: No company ever has "educated workforce" as part of its mission. Missions are about what the company exists to do. Maintaining an educated workforce might be, and often is, a very important aspect of how the company plans to achieve its mission, but that's a different matter entirely.
So I'm willing to bet the entire Mission Statement was severely lacking in meaning from start to finish.
- Bob
Posted by Bob Lewis on June 3, 2006 07:34 PM
|
Three books. Three ways to change the world, your life, or at least Bob Lewis' bank account. Leading IT: The Toughest Job in the World distills the world of IT leadership into eight learnable skills and gives you concrete, practical techniques for each one of them. Bare Bones Project Management: What you can't not do makes project management manageable, even for first-time project managers with no formal training in the discipline. ManagementSpeak: What managers say/What they mean … well, it won't help your career, and won't make you a better manager. Mostly, it will make you chuckle, guffaw, and maybe even chortle. Make friends - it's the perfect gift for anyone who has ever suffered through one of those meetings. Order your copies today! |
TOP STORIES
Microsoft's post-Yahoo optionsNet neutrality bill introduced
MS adds $3 million to Big Easy
AMD's Java improvement efforts
Leopard at 6 months
Intel still investing in WiMax
Yahoo tests aggregated search
Developers vs designers
Sun defends JavaFX Script
Botnet spams 60B a day
ADDITIONAL RESOURCES
- Virtualization: A Step by Step Approach to Success
- Dialing up Agility with Business Transformation
- 5 Things You Need to Know About Storage Virtualization
- Virtual Test Lab Automation: Manage development infrastructure
- Improve Resource Utilization and Lower Operating Costs
- Protect Your Data with SSL
