Search results matching tags 'Career' and 'Development'

The Top-Five Most Valuable Development Team Positions

BuckWoody — Tue, 30 Nov 2010 14:34:00 GMT

In many organizations, there’s a push to save cost. “Cost” is an integral part of a profit-and-loss statement in the organization. Even if you work in a non-profit organization, cost control is central. Of course, you can take cost-control too far. You could, for instance, remove the shipping costs from your company, but if you happen to be an online retailer, removing the ability to ship your product would eventually doom your company. So there’s obviously a spectrum of necessary cost and wasteful costs.

People are a large part of the cost of any company - in some cases the highest cost. So it stands to reason that there’s a natural tension between paying well to find good people, and the need to lower the cost of those resources. In the rush to save costs, we’ve all seen people let go that really shouldn’t have been – and in other cases some folks stick around that need to go. How do you make those choices? Well, there are a lot of factors to consider, but if your firm has an IT focus, meaning that you sell software or develop software that is core to your organization’s business strategy, then certain positions can actually save or make you money – even when they are very expensive.

There are a few caveats here -

The first is that I’m assuming that every resource here is the best they can possibly be. By “best”, I mean that they know their craft inside and out, are recognized as an expert, and that they are continually improving themselves. Also, I realize there are lots of definitions for these roles, but I’m taking the minimalist approach. The role is what the title says.

The second caveat is that you actually have a team with these positions. You might have a smaller or different team that doesn’t include the position. And keep in mind, I’m talking development teams here. No mention of operations, like sysadmins or platform administrators, networking professionals, nothing like that.

The third caveat is that this is *my* list. You’ll probably have a different one, and good on you if you do. I’m not saying that you should make more or less money, that you’re not important, or that you’re not a good person. I’m sure you are. This list is strictly confined to making and saving money for an organization or company. If you disagree with my list, post your comments – with one requirement: include your logic.

On with the list. In descending order, the top five money makers for your IT development shop are:

Number Five: Developer

It stands to reason that a good developer is faster, makes less mistakes and is generally more efficient than a poor one. But the developer will also save money for the entire organization when the code they write runs faster, and with fewer errors. That means even after a software project is complete, the good developer saves you money every time their code runs.

Number Four: Tester

But code has errors. All code, from everyone. And studies show that every error that gets out with deployed code costs up to four times more to fix than having a tester catch it before it hits the field. So it follows that a tester – a really good one – has a bigger cost/profit impact than a good developer alone.

Number Three: Lead Developer

Software is complicated. Keeping a development team on track, and keeping the work “pipelined” is also a key to utilizing those developer and tester resources at as close to %100 as possible. Every dev or tester that sits around, or writes code that isn’t needed or eventually is thrown away, is a waste of resources. A good Lead Developer keeps that from happening. Oh, and don’t forget who hires those developers and testers and assembles them into a team. Done properly, the Lead Developer handles that, so they have a direct impact on the prior two positions, making them more valuable. When there’s no lead developer, a power vacuum forms and the loudest voices win. And heaven help you if you have the misfortune of an overbearing, micro-manager in one of the so-called “Agile” environments. You’ll lose good people faster than the U.S. Government spends money.

Number Two: Project Manager

Really? In some companies I’ve worked at, the Project Manager is not viewed as a more valuable resource than a lead developer, but if you think about it, they have an incredible impact on cost (and subsequently, profit). How many projects have you seen that were scoped incorrectly? If the organization had a good PM, they would have had a better estimate or work and schedule – and perhaps have made a choice to implement or not implement a feature. Both of those choices have vast cost implications. Make something you shouldn’t, and the whole thing is wasted, don’t make something you should, and you lose opportunity costs.

Add to the scope question the ability to properly lay out time and resources, and the PM can make or break the budget on not just one but multiple projects.

Number One: Architect

In many firms, the title “Architect” is sorely mis-used, handed out with little definition. What an architect should do is understand the business and mission of the organization, and thoroughly understand multiple technologies. I’ve seen lead devs play this role, and in my opinion that’s hard to pull off successfully. In some companies, the IT Director, CTO or even CIO act as the Architect, and in my mind those roles have too many HR and Budget duties to be effective as an Architect.

