58 Search results

For the term "management".

the ubiquitous resolution post…

Obviously, with the start of the New Year, there will be a flood of posts on the blogosphere regarding resolutions to change bad behaviors and adopt new good ones; why should I be any different? There’s lots of things I want to change about myself, and I figure I should put them out there and see how I’m doing over the year. So, with little fanfare, here’s my list of challenges I plan to tackle for 2011 (broken up in to categories and subcategories for easy reference):

Professional

Technical Skills

I want to learn something new every month. My goal is to tackle something challenging, and be able to understand the ins and outs of it within 30 days. For example, I want to finish tackling XML (including XSD’s) in SQL Server.
I want to upgrade my certifications by the end of the year; I’ve been dancing around the MCITP exams for a while, and I need to finish them.

Presentation

I want to make at least 6 technical presentations by the end of the year; last year, I managed to eke out 8, but given some of the recent changes in my personal life (see below), I think 6 is reasonable.
I will blog at least once a month about some technical topic (see the first bullet point under technical skills).

Management

I will understand the SCRUM methodology, and learn how to implement it with my team at work. Although I’m not a team leader, I AM the Senior Database Architect, and I need to code less, and teach more. This is my year to do so.

Personal

Health

I’m getting married again this year, and I want to look good for my new wife. I also want to avoid long-term health issues. I was losing weight last year (until I started dating), and I want to get back on track. I’d like to lose 50 lbs by October.
I have apnea, and I’ve been horrible about using my CPAP on a regular basis. I will use it regularly.
I need to exercise more, so I will find 20 minutes a day to do SOMETHING, even if it’s just walking around the office for 20 minutes.
I will drink at least 8 glasses of water per day.

Spiritual

I’ve slacked off in my religious activities; my faith was nourished by church attendance during my divorce, and I need to start growing again. I will find a new church in the next two months (my old church is too far to drive on a regular basis), and become a regular attendee.
I choose to absorb the goodness from people who love me, and I will reject the poison from those who do not. I will focus on the important things in life (like my kids, and my future bride), and worry less about the unimportant things (like who’s mowing the grass).

Social

I will listen more to my children, my family, and my friends. I will find ways to let them know I love them.
I will nurture my own friendships; while I love my fiance’s friends and family, I want to bring more to the table than just me.

Financial

My divorce pulled me way off course. While I’m a long way from being out of debt, I will continue to make strides in that area. I will pay off at least one credit card ahead of schedule.
I will save more; I plan to find ways to cut costs (like taking advantage of coupons, and eating out less).

Anyway, there you have it: my New Year’s resolutions for 2011. May it be a good year for all.

SQLSaturday 41 Status Update

I know many people have been worried about me because of the recent personal issues that I’ve been dealing with, but things have finally started to stabilize. I know I’ve promised that before, so no promises to return to blogging or getting more involved in the community, but I’m starting to climb out of the pit (and hey, I have light bulbs)!

Anyway, despite me, SQLSaturday 41 on April 24, 2010 is plugging along, thanks to a group of dedicated volunteers that have really pushed me to keep this on track. Thankfully, I’ve been able to give them the information they need, and they’re quite capable of making this happen. We’re a little more than a month out, and we’re almost full with our speaker’s list, and are sitting at nearly 60% registration. Seats ARE filling up, so if you haven’t registered, now’s the time to do so.

Here’s a short list of topics so far (in no particular order):

A Lap Around SQL Server 2008 Master Data Services
Whitney Weaver
Beginner

Advanced Parameters in SQL Server Reporting Servic
Mike Davis
Intermediate

Can you control your reports?
Ryan Duclos
Intermediate

Common Table Expressions
Ryan Duclos
Beginner

Data Warehouse Assessments – What,Why, and How
Noah Subrin
Beginner

Database Design Fundamentals
Louis Davidson
Intermediate

Database Design Patterns
Louis Davidson
Intermediate

De-mystifying Execution Plan Analysis
Dave Turpin
Intermediate

