Applied Visual Studio Team System : The Developer Community

Attending the PASS Summit

andy — Sat, 22 Sep 2007 08:33:00 GMT

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

Thanks to PASS Attendees!

andy — Fri, 21 Sep 2007 02:19:00 GMT

I'd like to thank the people that attended my sessions at the 2007 PASS Summit in Denver this week! I had a blast and hope you all did as well.

The code will be available from the PASS website and on a DVD. For those in my sessions, I promised I would post the code here for my custom Counts test condition for Team Edition for Database Professionals. Free registration to VSTeamSystemCentral.com is required. The site has been live more than two years. I've sent a total of two emails to registered users during that time. And I never share email addresses - ever.

Extending Team Edition for Database Professionals with custom test conditions is fairly straightforward once you understand it. (Like everything else in life, Mr. Obvious...)

If you are completely new to coding and would like to build a custom test condition for database testing, fear not! The last part of Chapter 4 (entitled Testing the Database) of the Wrox book Professional Software Testing with Visual Studio 2005 Team System: Tools for Software Developers and Test Engineers is dedicated to a beginner's walk-through of building your first custom test condition.

Yes I am promoting my new book. There's a reason: it's a good book.

:{> Andy

Technorati Tags: Database testing Team Edition for Database Professionals Custom test condition PASS

SQLServerCentral.com and Solid Quality Socials at the PASS Summit

andy — Wed, 19 Sep 2007 09:46:00 GMT

I just returned from a night on the town here in Denver! First, I mosied over to the SQL Server Central bash and got to meet lots of interesting people including Steve Jones and Andy Warren - how cool was that!

Steve was busy administering the event but we finally got to meet and talk for a few minutes face to face - well, I had to look up to Steve... he's a tall guy! But I've been looking up to Steve for a while now anyway.

Andy's a wealth of developer community knowledge and it was great to hang out with him and discuss User Group, Code Camp, and SQLSaturday stuff.

Then it was time to saunter to the Solid Quality Mentors party. It was great to finally meet the people who have been writing the books I've been reading all these years! Solid Quality has the most awesome support folks on the planet - it was great to finally meet them face to face! I still can't believe I'm part of this cool organization.

It's now time for another run through the material for tomorrow's presentation entitled Applied Team Edition for Database Professionals.

:{> Andy

Technorati Tags: Solid Quality SQL Server Central PASS Summit 2007 SQLSaturday

At the 2007 PASS Summit!

andy — Wed, 19 Sep 2007 05:19:00 GMT

I'm at the 2007 PASS Summit!

I was wandering around the Colorado Convention Center earlier today in shorts, unshaven, tired... looking like I'd been rode hard and put up wet. But I caught the last half of Gert Draper's excellent presentation on Team Edition for Database Professionals! Gert is the man.

I'm presenting on the same topic tomorrow (yeah, I know - great move there, Andy...) and then on SSIS Development practices Thursday. This promises to be the geekiest week I've had in a long time!

:{> Andy

Technorati Tags: PASS Summit 2007 Denver Team Edition for Database Professionals

Getting Ready For The PASS Summit!

andy — Fri, 07 Sep 2007 21:31:00 GMT

The PASS Summit is less than two weeks away!

I'm getting ready for my presentations. I need a couple laptops to host virtual servers for the demos, so I bought some new gear to take with me.

Check out my Network-In-A-Bag!

It's a power strip, a couple CAT6 cables, power supply, and a NetGear 1G 5-port switch - all in a 1 gallon Ziploc bag.

:{> Andy

Technorati Tags: PASS Summit 2007 Networking

Good Managers

andy — Fri, 07 Sep 2007 20:30:00 GMT

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

Tech bloggers: Heads up

andy — Thu, 30 Aug 2007 14:48:00 GMT

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

Getting Lucky

andy — Fri, 17 Aug 2007 21:28:00 GMT

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

andy — Thu, 09 Aug 2007 15:59:00 GMT

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

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

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

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

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

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

My experiences have led me to a couple thoughts:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

:{> Andy

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

Technorati Tags: Project Management IT Software Development

Frank's Trying To Plan A Wedding

andy — Thu, 09 Aug 2007 07:43:00 GMT

Frank La Vigne is trying to plan a wedding (Congratulations Frank and Roberta!) but ran into an error that appears SQL-related (in method name, at least):

:{> Andy

Technorati Tags: Frank La Vigne Sql Error

Iteration = Maturity

andy — Tue, 31 Jul 2007 14:01:00 GMT

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

Team System Web Access Power Tool!

andy — Tue, 31 Jul 2007 04:08:00 GMT

Microsoft (Brian Harry, actually) announces the availability of the Visual Studio Team System Web Access Power Tool!

Web-based TFS folks - get it while it's hot!

:{> Andy

Technorati Tags: TeamPlain Team Foundation Server TFS Power Tool

Prepping for the Upgrade

andy — Fri, 15 Jun 2007 07:01:00 GMT

As I type this I am working out the details of an upgrade for this blog. If all goes as planned, I'll be moving these existing posts over to a snappy new Community Server instance - where my other blog, Applied Business Intelligence, is hosted.

The folks at GoDaddy Tech Support have been great. No, make that awesome! Like every other competitive IT vendor on the planet, they've been making changes to internal structure and support. One of the more recent changes allowed me direct access to databases containing my value-added applications (like Community Server). Prior to this, I couldn't directly access the databases.

To complicate matters, I'd installed an updated instance of Community Server in another directory on my site. So I had two instances of CS running - one of which I could not reach the files and data (that would be the instance containing this blog).

I would ask them about my Community Server instance and they would respond "It's right there - see it?" And I would have to explain to them I couldn't see one of the instances. It took more than a few emails, but they really hung in there with me, were very professional, and worked with me until I got the data I was after. Kudos GoDaddy Tech Support!

:{> Andy

Technorati Tags: GoDaddy Customer Service Tech Support Moving Applied Team System

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

andy — Wed, 06 Jun 2007 07:01:00 GMT

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

andy — Tue, 05 Jun 2007 07:01:00 GMT

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