Applied Visual Studio Team System

Attending the PASS Summit

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

Good Managers

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

On Government Regulation...

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. , , , - 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 .

:{> Andy

Technorati Tags: bureaucracy government regulation

Tech bloggers: Heads up

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

Penny's Blog!

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

Getting Lucky

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:

Bad IT Project Management

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 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

Iteration = Maturity

Introduction 

I was recently reminded that iteration matures software.

The History of Andy, Part 1 

Like many DBAs, I was a software developer in another life. I built web applications - working my way up from HTML through DHTML and finally to ASP - and could regale (and bore) you young whipper-snappers with war-stories of how things were "back in my day". [/DanaCarvey]

But I won't.

The Times They Are a-Changin'

I'll share instead something I've witnessed many times since starting with software in 1975 - and something you probably already know: stuff changes.

And thank goodness stuff changes!

I recently ordered 1G of RAM from an online retailer. It should arrive before my next son (but that's not a given as Riley refuses to provide a tracking number - the doctors will induce Christy into labor Friday if he hasn't been born by then - but I digress...). I remember my neighbor John, who introduced me to computers, purchased a 256-byte RAM chip in the mid-1970s for about what I paid for the 1G. That's 256 bytes of RAM - not a typo. As I recall it was either a 14- or 16-pin IC.

Things have changed since then. Improvements in technology, brought about by building and improving upon existing knowledge, have brought us to a day when I can purchase 1,073,741,824 bytes for roughly the previous price of 256. I don't know how you feel about that. I think it's a good thing.

The idea of "building and improving upon existing knowledge" defines iterative development. Although the idea is relatively new to the software development field, it serves as the basis for engineering disciplines. Engineers iterate - build and improve upon existing knowledge - and we get more powerful hardware for the same amount of money. What's not to like?

Iteration - it's not just a good idea... 

Iterative software development builds and improves upon existing knowledge within a specific domain. Most domains are defined by an application (wholly or in part), enterprise knowledge (again, wholly or in part), or - most likely - some combination of the two. For example, let's say you work for a large corporation as a software developer. Your domain could be the corporate website. In which case you possess knowledge about the business of the corporation and web development. You mix these together to do your job. In this case, you will probably pick up marketing savvy and current trends along with the latest AJAX techniques.

As you make successive passes (iterations) through the website design interacting with marketing, your domain knowledge is built and improves. As your domain knowledge increases, the website will become more valuable to the corporation - as will you.

Iteration adds value.

Got Iteration?

The same can be said for database development.

Perhaps you've experienced this in your own database development efforts: you receive a request for a database design to meet some desired functionality. Or you're handed a design and asked to optimize it. Or maybe even you had an idea to capture data - performance metrics or something similar - and you're designing a database solution to accomplish this.

You get into the development a few hours or a few days and realize a little tweak here or there would improve performance, or readibility, or better adapt the design to your intentions. So you make the tweak and continue.

This improvement leads you to re-examine other portions of the design and you make more tweaks. Maybe your last change broke things. Maybe you see an opportunity to add a parameter to a stored procedure and combine the business logic of three stored procedures into one.

A "Growing" Solution 

Pretty soon, you have iterated enough to feel comfortable promoting, integrating, or even releasing the results - letting the effort move to the next step.

Depending on the nature of your efforts, it may not end there. If your database development is the back end of a larger application - say, the corporate website, for example - there will likely be requests for changes over time as the site grows (scales) in complexity and size.

When the requests come in you are not likely to start over. You will most likely build and improve upon your existing knowledge. You will most likely iterate.

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

Sucking Up

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

Gatekeeper or Roadblock? Part 2

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

The Hidden Cost of Business Enemies

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

Notes On Project Success - Part 2, to Stake-Holders

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.

My questions were:

• Who failed? Did HR fail 80% of the time by hiring mediocre to poor employees? or did our management disillusion and de-motivate these people into their non-excellent state?
• Are we, in effect, planning to never get better?

Statistical control works on processes, not people - at least not well on people.

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

Notes On Project Success - Part 1, to 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

Surface

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

, 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

Managing The Thing You Cannot Touch

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

Technorati Tags: Consulting Software Development Satisfying The Customer Leveraging New Business

The Thing You Cannot Touch

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

Requirements

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

Business Communications in May 2007

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:

UnSending Email

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

Lanham on Code Quality

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 .

:{> Andy

Technorati Tags: Software Business Brian C. Lanham Code Quality

Customer Service

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

Microsoft announces - 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 after an individual. Congratulations David!

:{> Andy

Technorati Tags: Silverlight web platform

Some days blogs just write themselves...

...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:

Go to http://maps.google.com
Select "get Directions"
From "Madrid" to "Seattle"
Click on "Get Directions"
Look at step #40
:)
Cheers

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

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!

Everything Scales

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:

CREATE TABLE dbo.ProcessData
(ProcessDataID int IDENTITY(1,1) NOT NULL,
ProcessDataDateTime datetime NULL CONSTRAINT DF_ProcessDataDateTime DEFAULT (getdate()),
ProcessDataIndicatorName varchar(50) NULL,
ProcessDataIndicatorValue varchar(50) NULL,
ProcessDataIndicatorStatus char(1) NULL CONSTRAINT DF_ProcessDataIndicatorStatus DEFAULT ('C'),
CONSTRAINT PK_ProcessData PRIMARY KEY CLUSTERED (ProcessDataID)

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):

CREATE PROCEDURE dbo.SomeProcess
AS

begin

INSERT INTO dbo.ProcessData
(ProcessDataIndicatorName,
ProcessDataIndicatorValue)
VALUES('ChildProc1','Starting');

EXEC dbo.ChildProc1

INSERT INTO dbo.ProcessData
(ProcessDataIndicatorName,
ProcessDataIndicatorValue)
VALUES('ChildProc1','Ending');

INSERT INTO dbo.ProcessData
(ProcessDataIndicatorName,
ProcessDataIndicatorValue)
('ChildProc2','Starting');

EXEC dbo.ChildProc2

INSERT INTO dbo.ProcessData
(ProcessDataIndicatorName,
ProcessDataIndicatorValue)
VALUES('ChildProc2','Ending');

INSERT INTO dbo.ProcessData
(ProcessDataIndicatorName,
ProcessDataIndicatorValue)
('ChildProc3','Starting');

EXEC dbo.ChildProc3

INSERT INTO dbo.ProcessData
(ProcessDataIndicatorName,
ProcessDataIndicatorValue)
VALUES('ChildProc3','Ending');

end

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:

CREATE PROCEDURE dbo.AddProcessData
@ProcessDataIndicatorName varchar(50),
@ProcessDataIndicatorValue varchar(50)
AS

begin

INSERT INTO dbo.ProcessData
(ProcessDataIndicatorName, ProcessDataIndicatorValue)
VALUES(@ProcessDataIndicatorName, @ProcessDataIndicatorValue);

end

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

CREATE PROCEDURE dbo.SomeProcess
AS

begin

EXEC dbo.AddProcessData @ProcessDataIndicatorName='ChildProc1', @ProcessDataIndicatorValue='Starting';

EXEC dbo.ChildProc1

EXEC dbo.AddProcessData @ProcessDataIndicatorName='ChildProc1', @ProcessDataIndicatorValue='Ending';

EXEC dbo.AddProcessData @ProcessDataIndicatorName='ChildProc2', @ProcessDataIndicatorValue='Starting';

EXEC dbo.ChildProc2

EXEC dbo.AddProcessData @ProcessDataIndicatorName='ChildProc2', @ProcessDataIndicatorValue='Ending';

EXEC dbo.AddProcessData @ProcessDataIndicatorName='ChildProc3', @ProcessDataIndicatorValue='Starting';

EXEC dbo.ChildProc3

EXEC dbo.AddProcessData @ProcessDataIndicatorName='ChildProc3', @ProcessDataIndicatorValue='Ending';

end

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

The Freezing Redneck Tour 2007, Week 3

Week 3 of the Freezing Redneck Tour 2007 finds me on the way to Boston this fine Monday morning.

We had ice yesterday and overnight in the central Virginia area - not fun and certainly not conducive to driving 90 or so miles to the airport one way starting around 3:30 AM.

The air temperature was below freezing in Farmville but, fortunately, the ground temperature was not - at least not on the roads. In addition, the good people at the Virginia Department of Transportation were out early putting sand on ramps and bridges. Thanks VDoT!

So the roads were fine but leaving a little early didn't hurt any.

:{> Andy

Technorati Tags: Freezing Redneck 2007 VDoT Boston

Competition and lawyers

Let me state at the outset that some of my friends are lawyers. My oldest daughter Manda even has a pre-law degree (Political Science). And I am certain some of the nicest people on the planet are lawyers.

In the interests of full disclosure, I'd like to also say I've had my share of run-ins with the law. Nothing major, mind you... My experience with lawyers has been educational. That's a good word to use: educational.

So I'm sitting here watching television - that's right, the play-offs are about to start (arguably the best football of the season will be played today and not a couple Sundays hence) and most of you know I rarely watch television - and I see this commercial about calling this 800 number if you've lost money in the stock market. And I feel the blood rush to my face.

Lean in, real close to your monitor - I have a secret to share with you about investing in anything, especially the stock market: It's

RISKY!!!

1...
2...
3...
4...
5...
6...
7...
8...
9...
10...

I construct a quick use case of how this commercial came to be. My thoughts are:

• Someone invested in the stock market
• This person expected to make loads and loads of cash
• Instead, some or all of the money was lost
• So the person contacted a lawyer

Some people do make money in the stock market. A few of them share how they did it in ways you and I can understand. I like Jim Cramer. His books help ordinary people understand the risks and propose a methodology that helps me invest according to my risk tolerances. I particularly like .

This, and all good books about investing, make the point that investing is risky.

Then, catching up on my blogs, I come across a link to this: Comes v. Microsoft.

I read through some of the information posted there and my reaction is "Thank God for Google."

"What?!" you gasp, "aren't you sold out to Microsoft and isn't Google their arch-rival?" No, and yes.

I'm not sold out to anyone. I have a limited number of minutes to apply to learning new stuff everyday and I can barely keep up with the products offered by a single company, so I chose Microsoft technology. And ask anyone, I give Microsoft high marks for the stuff they do well and low marks for the stuff they don't do well. I don't see that as being sold out. But I digress...

So why "hooray for Google?" Google has proven beyond a shadow of a doubt that it is possible to compete with Microsoft.

It is my contention that there would be no lawsuits if, say, Microsoft had simply rolled over and allowed these companies to catch up - or if they'd met with these companies to divvy up the market... no wait, that would be illegal, nevermind.

My point is pretty simple. Microsoft isn't perfect. But neither are their competitors. If some of the "technological alliances" formed to compete with Microsoft had been formed to compete with anyone else on the planet it would have been shot down by some monopoly law or other, but since they were formed to combat Microsoft they were deemed legitimate.

When Microsoft provides the lowest TCO (total cost of ownership) and the highest ROI (return on investment) one competing strategy seems to be to form an alliance to try to create a standard that excludes Microsoft, or engage in admittedly clever marketing (will they break into double-digit marketshare with those commercials?) with cool people and sappy comparisons (conspicuous in its absence was the C# GUI Programmers Guide). Here's something I really admire: When Microsoft gets outwitted in the market - like by - their strategy is to compete.

It isn't Microsoft's "fault" that the competition makes mistakes and Microsoft takes advantage of it. It's the competition's fault for making the mistake in the first place. Microsoft is simply doing what every other business on the planet - including mine - does to remain open and profitable: competing.

When you're that big, however, it looks awfully unfair from the standpoint of the little guy.

But the opposing argument is: Microsoft should not be allowed to compete. And this is just wrong.

So, bringing it all back around...

How about some personal responsibility?

If you invest in the stock market, you could lose every cent. That's the way it is. If you do not wish to accept that risk, you have an option: don't invest in the stock market.

If you decide to start a business that competes with Microsoft, you could lose. That's the way it is. If you do not wish to accept the risk of losing, you also have a similar option: don't go head-to-head against Microsoft.

The first game's on...(and I believe the Bears Defense will decide the remainder of the games in which they play this season...)

:{> Andy

Disclaimer: The opinions expressed herein are the opinions of the author and not the owners and operators of the site or the internet. Ok, maybe the owners of the site since the author does, in fact, own the site; but definitely not the operators. And other people are responsible for what they say and do on the remainder of the internet - the set of said which encompasses but excludes this site herein. Wheretofore. I am not a lawyer and I do not play one on the web. Ad nauseum, ad infinitum, add oneplusone, e pluribus unum.

Technorati Tags: Microsoft legal battles competition

A couple changes!

I've started a new blog: Applied Business Intelligence!

I will continue to blog here about Team System topics. I'll probably continue to share personal stuff here as well - I'm debating that...

I've also changed my login here at VSTeamSystemCentral.com. I'll no longer be posting as that dry and boring "admin" guy - now I'll be posting as me!

:{> Andy

Technorati Tags: New blog Applied Business Intelligence BI SSIS ETL Reporting Services

Editorial Decision

I am making an editorial decision based upon the following: The more I blog about my air travel experiences, the worse said experiences get.

I think my blogging may be impacting my experiences - kind of like Spin, Twin, and Fin imply some sub-atomic particles exhibit free will or maybe it has something to do with the physics of dimensions four through ten.

:{> Andy

Technorati Tags: physics blogging airports twin spin fin 10 dimensions

Career Advice: Going Solo

I recently shared this advice with a friend who is considering becoming an independent consultant:

0) There's a great book about consulting by Tom Lambert called . I highly recommend it. I love Chapter 6. I just bought a used copy from Amazon for $4.20.

1) Don't take anyone's advice seriously - unless you know for a fact they have a fully licensed version of CrystalBall 3.2 software installed and running, and you've conducted the tests yourself to validate it works as advertised. I do not have a fully licensed version of CrystalBall 3.2 installed.

2) I'm a huge believer in going for it. Any comments I make are going to slant that way. But - and this is a big butt (double-entendre intended) - be aware of as many risks going in as you can possibly identify. When you go for it, identified risks provide metrics for measuring your progress.

For instance, if you are not independently wealthy, money makes a good metric. As I mention in The Clean Break : I remember looking at the checking account one day during my first few months of entrepreneurship and seeing $80 in there. I thought "I must've done something stupid." I was right, and this was the beginning of my understanding of business development.

3) There's a lot of hubbub out there about identifying your weaknesses and trying to "not do anything stupid." Hogwash. Quitting Harvard in your junior year to start an industry is stupid, but it worked out ok for Bill Gates.

4) Odds are you're not going to make as much money as Bill Gates. That's ok, you can live very well on substantially less.

5) I subscribe heartily to the philosophy. It basically states "you're good at what you're good at - go do that." Weaknesses will remain weaknesses but they do not have to stop your momentum with your strengths.

For instance, you are passionate about great coding. I built my first (and now my second) business on passion. I kid you not. The fact that I was good at what I did helped, but the passion sold.

It's like the scrawny kid who gives 110% every football practice. The coach is going to call that kid's number before long - and that kid will likely impact the game. Be that kid.

6) Speaking of sales, it will be good at some point to figure out how you're going to get new work. The inherent weakness in any consulting model (and this is a weakness for me too) is: you (and I) do not scale well. If all our business is generated by us, then performed by us, then invoiced and accounted for and business-developed by us - we are going to be very busy doing a lot of stuff which a) we may be no good at; and b) we may not like in the least.