Dynamically Configuring Packages
Mike Davis
Intermediate

Full Text Searching – A Guide for DBAs & Devs
Robert Cain
Beginner

Introduction to Data Warehousing / BI
Robert Cain
Beginner

Introduction to Performance Tuning
Mike Femenella
Beginner

Introduction to Transactional Replication
Troy Gallant
Beginner

Loading Data In Real Time
Mike Femenella
Intermediate

Off and Running with PowerPivot for Excel 2010
Robert Cain
Beginner

PowerShell for the Data Professional
Aaron Nelson
Intermediate

RESTful Data
Chris Eargle
Beginner

Slowly Changing Dimensions–Done Well.
Julie Smith
Beginner

Solving Real World Problems With DMVs
Whitney Weaver
Intermediate

SQL Server 2008 R2 Overview – Session 1
David Rodriguez
Beginner

SQL Server 2008 R2- BI Drill Down Session 2
David Rodriguez
Beginner

SQL Server 2008 R2- DBA Drill Down Session 3
David Rodriguez
Beginner

SS2008 Data Mining with Excel 2010 and PowerPivot
Mark Tabladillo
Intermediate

Survey of Windows Azure Platform Storage Options
Glen Gordon
Intermediate

The Art and Science of Data Modeling
Audrey Hammonds
Beginner

Tuna Helper for SQL Server DBA’s
Janis Griffin
Intermediate

Using Event Handlers in SSIS for Auditing and Noti
Mike Davis
Intermediate

Virtualize This!
Aaron Nelson
Beginner

Wait-Time Based SQL Server Performance Management
Janis Griffin
Intermediate

When GEO meets SQL: Hotwiring Data to Locations
Michael Clifford
Beginner

2010-03-15 by Stuart Ainsworth Conferences SQLServerPedia Syndication 0

Maker’s Schedule, Manager’s Schedule, User’s Schedule

During the recent SQLSaturday #25 in Gainesville GA, we had an open session at the end of the day which we treated like a “Meet the Experts”. During the discussion, Cliff Jacobson referred to an article detailing the difference between the Maker’s Schedule and the Manager’s Schedule.

Here’s the link for your reference: http://www.paulgraham.com/makersschedule.html

It’s a quick read, but I’ll sum it up for you

There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour… But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started…

I would argue that (at least in our shop) there’s a third schedule: the User’s Schedule. Some managers ARE users, so their time alternates between the Manager’s Schedule and the User’s Schedule, but for the sake of this discussion, we’ll keep this separate.

What is the User’s Schedule? Basically, users only know of one time: Now(). Now is when they have to get their work done, and Now() is when the software breaks. When their work gets interrupted, they have to resolve the problem before they can move on.

Why is this important? Because when Users need a resolution, they don’t want to hear it’ll take a week to implement; they want it fixed Now(). When they request a feature, they want to know it’s being worked on Now(). Obviously, this is unrealistic for Makers; good code takes time to write, time to test, and time to document. When a Maker skips one of those steps, it’s usually because they’re attempting to work on the User’s Schedule.

Now() is not necessarily a bad time; Users are not attempting to screw the Maker out of task completion. The User really believes that Now() is when the Maker wants to know about the issue, so that the Maker can fix the problem before it gets too severe. Notifying the Maker about the issue as soon as it happens is the User’s method of helping.

So how do we reconcile these three schedules? Programmers need to meet with managers (they determine priority) and users (they determine requirements); in fact, the Agile Manifesto states that

Business people and developers must work together daily throughout the project.

How do you keep the conversation focused on the scheduled deliverable and not the bug of the moment? You have to keep moving forward, but you also have to be willing to acknowledge the Manager’s need for status reports and the User’s need to report issues and request features. I am no expert in this, but these are the principles I am starting to implement in my own schedule.

