Buck Woody : Help

“I could use a little help here” or “I can do it myself, thank you” for Cloud Projects

BuckWoody — Tue, 03 Apr 2012 13:20:55 GMT

Windows Azure allows you to write code in languages within the .NET stack, you can use Java, C++, PHP, NodeJS and others. Code is code - other than keeping things stateless, using a Web or Worker Role in Azure is not all that different from working with an on-premises system.

However….

Working in a scalable, component-based stateless architecture that can use federated security is not all that common for many developers. Some are used to owning the server, scaling up, and state-full paradigms that have a single security domain. Making the transition whilst trying to create a new software application or even port a previous one can be daunting. Sure, we have absolutely tons of free training, kits, videos, online books and more to learn on your own, but some things like architecture can be pivotal as you move along.

So the question is, should you just strike out on your own for a Cloud project, or get Microsoft Consulting Services or another partner to work with you on your first one? I use a few decision points to help guide the projects I assist in.

Note: I’m a huge fan of having help that ends up giving you training and leaves you in charge. If you do engage with someone to help you, make sure you keep this clear and take more and more ownership yourself as the project progresses.

How much time do you have?

Usually the first thing I ask is about the timeline for the project. It doesn’t matter how skilled you are, if you have a short window to get things done it’s better to get help - especially if this is your first cloud project. Having someone that knows the platform well can save you amazing amounts of time. If you have longer, then start with the training in the link above and once you feel confident, jump in.

How complex is the project?

If there are a lot of moving parts, it’s best to engage a partner. The reason is that certain interactions - particularly things like Service Bus or Data Integration - can be quite different than what you may have encountered before.

How many people do you have?

I have a “pizza rule” about projects I’ve used in my career - if it takes over two pizzas to feed everyone on the project, it’s too big and will fail. That being said, one developer and a one-week deadline does not a good project make, usually. It’s best to have at least one architect (or someone in that role) guiding the project along, and at least two developers to work on a cloud project. That’s a generalization of course, since I’ve seen great software on Azure with one developer writing code all by herself, but for more complex projects, more (to a point) is better. The nice thing about bringing on a partner is that you don’t have to hire them full time - they help you and then they go away.

How critical is the project?

There’s no shame in using some help. If the platform is new, if the project is large and complex, and if it is critical to the business, you should engage a partner. That’s regardless of Cloud or anything else - get some help. You don’t want to hit your company’s bottom line in a negative way, but you have to innovate and get them a competitive advantage. Do your research, make sure the partner is qualified to help you, and get it done.

Don’t let these questions scare you off. There are lots of projects you can implement on Windows and SQL Azure with nothing other than the Software Development Kit (SDK) that you get for free with Windows Azure. And assistance comes in many forms - sometimes just phone support, a friend you can ask. Microsoft Consulting Services or any of our great partners. You can get help on just the architecture piece or have them show you how to write the code. They’ll get involved as little or as much as you like.

When you’re asking for help, make sure you explain what you’re trying to accomplish

BuckWoody — Thu, 22 Jul 2010 12:24:09 GMT

At some time, all of us need technical help with something. Whenever you do, make sure you try and frame the question not necessarily in terms of what you want to know, but what you're trying to do. Spending time on thinking through your questions will help you get better answers, and people will appreciate that you're putting some effort into the process, and they are more willing to get help.

For instance - let's say yo're stuck on a particular SQL Server Replication issue. You're not sure whether moving the Distributor function away from the Publisher server is the right thing to do, given your budget. You could ask:

"Where should the Distrbutor go in a Replication scheme?"

That's too vague, and doesn't help others help you. Instead, this might be a better way to put the question:

"I'm setting up the design for my Replication scheme, and I have a limited budget. What are the best ways to save money in my design?"

This question goes more towards what you really want to know, and in fact, you may find out that the Distributor question isn't what you need to care about at all. Sure, sometimes you just want the phone number to a store, and you really don't need to tell everyone you're hungry, but if the question goes beyond simple facts, it's a good idea to include as much information as possible so folks can help you best.

Lessons from Volunteering

BuckWoody — Tue, 23 Feb 2010 14:31:01 GMT

Saturday I volunteered at a work-day at our church. Our building is one of the first buildings built in this area of Washington, so it’s a beautiful old structure, which of course means there’s lots of maintenance.

I’m fairly decent with tools, I’ve done some woodworking in my day, and I’ve even rebuilt a car or two. But working on a structure this old requires some special skills, skills that I don’t (or didn’t) have. And as I re-glazed a stained-glass window into an ancient window opening, I was not only humbled, I thought about how the entire project was handled and how I could learn about being a better DBA. I decided to share those lessons I learned here.

Not everybody knows what you do
This seems obvious – but I’m so often on the “knowing” end of a project that it’s easy to forget. Several of the other people at the workday knew what went where, how things worked, and what to do to take something out or put it back in. Even with my construction skills, I felt a little overwhelmed. Happily, the people that were there were VERY gracious and helped me do what I could. The nice thing is that they did not talk down to me or treat me like an idiot – they found out what I did know, and then mapped that to what I could do. They helped me learn, and by doing that I became useful to them.
This is also true in our career field. Are you having trouble between developers and data professionals? Buy a pizza, have a lunch and each team should take a turn at learning what the other knows, and what they would like them to know.