This is business development. I've always managed this with channels. You probably know this already, but a channel is a company or individual that will tell others about you and your work - either for free or for some direct or indirect gain (money).

That aside, you will be amazed at the work that finds you once you go into business for yourself.

7) How much do you know about contracts? I didn't know beans about them until I got handed my [sic]hat once. It only cost me $6,500 to learn about contracts - which, I hear, is pretty cheap.

There's lots of approaches to contracts. Verbal contracts usually prove at some point to be as valid as the paper on which they're printed. I like work orders that specify deliverables and percentages expected for bid-by-job work. I like billing cycles (1st of each month, 15th and 30th, or my personal favorite: every Friday) for bid-by-time work. No matter what, you want to have terms (net 30, net 10, etc.) in writing up front.

The customer is not always right. In our field, a lot of customers are completely ignorant of what they're asking you to do for them. You need to keep this in mind when negotiating the contract. And protect yourself.

There is such a thing as bad business. Bad business will hurt you way more than no business. Bad business ends up causing you to work for free. And there are a substantial number of business people out there who believe they're doing you a service by teaching you this valuable lesson while consuming your single, non-scaling resource: you. They're on par with people who want to teach you how to play poker or pool... just bring money. ;)

Pop quiz: The nicest, most sincere people with whom you are negotiating are:
a) Truly the salt of the earth, genuine, will-do-anything-to-help-everyone-succeed people.
b) Sick bastards who are playing a game with your life and future by which they gain points the more you suffer.
c) You have no idea - until payday.

The answer, sadly, is c.

8) How much do you know about managing cashflow? You can actually lose money - for years in fact - and remain in business if you can maintain a positive cashflow. In my opinion, this is the key to the business side of things.

:{> Andy

Technorati Tags: Developer Community Career Advice Independent consultant

Career Advice: Team Building Activities

I had this experience once with Team Building Activities. I go into work one Monday and there's an email in the Inbox about this subject, and I open it and read that it's the Saturday after next.

Saturday?

Ummm Yeah.

Pop Quiz: You're president of a company with a dozen or so employees and you find certain parts of the movie Office Space highly offensive and usually talk to the television when the movie is playing saying things like "That's such an exaggeration!" The real problem is:
a) The market
b) Supply-side economics
c) Your employees
d) Mike Judge
e) You

The email - gosh I wish I'd saved it - said something about how important the event was, and I believe it stated it was voluntary but then implied you weren't a good employee if you didn't attend. All in all, very reminiscent of the "flair scene" in Office Space.

Here's some thoughts:

If you own a small company, you probably work Saturdays anyway. This is a fun outing for you and a chance to do things away from the office with people who work for you - a way to get to know them better and for them to get to know you better.

To the employees, this is a day when they usually would not be working, but now have to. They're just working in a different location - one which you thought would be a lot of fun. It's not as fun for them. The work- / game-face needs to be on - on a day when usually it's off. They're giving up a day of doing-nothing-for-the-company to do something for the company. You are stealing a day from them.

It's completely different if you're hiking on a mountain trail or walking on a beach and bump into one of your employees. They're doing what they planned to do that day - all by themselves and without your help - on their day off.

So, if it's that important, schedule it for a Monday or Tuesday or Wednesday or Thursday or Friday - one of those other days when important work-related stuff gets done.

:{> Andy

Technorati Tags: Developer Community Career Advice Team building activities

Career Advice: Interview the Company

I had a refreshing conversation with a Human Resources person recently.

I was asked by a friend to provide a reference for employment, and was honored to do so. During the course of describing my relationship with the person in reference, I mentioned that I had been fired from the company where we met and worked together.

The engineer in me mentions these types of things, with no value judgment assigned, as facts. I say it with no more passion or conviction than I state "The sky is blue."

But I learned something during this exchange. The HR person was impressed with my openness about the matter and told me my attitude about it indicated self-confidence. Indicating self-confidence is a good thing if you're talking to a human resources person, so I thought I'd pass this tidbit along: If you've been canned, bring it up!

It might help.

The details of my experience are not as important, but these sorts of things happen so I'll share some.

It was a small company that had been in business for a couple years when I joined them. My motivation for going to work there was to be closer to my girlfirend (to whom I am now happily married) which, I'm certain, affected my judgment while interviewing the company.

"Interviewing the company?" you ask. Yep - they're interviewing you, you should be interviewing them too. That "good fit" stuff (more on this later) is a two-way street.

Looking back, there were clues during the interviewing process that I ignored. When I took notice of potential warnings, I naively thought "I can manage this." Truth was, I could not manage it.

From my first week on the job, bad things happened. They continued to happen and grow in magnitude. Although I made a couple friends there - people with whom I will remain in contact for the rest of my life, most likely - I also lost one good friend as a result of my involvement with this company. And it happened within the first 30 days of arriving on the job.

Still, I persisted. Still thinking "I can manage this."

I put that episode behind me and resolved to "do better next time." I did do better, but things did not improve for me. In fact, they grew much worse.

At my 90-day review I was denied a raise discussed at the time of my hire. There were three measurements I was to achieve in order to earn the raise:

• Provide technical leadership
• Develop software
• Generate a certain volume of sales

I hit two of the three. The owner of the company acknowledged this during the review. I missed the sales target.

Pop quiz: The resulting raise was:
a) 66.6666% of the agreed-upon amount + the percentage of the sales quota I did generate.
b) 66.6666% of the agreed-upon amount
c) 50% of the agreed-upon amount
d) 25% of the agreed-upon amount
e) 0% of the agreed-upon amount