I’m working with Management to find appropriate times to schedule status reports. I’m trying to fit them in either right before lunch (either the meeting ends on time, or I may get a free meal out of it), or in the last hour before the end of the day (sometimes meetings go long, which is unfortunate). This takes care of the Management/Maker disconnect.
To avoid addressing issues Now(), I have started closing my email, forwarding my phone, and setting my IM status to Do Not Disturb (note: for a feature in Office Communicator, I wish I had a way to set different statuses for different contacts; DND doesn’t raise an alert, but I wish I could let my boss through) for 45 minutes out of every hour. The last 15 minutes, I stop coding, and check email, etc. This keeps my finger on rising issues, but is less interruptive than constant contact. Of course, I work remotely most days, so I don’t have to deal with Spring-Loaded-Butt Syndrome (and I’m not talking about hinges).
When I do contact users to deal with the bug-of-the-moment, I try to reassure them that the a) bug is being recorded, and b) will be prioritized. We use Team Foundation Server, which is OK for a bug tracking system. The biggest problem that I see in my current environment is that Users don’t often follow up with Managers to make sure that the issues are prioritized.
When discussing features for rollout, and the User attempts to bring up the bug-of-the-moment, I ask them to hold off on that discussion until the end of our stated objectives, and I encourage them to write it out. By writing out the issue, they begin specifying the core elements of a bug report/requirements document.

Is this perfect? No, but it’s a start. I’d be interested in hearing what your ideas are on the subject, and what steps you have taken to coordinate Maker’s time, Manager’s time, and User’s time.

2009-10-16 by Stuart Ainsworth Development Methods SQLServerPedia Syndication 0

SCRUM, Source Control and the SQL Server Developer (Part 1)

(If you’re just visiting me from SQLServerPedia, thanks for stopping by!)

I recently responded to TJay Belt’s post about his Release Management process, and thought it would be better to fully explain our development cycle here. Although I come from a DBA background, I currently work on the development side of the house in our enterprise. About 6 months ago, we made a decision to adopt Scrum as our development process, and for the most part, it has greatly simplified our release cycle. I’m planning on this being a two part post; this part will focus mostly on what Scrum is, and how we use it in our shop to release database changes, and part two will focus on how we use source control within the Scrum methodology.

You can read the Wikipedia article about Scrum, and it sums things up far better than I can; however, what I want to contribute to the discussion are some guidelines for implementing the scrum process. There are two basic goals to scrum: first, you want to increase visibility into the development process so that customers (the product users) know what to expect and when to expect it, and second, you want to organize your deliverables around measurable increments (sprints have daily scrums, which identify progress and impediments). It’s important to understand these two goals in order for you to understand why we implemented the rules we did. Please note that these are our rules as of this date, and they may change, and your shop is free to change them as you need.

The Sprint will last 4-5 weeks. Most scrums talk about Sprints lasting x number of days, but we broke it down into weeks because of the following constraints:
- We have certain processes that begin at the beginning of the month, and some that begin at the end of the month. We wanted to be sure that our Release Date always fell in the middle of the month, and
- We wanted to have a consistent day of release. We’re a 24x7x365 shop; for our business, most installation is best done in the middle of the week (so we can quickly identify any adverse affects).
We wanted to minimize the number of releases. Most issues can wait 4-5 weeks for complete development, even though the Product Users obviously want it NOW!!! To accomplish this, we had to deal with the issues of units of work, and emergency patching:
- If an issue is an emergency, and cannot wait until the end of the Sprint for release, we will release a patch on Wednesdays. In our model, patches are discouraged, but if they have to happen, they at least happen on the same day of the week as the regular sprint release. This ensures that everyone affected knows when patches may be implemented (and when to expect downtime).
- In the scrum model, a Product Backlog Item (PBI) is a prioritized unit of work; a Sprint Backlog Item (SBI) is a unit of work that is accomplished during the sprint. We enforce a hierarchy in our shop; PBI’s are composed of SBI’s. We do not release partial PBI’s; all of the child tasks (SBI’s) for a given Product Backlog Item MUST be completed before we release the code into production. If some set of SBI’s is required for a given release, we may split the PBI into two in order to accomplish this goal.