An Architect is a single role that is allowed to focus on the marriage between business and technology strategies. Even if they are a “Data Architect” or a “Software Architect”, they need to know security, hardware, networking, the Cloud, whatever. That’s their job – to “know”. All areas inter-mingle at this level.

So why does this knowledge make them the most important resource in an IT-centric company? Because innovation, market applications, and general business strategy are where the architect can have the most impact. Decisions for technology strategies affect every single person not only at the company, but shareholders and the public as well. If – and these are a big deal – they are valued, competent, can communicate that strategy and are listened to by leadership.

T-SQL Tuesday : Are hotshot DBA skills necessary?

AaronBertrand — Tue, 02 Nov 2010 05:08:00 GMT

Let's face it, there is a wide variety of skill out there. If you spend any time monitoring StackOverflow, MSDN forums, Ask SQL Server Central or twitter's #sqlhelp hash tag, you'll be very well aware that there are people out there barely managing their database environments - people that some of us wouldn't let within a mile of our own data centers. But a lot of these people are not trying to build the next facebook or amazon - they're just trying to keep their small business running, and don't necessarily need perfection.

One of the "live by the sword, die by the sword" problems with SQL Server is that it has become so easy to manage. (I remember one of the mantras of SQL Server 7.0 was to make it so self-tuning that a DBA wouldn't be needed. That's not quite how it turned out, but a lot of systems are certainly less hands-on than they were in the 6.5 days.) Because of this, in probably a good 80-90% of cases, a business can get by with minimal or no DBA expertise. While some of the things that people will set up instinctively (e.g. maintenance plans) will not be the most efficient things in the world, they're also not going to be bad enough to cause the business any grief - they're just not trying to squeeze so much performance out of the system that these minor inadequacies are really going to cause them any grief.

Does that mean you should stop learning, and ignore great blog posts on backups, compression, security, and other important aspects of SQL Server? Of course not. The challenge is to know when you will need those skills to be present. At the beginning, for most start-ups, I wouldn't suggest that a rockstar DBA is priority #1. But as your application becomes the next big thing, there will come a time when boot-strapping it just isn't going to cut it anymore. If you don't have a database person on staff or retainer periodically looking at your stuff, you can end up in a really bad situation.

A lot of the things that you started on an "expertise budget," we'll call it, can be fixed later on; but some things will be more challenging. Storage, for example, is important... but as long as you can afford maintenance windows or other scheduled downtime, moving from DAS to SAN is something you can do when it's required (and when the budget is justified). Similarly, scaling up to larger machines, or adding memory, are things that are relatively easy to do and don't necessarily require a DBA (except maybe in downtime planning or data migration).

On the other hand, choosing whether to use IDENTITY or application-generated GUIDs as a primary key is something you should put more thought into up front, because re-engineering both the schema and the application(s) is not something you can pull off during a Saturday afternoon maintenance window. Nor is being prepared for scale in general... you don't want to get caught with your pants down, thinking 10GB drives were big enough, and you run out of disk space on day 2. You probably don't need a high-end DBA for ballpark capacity planning (take your best guess and double it), or to figure out efficient ways to replicate and distribute data (I wrote about this a little bit last year).

Now, please don't take this the wrong way. I am not saying that DBAs are useless, nor am I suggesting that you *should* avoid a DBA at all costs. I just think that, in some scenarios, you can live without a DBA - for a little while. Not all applications need to be bleeding edge, and many will never grow beyond very meager needs (I wonder how many of today's apps could feasibly run on Express?). In fact many of these apps are going to start moving to the cloud, where even the rockstar DBAs out there won't have much control over storage, availability, redundancy, etc. So some DBA skills are, at least to some degree, being deprecated right out from under us. Maybe you're not currently in a position where you need to worry about this, but how confident are you that this will always be the case?

Thanks to Paul Randal (blog | twitter) for hosting and coming up with this month's T-SQL Tuesday topic!

"What three events brought you here?"

AaronBertrand — Tue, 19 Jan 2010 21:03:00 GMT

I was tagged by Tim Mitchell (twitter) in a recent meme launched by Paul Randal (twitter), entitled, "What three events brought you here?"

Well, I've ~~lied~~ told stories about this in the past. If you've read my previous posts about my career (in particular, this one), you'll know that I'm Canadian, gave up NHL dreams early, took Economics in College, started earning a living with computers in desktop publishing and later web design, and soon after graduating moved to Rhode Island (where I still live to this day). It will be tough to pick out three solitary events along that timeline that dictate who I am and what I'm doing now, but I'll try.