Sadly, the answer was e.

Now I'm not one to make excuses. I believe if you agree to something - especially something involving money - you stick to it no matter what. That said, I started with this company in August 2001. Anyone recall any market-impacting events around a month after that?

It had already become clear to me, by the time of the 90-day review, that my career with this company was in trouble.

Why? In all fairness it was not a "good fit." That's what the owner told the Virginia Employment Comission when he protested my application for unemployment after firing me, and I have to agree.

Things I did - heck, things that are just my nature - irked the company president. I realized much later he really enjoyed having an impact on people's lives, and he measured that impact by their reactions to things he did.

Ask anyone who knows me, I don't react. It's not in my nature. I'm almost always content and happy. When life hands out a lemon, I wait for life to hand out a crab-stuffed flounder filet to squeeze it onto.

It's how I roll.

I also don't derive satisfaction from the misfortune of others, no matter how much effort they expend to bring said misfortune upon themselves. There were about 12 employees working there the day I got canned, including the company president and a vice-president whom I believe is part-owner. Of those, only the president and vice-president remain with the company, and last time anyone mentioned it to me (I don't ask about such things), the company had 2 or 3 employees.

Part of this is due to the general economy of the area.

But most of it probably isn't.

:{> Andy

Technorati Tags: Developer Community Interviewing Technical Personal You're Fired!

Integrity

Steve Jones makes some good points about ethics in an Ethics editorial at SQLServerCentral.com.

My oldest daughter Manda is working on a masters in theology (and another masters in counseling, I think...). She said something that really stuck during a pre-Christmas lunch: "Integrity is now the key to business leadership and not just some nice-to-have trait."

One thing about business ethics is it doesn't lend itself to "balancing" like other things in our field. For example, Jeffrey Skilling could not argue that he engaged in proper accounting most of the time at Enron and should therefore not be punished for the few times he strayed.

There's also the myth that disclosure will absolve all that's wrong. Disclosure is nice, mind you, but calling the person you just screwed in a business deal and telling them "you've been screwed!" doesn't really make it right. "Un-screwing" is the solution - and good luck with that.

In an age where integrity is key it's not the 1,000 ethical things you or I do that will actually count, it's the absence of 1 unethical thing.

Thinking in this manner may seem difficult but it's more a matter of habit than anything else. I was fortunate to have a grandmother that drilled this fact into my very being. She said (several times) "Doing the right thing ain't always easy, but it's always the right thing."

:{> Andy

Technorati Tags: Ethics business SQLServerCentral

2006 - the Year in Review

This is probably my last post of 2006. It's been a good year. Not perfect, but very good.

got lots of traction in the industry. Most SQL Server technologists I know agree five years was a long time to wait for a new release, but the feature set matches or exceeds the development effort.

Most shops I deal with have either migrated, are testing 2005, or have plans to in 2007.

was released and Service Pack 2 is on its .

- aka Data Dude - went from CTP1 to RTM in six months. Very impressive development cycle!

It's been a good year for the Richmond Developer Community.

We started a new SQL Server Users Group, which is now the official PASS chapter for Richmond, VA! We also held two successful MSDN Code Camps - and the leadership team is planning more for 2007.

Speaking of leadership, the team did an outstanding job in 2007 - thanks to all who led and participated at every level! You folks rock!

Personally, it's been a good year too.

Christy and I bought a house in Farmville, VA - completing our move from Jacksonville, FL back home to Virginia.

We recently learned we're going to be parents again! :)

Business-wise, it's also been a cool year.

I moved from a temp-to-perm position to a permanent consulting gig, and was then recruited by Solid Quality Learning! The relationship with Solid Quality allows me to be an independent consultant. It's nice to be working for me again, although my boss is sometimes a jerk... ;)

I learned a couple difficult lessons as well. Without going into detail, suffice it to say this year affirmed my long-held business standards regarding the importance of integrity, loyalty, and trust. At my age and with my experience with people and in the industry, I am not often surprised by people - but I was surprised this year. My lovely bride Christy has an applicable saying about such times: "Good judgment comes from experience, and experience comes from bad judgment." Amen. I believe it is best to always treat people as you want to be treated because you never know...

I also experienced new levels of trust and respect. I worked with an incredibly talented team on a cool project. Loyalty was a hallmark of our experiences on the team. The result? Against seemingly insurmountable odds and obstacles, both internal and external, we succeeded - and made it look easy! My experiences at Solid Quality Learning have underscored the value of loyalty and integrity in all we do. The professionals that lead this company are at once the most talented, intelligent, down-to-earth, humble, and open people on the planet. It is an awesome honor to be part of this organization!

I was honored several times this year:

• one of the authors of (Wrox)
• allowed to participate on the leadership team for the Code Camps
• honored to lead the Richmond SQL Server Users Group
• honored to lead the Richmond .Net Users Group
• nominated for MVP
• honored to deliver the Team Edition for Database Professionals keynote at the Philadelphia Launch Event
• honored to be invited to Redmond several times to participate in TAP and certification discussions
• honored to work with a fantastic team to develop an industry-changing application (which I cannot talk about!)
• honored to be asked to join Solid Quality Learning as a mentor

I don't do resolutions, I merely set goals for the forseeable future. I was able to accomplish two of three goals I set at the end of last year. I find three is a nice round number for goals - and I am working on my three goals for 2007 this last afternoon of 2006.

Here's to 2007 - may you have a safe, prosperous, and happy new year!

:{> Andy

Technorati Tags: 2006 Year in Review trust Solid Quality Learning integrity new baby 2007

Trust

My older daughters Manda and Penny gave me gift cards to a popular bookstore chain for Christmas. So I purchased a sci-fi paperback (you can't beat sci-fi for inspiration) and The Speed of Trust by Stephen M. R. Covey.

I like this book a lot so far. It reminds me of the ethics I've witnessed at Solid Quality Learning. Here's a quote from Chapter 1 in a discussion about the Sarbanes-Oxley Act:

Compliance regulations have become a prosthesis for the lack of trust - and a slow-moving and costly prosthesis at that.

Amen.

:{> Andy

Technorati Tags: Trust The Speed of Trust Stephen Covey business ethics Sox Sarbanes-Oxley

Out of Canada...

I'm on the way back to Farmville from Guelph this morning - with mixed emotions.

It will be great to see Christy, Stevie Ray, and Emma when I get home! I always miss them when I'm on the road.

But I also met some good people in Guelph. They were simply awesome to work with (and for). I believe I made some new friends.

It's always good to be able to "geek out" with people doing cool work. I'm very fortunate in that most of the people I work with (and for) are doing cool work. I love this job!

But it's even more cool when I have time to geek out over a couple pints at a good local pub before hitting the road - even if someone had to twist my arm. ;)

:{> Andy

Technorati Tags: Geek out pints pub friends

Bill Gates for President

There's a website called Bill Gates for President. Interesting.

Scott Adams has some poignant thoughts on the matter!

:{> Andy

Technorati Tags: Bill Gates President Scott Adams

You learn something new everyday...

So....

Work finds me in Guelph (pronounced "Gwelf"), Ontario this fine evening. As I type this, I'm awaiting room service - pasta alfredo with chicken and mushrooms. Yum.

I almost didn't get out of the airport this afternoon. But I learned something very important about Canadian Customs: they don't care one whit for (in my part of Virginia, we'd say "they don't cotton to") Americans coming into their country to work! Who knew? Certainly not moi...

At the airport, I was handed a customs document to fill out. It had a couple checkboxes labeled "Why are you here? Pleasure, Business." I'm here to conduct an SSIS class, so I naturally checked "Business." Wrong answer!

After a bunch more questions: "Who do you work for? Myself. Who hired you? I subcontract for global virtual corporation. How many people work for your company? Just me. What kind of work is it? Training. What kind of training? Microsoft SQL Server Integration Services. And why did they call you to train them on this? I wrote part or this book last summer about it. Where were you on the night of June 21st?"

And the looks kept getting meaner...

I was asked to go sit in a waiting area while they "figured this out." I did. After about five minutes, the official returned to tell me "you are offering specialized training." To which I nodded "yes." "You are free to go," he said.

And go I did.

I went right across the street and rented the last Hertz car on the lot (apparently, if you're he last person to get in line at Hertz, they forego the usual "Which model would you like today?" question...). So, what do you know, I learned a couple new things today!

:{> Andy

Technorati Tags: Canada Customs Far from home

I'm a Mentor!

My Solid Quality Learning business cards arrived in the mail yesterday. I like my new title: Mentor.

I believe the title is appropriate for the mission of Solid Quality Learning which is summarized:
Solid Quality Learning is the trusted, global provider of advanced education and solutions for the entire Microsoft database platform.

Cool.

:{> Andy

Technorati Tags: Solid Quality Learning SQL Mentor

The Clean Break

For the first time since 2001, I find myself sitting behind the president's desk in the global headquarters of my own business!

The new venture is called Andy Leonard Technologies, Inc. and this my first full-time day on the new office.

I mostly perform work for Solid Quality Learning as a mentor. For those who are unfamiliar with S. Q. L., it's a fantastic company! Not only are the people industry-recognized experts, they're actually cool! They engineer the entire process of joining their ranks so that it's low-stress. It has allowed me to ramp up quickly - and for that I am very thankful.

Mentoring is a great concept - it's a hybrid between consulting and instructing. Here's how it works: I join teams for a number of days or weeks. While working together, we develop a specific set of objectives - usually to develop template projects, best practices, and establish a foundation for the working environment. Together, we build out example projects using the templates to demonstrate their effectiveness.

In addition to this, I'm also a trainer. When training, I lead excellent classroom-based instruction courses. I currently lead the ETL with SSIS course, but I am ramping up on more course material - hoping to lead others.

In my previous jaunt into business, I operated ASI. ASI specialized in industrial automation and integration. It was a lot of fun for me because it brought together several disciplines I enjoyed (and still enjoy!): engineering, electrical control systems design, and software development.

ASI started in 1995 when I wrote one of the first completely web-based Manufacturing Execution Systems (MES) called Plant-Wide Webs. Plant-Wide Webs started using dynamic HTML before DHTML was widely available, then graduated to ASP. Writing the application and running the business were cool experiences!

I learned a lot about business and myself. :)

Most of those lessons were learned the hard way. I remember looking at the checking account one day during my first few months of entrepreneurship and seeing $80 in there. I thought "I must've done something stupid." I was right, and this was the beginning of my understanding of business development.

When Solid Quality Learning called I was ready. I understood the risks of making the leap. I knew it would be a lot of hard work. But, unlike last time, this time I have a fantastic team supporting me - and outstanding business development support!

The person who deserves the most credit has to be Christy. Not only does she support this decision, she's actively involved - booking my flights, making hotel arrangements, and renting cars... she's awesome! She even jumps onto mapping software and talks me in from the airport to the hotel so I don't drive around lost my first night in a new town! (The car rental people always ask "Do you know where you're going?" and look at me funny when I say "No, but I'll find it!") Christy does this in addition to taking care of Stevie Ray and Emma without help from me (when I'm out of town or holed up in the office) - and she does it without complaining.

Thanks, Cutie. I couldn't do this without you!

It feels good to be back. So far, the new boss is treating me ok... but it's still early on the first day... ;)

:{> Andy

Technorati Tags: Andy Leonard Technologies, Inc. Self-employment SQL Server Solid Quality Learning SQL

Transition

Changing jobs is tough. It's a job in and of itself.

Most regulars here know I moved from Jacksonville, FL last year to be closer to Christy's and my folks in Virginia. We've settled in Farmville, VA and love it here.

I recently received a call from Solid Quality Learning and have accepted an offer to become a Solid Quality Learning Mentor.

It's a huge honor to work with these legends of SQL Server. For someone who enjoys learning as much as I do, it is an added bonus! I am learning more than I have in a long while.

Most important, Solid Quality Learning is everything it appears - a very cool company of awesome technology professionals.

But I've been spoiled lately at my current position with CapTech Ventures, Inc. CapTech is also an awesome company. It's been an honor to work for them as well - and they have treated me well. CapTech is headquartered in Richmond, VA and most of their work is in the Richmond area. They're a consulting firm - putting people into strategic project roles with businesses to accomplish some business goal or perform a business role.

CapTech is growing like crazy. My theory about why is twofold: 1) they hire good people and 2) they treat them well. If you're a Richmond technologist (or a technologist thinking of moving to Richmond), you owe CapTech Ventures Careers page a look.

So I bid CapTech farewell with thanks for the experiences, and look forward with excitement to this new relationship with Solid Quality Learning!

:{> Andy

Technorati Tags: About Andy Solid Quality Learning CapTech Ventures Richmond, VA

Scott Adam's Dilbert Blog

Dilbert.blog

Enough said.

:{> Andy

Technorati Tags: Dilbert Scott Adams

Time to get back to it

In the US, the traditional end-of-summer has arrived: Labor Day is almost over.

This time of year always marks a change. The days, though still longer than the nights for the next couple / three weeks, continue to shorten. The first chilly winds blow in Virginia, and this month will mark the first time in a few months for furnace activity.

School has already started here in Farmville, Va. Stevie Ray started at his new preschool in mid-August. So far, he likes it a lot.

An interesting business cycle starts in the Fall as well. September marks the last month of the previous business calendar for many. Most corporate budgets are built in a use-it-or-lose-it fashion: they must spend all the money allocated to this year's budget or suffer a reduction (or at least questions) in the coming year's budget. It's an interesting problem for some departments, but a problem nonetheless.

With October comes a fresh fiscal year, and then businesses that were unable to spend in September (or perhaps August and maybe July as well) then have a new budget with which to work.

What does it all mean?

If you're in the software business, your phone will begin ringing this week - that's what it means. And that's always a good thing.

If you're a micro-ISV or even a small shop, keep in mind that you do not have to swear off sleep until Christmas. You can schedule (book) the work. You can even begin the project now and bill forward (at a discount for paying a heavier percentage up front, even) tied to a well-written schedule of deliverables - thus helping companies in a use-it-or-lose-it situation. (And how you and your customers define "begin" is entirely up to you.)

The point is this: In business, not everything is negotiable, but usually most things are.

Talk to your customers. Find out about their plans and the fiscal constraints to which they must adhere.

Then use to build them some awesome software! Let everyone win!

:{> Andy

Technorati Tags: Team System Software Business fiscal calendar year budget corporate

Follow-up #2 to Database Professionals: An Enterprise Requirement

Eric Wise drew some heat from the developer community at CodeBetter.com with this post about the need for a DBA during development (see my post on the subject here).

I think Eric makes a couple good points, one explicitly and one implied:

1. (Explicit) A DBA - or Database Developer, more accurately (and there is a difference) - adds value to development.

2. (Implicit) There are Software Developers out there who can step into the Database Developer role long enough to solve most database tuning issues. Eric demonstrates this with himself in profiling and addressing a missing or ill-defined index.

I find most of the comments - presumably by software developers - typical. One developer stated:

My current project didn't have a DBA for 2 years, until recently since we're now at the stage of optimizing for performance. It seems to me that as long as the database is intelligently structured in the first place, a DBA's role would be rather small in most cases.

I agree with the sentiment expressed here - as much as I agree that code-generation tools can replace developers. It's true that you can utilize SQL Server or any database engine as a dumb file store. And it's equally true that you can build an enterprise application in C# that consists of thousands upon thousands of lines of nested If... Then... Else statements.

The question is: Why would you?

This goes beyond arguments over syntax, coding standards, methodology, and design philosophy. This is about putting competent professionals - at the height of their game - into the mix on a project.

You don't have to take my word for it - ask software developers who have worked (or are working) with competent database developers.

:{> Andy

Technorati Tags: Developer Community software developers DBA database developers SQL Server

Spam - The heart of the matter

According to this Consumer Reports article:

Too many consumers’ defenses are down. Twenty percent of the households surveyed didn’t have antivirus software installed. Thirty-five percent didn’t use software to block or remove spyware. And consumers in roughly 795,000 households continued to buy products advertised through spam. Most homes had a firewall installed to block hackers. Still, based on our findings, we project that about 2.4 million U.S. households with broadband, who are hackers’ prime targets, remain unprotected by a firewall.

Thing Number 1:

If you are one of the people in one of the 795,000 households I have a question for you:

1...,

2...,

3...,

4...,

5...,

6...,

7...,

8...,

9...,

10...

What the heck are you thinking? (This, mind you, is the edited version, after counting to 10 (and actually after even more editing)...).

You actually pay money to people who send you unsolicited email for their products and/or services? Did you get what you paid for? If not, were you too embarassed to report it?

Here's the simple truth: people that purchase items advertised (and I use the word "advertised" here extremely loosely) in Spam are the problem - not the spammers themselves. If you stop feeding them, they will go away!

Not everyone is computer- or web-savvy. That's ok. There's no test you must pass before you purchase or own a PC and obtain internet access - and I don't think there should be. The internet is a wonderful thing. But like all wonderful things, it can be abused. And it is being abused by people who are taking advantage of those less computer- and web-savvy than themselves.

Here's a few simple rules I follow regarding email:

1. If you don't know who the email is from, don't open it - period. It may contain some really important information, but if it's really that important, someone will follow up with a call.

2. If you know who the email is from and it contains an unexpected attachment, don't open it. You can always email the person who sent it to you and ask them if they sent you an email with an attachment.

3. If curiosity is just eating you alive and you cannot take it and you just have to see the picture the email subject states is attached just in case it's real and not botware that will turn your broadband connection into a denial-of-service attack in the name of some holy cause or other, please see item 2 above.

4. Never ever ever (ever) buy anything advertised (again, using the term loosely) in an unsolicited email. By unsolicited I mean an email that arrived in your email inbox through no action of your own. If you must have the item, please buy it somewhere else - even if it costs more. Trust me, you're doing us all - and probably yourself - a great service.

Thing Number 2:

There are lots of good antivirus software packages out there. AVG will allow you to download a free (as in beer) version of their software "for private, non-commercial, single home computer use only." This means you can download it and install it legally on your home computer for free. If you're in the 20 percent of households without antivirus software, please visit this link immediately.

Thing Number 3:

If you're part of the 35 percent of households that don't use antispyware software, and if you run a Windows operating system, you can download . Spyware can do lots of nasty things - you need to protect yourself. Windows is particularly vulnerable because it runs on the majority of desktops on the planet (not necessarily because it's less secure... a topic for another blog entry, perhaps...).

Thing Number 4:

Apologies for the tone at the start of this blog entry. Nothing torques me more than this sort of abuse of people and technology. And this entry discusses bad people using technology to abuse others!

Thing Number 5:

If you send a link to this post to everyone in your address book, something wonderful will happen to you during the next week. ;)    (... definitely a topic for another blog entry...)

:{> Andy

Technorati Tags: Developer Community Spam Virus Email

Database Coding Standards

Brian Kelley, noted author and database guru, offers insight on the necessity of T-SQL coding standards in this post.

"While they had naming standards for table, views, stored procedures, and other database ojects, nothing actually covered how best to implement stored procedures or what kind of T-SQL was acceptable and what needed to be justified."

Coding standards are always a difficult subject to address. I've had positive and negative experiences with them.

I've seen organizations create them in response to a coding tragedy, and I've seen organizations abandon them in response to the inflexibility of the standards.

Simply establishing a list of rules won't solve any real-world issue - at least not for long. This is especially true in the world of software where things change early and often. Coding standards need to be maintained. I believe a brief review of coding standards should be included in any project wrap-up / post-mortem process. It doesn't have to consume the meeting - it shouldn't, in fact. And it shouldn't be a philosophical debate; but rather a practical discussion of what the standards helped, hindered, or didn't address in the project.

:{> Andy

Technorati Tags: Coding Standards T-SQL SQL Project Management

Identity Management

Joel Spolsky runs Fog Creek Software and writes really cool articles on his blog.

He knows how to manage talent and has an excellent article on the Identity Management Method posted at his site. It's worth a click!

:{> Andy

Technorati Tags: Joel Spolsky management talent identity management

The Words We Use 3

Another episode in my Tales From The Under-belly of Business Communication series...

This actually happened to me.

A few years ago, I was toiling diligently on a data warehouse project, while the company for whom I was toiling was going public. I was a contractor in a temporary-to-permanent position. The rules were pretty clear: "Make it work and we'll hire you." Cool.

So I'm hammering away one morning when a young lady from HR shows up at my cubicle entrance with a gift to celebrate the company's IPO - and to express the company's appreciation for my contribution to thier success. She smiles, asks what I'm working on, I tell her, she smiles again, gives me the appreciation gift, moves to the next cubicle entrance, rinse, repeat.

"Cool" I think and go back to work.

But she returns about 10 minutes later - looking concerned. "Are you a temp?" she asks. "Yep" I respond. She reaches out and takes the appreciation gift and stammers "These are only for permanent employees" before leaving the cube looking very embarassed.

I felt bad for her. Really, I did.

I understand the company wanted to express its appreciation to the folks that had contributed - and were continuing to contribute - to its success. I think that's a good idea, in fact.

I also understand they probably only produced a limited number of the appreciation gift items - one for each full time, permanent employee. This meant I would have been taking someone else's appreciation gift had the young lady from HR not returned to reclaim it. All well and good.

What I do not understand - and this isn't a criticism as much as an admission of ignorance - is why the company* treated me as a second-class individual.

*I did not name the company for two reasons: they're a good company; and I experienced similar treatment as a contractor at almost every company I've contracted.

:{| Andy

Technorati Tags: Software Business Communication Contracting Contractor

The Words We Use 2

A friend is employed at a company with "an open door policy". According to my friend, this policy means anyone, at any time, can walk into any manager's office to discuss any issue.

My friend overheard a manager speaking to another employee about yet another employee complaining to the director about the manager (take that Mrs. Eppes, my second grade English teacher who taught me the meaning of the term run-on sentence!). The manager used the verb "open-doored" to describe the incident.

This is a clue.

If your organization has such a policy and this verb exists in the collective vernacular, then you have a failed policy.

Think about it. The purpose of an open-door policy is to provide a channel for immediate feedback on pressing and/or otherwise important issues. Let's face it: Stuff happens. One thing that distinguishes effective management from ineffective management is accepting this fact. When there's no Stuff going on, everyone looks like a great manager. It's when a manager has to manage Stuff that the metaphorical men are separated from the metaphorical boys.

An open-door policy is one tool to accomplish Stuff Management. When properly implemented and correctly understood, it provides instant feedback on matters that require immediate attention to people in a position to effect the required change. When improperly implemented and misunderstood, it becomes more Stuff.

:{> Andy

Technorati Tags: software Business Words We Use Open Door management

Database Professionals Required - A Followup

There's been some interesting responses to my earlier post Database Professionals: An Enterprise Requirement.

Brian Kelley, noted author and database guru, expanded on the post twice: first in Does your organization need a DBA? and again in Does your organization need a DBA? (Part 2).

Frank La Vigne responded from the developer perspective with Yes, You Do Need a DBA.

:{> Andy

Technorati Tags: Database Professionals Need a DBA SQL Server Frank La Vigne Brian Kelley

Database Professionals: An Enterprise Requirement

A friend (who shall remain nameless) recently told me his company interviewed a competent database developer and DBA. All seemed in agreement an offer would be forthcoming until the very end of the recruiting process. At that time, someone made the comment "we don't need a DBA."

It would be notable if this sentiment wasn't so widespread - but I see it often. How often? Well, I would have to tell you how I see it to qualify that statement:

You see, people rarely say to me "We don't need you because we don't need a DBA." Mostly I see it in their applications - many of them prominent companies in which you may even own stock. I can tell when I examine their schema. I can see it when I execute Profiler against their SQL Server database.

Now, there are lots of reasons to design a denormalized schema. And there are lots of reasons to encapsulate the business rules in code. This is not what I'm talking about - though some of these systems would clearly perform better (or at all, in extreme cases) if they took advantage of better design patterns.

I'm talking about designs where this much is obvious:

1. At least two people designed the data layer; and
2. They did not communicate during the process.

Often, enterprise-level database design is shoveled onto developers as a secondary task. No, I'm not making this up - it's too tragic to joke about. There are developers out there who can handle this task, but they are few and far between. (Before I became a SQL Server DBA I was a developer who thought I was a SQL Server DBA...)

There will doubtless be readers who can provide examples of how their enterprise application was built by junior developers who did the database and code work and whose systems are performing just fine. I'm happy for you and sincerely hope the system scales. 

Designing a scalable solution  - database, application, or architecture - is one of those things that consumes time, thinking, resources, and money during the early phases of an enterprise development cycle. But it is - hands down - one of the best (if not the best) investments in the solution. And in today's market, scalability is as optional as security. And like security, a scalable design is not something you "add later." It's not part of the foundation - it is the foundation.

My experiences with designing scalable solutions has proven to me there is no free lunch nor any shortcuts that work. If anyone - me included - skips the work of designing for scalability, there comes a day when they (or I) must pay the fiddler. From what I hear and have experienced, designing in this fashion is most often sacrificed on the altar of a deadline. Trust me, if it falls apart in six weeks or six months, you haven't saved any time - and you may have lost a customer.

Someone told me this and I remember because it has proven true several times over: "Deliver quality late, no one remembers. Deliver junk on time, no one forgets."

If you're building (or upgrading to) cutting edge technology, you need a DBA.

:{> Andy

Technorati Tags: Software Business scalable database design quality

Windows Genuine Advantage vs. Privacy

Steve Jones has an interesting editorial about WGA () at SQLServerCentral.com.

Like many of you, I too earn a living implementing Microsoft software. In addition, I've openly declared my admiration for Bill Gates as an individual and Microsoft as a company in an earlier blog.

That said, I think this is a huge mistake. I believe Microsoft is capable of doing a better job fighting piracy at the expense of privacy, and I believe they should.

Several comments in this interview with Peter Cullen, Microsoft's Chief Privacy Strategist, smack of the Sony rootkit debacle - including "phone home" functionality (that has since been removed from the product).

:{| Andy

Technorati Tags: WGA Microsoft Developer Community

...on Children, Laptops, and Kool-Aid

Fact 1: My bride Christy and I have two wonderful children: Stevie Ray (3 years) and Emma Grace (14 months).

Fact 2: Because I am a geek, we also have approximately 14,312 computers in the house, some of which are laptops.

(We also have two cats - not because I'm a geek, but because I'm lazy and you can always turn a cat out and he or she will eventually find something to eat and eat it rather than starve... I admire that. The cats are named Rex [male] and Rufus [female]. I named Rufus. I don't get to name any more mammals at our house...)

Fact 3: The aforementioned children consume mass quantities of Kool-Aid on a daily basis and have managed to spill it in every square foot of the house floor, the walls from the three-foot mark down, and a couple ceilings (I don't know how) several times each week - much to the chagrin of the aforementioned cats, who hate kool-aid-sticky-paws. But then they lick it off and look at you as if to say "Mmm! Kool-aid!" Cats also change their minds approximately every 14 milliseconds, which makes them fun - or at least interesting - to have around.

You may have already guessed the inevitable: one of the kids decided to place their cup of Kool-Aid on Mom's laptop. And, in an effort to protect the $0.19 cup from the harmful effects of prolonged Kool-Aid exposure, decided to turn the cup over, storing the Kool-Aid inside Mom's laptop which is filled with empty spaces that - it turns out - will hold about half a cup of Kool-Aid which - it turns out - is about how much was left in the cup. Looking back on it, the engineering was impeccable. It warms my heart just to think about it.

At this juncture, the laptop produced several abnormal sounds. I was at work and my bride was out of the room for a moment, but it was abnormal enough that a 3-year-old (Stevie Ray) knew something wasn't right - and promptly alerted his mother that something was wrong with her "ka-pewter".

Christy shut the machine down, tipped and emptied it of Kool-Aid (I think it was grape - aka "bape" Kool-Aid), and called me.

I'm an engineer at heart. Nothing warms the heart of an engineer like a good old-fashioned smoke test. "Fire it up and let's see what happens!" I advised.

It actually booted, sounding much better after draining. But no display. Great.

My mind immediately flashed back to the young man at the electronics superstore asking me if I wanted to buy that $200 extended warranty, the quick odds calculation I'd computed, and my answer: "No - I'm an engineer! I don't need no steenkin extended warranty!" I am such a funny guy - I kill me. Well, I feel like at least kicking me... now.

I tell my lovely bride to leave the laptop turned off until I get a chance to work on it. Which will be in approximately 30 hours. I have to drive to northern Virginia to speak at the Cap Area .Net Users Group meeting that night and will arrive home around 1:00 AM. I'll get up at 5:30 AM (sleeping in an hour...) to head in to work, so it'll have to wait until the next evening.

She tries it later and it works. It's still working. I'm so impressed I'm mentioning the product line and manufacturer. It's an HP laptop. We've had this one for about two years and it's survived other spills, as well as the aforementioned cats "loving" it (covering the keyboard and clogging the fan with fur) and now this. It's a tough box and has earned my admiration.

Good job on this laptop, HP.

:{> Andy

Technorati Tags: Laptop Kool-Aid Children HP

Bill Gates Announces Stepping Aside

I'd be remiss in my blogging duties if I didn't take a few moments to reflect on yesterday.

I'm an old-timer in computer years. I'm a few years younger than Bill Gates, but I started writing code a couple / three years after he did (I started in 1975 when I was 12). Computers have changed a lot since then. And a lot of those changes can be traced directly or indirectly back to Bill Gates and Microsoft.

I rarely meet someone in IT these days who doesn't have an opinion about Bill. Some hate him and others love him. Critics have been less vocal as Bill and Melinda have poured so much of themselves and their money into the Gates Foundation.

I have always admired Bill. He cofounded a company and co-led it from a couple geeks to a huge corporation. More than any other company - including IBM and Apple and Sun - Microsoft has worked to bring the power of personal computers to the masses. They are rarely first, and they don't always get it right on the first attempt, but they do a couple things better than most competing companies: 1) deliver value; and 2) integrate.

I'll start with integration. The idea of how integration works can be seen most recently in Team Foundation Server and Team System. Project management, software development, testing, and quality reporting and control are all now integrated into the developer's IDE and available to all in the enterprise via Reporting Services and Windows Sharepoint Services. This is just the latest example - there are lots more. What struck me early on as I began working with Microsoft Office was how much I learned about Excel while learning Word - and vice versa. That's integration too. An idea in one tool translates to all tools in the suite. And Microsoft has always integrated very well.

Then there's value. Microsoft software is roundly (and rightly, sometimes) criticized for security gaps and software bugs. But no one complains about the price. The reason? Microsoft software is a darn good deal! It always has been. When comparing bang-for-buck, there's always a sector - a large sector too - of the business community where Microsoft is simply the best horse on the track.

From a business perspective, I believe the comments made yesterday at the press conference: they've been planning this for some time, and the company will continue to innovate, lead, and consume marketshare. For Microsoft, I don't see this as devastating or even necessarily a bad thing.

For me personally, there has always been a sense of comfort and confidence in the knowledge that Bill was there somewhere with his hand on or near the rudder.  I'll miss that sense of comfort, but I have confidence he wouldn't hand leave the company in the hands of incapable folks. And I believe he's leaving Microsoft in very capable hands.

Personally, I wish Bill and Melinda all the success in the world with the Foundation. To Bill, I would just like to say, "Thanks."

:{> Andy

Technorati Tags: Bill Gates Microsoft Software Business Developer Community

Software Development... and searching for your car keys

I'm big on analogies. I believe good analogies are powerful teaching tools. And, of all the jobs and projects I've worked on or at, teaching at ECPI was the coolest - hands down.

While teaching basic electronics at ECPI, I once built a bridge rectifier out of LEDs (light-emitting diodes). A bridge rectifier converts alternating current (AC) to direct current (DC). It does this by switching the path of the alternating current and then summing the result. (Failure in my attempt to simplify this concept duly noted...)

If you haven't gathered it from reading the above paragraph, this is not an easy concept to grasp by simply reading about it.

But...

If you use LEDs, they glow when the current is flowing through them. In my lab, I used a function generator set to output a sine wave running at about 1 Hz (1 cycle per second). The students could then watch as opposing pairs of diodes conducted the applied AC - converting it to noisy DC, as all bridge rectifiers do.

It was (and is) a great analogy.

In developing software, I routinely (pseudo-) multitask. I don't actually multitask. My beautiful bride can attest to the fact that I'm quite incapable of thinking about more than one thing at a time. I pseudo-multitask by time-slicing. I work on task 1 for a bit, then task 2, then task 3. Three tasks seems to be a good fit - for me, at least.

I've worked through about eighteen task 1's and task 2's recenty while tackling a tough task 3. I won't go into details - there will be a blog about it here soon enough - but it wasn't difficult technically, it just stumped me.

I found the solution this morning and fixed it. Where was the solution? The last place I looked! :)

Herein lies a secret to software development: Don't give up. Make the problem give up before you do.

So if you're faced with a particularly difficult bug today, or any day; just when it gets so frustrating that you do not believe you'll ever solve it, take a break. Grab some green tea, go for a walk, get out of the building. Put your mind on something else for ten minutes. Maybe time-slice onto another task when you return.

When you get back to the issue or bug, you'll have a fresher perspective. And you will find it.

It'll be in the last place you look.

:{> Andy

Technorati Tags: Software Development Development car keys Developer Community

The Words We Use

This isn't a rant, it's a confession.

A popular, albeit opinionated, radio talk-show host sometimes says "words mean things." He's right (pun intended) - they do.

I use words quite often - speaking and writing professionally, business communications, websites, articles, and blogs. Sometimes I use less appropriate words than at other times. If the words remain under my control, such as on this blog or one of my websites, I can edit out the less appropriate words for better words when I realize my error. When I click the Send button on a business email, however, it's almost always impossible to correct inappropriate words contained therein.

When I use inappropriate words, I tend to follow a pattern. It's not that the word can't mean what I intended to communicate - it's a combination of it rarely meaning what I intended along with there being a much better word for expressing (or expressing more of) the thought. Some examples may help:

Word(s) I Use               Better Word(s)
Difficult                         Important
Wrong                           Incomplete
That's not possible          I don't understand
Wrong                           Different

You see? Call it a mid-year resolution - as opposed to a New Year's resolution: I resolve henceforth to use the best words for each situation.

:{> Andy

Technorati Tags: Software Business Business Communication

You never know...

"You never know..." This is one of my Mom's favorite things to say. She says it most often when talking about treating people politely, because "you never know when you're going to cross that person's path again, Andy Ray." Mom calls me Andy Ray when she's trying to make a point.

And Mom is right. You never know what the future holds, so it's best to always treat people as you wish to be treated.

On the way into work this morning (circa 4:45) I stop at a local gas and grill establishment for a sandwich and some coffee. I'm wearing my Jax Code Camp speaker's shirt today and the young man behind the counter notices it. He asks, "What does MSDN stand for?"

"Microsoft Developer Network," I respond.

"What's an MSDN Code Camp?" he asks.

"It's a free event where local and regional developers present information about current and emerging Microsoft technologies to other developers. An MSDN Code Camp is happening in Richmond April 22 at the ECPI Moorefield campus, if you're interested."

"I am interested!" he responds as he manually advances the cash register receipt roll so he could jot down the info. "I've been working mainly with Linux, but I'm interested in learning more about Microsoft development."

"Aprill 22" I tell him, "at the ECPI Moorefield campus in Richmond. The website is RichmondCodeCamp.org."

I hope to see him there. This zealous young man may write the next killer app. You never know...

:{> Andy

What should be on an IT resume?

The purpose of a resume is to get an interview - period.

So what should your resume contain? Experience leaps to mind. Education looks good also. What about an abstract? or job objective? or even your "perfect" or "dream" job?

Many experts say all this and more.

My limited experience searching for qualified DBAs has lead me to believe the search for candidates is either feast or famine. Either you cannot find anyone - qualified or not - or you're deluged with qualified resumes.

So what do I look for in a resume?

First, an indication of experience. Experience is probably the most important thing for DBA work. Second, I look for... ok, all I look for is experience on the resume. If I see some, I'll schedule a phone interview.

:{> Andy

SOx

I received an advertisement brochure recently. Prominently displayed on a front page was section was this eye-catching question: "Is compliance taking over your life?"

I responded (out loud, even): "Not anymore."

It occurred to me how less stressed my professional life is now that I am working for a private firm. The stress from my former Fortune 500 corporate experience was due in large part to Sarbanes-Oxley compliance - or rather the interpretation of Sarbanes-Oxley compliance.

Whether you agree with the legislation or not, most admit there was clearly a need to do something in response to the WorldCom and Enron scandals. So, something was done. Personally, I believe the legislation attacks the wrong side of the equation for this reason: there were already laws on the books to address the crimes committed at these corporations. If Congress truly wants to protect investors, educate them. And if Congress simply must pass a new law, pass legislation requiring investors become certified before being allowed to invest in publicly traded companies. (Step 1: A DVD of me pointing at the camera, screaming "YOU CAN LOSE ALL YOUR MONEY IF YOU PUT IT IN THE STOCK MARKET... ALL OF IT!!! DO YOU UNDERSTAND?!?" Step 2: Sign the document acknowledging you understand what you learned at Andy's School of Investing.)

But I digress...

While I was enduring the stresses placed upon a sole database administrator group manager by internal auditors, a colleague mused: "Those can, do. Those who cannot, teach. And those who cannot do or teach, audit." That was mean (...apologies to all my auditing readers out there...), but I think I understand the underlying sentiment.

Given the tools on hand, we were faced with unpleasant choices:

1. Cease supporting business operations. It was simply not possible to comply and execute DBA tasks required to keep the business running. Without naming industries, companies, or names, ceasing support would have meant hardship to thousands of people already enduring enough hardship and economic loss to literally thousands of others.
2. Refuse to comply. Which would have solved several stressful issues but created a few more - such as how to pay the bills, eat, etc.
3. Lie. I could break my personal code of ethics and possibly the law of the land, and misrepresent the facts of the matter.
4. Be honest. And take the ensuing whoopin'.

I chose to be honest. My reward was pressure from every imaginable angle.

From business, sales, and accounting, "Why can't you just comply and end all this?"

From auditors, "We will have to report this to _____. They will open an incident. It will be filed with the SEC. It will be made public."

From executives, "Make this go away."

It was ugly. And it all stems from an open season on business data. Heck, the auditors at my former employer were reaching into the personal development databases of developer workstations. I understand some of it, but not all.

I'm interested in your thoughts on the matter. Have any of you had similar experiences with SOx compliance?

:{> Andy

What motivates you?

Thomas Edison said "Genius is 10% inspiration and 90% perspiration." (Edison was a renowned workaholic... in competition most of his career with another type of genius, Nikola Tesla...)

Is this accurate in modern IT? If so, what motivates you to put forth that 90%?

Is it money? fame? the rush that accompanies watching your efforts execute in Production?

I've created a thread in the forums for responses.

:{> Andy

Gatekeeper or Roadblock?

Which are you? Gatekeeper or roadblock? ... or none of the above?

When it comes to database work, both stop "things" from occurring. Here's a couple/three questions I ask myself when my knee begins its pre-jerk twitch:

1. Are we in the data-protection business? Does this business in general - and my job specifically - exist solely to guard this data from everyone? I am still quoted at a manufacturing facility. I once said to a network engineer: "I understand, we're a network company. Apologies if all these ____-making efforts are getting in your way." (... for some reason, I no longer work in manufacturing...)

2. Does this request support or provide business value? Not: Is it a duplication of data? or even: Does it violate 3rd normal form?

3. Perhaps the most important question when I truly disagree with the request (which is rare, mind you): Is this battle worth fighting?

I consider myself a little of both gatekeeper and roadblock, at times. Mostly, I see my DBA role in the IT department as facilitator. When someone shows up with a request, I endeavor to help them succeed.

How about you?

:{> Andy

More on Leadership...

Found a great article on Everyday Leadership.

:{> Andy

Soloists vs. The Choir

I discovered blogs a few years ago reading Eric Sink's blog, Eric.Weblog(). I was led to his blog by his regular columns on the  (the series is still posted there): The Business of Software. For those who do not know, I once earned my daily bread running a small business. Eric expressed things about the software business that I had learned (or wished I'd learned) during that time. His blog remains at the top of my bloglines favorites - right next to Joel Spolsky - legend and founder of Fog Creek Software - whose blog I discovered through links on Eric's blog (isn't the internet wonderful?). The thing I admire most about these guys is their obvious passion for the business of great software development.

During the summer, Joel posted an awesome tome entitled Hitting the High Notes. In it, he delves into one motivation for starting a software company in the first place: "building the company where the best software developers in the world would want to work." Joel's premise is the Best Working Conditions lead to the Best Programmers which lead to the Best Software which leads to Profit! His post deals with a cornerstone of this philosophy: Is there really that great a difference between good and great programmers?

Joel cites some impressive statistics gleaned from Yale Professor Stanley Eisenstat, who teaches a software development class. The scatter plot says it all.

As Joel notes, "There's just nothing to see here, and that's the point. The quality of the work and the amount of time spent are simply uncorrelated." His conclusion: "You can't afford to be number two, or to have a 'good enough' product. It has to be remarkably good, by which I mean, so good that people remark about it. The lagniappe that you get from the really, really, really talented software developers is your only hope for remarkableness." (For my fellow vocabulary-challenged readers, lagniappe means "an unexpected added benefit." I had to look it up... isn't the internet wonderful?)

Please read the post in its entirety, I'm sure you will get more out of it than this summary provides.

A couple months after Joel's post, Eric responded with a post entitled My Comments on "Hitting the High Notes". Eric's post emphasizes the importance of teamwork in developing great software. The contrast in the two paradigms is summed in three paragraphs:

"For a soloist, hitting the high notes is an essential skill.  In a choir, the essential skill is the ability to blend.  Some of the most gifted soloists just don't have the stuff it takes to fit in a really great choir. 

Sometimes, they can't blend.  Their voice is the problem.  A really distinctive voice is an asset to a soloist but is a disadvantage in a choir.  They can't blend because that's just the way their voice is.

More commonly, they won't blend.  Participation in a serious choir requires a generosity that simply is not present in everyone.  Choir members don't get individual accolades or fame.  Soloists do."

The remainder of Eric's article answers the question: "So are you saying we should forget about the high notes?  Certainly not.  I am not suggesting that you hire 'mediocre programmers'." His conclusions (summarized by me):

1. "Be it a choir or a team, you want every member to be at the highest possible talent level.  But the people on your team have to be willing and able to blend."
2. "Great developers don't just make the product better -- they make everybody around them better."

Again, please read Eric's post in its entirety for the full effect.

I am interested in your thoughts on the matter.

Is solo talent the key to great software development? Is it team talent that leads to greatness? Or is it some combination of the two? Is such a combination possible and/or necessary? What do you think?

My two cents:

My experience has shown results matter - regardless of your market. But - and this is key - markets are different.

If you are, or work for, a small software shop, your results are directly tied to the consumer of your software products. This is your market. You don't have to guess whether you did a good job or not - you merely need to examine the corporate checking account.

If you work for a larger firm as part of an IT department, your market is comprised largely of internal customers. Internal customers consist of business people and analysts of all sorts, shapes and sizes; most of whom have or are seeking advanced degrees in business or marketing. This is your market. Your measure of success is feedback from these good people.

To sum:

• Small software company, consumer, bottom line is your critical success factor (CSF).
• Larger organization, MBA, feedback is your CSF.

Herein, I believe, lies a cultural disconnect.

Teamwork is essential in a large organization. If you cannot "play well with others" you will find your(talented)self out of corporate life quicker than you can say "I hate Microsoft" or "Open source rules." And yet, why can't we find a way in the corporate world to professionally and successfully manage talented, yet difficult, people?

My friend Mike Potts, the Efficient Coder, perhaps characterizes the bane of the coporate coder best in his essay entitled Where are you OOP??: "Developers in these shops are typically doing all they can just to meet their deadlines, probably have a very low team morale with hardly enough time to do their jobs much less truly analyze anything. A little Psycho meets MS Project."

Is managing talent that hard?

I've been a manager a couple times - most recently in the IT infrastructure for a large corporation (trust me, you would recognize the slogan...). I can criticize my peers and myself alike for errors handling talented individuals - but managing talented individuals comes down to some simple, yet often difficult, concepts:

• Don't do anything stupid.
• Don't tick off the talent.

Actually, ticking off the talent is kind of stupid, so Concept 1 would probably suffice.

Sometimes, however, the scales tip in the opposite direction and the talented individual hijacks an organization (or appears to) as discussed in this thread.

My experience managing talented people has been double-edged. It's great when you find a way to communicate the harsh realities of corporate culture in a manner which actually penetrates the talented psyche; and it cuts like nothing else when you fail at this endeavor. My practical advice to corporate IT managers:

1. Don't be intimidated by talent - lead it.
2. Communicate the (sometimes harsh) realities of the current corporate culture to your team - then challenge institutional bureaucracy at every opportunity.
3. Greet individual or team success and failure with a predictable and balanced response - and protect your team members from unpredictable and unbalanced responses. Remember: You must be free to fail before you are free to succeed.

:{> Andy

PS - Every IT manager (ok, professional) in large corporations should read Career Calculus - another great post by Eric Sink.

Want to Double Your Salary?

Catchy title, eh? :)

Salaries are one side of a trade. A salary is presented to you on a semi-regular basis from a business venture or organization. Most of us consider salary when choosing with which business venture or organization we should spend our time and effort - because time and effort are what we bring to the table.

The other side of the trade is what you bring to the organization. What do you do with your time and effort that helps the company achieve its goals and objectives? The key concept here is business value. (Apologies... the image of the banner from the movie Office Space proclaiming "Is this good for the company?" keeps popping into my head...)

The balance between these two forces of business physics - business value and your time and effort - determines your salary. (Perhaps that's naive. It's more accurate to say your understanding of these forces of business physics determines your salary. Increasing your understanding is the purpose of this post.)

Although you may learn nifty things at work and enjoy learning, businesses are not training centers. If you want to learn new, cool, and exciting things, there are places for that sort of thing - they're called "schools." If it's recognition you seek, try a book or speaking at seminars - or even starting your own website.

This may come as a shock, but businesses exist for the sole Gordon-Gecko-esque, Ebeneezer-Scrooge-ish purpose of making money. Work is a place to get things done - to accomplish things that bring business value - which in turn increase and/or sustain the amount of money flowing into the business. "Is there business value in learning and recognition?" Absolutely! Businesses wouldn't waste resources on these activities without a return on the investment.

"So, Andy, I'm confused... are you saying businesses should or should not engage in training and recognition?" I'm not talking about whether business should or should not do anything. Rather, I am attempting to explain some harsh realities regarding life in the business jungle. The brutal fact is: Businesses engage in these types of (expenses) activities as a means to an end - and that end is not solely to make you feel better about yourself. The reality of the goal is something closer to: "If you feel better about yourself and your job, you are more likely to produce more business value with your time and effort." It's not as much about the what as it is the why.

The software Business should be considered as it is addressed here - software with a lower-case "s;" Business with a capital "B." It is a Business first. Please keep that in mind.

The software Business has matured to adolescence at best. This presents a set of issues unique - but surprisingly predictable - to adolescent industries. Other industries have matured in the past. They offer models of the phases (into which I will not delve here) through which all industries grow. The current, adolescent state of the software industry is somewhat analagous to the American West - just about the time some semblance of law and order arrived on the scene - or the early years following the industrial revolution. My mother (who raised four "rambunctious" sons to adulthood - no small feat for any woman) would describe it as "scrappy."

"So, Andy, how do I double my salary?" you ask? "Quadruple your value - and split the difference."

"Lovely advice. How does one accomplish this?"

"I'm glad you asked."

You can be a good DBA. You can be a good coder. You can be nice. You can be fun. You can practice good hygiene (I hope you do, in fact!). You can get to work early and stay late. All well and good - but what have you done for the business lately?

Again, brutal.

Again, true.

We, as technology professionals, get paid to think. So how do we think better? One method is more familiar to technology professionals than others (but there are many ways to "think better" <-- loaded term, by the way...): Think about scale.

Enterprise technologists deal with scale daily. It's something we're uniquely qualified to comprehend. We usually learn about it as we watch the best laid plans of mice and men go awry right before our deploying or disaster-recovering eyes.

Does "scale" scale? Why, yes it does. It scales right out of our little (lower-case "s" software) world and into the (capital "B") Business world rather nicely. In fact, some business theory relies heavily on concepts of scale in organizations. At the very least, we should be among the first to identify a scaling business issue.

"Specifics, Andy - give me specifics!"

Ok.

How do you know your enterprise application has reached the limit? What are the symptoms of it maximizing its potential? hitting the wall? dashing itself to pieces against the rocky coast of your competition? For one, the "old way" - the way that has worked so well for so long - stops working. Processes bog, traffic slows, complaints mount, crises loom. Have you ever seen this in software? Have you never seen this in Business?

Your response requires strategy. Business Strategy For Geeks is a topic for another post. But simply recognizing - and effectively communicating - issues of scale will add to your business value. And it's really as simple as applying skills you already possess in a different field.

There is opportunity for you to improve your business value to your current orgainzation. As such, there is also opportunity to increase your current salary. It is a trade, after all.

:{> Andy

On Leadership, part 1

I started a blog months ago to discuss the software business, but haven't really done a good job maintaining it. There are several drafts saved out there that haven't been posted, so I thought I might post them here. This is one of those posts.

My favorite play is Shakespeare's Henry V. One of the main reasons it's my favorite play is the inspiring example set and maintained by King Harry as he leads his band to victory against impossible odds.

While I find the battle scene at the end of Kenneth Branagh's 1989 compelling, the king's speeches during the bleakest of circumstances make the plot, in my humble opinion.

I post the following quote by the Chorus from the Prologue of Act IV, as the English camp at Agincourt, outnumbered and preparing to battle the French the following day:

The poor condemned English,
Like sacrifices, by their watchful fires
Sit patiently and inly ruminate
The morning's danger, and their gesture sad
Investing lank-lean; cheeks and war-worn coats
Presenteth them unto the gazing moon
So many horrid ghosts. O now, who will behold
The royal captain of this ruin'd band
Walking from watch to watch, from tent to tent,
Let him cry 'Praise and glory on his head!'
For forth he goes and visits all his host.
Bids them good morrow with a modest smile
And calls them brothers, friends and countrymen.
Upon his royal face there is no note
How dread an army hath enrounded him;
Nor doth he dedicate one jot of colour
Unto the weary and all-watched night,
But freshly looks and over-bears attaint
With cheerful semblance and sweet majesty;
That every wretch, pining and pale before,
Beholding him, plucks comfort from his looks:
A largess universal like the sun
His liberal eye doth give to every one,
Thawing cold fear, that mean and gentle all,
Behold, as may unworthiness define,
A little touch of Harry in the night.

I don't pretend to understand all Shakespeare is conveying in this passage, but I get these parts:

• Things are bad.
• Things look like they're going to get much worse.
• Many of us have had mornings where we sat patiently by a watchful monitor, inly ruminating like a sacrifice.

But then the coolest thing happens - the king makes his rounds during the middle of the night. He offers the most basic of encouragement to the troops: he speaks to them as if nothing is wrong - referring to them as "brothers, friends, and countrymen."

Sometimes effective leadership comes down to showing up, ignoring the bad stuff, and acting normally.

:{> Andy

Which "flavor" DBA are you?

   I received a cool compliment today from a peer who's a developer. He said, "You know, I really like having a DBA on my team!" I have to tell you, it made my whole day!

   It led to a discussion about past experiences and expectations, and I shared something I thought was pretty much common knowledge: there are three types of DBAs. My peer was shocked, so maybe the knowledge isn't so common after all.

   The three "flavors" of DBAs I define are:

1. System, Operations, or Production Support DBAs - these DBAs write maintenance plans in notepad and have no qualms whatsoever about executing in command-line. They were DBAs in the old days, when we carved our own ICs out of wood. They will get your server and database back online fast - and with less data corruption than anyone else on the planet. They live for torn pages and I/O faults.
2. Application Support DBAs - these DBAs are familiar with one or more (usually complex) applications. I'm talking PeopleSoft, Seibel, and SAP here. If you want to customize a screen or write a one-off web application, you desperately need these folks.
3. Database Developers - these DBAs are ruthless bit-heads. They use bigint and byte fields for masking binary states. They can optimize a stored procedure in their sleep and wrap an API around a database so developers never have to consider writing SQL that directly hits tables. They are performance freaks that will work 18-hour days on weekends to test in Production - when it's "safe."

   Do you think DBAs fall into these categories? Do you know any that do? Do you see yourself in there anywhere? Do you have more or less or different "flavors" for classifying DBAs? 

:{> Andy

Technorati Tags: Sql Server DBA flavor

Are you happy with your job?

I am elated with my job. I'm a geek who enjoys business stuff, and I'm employed as a DBA manager.

Are you happy with your job?

The good folks at AGreatResume.com posted an interesting blurb about job satisfaction survey results by career. They collect this data each quarter and publish interesting trends.

:{> Andy

It's All About...

Occasionally I'll overhear a conversation regarding software. This usually happens at work, but I sometimes overhear them at lunch when a gaggle of geeks at a nearby table discuss software. Being a geek, I sometimes participate in like discussions about software design. It's all well and good until someone's pet language or methodology gets bashed... then watch out! [:)]

I wasn't always a DBA. Being a recovering engineer ("Hi. I'm Andy and I'm an engineer..."), I find pragmatic dialectic (Socratic, not Hegelian) on such topics enlightening and/or frustrating.

It gets interesting when someone stakes out a position regarding the most-important-thing for successful software design. An example: "It's all about the interface." I use this example because I've said this in the past - and used to believe it.

Why does it get interesting? We all have opinions - supported by examples and sound logic - about the ingredients of successful software design. People much smarter than I have written more wisdom on the subject than I will here, and I will not disagree with them.

I no longer think it's all about the interface, I think it's all about everything.

But I want to discuss the interface, why I used to think it was so important, and why I no longer think that:

Interface is the layer the user sees and interacts with. My influence for interface design is Alan Cooper. Early in my professional software career, I read . Cooper's passion influenced me dramatically and changed - ok, started - the way I approached interface design.

My logic at the time: Build a great middle and backend with a crappy interface, no one will want to use it; build a great interface with a crappy middle and/or backend, and it will sell. Mind you, I can provide market examples - even today - to back up this philosophy.

Why do I now think great software design's about everything and not just the interface? Good question. My best guess is I've seen good examples of all-of-the-above development efforts. I've even had the opportunity to participate on some good software design teams (I work with a great team now, in fact).

Another guess: Having more recent experience with the data layer, I get to see more of the performance and stability spectrum than was previously visible to me.

It's all important. Interface, business layers, service and object brokers, data layer. If it doesn't all work well, and work well together, the result is crappy software. And who wants to use crappy software?

:{> Andy

Performance-Based Organizations

Performance-Based Organizations (or PBOs) grew out of manufacturing into the technical sector. The message prompting the shift was "Hey, we tried this and got results." Unfortunately, no one communicated the details of those results - especially in IT.

I spent some time in manufacturing. As anyone who's been there can tell you, industry is demanding and very what-have-you-done-for-me lately in nature. Results rule each day.

The studies performance-based promoters seize upon are those conducted on the menial workforce. I do use the term "menial" in a derogatory fashion - I simply mean the work is done mostly by hand, foot, body, eye, ear, etc. If I'm going to offend you, it will be here: The work is repetitive in nature and therefore allows the worker to optionally engage in the work intellectually. In other words, performance-based work is that which focuses less on innovation and creativity and more upon, well, performance of a task.

When I was in manufacturing, PBO provided outstanding metrics for the shop floor: Widgets / hour, Defects / 1000, etc. When manufacturing leadership attempted to apply this new-found measurement methodology to knowledge workers it failed miserably. That part of the message isn't making it into the books I've read on the subject.

Don't be deceived - there are some recognizable acronyms among those proffering PBO to the software industry.

One application of PBO states your workforce can be divided into three categories: the Top, Middle, and Bottom performers. Typically, percentage weights are assigned to these categories, such as 20 / 60 / 20; meaning there's a Top 20, and Middle 60, and a Bottom 20. The wisdom is you can train your bottom 20% all day long and not receive near the return on investment as you would if you trained your top 20%. There are studies to back this - involving menial tasks. The least menial - and coincidentally most quoted - is a study involving copy readers. Reading copy is menial (no offense to my editors). Writing copy is creative and innovative. I'm not judging menial work - nor those who perform it - as something - or someone - less; I'm merely stating the two types of work are different.

I am further stating you cannot accurately measure different types of work in the same way. Here's why:

• How do you score innovation? 
• What about the ability to write code or design a solution that's easier to maintain?
• How do you weight inspiration?
• How about someone who motivates? or invigorates the workplace nearly every day with a combination of vision and mentoring?

How do you effectively and consistently measure these? The short answer is you can, but you truly must weigh the results.

Returning to 20 / 60 / 20: If 80% of your workforce is failing to perform, who's to blame? Did HR hire the wrong 4 out of 5 people? or did HR get it right and the workforce is being horribly managed?

Also, the PBO philosophy presumes the workforce enjoys a Darwinian business climate. A friend in a PBO once remarked to me, "I'm in a competition with members of my own team: a competition I didn't want, I don't need, I did not ask for, and that I cannot escape."

There's a word for people who enjoy a more Darwinian business climate - they're called entrepreneurs. Entrepreneurial pursuits are credited with all innovation. This is simply untrue.

There are plenty of talented people working within large corporations who are as - if not more - creative than their self-employed peers. Part of this is likely due to the fact they're more rested. These innovators work best within the social and economic surroundings offered by corporate culture. They desire to expend all their intellectual capital on more scalable architectures and less tightly-coupled systems, rather than burning creative clock cycles on cashflow and business management. Again, one's not better than the other - they are merely different - except on the scales of a PBO.

...a lighter subject next time, I promise...

:{> Andy

blAndySql

:)

A little Hungarian (or pseudo-Hungarian) notation is a nice touch to get us started, I think...

...and this blog will contain things I think about, questions I have, and thoughts about answers to these and other questions. It will also contain numerous typos (as I have not yet discovered the spell-checker) and the occasional double entendre - and maybe, just maybe, some humor.

Your responses are encouraged! Initially (at least), I am not moderating user comments. I do this for two reasons: 1) I like free speech and I'm prepared to deal with the consequences for now; and 2) If someone is so upset as to rant about something I have written, this is probably as good a place as any for them to do so.

Ok.

Let's start with the history of Andy Leonard, part 1. I was born... wait, not that far back - we'll just skip to the technical highlights. :)

I learned Motorola 6800 machine code the summer I turned 12. That was a few years ago - back when we used to carve our own ICs out of wood. By the end of that year, I was coding in BASIC.

As a hobbyist programmer, I endured years of derision from professionals and peers for "not learning a real programming language." The simple truth was and remains: I've always liked BASIC.

I learned Visual Basic as VB 2.0 was being released and have stayed with the language as it moved into the realms of 32-bit development, classes, and native compilation.

At the time of this writing, I use VB.NET 2003 and 2005 beta for development work and play. Why? I still like it... probably for the same reasons I like chocolate ice cream.

I - like many of you - became a DBA completely by accident. Until very recently, I would not even refer to myself as a DBA (... my opening line at the first interview for my current DBA job: "I don't consider myself a DBA." I'm not kidding.). The first clue that I may, in fact, be a DBA came at the 2004 PASS Summit in Orlando. I told people my job was to tune a 1.6 TB SQL Server 2000 data warehouse so 90 users could write ad hoc queries and then witnessed aghast expressions on the faces of folks whose names I had been reading on TechNet for years.

I can - and likely will - share more about the methodology employed to tune the aforementioned data warehouse in this blog. The secrets to my success lie in my engineering background... digressing a bit:

Programming was a hobby until the 1990's. My trade at that time was electronics technology, which still brings immense enjoyment when I have the time to breadboard. I was lured into manufacturing by the opportunity for more challenges (money) and found a new home in industrial automation. It was here that my hobby became a profession.

After a few years in industrial automation, I decided to strike out on my own. I wrote one of the first completely web-based manufacturing execution systems (MES) and formed a business to market it. Things went well with the business for about five of the six years it was active. Suffice it to say that a general decline in the manufacturing economy created less opportunity for more challenges.

I re-entered the workforce as the tech bubble was collapsing, so it made sense to get certified. The MCSD got me enough second interviews to justify the expense. Plus, heck, I like having letters after my name.

I was born in Virginia but now live and work in Jacksonville, FL. The weather's nicer here - plus I'm a beach person. The coolest part about living in Florida (besides the hurricanes) is calling my brothers back home during the Fall and Spring and asking about the weather up there. They hate me. And since they're all bigger than me I can never return.

So, that's my opening post. Comments? Questions? Bring 'em on!

:{> Andy