As a database developer, most of work is at the core of many of the changes; there are few PBI’s that do not involve some sort of change to the database. What we’ve noticed is that I’m often in demand at the beginning of the sprint, but my time consistently frees up toward the end; to help shift the burden a bit, we often stub out a dataset for the application (i.e., the app developers will dummy up a local dataset as opposed to making a stored proc). This is useful for two reasons; it delays their need of my services until later in the sprint, and it also defines what they want the output of a stored proc to look like.

In the second part of this article, I’ll discuss our source control arrangement and how it maps to the sprint.

2009-05-20 by Stuart Ainsworth Development SQLServerPedia Syndication 1

Death by a thousand cuts…

This is has been an awful week; things have just not gone as planned from the get-go. I’m gonna run through several issues in this post, and perhaps someone will find some value in them; lessons learned may help others avoid the pain of my ways.

VSTS: DB Pro

This week, I’ve spent way too much time just trying to figure out how to use Visual Studio; I’ve mentioned in previous posts that I’m a database developer, but that I’ve spent most of my career working with the standard SQL Server DBA tools: Query Analyzer & Management Studio. When we migrated to TFS, my manager encouraged me to adopt VSTS:DB Pro as a method of developing, and I’ve put some real effort into learning how the system works. I’m slowly becoming accustomed to it, but there’s still some very quirky things that I’ve yet to figure out.

Issue 1: Logins. Whenever I import a database into a database project, I get a long list of errors because we have Windows accounts associated with users in the database; since those users don’t exist on my laptop, the project throws all kinds of ugly errors. Googling the error reveals very little information; the only method I’ve found to eliminate the errors is to drop the associated users and schemas, which of course, can lead to VERY BAD THINGS in deployment scripts. I’m sure there is a method to resolve it; I just haven’t found it yet.

Issue 2: The Silent Source Control Failure. Most of my projects involve references to vendor databases; we have a policy of not modifying vendor databases, so when I need to write a stored procedure that accesses data from a third-party source, I create a linked database that sits on the server beside the vendor database, and include my proc in there. I don’t touch their code, but am able to customize my queries to pull data. When setting up projects in VSTS:DB Pro, I usually make my custom database the primary project, and include a database reference to a project based on the vendor db. This usually works out OK, but I ran into an error yesterday where the project wizard would complete, but the project was unable to load. Nothing I did would fix it; I finally removed the vendor db from the solution, and was able to load my project (albeit with tons of errors because of the lack of references).

The problem? One of the stored procs in the vendor db has an extremely long name (nearly 100 characters); combined with the path to the workspace, the name of the file exceeds the 255 character limit for Windows file management. TFS apparently doesn’t know how to tell me that the file name is too long, so it just refuses to open. Try wasting 2 hours of precious development time tracking that down, and you can imagine how frustrating that is.

Haste makes waste.

A few months ago, we made a decision to adopt a version of Scrum to standardize our development processes; we’ve made up some of our rules along the way, and for the most part, we’ve done OK with it. However, the pressure to show progress and meet the needs of the organization means that sometimes I’ve made the wrong decision in my desire to please our Product Users. One case was today; one of our rules is that we a) strive to only deploy once a month (at the end of a sprint), and b) if we need to deploy an emergency patch, we only deploy on one day of the week (Wednesdays).

One of our users found an issue, and a production DBA researched it and made a recommendation for a relatively simple code change; I was out of the office Monday, so I only saw the recommendation on Tuesday. The issue was important, and the code looked good, so I thought I could get away with rolling it out today; unfortunately, I didn’t do due diligence on the code, and neglected to check for dependencies on that particular proc. We deployed my change today at 8:30 AM; by 3:30 PM, I was rolling it back. Luckily, the only side effect was that we generated a few extra tickets for our clients, but still, it was a painful experience.

The one thing I want to carry away from this experience is that as our system becomes increasingly complex, the less likely it is that a simple change can be made in less than a day. The code may be simple, but the context of the code in terms of surrounding processes SHOULD warrant time for thorough review. I need to quit reacting to the deemed urgency of the issue, and think about long-term stability instead.