No, this is not a young me, but did I fool you for a second?

My first real computer

In college, I overpaid (and I mean really overpaid) for a used 486 from a "friend" who I thought was giving me a good deal. Mind you this was before Dell and Gateway, and before online stores, when you could only buy computers directly from the local computer nerds or Radio Shack. It was a pretty crappy computer, even at the time. Still, it really sparked my enthusiasm for using a computer for good, and not for evil; to stop doodling silly Don Martin faces on paper, and start doing it "for real" (albeit digitally) in Photoshop. The turning point in my career was when I realized I could get ahead in school not by getting smarter, but by making things look better: in a lot of cases, it's all about presentation. The computer seemed to me to be an easy way to bypass all the hard work, and get by on (mostly) looks alone. Now in my current position, my peers and managers can see through all that kind of fluff, so it doesn't fly anymore... they want substance, and can tell when they aren't getting it. But as a kick-starter to how I became marginally tech-savvy, it certainly got me on my way.

The dawn of the Internet

Do you remember Geocities? I do! I built my first homepage there. It was predictably ugly with a grey background, blue underlined links and a literal puke pile of animated Simpsons logos - I believe there was background sound as well. (I know this paraphrase came way later, but imagine a web page saying to you, "Hey Marge, did you know they have the Internet on computers now?") This in itself wasn't the event... but my amazement with the ability to instantly communicate with people all over the world, even if I was bragging about something as meaningless as my latest Tetris scores, was the start of something huge. I jumped from normal desktop publishing to web design and eventually, as my previous recounts detail, this landed me a job here in Rhode Island.

My first professional database

One of the first projects I worked on when I moved down here was an e-commerce site for a condom company (Global Protection Corp. who, it looks like, hasn't updated their web site since 2003). We did all of the scans and photographs for the product gallery, so we received boxes and boxes of this stuff. (Sadly, much of the free product went unused, but it was fun nonetheless.) Anyway, free lubes and condoms didn't have any direct impact on my career, but that first taste of data modeling certainly did - I still remember thinking I had "graduated from spreadsheets," and can still feel the sense of accomplishment when the web site was taking orders successfully and not falling over in the process.

I'm going to be nice, and not tag anybody. This meme has already made the rounds and I think I'd have a hard time finding anyone who hasn't already been tagged anyway.

Know Your Product Specifications

BuckWoody — Wed, 13 Jan 2010 14:57:01 GMT

As the Data Professional in your organization, the rest of the org looks to you to ensure that the system can handle what the business requires. To do that, you need to know two things: what the business requires, and what SQL Server can do.

But of course there’s a bit more to it than that. Knowing the business side of the requirements – well, I teach an entire course on that. But knowing what SQL Server can do is something you can find out on your own.

SQL Server comes in versions, which are released based on date, and editions, which are based on features and capabilities. It’s that last part that I want to focus on today.

As Microsoft SQL Server matures, you’re going to see even more separation between what each edition of SQL Server can do and where it should be used. In the past, most folks have only focused on three editions – Express (the “free” one), Standard, and Enterprise. The rule of thumb was that if Standard was good enough at the moment, put it in. And it is true (and a good thing) that you can upgrade from one edition to another fairly easily.

But as time goes on, we should spend a little more time understanding what each edition does, what it’s features and capabilities are, and where and when we should put them in. As I study this information, I’ll throw in my 2 cents and you can as well based on what you see. One thing I’ve found so far is that once I have the business requirements, there’s a mix of what I can write in code and what might already be included in a different edition. It’s important to look long and hard at that choice – writing a feature on my own is certainly cheaper in the short term than moving to a “higher” edition, but in some cases it makes sense to let Microsoft handle that lifting.

These links are ones that you should bookmark and take a peek at periodically. They are the “header” links for more information on those features and capabilities:

SQL Server 2008: http://msdn.microsoft.com/en-us/library/ms143287.aspx

SQL Server 2008 R2: http://msdn.microsoft.com/en-us/library/ms143287(SQL.105).aspx

In addition, you might start learning a little more about SQL Azure. I’ll talk more about that later.