ScottGu has a great post about enhancements in Visual Studio 2008 Service Pack 1, released today in Beta.

Of particular interest to database developers: SQL Server 2008 support, a built-in Entity Data Modeler, and REST support!

:{> Andy

Kevin Hazzard did an outstanding job presenting to the Richmond SQL Server Users Group this evening on LINQ To SQL!

I really like the ORM / code generation aspects of this new feature of the .Net Framework 3.5. Seeing it in action made me yearn (a little) for my application developer days.

Kevin's VPC crashed a couple hours before his presentation so he recreated the presentation and three demos in 1.5 hours before the meeting - and they were not simple demos, especially the last one.

It's always cool to watch technology in the hands of a master.

:{> Andy

Introduction

A long time ago in a place not so far away from Farmville, I learned Motorola 6800 machine code. It wasn't easy but with patient instruction from my neighbor, I was soon making things happen on the computer screen and in memory. I was hooked!

Fast Forward 3.3 Decades...

I'm still hooked! That thrill was and remains my motivation for doing this work. I've learned it's contagious and I think that's a good thing.

I now use higher-level programming languages to accomplish screen and memory interaction, but it's the same thrill when it fires up and runs. I've noticed a trend over the past three decades or so: interacting with the machine is now easier. It's not just that I can do more in less time - the things I can do are easier to learn (for the most part) while being more complex, flexible, and powerful.

I am reminded of a scene from a Star Trek movie (Star Trek IV - I'm talking old school Star Trek here) where Scotty interacts with a 1984-era desktop. At first he speaks to the computer. When the computer doesn't answer Dr. McCoy hands him the mouse, which Scotty then speaks into as if it's a microphone. It's a funny scene and one that makes sense. The rest of the scene departs from the reality expressed in the first part as Scotty cracks his knuckles and begins frantically typing at the keyboard to ultimately reveal the molecular structure of tranparent aluminum.

The reason I call this a departure? Things get easier. Scotty could no more return to 1984 and interact with a program than you or I could travel back in time to the mid-1940's and program ENIAC.

And We Liked It!

Things were different when I learned M6800 hex. I had to learn about registers and accumulators and bit-shifting - things that still occur inside the CPU but that we rarely have to think about to develop software these days. Why? We use higher order languages.

As mathematics gives way to geometry and algebra, and then to the Calculus, our knowledge of software development has built upon itself as more powerful and more complex generations of programming languages have evolved. Gone (mostly) are the days of punch cards and keying base 16 numbers - which, believe it or not, were a vast improvement over previous methods.

Even though some of us grumpy old men may have liked it that way, things changed.

Things Got Better

Abstraction allowed us to do more. It allows us to manage (or at least mask some of) the complexity of software development. It also allowed us to do it faster. There's a natural progression from simple-and-less-functional to complex-and-more-functional. We're surrounded by it in nature. It's here and it's not going anywhere soon.

Grow with it or be overgrown.

It's the law of nature we inherited, overloaded, and extended to use in software development. It will not change.

That doesn't mean it's perfect - it's not perfect. Joel Spolsky (very effectively) argues abstractions leak and leaky abstractions ultimately slow us down and add work.

In The Box 

So how can I say things got better? Allow me to qualify that statement: Generic things got better.

So long as one remains within the confines defined by good people in charge of the abstraction in the first place, things will usually go well. It's when one approaches (or crosses) the edge that stuff gets all whacky (that's the technical term). Stay within the box or prepare to slay the dragons.

Should abstraction work this way? That's open for debate, in my opinion. The fact that it is - and finding some way to effectively deal with it - is a more productive discussion.

How Not To Do It

As a consultant I visited a shop that had experienced a recent turnover in their database department. The new team was in place and they were committed and eager and excited to set things right about the previous crew's work. 

Now.

If you walk into a situation like this as a consultant, several red flags should be flapping loudly as they are hastily raised in an increasingly turgid breeze in your consulting brain. If you find yourself sitting in an interview and the interviewer says something along the lines of "Everyone quit," several questions should leap to mind, including:

• Why did everyone quit?

But I digress...

I was tasked with converting a process from an older platform to a newer platform. The older platform was poorly documented. Which is to say there was nothing written down, but there did exist a screencast recorded by one of the developers of the application - no doubt after he'd submitted a notice - containing a rambling explanation that most likely made perfect sense to anyone who built the application in the first place, but did very little for someone walking in the door with no experience using the application.

So I asked one of the fresh new team members for help. The response: "Have you seen the video?"

It's difficult to grasp the tone of this response when written as above. So let me add the additional message that was being communicated: "When I started this position n months ago this was all I had and I hated that I did not have more to go on, but I also ignored the large collection of red flags during the interview process and found myself stuck in this job with no net after leaving my last position. And now you walk in with your fancy I'm-here-to-save-the-day attitude and high hourly rate and you expect me to share anything I've learned with you? Ha!"

Did I mention this was a fun gig?

My point is this: You don't do anyone any favors by amplifying the inherent difficulties of abstraction. You don't personally benefit from it, and neither does anyone else.

Footnote: All members of the "new" team at this location have either moved on or are about to.

How To Do It

The way to overcome the inherent difficulties of approaching the boundaries of abstraction is to understand the stuff that's being abstracted.

"But Andy," you ask, "doesn't that undo the benefit of abstraction in the first place?" I'm glad you asked. It certainly can, but this can be mitigated. How? In stark contrast to the exchange above, team communication and collaboration is one way.

Another way is to only hire people who know everything. This second option can be pricey, but can also be worth the price. To quote Andy Warren, "It depends."

Conclusion

Regardless of how we choose to deal with the overhead associated with managing abstraction, manage it we must. Even with its inherent difficulties, it is the way we will progress for the forseeable future.

:{>

The New Laptop Is Here! 

When I returned from Minneapolis, my new Dell XPS 1530 RED laptop was waiting! My lovely bride sent me a text message Thursday to tell me it was in Farmville. I didn't get to play with it until Friday evening, but I've been working on it on and off since then.

Taking It To x64

After mulling it over I decided to go ahead and install Vista Ultimate x64. The deciding factor for me? I wanted full access to RAM. I knew there would likely be a battle involving drivers (I'd taken a Dell desktop to x64 late last year) but I steeled myself and dove in.

The Vista installation went well - fast in fact. The new hardware is peppier than the old. Part of the reason is I've been purchasing low-to-mid range commodity laptops for the past few years and just replacing them when I wore them down. Most lasted a year. The last laptop had been pushed for 16 months and was showing the signs of age and wear. The RED machine is a solid mid-range (maybe more) laptop. I spent some money on processor power when I bought it.

Drivers... 

The first thing that didn't work was the network cards. It's tough to fix NIC issues when you can't connect to download updates so I fired up SneakerNet and began the ThumbDrive shuffle. The key to getting the Dell Wireless 1395 WLAN MiniCard wireless card to work was to snag a driver from Dell's own website - though for a different model laptop.

I renew my call for Dell to step up on x64 support - this just seems dumb to me.

With that driver installed, Vista took over and began identifying issues. It found problems with the built-in camera, audio, and ethernet card drivers. What's more, it provided links to download updated drivers! I like this feature a lot. "I found this problem and here's the solution." I wonder if Apple will ever do a commercial about that? Probably not. (On a side note, those commercials are having an impact. A local Mac repair shop modified their advertising recently to say something like "Macs never break, but if yours does..." Too funny.)

Windows Update kicked in and supplied yet more goodies. All in all, Vista did at least half the work of finding and fixing the driver issues I loathed when I started the process. Pretty cool.

The Restore 

I'm currently loading software onto RED now. I have a 200G hard drive, but it's the fast drive - another good choice. The box is performing well - even the loads scream.

And a couple months back I subscribed to Carbonite. I aimed it at a handful important directories for business, books, projects, etc. One configured, Carbonite keeps track of my changes and stores copies off-site. I have about 25GB out there now. When I fired up the new laptop I went to the Carbonite website, clicked a link that I was moving my subscription from my old laptop to the new, and downloaded the client. Since then, Carbonite has been trickling my files back to my new laptop. Again, pretty cool. I opted for the two-year plan - I get unlimited storage, backup, and retrieval for $45/year. Not too shabby.

As I type this, it's been running for about a day - it was down some because I didn't have the power options set to keep the disks running while plugged in. I'm at 85% restored. The restore is running in the background too, so I've been loading SQL Server and Visual Studio while this has been restoring. Nice.

Now that the major applications are installed, I'm loading the smaller utilities. I need to come up with a good way to restore these in the future. They're small and light applications - maybe I'll just drop the setup.exe's into a Carbonite-managed folder and be done with it.

So Far...

So far the experience has been positive. I have a couple weeks to get the kinks out before my next gig in Kansas City. I will likely travel with both laptops though, just to be sure.

:{> Andy

It's The Little Things... 

In Better, Dr. Atul Gawande mentions several basic things medical professionals can do to drastically impact the rate of hospital-passed infection. His first point is: Wash your hands.

This seems simple on the surface, but the time requirements for properly washing one's hands using traditional soaps is noteworthy: Once specified and quantified, this becomes a time-consuming exercise.

The procedure:
 - Remove watches and jewelry
 - Wet your hands with warm water
 - Dispense soap and lather everything from 1/3 of the forearm down for 15 - 30 seconds
 - Rinse for 30 seconds
 - Dry completely, then use the towel to turn off water.
 - Repeat after any new contact with a patient.

   Let's try to be realistic and say we can remove our watch and jewelry in 6 - 10 seconds. We can turn on the water and wet our hands in 5 seconds. We have 45 - 60 seconds lathering and rinsing. Then 15 seconds drying and finishing up. That's 1:11 - 1:30 each time a medical professional touches a patient.
   Add to the mix: some medical professionals are expected to interact with 20 patients per hour. That's 3 minutes per patient - and nearly half of that time is to be taken doing "unproductive" work - washing one's hands.
   Why do they do it? People die if they don't. The statistics are sobering: 2 million people annually catch a bug in the hospital in the US alone. 90,000 of them die.

Of Hand-Washing And Software...

   Andy, what does any of this have to do with software?

   I'm glad you asked. Like Dr. Gawande and lots of you, I believe we can also do Better. What's the equivalent of "washing our hands" in software development? My friend Harper Trow says "if you mean the most basic practice - the most common sense, I would say use source control". Harper also points out source control is Item #1 on Joel Spolky's Joel Test post.

   Now you don't need to use source control. And you don't need health insurance. These are equivalent statements, unless you are (and will remain) in perfect health or are (and will remain) a flawless coder. Source control is not suspenders-and-a-belt - it's a belt and you have no suspenders. You need it or you're in danger of showing something you (or we) may not wish to see. It's as optional to the software development process as security to the information technology enterprise.

Source control can be setup and configured in a day, learned on Day 2, and mastered in a week. You don't have to start with a full-blown Application Lifecycle Management (ALM) Suite, you can grab an open-source project or trial edition and install it on your Dev server. Most products integrate into Visual Studio and many into SSMS. It's not hard, it just requires a bit of discipline and the desire to do better.

Changing

   Dr. Gawande cites several attempts, some successful and some not, to implement change in the personal habits of people - change which is literally a matter of life and death.

   The failures of these attempts are staggering.

   The implication for us is this: If humans are incapable of change when life itself is on the line, how much less capable are we when it's "just software?" This is my theme and central question.

   What makes developers change habits? What causes DBAs to do things differently? What drives us? motivates us? changes us? makes us better? Is it even possible?

What Worked?

   At the veterans hospital in Pittsburgh, Jon Lloyd attempted a strategy based on Positive Deviance. (Positive Deviance is exemplified in Good To Great - an awesome book on patterns of business success.) It worked like this: They held short meetings with everyone in the hospitals. Everyone. Doctors, nurses, janitors, food service workers, even patients. They made one statement: We're here because of the hospital infection problem and want to know what you know about how to solve it.

   Holy smokes. Asking the people that do the work - that's crazy talk!

   It worked, but not for the reasons you may think. It worked because it engaged the population. When anyone actually acted on the ideas presented - which by and large were repeated in every 30-minute meeting - the people in attendance felt someone was listening to them and responded by helping implement their own ideas.

   Someone break out the bold red font. This is important. Engaging people works. Someone should tell user groups! Oh wait, someone did! ;)

   Listening, then acting upon what's said, prompts participation like nothing else. There is no substitute. How's a leader to get started?

Here's How To Start

   Invite the team to lunch and pop the question. No, not that question. This one: "What do you know about doing our job better?" Let the ideas flow - don't respond and for goodness' sake do not defend anything. Listen. Then listen some more. And then - you got it - listen yet more. Make notes. Nod. Engage. 

   And then implement some of the suggestions.

   How hard is this? Everyone likes to be appreciated and almost everyone wants to do a good job. Lead them. By example. You want them to do a good job? You do a good job leading first. You be Better first. Unless, of course, you want them leading. ;)

 :{> Andy
 

I just now (well, when you read this it will be late last week; I write ahead sometimes) purchased a Dell XPS 1530 Red laptop with the new Windows Vista Ultimate (PRODUCT) RED SKU installed. Granted, it's 32-bit - mainly because it's a Dell (c'mon Dell, get with x64 already!) - but I'm psyched about the new box. It should arrive next week.

I'm also psyched about helping fight the spread of AIDS in Sub-Saharan Africa. Microsoft has a page about the effort here. It's cool to be able to help people and score a snappy new laptop. Kudos to Microsoft and Dell for joining this effort!

You can learn more about RED here. The more I read about this cause, the more I want to join in and help out. If you have a minute, check out the great work these folks are doing.

:{> Andy

Kudos to the Richmond Code Camp Steering Committee for a record turnout and fantastic event! Throughout the day we had 113 people drop by for the event, breaking the previous record of 110. By three whole people. It was a great day.

It was good to see everyone - we'll do it again in October!

 :{> Andy

On Developer Communities... 

I hold the following hypotheses about successful, growing, and thriving developer communities:

1. First, you need a team builder. 
2. You can run a company like a user group, but the inverse is not always true.
3. Quality always works.
4. People are not resources or assets.
5. Don't go away.

Each hypothesis is accompanied by one or more "anti-hypotheses" - clues that you are not participating in a sustainable developer community.

Keep On Truckin'

The secret key to growing a developer community is (drum roll please): Keep it going.

That sounds a bit anti-climatic, doesn't it? But this is what I've been writing about for five posts now: The details of how to keep it going. This is all well and good when things are going peachy. But it's in the darkness that the light shines brightest.

There will be darkness. Some days things will not get done. There will be gaps and some people will be disappointed and others will leave the group. A vociferous minority will fire off emails or blog posts describing their disappointment as they go.

They will name names and call down fire. It will not be pretty.

I think it was Winston Churchill who said "If you're going through hell, keep going." The gist is simple: When the going gets tough, get tough right back.

Anti-hypothesis: If your user group leadership does not respond to criticism well, you are participating in a dysfunctional community. 

If it was easy, anyone could do it. But it's not easy, and therefore requires an impassioned developer community advocate to see the job through. You're going to make mistakes - we all do. You're going to have to deal with jerks. It's part of the job my friend.

Conclusion

My Granny used to tell me: "Boy, God gave you a backside so you'd have somewhere to land when you fall." The moral? You will fall down. Get back up again. Keep going and do not go away, and just watch what happens!

:{> Andy