Even the best deployments can have issues.

Overall, I think our deployment process works well, but even a good process can have points of failure. Even though we have several sets of eyes examining all of our code before it goes into production, things can still slip by. For example, at 3:45 this afternoon, I was informed that a stored procedure in production was not returning all of the data; the procedure pulls data from a third-party database, and makes certain assumptions about the nature of that data. In this case, we have a standard naming syntax for all of the devices we manage; ClientID, followed by a space, then device name (e.g., 999 Joe’s Server). The stored proc had a where clause that ended with LIKE ‘[0-9][0-9][0-9] %’; the missing row of data had a device name with the space omitted.

Now, it wasn’t entirely my fault because I had written the code to spec; however, I should have anticipated that the naming convention could be slightly off (and still be parseable; if they had a 2-digit client id, it would be a different story); in the end, our company looked bad to a client because of typo, and that’s not good. Easy to fix the code, but hard to regain the trust of the client.

Tomorrow WILL be a better day.

I’m not much for mumbo-jumbo, but I do believe that life is what you make of it. If I go back to work tomorrow and assume that it’s going to be a bad day, then I’ll probably be proven right. I’m changing my attitude as of this moment, and I choose to believe that the priority issue that I address tomorrow (while it may not be the issue I want to work on) will be the issue I was meant to work on.

2009-05-14 by Stuart Ainsworth SQL SQLServerPedia Syndication VSTS:DB 0

SQL Server 2006 DBA Street Smarts – Joseph L. Jorden

Welcome to my first book review! As part of the process of arranging for swag for SQLSaturday, I’ve encountered a number of publishers that have agreed to donate books to our event in exchange for book reviews. Obviously, they’d like favorable reviews, but I don’t feel obligated to hold back any legitimate criticisms that I may have of their material. I do think this is a good opportunity to expand my own writing skills, plus encourage me to read more.

I’ve been studing for my MCITP: Database Administrator exams for some time; I picked up Jorden’s Street Smarts a while back, and have slowly been easing my way through it. other things seem to occupy my time, so I’ve been unable to fully commit to taking the exam. However, that’s no fault of the author. He does a great job of simplifying the material that will be covered on the Microsoft exam 70-431, and it really is framed in terms of common “street” scenarios that a typical DBA might encounter.

The book is laid out in four phases: Installation and Configuration, Implementing High Availability, Maintaining and Automating, and finally, Monitoring and Troubleshooting. Each phase is comprised of tasks; for every task, there’s a description of a plausible scenario, followed by a step-by-step explanation of how to do the task using SQL Server Management Studio. There’s lots of pictures (probably because the exam emphasises the use of the GUI), and it’s a very easy read. Unfortunately, there’s only so much you can do to make this material exciting. As a development-oriented DBA, I’ve been sitting for months on the second section (mainly because it’s the stuff I don’t do on a day-to-day basis anymore), and even now, I’m dreading cracking it back open again.

The book is well-written, and if I were more enthralled with the material, I think I would actually enjoy using it as a study guide. It’s better than many other certification books I’ve encountered, because I think the author really tries to use examples that are realistic (rather than simply trying to teach the test). If you’re looking to upgrade from a SQL Server 2000 MCDBA to the MCTS SQL Server 2005 cert, this is a good place to start.

2009-02-12 by Stuart Ainsworth Book Reviews Certification 0

Happy New Year!

So, sitting up and watching Double Impact and cruising the web, I read Andy Warren’s Thoughts for 2009, and I thought I should probably contribute my own ideas as well. I definitely want to spend more time blogging and contributing to the user groups at large. Obviously, I’m going to be tied up with SQL Saturday for the first part of the year (speaking of which, I need to get my sponsor letter organized), but I still want to do more.

Professionally, I need to find more leadership opportunities in my company. This year’s a bit of a challenge because we’re understaffed with a lot of projects coming down the pipe, and there’s not a lot of openings in management positions, BUT I need to find a way to make my name known. I want to be the SQL guy for not just my division, but I also want to expand beyond that to the company level as well.

