Applied Visual Studio Team System

Steve Jones makes some good points in his blog post Training. I find it difficult to believe the short-sightedness of some organizations when it comes to training events like the PASS Summit.

This year's Summit - like all previous years to date - had enough top notch presentations and labs to make it worth the cost of admission, travel and expenses, and the cost of allowing a database professional to leave work for three days combined. More than enough.

Like Steve, I don't get it.

Also like Steve, I bet we'll see these DBAs at the 2008 PASS Summit in Seattle - and working for another company.

I wonder if those responsible for denying database professionals opportunities for training factor in the cost of hiring and training a new DBA every six to eighteen months?

:{> Andy

Technorati Tags: EMPs Database Professionals PASS Training Changing Jobs

It occurs to me today that there are two types of IT managers: those who lead teams everyone wants to be on, and those who lead teams no one wants to be on.

:{> Andy

Technorati Tags: Management IT Leadership Team

Steve Jones has an(other) interesting editorial this morning in which he toyed with / proposed the idea of the government forcing Microsoft to release patches on some regular basis.

I like Steve a lot. We have a lot in common. We're both husbands and fathers. He's a Virginia boy like me and we both like database work. We haven't met, but we plan to meet at the PASS Summit in a couple weeks.

Meeting Steve face-to-face is something I'm looking forward to.

Mostly I agree with Steve's editorials. I read them every day they are published. They are a cool part of my morning routine. I strongly disagree with the idea of any government involvement in industry - period - and stated as much in a response to Steve's words.

I'm not here to beat a dead horse. We may disagree with how to fix the issue of delayed and poorly tested service packs, but we agree they're a problem for us and our clients.

What I find fascinating about the idea and exchange is this: This is exactly how good organizations go bad. Allow me to explain:

A couple months back, I posted Gatekeeper or Roadblock? Part 2 in which I rambled about an (hypothetical) evil conspiracy between a network admin and an executive. Most scenarios of good organizations going bad lack the level of intentionality or malice described therein. Some do, but most don't. What happens to those lacking malice? How do they go bad?

I'm glad you asked.

Normal day-to-day business issues arise. And they are responded to poorly.

What do I mean by "responded to poorly"? I mean companies mired, tangled, and snarled in bureaucracy didn't get there overnight. It's a slippery slope if ever there was one. And it begins innocently enough: with a business need.

The simplest, most elegant solution appears out of nowhere: just create a tiny teentsy-weentsy bit of bureaucracy - no one will mind and few will even notice. Look at all the good that will come out of it. How can this be wrong and bad when it will create so much good? That's the logic.

And the djin escapes.

Somewhere, someone senses satisfaction. Things are finally clicking into place. Making sense. Order is evolving out of chaos. Resources are being managed. Good is arriving.

Then there's that pesky physics and nature of the universe stuff. Equal and opposite reactions, unintended consequences and the like. What of them?

Sadly, they too follow.

Bureaucracy is a creativity-killer.

Please do not take my word for it. Read every classic on industry in print. Good to Great, The Executive in Action, First Break All The Rules, The Mythical Man-Month - I could go on, but you get the picture.

Stifle innovation - especially in the software industry - and you are months away from corporate death or worse "re-organization", "re-branding" or just plain old-fashioned "re-hemorrhaging-talent".

It's not this way because Andy says it's this way. This is just the way it is. You don't have to like it or even like me saying it, but you do have to deal with it. It's right up there with E=mc^2.

Nature abhors a vacuum. You step (or worse, lead your company) out of the path of innovation and it's merely a matter of time.

Pretty grim? Yep. Accurate? Yep.

So what's the solution?

I'm really glad you asked!

There are two possible solutions:

• Build a time machine. Travel back to when you first thought of the bureaucratic idea. Scream into your own ear "THIS IS A BAD IDEA!" If that fails to work, try to occupy the same space at different times, thus annihilating yourself before you destroy something so cool.
• Stop. Go back. Turn around. Return to the older way. Do so as quickly as possible, with humility, and making all necessary apologies.

Both of these suggestions are equally likely to occur in the experience of a bureaucrat. One of them sounds ludicrous - the other violates our current understanding of the laws of time and space.

To me it's pretty clear. You don't call the IRS and ask them if you paid enough taxes last year and you don't invite bureaucracy.

Democracy is inherently sloppy. It resembles herding snakes down an interstate with a cane fishing pole. Does this mean chaos is good? Not if it's simply chaos for chaos' sake.

Freedom is good... and just happens to be chaotic.

Don't take my word for any of this. Ask the Xerox executives that successfully marketed all the cool technology produced by PARC.

:{> Andy

Technorati Tags: bureaucracy government regulation

I received an interesting email a few days back. The sender isn't important - the text is:

Hi ,
I am interested in purchasing textlink advertising on your website Let me know if you are interested and we can discuss further details. I can make a good offer to make it worth your time.

Let me know!

Thanks

No one had ever asked about advertising on VSTeamSystemCentral.com before, so I responded positively.

The conversation took a couple odd turns - enough to raise red flags.

I eventually refused politely, and then not so politely (begging, the final red flag). Compare the message I received to the one received by the blogger at phillsacre.me.uk. Again, I had a different name, but the same pattern of email domains - for me first it was Yahoo, then Gmail.

I'm not sure what these folks are up to but after the problems suffered by job boards last week, I'm sticking with the Google Ads for a while.

:{> Andy

Technorati Tags: textlink advertising your website bloggers tech

My daughter Penny started a blog: From the Help Desk!

I love the first entry, and not just because I'm in it. :)

Penny stopped by this weekend to meet her new brother Riley Cooper and we got some cool pictures. My favorite is below!

From left to right there's Stevie Ray, Penny, Emma Grace up top (aka "Mini-Penny" - she looks just like Penny when Penny was 2), and Riley Cooper with his I-love-my-big-sister face (also seen here).

Congrats on the new blog Penny!

:{> Andy

Technorati Tags: Help Desk Work Ethic Penny Trupe

I was recently reminded how lucky I am.

It's true, pure luck has played an important role in my life, defining where I am today personally and professionally. Well, maybe not an important role, but it's been there.

How?

Mostly in the form of opportunities. But I then had to act on these opportunities to get the most out of them.

This is starting to remind me of a joke a pastor once told:

A local minister rides out to visit Farmer Brown one fine summer day. As he pulls off the main road onto Farmer Brown's acreage, he admires the tall corn and plush rows of tomatoes and beans. When he greets the old farmer, the minister says "You and the Lord are running a fine farm here!" To which Farmer Brown replies "You should've seen it when the Lord was running it Himself."

I can show a direct correlation between the number of 75-hour weeks I work and how lucky I am.

I can also demonstrate an inverse proportion between the number of mornings I awake completely rested and how lucky I am; as well as a positive ratio of 20-hour days / "luckiness".

So yep, I'm a pretty lucky guy.

:{> Andy

Technorati Tags:

My sister-in-law recently passed the PMP certification (congratulations Heather!). I'm waiting for a call from her asking if we need to add resources.

The resources comment above is a joke, but it isn't really that funny. It's indicative of my decades of experience with bad IT project managers.

I believe and hope I have worked with some of the worst project managers on the planet. Why do I hope? I'd hate to think anyone has had to deal with folks worse than the poor project managers I've dealt with.

As I type, we're experiencing a heat wave in Farmville, Virginia. It was 107 degrees Fahrenheit here yesterday. It's the "dog days of summer", as my Granny used to call them.

Somehwere, you will find 30 or more push mowers lined up wheel-to-wheel along one axis of a lawn. On command, the 30+ operators will start their mowers. On cue, they will push them across the lawn, maintaining the wheel-to-wheel alignment, cutting the entire area in one pass.

This, my friend, is the home of an IT project manager.

My experiences have led me to a couple thoughts:

• Frederick Brook's The Mythical Man-Month should be required reading for all project managers.
• Proof of callouses should be required for the application process.

(The same can be said for MBAs, but that's for another post...)

Inspired by the book, Brook's Law states "Adding manpower to a late software project makes it later." It is perhaps best summed up by the following statement by Brooks himself: "The bearing of a child takes nine months, no matter how many women are assigned."

As an IT professional, you can learn to detect when you're about to be "managed". I share the following indicators and advice from my years of experience:

"Do we need to add more resources?" This question in and of itself is harmless. It's actually the way project managers greet each other and has no more meaning to ordinary folk than "How are you doing today?" or "How about this weather?"

The best answer to this question is a non-answer. After years of trying to correctly answer this (as though it were a meaningful question), I stumbled across an answer that works for me: "I don't know." Why does this work so well? The last thing a bad IT project manager wants to do is make a decision - at least one traceable to them.

"I am (or used-to-be) a software developer." If you hear this, you're in trouble. Big, big trouble. My advice to you is to vacate the project - and the premises - as quickly as possible. This isn't a fire evacuation, it's a bomb evacuation. You may wish to consider jumping out a window if you're on or below the third floor.

Why? You are dealing with a person who believes they were promoted because they were such a good developer. Mind you, this is true in less than 25% of my experience. And even then, odds are their resume includes COBOL or they aren't nearly the project manager they believe themselves to be. At best you have 1/3rd of a 25% chance that you're working for someone who knows a definition for delegate - a definition that isn't "someone who attends a convention."

The truth of the matter is this person was likely promoted before they could delay or otherwise further damage the software project to which they were assigned.

"What do I tell my boss (or the stakeholders)?" This question is the prelude to a demand. Your answer isn't important, the demand in the mind of the IT project manager is important. And that demand is for you to do something no sane developer would ever do.

There are a couple options. If you're feeling froggy, you can document the fact you were asked to take this ridiculous course of action by your IT project manager, and then do it. Be sure to address the issue in writing and as soon as possible. CC someone else - anyone else. If you can CC the project managers' boss without looking like you're trying to make them look stupid, that's best. If not, CC someone else at your level on the development team (and allow the bad IT project manager to continue their work of making themselves look stupid unassisted).

Note: Never BCC. BCC'ing the boss is the equivalent of placing a bold, red, flashing banner across the top of your message which states "I'M INSECURE". The boss will get this message, loud and clear. Go ahead and CC them if you believe it's warranted - those dogs need to wake up eventually.

Make sure it's in writing and someone else sees it - that's the point.

The other option is to simply ignore it and do what you know to be right and good. There's risk here too. Some bad IT project managers will call in bigger dogs to shout you down. It's good to have your mugshot and name on a book somewhere if you're going to exercise this option.

"Umm yeah. I'm going to need you to come in Saturday. Sunday's not looking good either..." People are people. Bad IT project managers don't get that. They call people "resources". People aren't resources, we use resources, but we're separate and distinct from resources. People are people.

Bad IT project managers are the reason we have IT Project Leads. After all, someone who knows what they're talking about needs to have some authority if any software project is to stand a chance of succeeding.

:{> Andy

PS - This post inspired a new category at Applied Team System: Expensive Management Practices - gotta love the acronym. :{>

Technorati Tags: Project Management IT Software Development

The same can be said for database development.

Scaling forces iteration.

Voilà

This is how solutions mature - be they applications, databases, or both - regardless of who writes them or how many are involved in the development effort. It doesn't matter if the development team is one lady in a cubicle in the European Union or a development team of thousands at Microsoft.

Iteration matures software.

:{> Andy

I am sometimes accused of sucking up but the truth is I'm just a nice guy who likes to compliment folks when they do a good job. Most of those folks are my peers, some of them happen to be supervisory, and that's when the accusations flow.

So be it. News flash: I didn't start complimenting folks because you commented about it. Can you complete this thought? ;)

In his post entitled Etiquette Rule #1 - Don't be a Sycophant Rob Caron quotes a Redmond Channel Partner Online piece on Microsoft Partner etiquette.

I've had interaction with Microsoft folks and this doesn't match my experience. Rob's response matches my experience instead, where he says :

If you use a competing product, I'd rather understand what our gaffe was that made it the more attractive choice. What could we do better to earn your business next time?
If you think one of our products sucks, please tell me why. What can we do to keep your business?

:{> Andy

Technorati Tags: Sucking up sycophant Rob Caron etiquette

Over a year ago I wrote a post entitled Gatekeeper or Roadblock?

At the time I was working as a Production and Development DBA for a small shop. People would show up with requests that sounded legitmate to me. Usually these requests would take 30 minutes of my time and provide data to an individual or team that they could use to continue their work for days or weeks.

But the oddest thing would happen. My boss would happen by and ask what I was working on. When I told my boss what I was working on, my boss would inevitably frown. Then my boss would look cross and say something akin to "You should not be doing that for him / them." You may think I'm exagerrating, but I assure you I am not.

Hence the post.

Fast forward some...

I'm doing some consulting for a large-ish IT team for a large-ish company. Team members can't find things. They cannot connect remotely to work from home or while on vacation or away for training or business trips. A lot of stuff that Just Works at most IT departments simply doesn't work here. And no one can figure out why.

As a result, the IT department morale is dropping faster than the Congressional approval numbers because no one can get away from the office for more than a fraction of a weekend. Talented people have been recruited and paid an excellent salary with excellent benefits (including lots of unused vacation). These folks stick around for six months or so and then leave - often for equal or less pay and benefits.

Word is getting out on this place locally. Recruiting efforts are moving farther and farther away.

Network performance is awesome, but very little is actually able to run on the network due to "security policies" (hence the stellar performance). The network department consists of Bill and his very-high-turnover network engineering staff.

Bill's been with the company for years. If you ask him, he'll tell you he "keeps things running around here" and "doesn't know what those colleges are teaching kids these days - none of 'em are worth a tinker's damn."

A long time ago, Bill cobbled together a solution that exceeded management's expectations. He saved the company hundreds of thousands of dollars in consulting and implementation costs. His network did everything those high-falootin' college brats said there's would do, and it didn't cost the company anything other than what they were going to pay Bill anyway. "Just doin' my job," Bill answered when asked about it by an executive. The executive was so impressed, he basically promised Bill a job for as long as he wanted to work there.

Now.

The system Bill put in place did, in fact, meet the immediate needs of the company. And it didn't cost as much as the consultant-proposed system.

But it also won't scale. At all. Ever.

Bill's learned this. He's tried to make it do more, but the system simply won't.

Bill has a few options.

• He could go to training, learn about building scalable systems, and implement a better version of his solution. After all, everyone knows you need to spend 25% of your time training in IT just to keep up.
• He could hire people with more recent experience and work with them to build a better version.
• He could admit that although he thought his solution was better for the company, it was really just a short-term patch and they should've implemented the consultant's solution instead of his.

Ok, I put that last one in there to see if you were paying attention.

Instead, Bill has locked down the network so every possible wavelength of bandwidth is available for his out-scaled solution. He doesn't need training, he has tenure. A guarantee. He still has an executive's ear - an executive he helped get promoted by saving all that money all those years ago - an executive who both owes him and cannot afford to have the truth come out.

As new people rotate into the department and get close to discovering the issues with Bill's outdated solution that won't scale, they're summarily dismissed. The executive backs his every move. "Bill knows what he's doing. These kids obviously don't."

And so, things do not change.

Except - all things change eventually.

In this case, the company's marketshare dips to an all-time low as productivity remains steady at a 1998 level for Bill's company - while the competition begins gaining marketshare using systems that scale.

When rivals reach the same marketshare, executives muse "they're topped out now!" and wait for the inevitable. After all, if their system won't scale beyond this point, no one's will. Right?

And then the competition's system does continue to scale. And in a few years Bill's company is bought out by their competition and the innovative IT department of the purchasing firm curses Bill's old system as they try to work through the hacks to get at something that resembles business rules.

In the end, I suppose the executive and Bill both parachute out into the business world, seeking another hapless company to victimize. They're richer, no wiser, and have left talent-devastation in their wake as they unceremoniously ended, wrecked, or disillusioned dozens of careers.

What a depressing post! For a good laugh, you have to go here and read the post and comments - very funny.

:{> Andy

Technorati Tags: Gatekeeper Roadblock A sad sad tale

In business, enemies are expensive.

I'm not talking about competition here. I'm talking about enemies. Competition is actually good for you for a number of reasons including:

• Competition indicates a market exists. Lots of folks think "No one else is in this market - I'll own it!" Unless your idea / service / product is truly innovative, there's a good reason for the lack of competition: there's no money in it. Always ask yourself "Am I the first person to think of this?"
• Competition keeps you on your toes by pushing you to excellence. If you don't satisfy, someone else will. That's powerful motivation.

An obvious enemy-related expense is lost business. If you tick someone off they will not likely use your service or product again.

But there are hidden costs as well. For instance, bad news travels much faster and farther than good news. Don't take my word for it - check out your local evening news. Very little good news is reported. Do one person / company wrong in a single business transaction, and it will follow the remainder of your career.

This is why I don't get the ethics scandals. Maybe I'm missing something but the risks of these schemes seem to far outweigh the rewards. Each time I hear of a new blatant, intentional ethical violation I wonder aloud "What were they thinking?"

There's also collateral damage to business enemies and sometimes it can turn around and bite the offended - again. How? Whenever you badmouth someone who treated you wrong, you are gambling that the person you're talking about will never do anything positive and meaningful for the person you are talking to - forever. Forever is a long time. Things change, stuff happens. Are you willing to take that risk?

Also, when you badmouth you're demonstrating you're the type of person who will talk trash about someone with whom you disagree. Odds are someone else will disagree with you in the future. Are potential clients willing to take the chance you will be happy enough with the outcome of your dealings to not impugn their reputation? Put another way: Is there anyone else they can hire who won't talk smack about them should things come out less than equitable for all parties?

It comes down to professionalism.

Everyone looks like a professional when the gig goes your way, you get plenty of recognition, paid more and/or earlier than anticipated or agreed upon. It's not hard to shake hands, pat folks on the back, give credit to those who helped, and genuinely thank those involved for the opportunity... when all goes well.

When things fly apart mid-project, when threats begin, when you start ignoring your email and silencing your cell phone without answering; when your subconscience sounds like a black-and-white World War II submarine naval movie in a scene where the sub is about to dive and is sounding the klaxon... that's the darkness where the brightest lights shine the most.

There's another word for these dim times: opportunity.

You have an opporunity to turn the project around. I am a firm believer that all projects-in-peril can be turned around. It is a sheer matter of will to do so.

The momentum gained by a project climbing out of the Pit of Despair can propel a business relationship to a completely new level, and, if you engineer such a turnaround, you will demonstrate your professionalism beyond dispute.

I know, I've seen it happen.

In conclusion, there are hidden costs to making enemies in business, and there is hidden profit in putting potential enemies in the friend column.

:{> Andy

Technorati Tags: Business Enemies Cost

Yesterday, I addressed Technologists regarding Project Success; today I address Stake-holders.

I have participated in projects that have succeeded and in projects that have failed. One thing I noticed about the failed projects: expectations were poorly - or not - managed.

What are examples of project expectations?

• Functionality - when completed, the application / upgrade / database / server will allow me to perform xyz.
• Time - how much time one expects to develop the functionality. Can also include a schedule for deliverables and / or milestones.
• Expense - how much one expects to pay for the functionality.

As a stake-holder you know what you want. And you can probably communicate your expectations - using the three areas above as a guide - effectively. Issues arise when, for whatever reasons, there is a disconnect between your expectations and the those of the IT team tasked with performing the work.

I've witnessed several unsuccessful executive responses to the disconnect scenario:

• "Ostritch" - ignoring the disconnect in hopes it will disappear with time.
• "Gambler" - belief that there's a big score (project or technical break-through) just-around-the-corner that will save the day.
• "Taskmaster" - belief that threatening people is the way to motivate them to work around challenges.
• "More-Resources" - a firm belief that more resources can solve any problem known to humanity. (I often imagine these folks live in subdivisions and get their neighbors to help mow their lawns. In my mind I see forty push-mowers aligned wheel-to-wheel along one edge of a lawn. On signal, they all puch across the lawn, mowing it from end to end in a single pass...)

I worked for a company that decided to employ Performance-Based Management techniques to a successful team. They actually applied the concept company-wide, regardless of whether the teams were successful or not. In this particular flavor of PBO, 20% of employees were considered outstanding, 60% were satisfactory, and 20% were acceptable losses that the company would be better without. These numbers were set in stone and never changed.

So what is the solution?

Communication.

It's that simple. Executives have to either be approachable by the IT team or someone representing them, or you must appoint someone to be approachable in your stead. Leadership dynamics (or just plain scheduling issues) may require you to appoint someone. If so, try to find someone who speaks both business and technology.

Realize that sometimes you do not know what you do not know. I run a couple small corporations and have an appreciation for the amount of work involved in merely administering such an entity. I also know technology changes every day. It's difficult for anyone to keep up - especially if you're minding stock-holders, regulators, and the lot. We may have moved beyond the technology you understand. If we haven't, we will soon.

Either hire people you trust or trust the people you hire. If someone violates the trust, respond accordingly. But do everything within your power to exude trust-worthiness as well as trusting-ness.

For truly innovative people to be free to succeed, they must first be free to fail.

The best tools were once toys. IT professionals are notorious tinkerers. You will be astonished at the return on investment for a weekly-scheduled hour of "play time" for developers.

:{> Andy

Technorati Tags: Software projects Success Failure Technologists

There was a very interesting article posted not long ago at SQL Server Central by Janet Wong entitled My Projects Have Never Failed.

In the article, the author explains projects that experienced varying degrees of success for various reasons - but in all cases a disconnect existed between the end-user or customer expectations and the delivered product.

Personally, I consider these projects failures.

Here's why: The stake-holder or executive has this expectation. It may be very unrealistic, but they hold it nonetheless. They may be very educated people or not. They may understand technology or not. None of this impacts the fact that they hold expectations.

Q: Who's in charge of communicating realistic expectations?

A: Technology people.

Or at least a member of the technology team.

A good technology team has several moving parts and people fulfilling different roles.
Note: If you're a one-person-show, this post is not about you.

At least one person on the team needs to be customer-facing. That person needs to be an expert in communicating with business people who hold unrealistic expectations. Make no mistake: this is a talent and an art.

Good communicators are rare in life, rarer in business, and practically extinct in the technology sector. Most good communicators abandoned IT departments decades ago and moved into sales where they could enjoy salaries orders of magnitude beyond what IT departments will pay them. But I digress...

I don't blame my customers when their expectations go unmet - I blame myself. Had I communicated something better - or even differently - the outcome would likely have been better for everyone.

So here are some tips for communicating with project stake-holders / executives:

• You may understand what you mean when you say "Third-Normal Form Relational Database" at a meeting with executives, but few of them will. It's not their job to understand - that's why they're paying you. Step up. If you cannot translate your conversation into executive-speak, let someone else do the talking. If your point is to embarrass the executives, you'll probably not try that at your next job.
• Identify someone on your team (or add someone to your team) to serve as a point-of-contact to the executives. If your team has a project manager, they may be the best person to do this. I've also seen horrible project managers who exacerbate the problem with their own inability to communicate (or worse yet, take the side of the stake-holders and hang the development team out to dry).
• Keep it short.
• Keep it as simple as possible. Stake-holders and executives do not need to know the history of iterations you went through to arrive at your conclusion. Take it as a sign of confidence in your abilities that they accept your judgment on the matter.
• Stake-holders and executives have different priorities from you and I technology people - remember that.
• If you deliver quality late, no one remembers. If you deliver junk on time and under budget, no one forgets.
• The old consulting axiom ever applies: Under-promise, over-deliver.

This is business. This isn't academia; you do not get to interpret your own results.

It's not a success unless they believe it to be a success.

Me, I've had projects fail. Some of them have been spectacular in the scope of their failure. To date, I've stepped up, admitted the failed status of the project along with my errors, and promptly moved to correct the issues. I've found excuses to be a waste of my and my customer's time.

Having a project fail is bad enough; failing to manage the failure takes it to the next level.

Remember, if you fix it, it will be ok.

Tomorrow, I address Stake-holders.

:{> Andy

Technorati Tags: Software projects Success Failure Technologists

If you have any interest in User Interfaces, you must watch this video - immediately.

Microsoft unveils Surface, a coffee-table shaped computer with some unique UI characteristics. The coolest of these is the ability to respond to multiple "touches" simultaneously.

The obvious question is: How long before this screen technology makes its way to other touch-based devices (handhelds and tablets)?

:{> Andy

Technorati Tags: Microsoft Surface coffee-table computer GUI User Interface

Yesterday I wrote about The Thing You Cannot Touch. Today I'm going to tell you some ways to manage the situation.

First, try to determine why You Cannot Touch The Thing. This is invaluable information in charting the waters ahead - especially if you're consulting.

Second, accept the fact that there's better than a 90% chance that you will not, in fact, be allowed to Touch The Thing. In my experience, three things must be true for you to overcome the business friction imposed by The Thing:

• You have to try everything else first.
• Everything else must fail to sufficiently address the issue.
• The source of the issue must be mission-critical.

Regardless, your best knee-jerk reaction is acceptance. This is tough for a professional. In your heart of hearts you know what it takes to solve the real issue. And yet, you've been told You Cannot Touch It.

The good news? There's also a better than 90% chance you can find a way to solve the issue - or at least alleviate the client's pain - without Touching The Thing.

Modern enterprise applications are comprised of lots of moving parts. The Thing is probably not the sole source of pain. Addressing other bottlenecks may do the trick - at least for now.

And, if you're the person they called last time they had an issue and you solved it (and weren't "difficult" to work with), you'll likely get the call next time.

How cool is that?

:{> Andy

I have this theory about consulting. I call it The Thing You Cannot Touch. Since a few friends have found it amusing I thought I'd share. It goes like this:

A potential client contacts your firm. A conference call is arranged to discuss the issue. During the call, the issue is defined. Resolution theories and attempts to date are shared, along with their results. The current status is explained - along with

The Thing You Cannot Touch.

Sometimes an attempt at justification accompanies the announcement: "We know it can't possibly be _______ so we're not going to waste any time looking at it."

Other times, it's just put out there for what it is: "You can't touch _______."

My experience has shown the heart of the issue almost always lies with The Thing You Cannot Touch. It needs to be fixed but someone, somewhere, for some reason does not believe it to be so - and so it Cannot Be Touched.

Sometimes it's political - It's someone's "baby". They built this application just ten short years ago - worked nights and weekends and toiled and sweated and bled to make it work - and rode it all the way to CIO, after all. Who are you, lowly consultant, to tell them VB 6 code should be re-written in this new fad known as .Net? Doesn't Vista support VB 6 until the mid-20-teens?

Sometimes the decision-maker doesn't understand the differences in the technologies.

Sometimes it's a purely market-driven business decision - and the decision-maker is right and justified in choosing to keep hands off The Thing. It's not all about technology folks... it's sometimes about what I like to describe as the (little "s") software (big "B") Business.

If you find yourself on a consulting conference call and The Thing You Cannot Touch comes up, pay attention. Tomorrow I tell you how to Manage The Thing You Cannot Touch.

:{> Andy

Technorati Tags: Consulting Software Development Thing You Cannot Touch Old Code Outdated Code VB 6

Eric Sink has a great post about Requirements.

I particularly like the way he covers Missing Requirements and Anti-Requirements. Very informative and true to life.

:{> Andy

Technorati Tags: Eric Sink Requirements Project Management

A couple more interesting tidbits to file under "On the Software Business" came in yesterday. One from a friend we'll call "Joe", another from another person we'll call "Mary".

These are their stories...

Joe's an expert in his field. Joe worked for a company last year and received an invitiation to a conference in his area of expertise. He also received free admission. He's that good.

Joe decided to pay his own airfare and hotel out of pocket - and this wasn't cheap. He attended and learned cool stuff, which he planned to implement in a new practice at his place of employ.

But when Joe was attending the conference, all heck broke out back at the office. Crises - some real, others imagined - had folks peppering Joe with all sorts of emails and demands for his immediate response. Joe did the best he could. When one crisis arose, Joe even responded from inside the convention hall from a digitized device using handwriting.

This caused a ruckus at the office. Folks accused him of being unprofessional. It got worse from there. But the gist of the entire matter is Joe found another job and moved on.

Fast forward one year: Joe is speaking at the same conference this year. And not only is his (new) office supporting him, they're actually congratulating him and wishing him well. They're proud to have someone of Joe's caliber working for them. They realize Joe can bring in business on reputation alone, and they're willing to encourage him to attend.

Granted, I am over-simplifying (and obfuscating) the facts to make a point. Two points actually. To be clear my points are: Some businesses don't know how to market industry recognition; and some companies do not understand the return on investment of happy employees - especially if said employees are over-achievers (or experts in their field).

Mary is a supervisor at a technical services company. She's sometimes asked to go above and beyond the call of duty, and regularly complies with these requests.

She's been promised a promotion for months now, but no promotion has materialized. When she asked about it a couple months ago, she was promised she'd be allowed to go to training - something she's applied for in the past.

It's been months and Mary is the only person concerned about the promotion or the training opportunity. When she asks about it, she's told "Yes, yes - we will get to that." But it hasn't happened yet. Mary's beginning to suspect it never will.

She regularly does the work of co-workers / managers who then turn in her work as their own. Mary's getting ticked and looking for another job.

It's likely, when Mary turns in her resignation, that she will be asked "Why are you leaving?" by the people denying her requests, taking her for granted, and taking credit for her work. Why would anyone want to leave that job?

And so I ask you, dear Reader, why do companies treat individuals like this? What possible benefit could managers derive from such petty dictatorship? Perhaps Scott Adams has the answer...

:{| Andy

Technorati Tags:

This post is definitely in the category: "On the software business." It's about lessons I've learned the hard way.

There are times when an email demands an immediate response. Servers are down, important files are inaccessible, the business is hemorrhaging cash. It's times such as these that separate the professionals from the crowd.

How does the professional handle these situations? I like Douglas Adams' advice: Don't panic.

If you panic, you now have at least two problems to manage: the original issue and your emotional state.

Panic will cause knees to jerk and later-regrettable emails to be sent. Always remember: You cannot UnSend email.

:{> Andy

Technorati Tags: Software Business email panic

Brian Lanham writes about Code Quality in a recent post. Brian makes several good points about the software business - it's well worth a read.

Brian is one of the authors of MCPD Self-Paced Training Kit (Exams 70-536, 70-528, 70-547): Microsoft .NET Framework Web Developer Core Requirements.

:{> Andy

Technorati Tags: Software Business Brian C. Lanham Code Quality

A few months back we decided to incorporate Richmond User Groups as a not-for-profit. We changed the structure of the Richmond User Groups to a sponsored model after careful consideration and a bunch of planning. It worked out well for us and most of the community. Now we're more flexible and scalable, and it isn't such a pain to manage leadership changes.

One of the things every corporation needs - whether it's for-profit or not - is a bank account. But I had a problem: I wanted to start the account, then use money from the account to form the corporation - sort of a cart-before-the-horse scenario. Since I'd been doing business with this one particular national bank for five years, I waltzed into the local branch here in Farmville, explained my situation, and asked them what I needed to start an account.

They told me I needed a tax id number, or Federal Employer Identification Number (FEIN). So I went online and found I was able to submit a Form SS-4 online prior to actually incorporating. How cool! Things were moving now.

I went back to the bank branch the next day with paperwork in hand all ready to open that account. I was then told I needed articles of incorporation.

Now, I don't mind providing a bunch of stuff to get things going. I do mind not getting a complete list of what's required up front.

I called customer support - a centralized service of this large institution. I was told by customer service I could open an personal account in my name, incorporate the business, then convert that account to a corporate account. I'm not a banker, I believed them.

Allow me to shorten the story some here by saying that the previous statement was also inaccurate.

So I went with the competition to open the not-for-profit account for the Richmond User Groups Corporation. It took less than an hour with my Tax ID number. I showed up two weeks later with official articles of incoporation and everyone has been happy as clams ever since.

I also opened my new business accounts with the competing bank. They were just as helpful and I even scored two free personal checking accounts and a free safety deposit box - very cool indeed. Thank you Wachovia.

So today I waltz back into my old local branch to close out a savings account and checking account I haven't used in several months. The savings account is actually in the red $14.99 due to monthly service fees. They ask why I'm closing the account and I tell them - politely.

Now at this point there's an opportunity for some customer service. I'm sending all the signals that I'm about to sever my relationship with this institution. The response?

I was asked to pony up the $14.99 before I could close the Bank of America savings account I hadn't touched in several months.

Great job there - lots of good will instilled. It's a good thing I'll never need banking services in the future...

This happens in the software industry too. Real or imagined, bad customer service is the fastest way to end a potential or thriving business relationship. It doesn't have to be anything dramatic - something that places you second on the list is enough to cost you a consulting gig.

If you find yourself on the other side of the desk in such a transaction, stop and think for a minute: "If it were me, what would I want out of this exchange?"

Answering that question appropriately - and then acting on it - can alter the dynamics of the situation dramatically. Since it generally costs so much less to maintain an existing customer than it does to gain a new customer, this is something to consider.

While it remains online and available, you may want to peruse Tax Facts - a weekly newsletter generated throughout the 1990's and into 2005. David B. Robinson is one of those people every business person should listen to. He's a mentor and a heck of a nice guy. He certainly helped shape my career as an entrepreneur.

Doing good customer service is its own reward. The return on good will is difficult to measure - but I guarantee you it's positive!

:{> Andy

Technorati Tags: Software Business Customer Service Richmond User Groups Wachovia David Robinson, CPA

Microsoft announces Silverlight - the new web platform for delivering RIAs (Rich Interactive Applications) via the web.

One interesting twist on the name of this platform: it was named after web guru and Community-Credit founder David Silverlight.

So far as I know this is the first time Microsoft has named a product after an individual. Congratulations David!

:{> Andy

Technorati Tags: Silverlight web platform

...and today is one of those days. :)

First, if you don't already receive Steve Jones' excellent daily editorials (from SQLServerCentral.com), click the link immediately and sign up. It's a free site and there's lots of good stuff there. I enjoy the afore-mentioned editorials a lot - Steve does a great job.

Today's editorial is about making IT better. If you are an IT manager, stop what you are doing and read this editorial and the articles to which it refers. It's that important.

Go ahead - I'll wait.

Ok, back now? Weren't those articles interesting? I thought so too.

Second, an email was waiting in my Inbox this morning from Fernando G. Guerrero - CEO of Solid Quality. It was in everyone's Inbox, addressed to all of us at Solid Quality:

I've had my share of experiences with PHBs (as Frank likes to call "Pointy-Haired Bosses") and remember how it feels to identify with comments made in the eWeek article. Having those experiences makes me really appreciate working with Solid Quality because, frankly, that crap doesn't happen here.

From what I've seen it only takes one individual in an organization to spread groupthink. And once it takes root, groupthink spreads like weeds in a garden.

Joel Spolsky's Two Stories illustrates the benefits (including profit) of empowering employees.

Although I can sympathize with people interviewed for the eWeek article, like Joel I'm no longer in that position career-wise.

I think the experience of having-been-there made me a better manager when I managed DBAs at a large company. I remember my first review said something like "Team members will take a bullet for Andy." I appreciated that because it was something I cultivated. I wanted to be a "follow me" leader and not a "go and do that" leader.

The eWeek article contained quotes from folks who lamented being reactive - the "fire-fighting" role their jobs had become. The DBA Team I managed was in that spot when I became manager. The situation was indeed dire. Not only was the team spending an inordinate amount of time fighting fires, we were losing the fight. The amount of time required was increasing.

The stratgey I proposed sounded simple: First we will fight fires better. Second, we will engage in fire prevention.

As a team (I cannot stress this enough) we brainstormed ideas about doing a better job fighting fires. We hit on a couple key concepts - communication and cross-training. Individuals on the team were experts in certain applications. When something "bad" happened with Application "A" the go-to guy was "Joe". When Joe fixed the issue, he started sending an email to the group explaining the fix. The plan was to post the fix on a SharePoint portal, starting a Knowledge Base. The email soultion worked well enough (Outlook is searchable) that we never implemented this fully. Communicating worked - really well. We expanded the knowledge among the group and everyone felt better about being on call, etc.

Doing a better job of fighting fires gave us some breathing room to address fire prevention. We implemented a suite of light-weight tools that allowed front-line support personnel to make changes to data. It wasn't a perfect solution, but it allowed us time to fix underlying bugs in database code, instead of spending all our time correcting the bad data generated by bugs. Yes, we had to admit we made mistakes. Test Engineers had to admit these mistakes weren't caught by testing. But that challenged our Test Engineers to write more robust custom tests - and these tests found their place in the regression suite so it served to strengthen quality overall. And quality improved - but that wasn't all:

The paranoia and threat level disappeared when we all admitted mistakes were being made. The walls dropped and people loosened up. It went from being an ok place to work to being fun.

Most importantly (for the business anyway) was the fresh attitude allowed more freedom, and developers love freedom. Freedom was channeled directly into creativity, which developers (database and application) used to produce applications that literally blew management's mind! All of a sudden we had applications doing things they weren't slated to do for months. Performing, scaling, the sorts of things that applications do to make a company money.

What happened at this company? Where are they now? Apologies for a sad ending...

IT management - the PHBs - were threatened by a technology they did not understand: .Net. Their paranoia expanded and they literally "stopped all development" within three months of the application setting new corporate records for electronic processing. I honestly believe they would have pulled the application out of production had it not performed around 100 times better than the old application. As it was, they clamped the screws on the team that built it and, understandably, that team dissolved within six months.

But hey, the threat was mitigated.

It doesn't have to end this way. There are still cool companies out there. Sadly, they will not all stay cool, but you can enjoy the coolness while it lasts. You can use this time to grow yourself, become better at what you do, more valuable to another cool company. Or you can start your own cool company!

IT managers would do well to pay attention to Solid Quality. Solid Quality attracts MVPs and authors and treats us well. All businesses face challenges and SQL is no exception. What is an exception is how they handle challenges.

Whether you're a CxO or shift supervisor, you can treat people fairly, communicate more / better, and - for goodness' sake - do what you can to see those in your charge are allowed to do their job unencumbered by stupid rules.

:{> Andy

Technorati Tags: business software PHB pointy-haired boss SQLServerCentral Steve Jones Frank La Vigne

Philadelphia Airport Blog - begins 12:50 AM 9 Mar 2007

So the past few weeks we've heard about Jet Blue alternating between stranding passengers in planes on the tarmac for 6 to 10 hours and cancelling flights at the last minute. I don't think I've ever taken Jet Blue so I wasn't too worried about their issues impacting my travels.

Monday morning, I flew out of Richmond to Boston for an on-going project - taking US Airways. Since the merger with America West, US Airways has been working to merge their IT systems. The merged result went live Sunday, and the results were immediately evident to me Monday morning.

As I am apt to do when working on a writing project, I got up at 3:00 AM and left Farmville around 3:30 thinking I could get to the airport a little early and write for an hour or so before the flight. Internet access at the Richmond International Airport is free (as in beer) - how cool is that? When I arrived around 4:45, however, there was a long line of people waiting for human interaction - and notes hastily taped to kiosks explaining they were broken.

Not a good sign.

I made my 7:00 AM flight with minutes to spare. Fast forward to Thursday afternoon.

My flight leaves Boston at 5:00 PM, a stop in Philly, and then off to Richmond and home. At least that was the original plan. A funny thing happened on the way home.

To remain as objective as possible, I will begin describing the events as they happened to the best of my recollection:

• US Airways flight 1109 fom Boston to Philadelphia was delayed from 5:00 until around 7:20 PM.
• Around 6:30 PM, we boarded the plane with plenty of time to fly to Philadelphia and make the 8:40 PM Richmond connector.
• Around 6:45 PM, someone announced over the airplane sound system "If you are connecting to a flight in Philly, get off this airplane! We have a mechanical problem and this flight will not be leaving for a long, long time."
• A lot of us deplane.
• The gate agent motions for us to continue back to the US Airways Ticketing Counter to get new tickets.
• A nice lady at the Ticketing Counter in Boston informs us that we need to move to the back of a line roughly (remember, no exaggerations) three hours long.
• I laugh to myself and get in line to return to the damaged plane and take my chances.
• Security stops me and immediately asks for the remainder of my ticket. They won't let me into the gate area with my remaining portion of a boarding pass.
• I tell my story to a sympathetic TSA person. The security manager comes over and walks me to the counter, where a nice lady gives my a new boarding pass.
• I go back through security and make it back to the gate just in time to watch the door close. I am unable to board the plane that was going to be under maintenance too long to make my connector.
• The gate people will not open the door. I think this is a good thing for security, even though it is keeping me from my family.
• I book the next flight to Philly, hoping it will take off on time and the Richmond connector will also be late.
• The Boston - Philly flight leaves later, the Richmond flight is not late enough, and I miss the connector.
• I get off the plane in Philly and go to the ticket counter here. They tell me I can stay in the airport tonight until a 7:40 AM flight tomorrow.
• I ask for a hotel room. The lady behind the counter tells me I qualify for a Distress Rate ($69) at the Quality Inn in New Jersey.
• I ask to speak to the manager. The manager appears and asks which flight I was on. Upon learning I came in from Boston he informs the ticket agent "Give him a room."
• I receive a voucher for the Quality Inn in a bordering state and go wait for the shuttle. The shuttle never comes.
• Fortunately.
• I couldn't raise them on the phone until I let it ring (again not exaggerating) about five minutes.
• When the lady answers, she tells me they're not accepting vouchers.
• I return to the ticket counter in Philly and wait until I am tired of waiting.
• No hotels are accepting vouchers.
• I stay in the Philadelphia Airport tonight.

It is now 1:30 AM. My flight leaves at 7:40 AM.

And now for some subjective observations:

When I arrived at the ticket counter in Philly, there were two people out front and five people in line. I overheard a conversation between two agents - complaining about the people filing in. One of them was the person who tried to send me out of state to a Quality Inn for my hotel stay, while the couple one counter over was offered a voucher for a Ramada right up the road.

Being a data person, I notice patterns. As we passed through security this morning, everyone in the lines for those complaining agents was "randomly selected by their airline for a security screening." The lady at the front of the security line even commented "what's up with all the screenings?"

Now I am all for the Patriot Act and for empowering officials to do what is necessary to protect our nation and us individually from the threat of terror. Ask anyone who knows me, they'll vouch for this.

But this was clearly a case of two agents who were upset at having to work later than expected taking out their frustration on the public they are entrusted (and paid) to serve.

This was just wrong. It undermines the integrity of every effort to protect the nation. And it should be corrected immediately.

Can you guess which airline I will never fly again?

I have this theory: Perhaps this is a self-correcting problem. It should certainly take care of all those long lines at the US Airways ticket counter.

At least I made some cool young friends in line. We're camped out in front of security, waiting for our morning flights.

:{> Andy

Technorati Tags: US Airways delays new system merger spend the night at an airport near you!

The tune to a Bush song is running through my head as I type this... the band, not the president - although imagining the President singing the song is an interesting brain-stretch.

It's a fact of IT life that everything scales. Some successfully, even. Problems start when things do not scale successfully (or well). It happens in business. It happens with software systems.

When it happens with businesses, you hear things like "They grew too fast." When it happens with software systems, you browse to a website and receive an HTTP 500 or 404 error.

Can this be avoided (in business or software)? I think that's an excellent question - one well worth examining.

The answer, I believe, lies with how predictable the scalability is.

Consider a database application: If you know which tables are going to grow, how, and how much, you can plan for said growth. How would you plan? You could partition the tables using one or a combination of partitioning techniques. You could appropriate filegroups, snapshots, and a host of other functionality. If you only you knew where to apply these techniques.

That's the key.

Achieving scalability starts with capturing metrics. If you know how your database is growing from the beginning - if you can chart the growth of individual tables, access patterns, and internal performance data - you can predict growth and manage scalability.

So the key is measurement.

Measurement is an engineering discipline in its own right. The field of applied measurement is called Instrumentation. Applying measurement to a process is referred to as "instrumenting the process."

How do you instrument a database process? Iteration 1 would include creating an internal table to house and maintain process metadata:

If your instrumented process is stored-procedure-based, you could add INSERT statements to your existing stored procedures. Consider instrumenting a parent stored procedure that calls child stored procedures. The instrumented proc could look like the following (instrumentation emphasized):

Before moving forward, removing code duplication would be a worthwhile effort. In application development, this is one of many processes generally referred to as Refactoring.

The INSERT statements are a prime candidate for refactoring and we can address this with a stored procedure:

Now the parent stored procedure instrumentation above can be modified to look like this:

Much better.

Measuring the current process provides a baseline - the first step in a continuous improvement process that will provides dynamic design changes, performance monitoring, and - eventually - a dynamically-scalable system. It also supplies the current performance status against which we can benchmark future improvements and modification.

:{> Andy

Technorati Tags: Bush Scalability Database Instrumentation