If you’re good at something, lead
One of the people at the workday was an older gentleman who was amazing in his knowledge. He’s a contractor, who’s dad trained him in construction starting at 5 years old! And in fact, his dad (and him) actually helped build this church. He’s an amazing guy. But he was running from task to task, doing all of the “hard” things. So I pulled him aside, and told him that we couldn’t do what he could do – but we were all willing hands and heads. I explained that if he would be willing, he could lead us. I asked him to group us into skillsets, and then come help each of us as needed. He agreed, and soon we were all productive.
You should do the same. If your kid’s school needs a “teacher for a day”, step up. Teach the kids what you know about databases. You’ll be surprised! Don’t be afraid to take a leadership role where you are.

Break things down into simple tasks
To do the two things above, you need to plan a little. The gentleman that helped us at first gave us things like “re-glaze that window.” After we stared at him blankly, he broke down the work into the steps of heating the old glaze with a torch, gently removing the old glaze, replacing the section of glass, and re-applying the glaze, all the while showing us the little parts of those tasks that keep the glass from shattering.
One of the easiest things to do when you’re a technical professional is to “glaze over” all of the little steps into a large one. You’ll need to learn to break things down into the simplest components, or at least the simple components that are needed for your workers.

I hope these tips are useful – I’ve been applying them each day.

Make it Easy for People to Help You

BuckWoody — Mon, 08 Feb 2010 14:17:59 GMT

OK, there are probably a dozen or more of these kinds of posts, but I’ll dive in anyway. From time to time, people send me e-mails or comments on this blog asking for help. Sometimes it’s on the topic at hand, and other times the topic just jogs their memory about something else.

Often I’m happy to help. If I know the answer without doing any research (or even if I have to do a little) I’ll interrupt what I’m doing and dash out a note with the answer. But of course I have a job (three, to be exact) and so any time I help with a question I’m lengthening my day, spending less time with my family, and so on. If you think about it, everyone that you ask (and everyone I ask) is in the same boat – when someone helps me, I am taking their most valuable asset: their time. So I learned a very important lesson very early on: Make it easy for people to help you.

So here’s the steps to follow to do that – it really isn’t that hard:

Request, don’t demand. I got an e-mail yesterday (on Sunday) where someone found a blog entry about one topic, and basically said this about another topic: “Tell me where I can find ‘x’ so that I can alter it.” Guess what I did? That’s right, I hit the delete key. If you are asking a question from a professional, you need to understand that they normally get paid – very well, sometimes – for their time. Make sure your question is a question, not a demand.
Be clear about the problem. Vague statements don’t help – and very few people have the time to dig the real question out of you. Be specific. Ask the single question you really need help with.
Keep the problem limited. “Rewrite my code for me” isn’t going to happen. “help me with this line” might. “Where do I go to find out more about the SELECT statement” is even better. If your problem takes more than a few minutes for someone to answer, then you should probably get someone on-site to help you.
Explain what you’ve already done. This, of course, means you’ve already actually done something. What have you looked up, what do you already understand, where have you looked, what have you tried?
Be polite. Please and Thank You are magic words, whether you get the answer you were looking for or not.

I’ll add one thing when you’re responding to a blog – not just mine, anyone’s. If you want to ask a question, ask it as a reply to a post, not an e-mail. The author wants to answer the question once, and it’s almost a guarantee that you’re not the only one with that question. Also, other readers might know the exact answer and help you even more. I know, you have to register, all that stuff. Just consider it the price of getting your answer.

Plan and Prepare or Just Do It? How about Both!

BuckWoody — Thu, 07 Jan 2010 15:56:00 GMT

I'm kind of a type "A" person. OK, I'm a VERY type "A" person. I even cook by setting things up ahead of time. I'm definitely more in the "Plan and Prepare" camp than the "Just Do It" camp.

But I do realize that there are times when you just can't stop and prepare. Sure, it would be great to know that server is going to melt down just now, but it happened and you have to deal with it. Now is not the time to open the plastic on that "Troubleshooting SQL Server" DVD course you bought! You just have to dive in and get the thing fixed.

Hopefully you're not operating like that all the time. If you are, you probably need to get some help with your systems, at least temporarily, until you can get them stabilized.

So which is it? Should you be like me, a type "A" who has to have everything planned out, or a reactionary agent, fixing things as they happen? How about - Both!

I think you should aim to plan and prepare as much as you can. Your life will be more stress-free, and you'll be happier in your job. But you can't lose your head when things go wrong and demand time to plan and prepare. You just have to jump in there and fix the problem.

But I think there's a happy medium in there somewhere. I ten to plan and prepare for the times I have to "just do it". I have my scripts ready for things like backups, DBCC repairs, restores, web site links for "how to" articles and so on. I have those right by my desk so that I don't have to panic when panic hits. So in effect, I'm doing both - I'm planning to just do it.