I want to complete my MCITP certs for database administration and development this year. One thing I learned at PASS Summit was that I need to continue to find ways to expand my knowledge. I feel very confident in my ability to code T-SQL and design elegant database solutions, but I have 0 experience in Microsoft’s BI solution, and my DBA skills are a bit rusty.

I like Andy’s suggestion to play chess; I’m going to open that up and say I want to play more games with my kids. They’re getting older, and soon they’ll be too old to hang out with me. I want to find ways to encourage them to think, and I want to spend time just having fun with them.

Finally, I’m going to get healthy. As soon as this shoulder recuperates from surgery, I’m back on the workout routine. I am going to find 30 minutes a day to work out, and I’m going to stick to it.

How about you?

2009-01-02 by Stuart Ainsworth Blogging is FUN! Education Health 0

SQL Quiz: Toughest Challenges

Blast those pingbacks; I lament feeling left out of Chris Shaw’s quiz, and the next thing you know, he tags me.

Here’s the questions:

What are the largest challenges that you have faced in your career and how did you overcome those?

First answer, a technical one:

One of my biggest challenges was designing a database that would handle millions of rows of syslog data; it was a SQL 2000 box, and the budget for hardware was tight. We started off with a dual-core machine, with only 4GIGs of RAM, and yet we had to analyze 100,000 rows per minute, looking for patterns. We also needed to report trends to the customer on a monthly basis, so I did some reading on data warehousing (Kimball, obviously), and started building fact tables. It became easily visible that we were going to need to partition the data so that the server wouldn’t need to slog through 90 days worth of data when looking for a minute’s worth; so I started playing with partitioned views.

One problem: partitioned views wouldn’t use parameters to activate partition exclusioning. I searched high and low for the answer, got into several arguments over execution plans with people on the newsgroups about why they thought it was working (they were clearly wrong), and I was just about to give up when I realized that dynamic SQL could save the day. I rewrote all of my procs to use dynamic SQL to activate the partitions, and I as off to the races. I ended up using something that most DBA’s would agree could easily be misused, and it solved my problem. It really drove home the fact that a good database developer will have a toolbox full of stuff; you never know when a left-handed screwdriver will come in handy 🙂

My second answer is ethical in nature; as most of you are aware, DBA’s are guardians of some of the most precious assets in a company: their data. I had just started working for a company as their all around DBA/report writer/developer/printer support person when they had a change in senior management. Shortly after the change, this company was being audited by their parent company; the auditor came on site, and at one point, asked me to run some numbers for him from our Enterprise Resource Planning (ERP) system. I agreed, but asked for more time, since I was arm deep in a printer at that point (I was serious about the printer support above).

Between the time that I finished repairing the printer and could get back to my desk, I was approached by the head accountant who asked me to “run the numbers for the auditor, give them to the Chief Operating Officer, make my computer look like it was doing something and go home for the rest of the day”. In other words, hand off the data and get the heck out of Dodge; the accountant would “make sure” the auditor saw it.

I wish I could say I took the high road, and say that I told the accountant “no, I’ll deliver it myself”, but I didn’t. I went back to my desk generated the data file, saved it to a disk, started a long-running query on my machine, handed the file to the accountant and left. I went home, and started working on my resume. The next day, the auditor was gone, the COO was trumpeting our success, and I told my manager about how icky I felt. Two months later, I was working at a new job, and I got a phone call from my former manager; apparently, the company was being audited again, and he invited me to share my experience with the new auditor. I did so, and shortly after that, most of the upper management (COO, CEO, CFO, and the accountant) were gone.

Is there a lesson in this? I’m not sure; I clearly didn’t do the right thing the first time, but things still worked out OK in the end. The only apparent victim was my sense of morality, but still, I walked away wishing I had handled the situation differently.

think I’ll tag SQL Sister and Tim Benninghoff now.

2008-12-17 by Stuart Ainsworth Development 1