July 2005 - Posts

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

BlogLines

I'm sure many of you already know about the blog aggregator site: BlogLines.

I did not know about it until the best C# Architect I know, my friend Mike Potts, shared the link this morning. It's an awesome way to keep up with gurus coding in the industry.

:{> Andy

PS - Thanks Mike!

posted Friday, July 15, 2005 5:42 PM by admin with 0 Comments

Jax Code Camp!

I'll be speaking at the Jacksonville Code Camp (Jacksonville, FL, USA)!

Sign up at .

Come on out!

:{> Andy

posted Thursday, July 14, 2005 5:40 PM by admin with 0 Comments

MSDN TV and GrokTalks

If you haven't checked out , you're missing out! There's some great stuff out there about SQL Server 2005, Visual Studio 2005, and more.

For similar content, check out GrokTalks too!

:{> Andy

posted Wednesday, July 13, 2005 2:11 AM by admin with 0 Comments

On Book Authoring (for the first time)

"Writing is a lot of work." I heard authors say that at countless conference sessions. I remember thinking: "How hard can it be? You're the expert! Just write what you know!"

So now I'm working on a couple chapters for an upcoming SQL Server 2005 Integration Services book. The stuff I heard other authors say is starting to make sense.

The first flaw in my former logic is more than apparent to me now: How does one become an expert on a yet-to-be-released product? My guess is there are two ways:

  • Develop the product.
  • Spend every waking moment - including moments you should not be awake - struggling through beta versions to learn the product.

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

posted Friday, July 01, 2005 5:00 PM by admin with 0 Comments