Wednesday, August 5, 2009
I think the database developer role is on the rise and that it's better suited for agile practices - but guidance is needed make that infusion of agile practices a success. Here's why.
My impression is that fusing agile practices into the DBA role is inherently awkward since administration differs significantly from development. A DBA might be involved in development occasionally or might bundle together a series of items into a project where a SCRUM sprint could apply - but commonly a DBA is frequently interrupted by a broad spectrum of issues and must also attend to routines of ongoing maintenance and support where they're taken out of development.
That said, there are signals that database development is becoming more formalized into its own role unique from that of the DBA - with both roles overlapping each other to some extent of course. One signal is that Database development now has its own separate Microsoft certification with the 70-433 test offering the MCTS certification in Database Development.
Mind you, I'm talking about the broad-sweeping trends. No need to argue about individual cases. I'm suggesting that out in the wild, more places are cropping up for a separate database developer role - and that role could be more suited for the infusion of agile practices.
Another signal is Oslo - an upcoming approach to development involving collaborative modeling. The goal is to get the various IT professionals to work together more effectively which includes getting someone from the database side of the equation into the collaborative development space. That person I suspect is the database developer primarily and the DBA secondarily.
I think that adoption of agile practices are coming to the database world later then the world of software development at large. That's hard to prove. One hint though is that articles relating to test-driven development practices (one area of agile practices) on SQLServerCentral are not frequent and are more recent. It's somewhat of a new conversation. The question is, if agile practices are late in coming to database development, is that an advantage or a disadvantage? An important question is will we learn from the mistakes already made, or will we be doomed to repeat them? It depends, of course, but on what?
To help answer that, let me take a quick step back. I've been talking so far about agile "practices," lumping things together whereas Alistair Cockburn, one of the very founders of the entire Agile movement keenly separates out the "procedures" used in agile from the "properties" of an agile environment. In his influential book Crystal Clear: A Human-Powered Methodoligy for Small Teams, Cockburn suggests that if a small team ensures that their environment has certain properties such as "reflective improvement," then the practices used to foster that property will follow.
That said, we can clarify here that it's the specific practices like teaming up programmers to run in dual-code mode, setting up a walking skeleton and using incremental rearchitecture and so forth, might be more awkward for the database world. The properties, however, are not as awkward.
For instance, one of Cockburn's properties is "personal safety" - (which could end up being one of the most important agile team properties of all) I think can be set up in the database world with no inherent impedance. Personal safety in a nutshell is "being able to speak about something bothering you, without fear of reprisal" (Cockburn). It can lead a developer for instance to admit that an aspect of a project is beyond their ability. They'll get help sooner and the project will move forward.
At this point I think I should lay down another impression about the whole agile movement that is taking hold of software development - because I think it can serve as a warning signal for the database world. I think there are forces acting on the agile movement from the business world to change it into a sort of magical "get something for nothing" proposition. In order to sell an agile methodology, the technical personnel and others emphasize speed and success and tend to leave out everything else.
I think developers are being talked about as if they were processors on a motherboard. Extreme programming is like working in dual-processor mode. The discussions are about efficiency, throughput and keeping developers at maximum productivity.
What doesn't get mentioned or emphasized is the human-powered side of the equation. The result can be project-seizing turnover and morale drain. Set up a series of intense sprints with little time to come up for air, adjust the methodology so that the developers aren't coming up with the timelines, and what do you think will happen?
Here's where I think the database world can sidestep some thorny issues by going back to the beginning and embracing some of the values that were discussed at the conception of the agile movement.
The history, some of which is kept at agilemanifesto.org, is that some experienced developers set up a meeting one late winter day in 2001 at a ski lodge in the Wasatch mountains of Utah. One of the original signatories of the movement, Jim Highsmith, made a statement that I think we should take particular notice of. Highsmith says "I believe Agile Methodologists are really about the 'mushy stuff' about delivering good products to customers by operating in an environment that does more than talk about 'people as our most important asset' but actually 'acts' as if people were the most important, and lose the word 'asset'."
From the beginning, the agile movement was concerned about not just the success of software projects but also about the human sustainability of the software development profession. There is a concern for the developer community. There are costs and trade-offs to be made. So to create a sustainable and humane development environment, an agile methodology can't be sold to the business segment as a cost-free trade-off free proposition. From the get-go, the signatories of the agile manifesto laid out the key trade-offs that they perceived should be made, which can be reviewed here. One of them is "individuals and interactions over processes and tools" where individuals and interactions are valued more.
I'd like to venture one last speculative point in this entry - the validity of which I think doesn't negate the other points I've made. Non-database developers seem to wield suprisingly little political power in general. They're struggling to get control over setting their own sprint timelines. I think the database developers and DBAs might have a little stronger bargaining chip. They preside over not just an RBDMS these days - but with SQL Server and the likes, they've got the reigns on an entire data-centric business platform that handles a gambit of technological needs. If that added leverage exists, perhaps database professionals will become more successful at creating the agile environment that was and is actually intended by the founders.
Lastly, I recommend Cockburn's book, which reviews both the ideal properties of small agile teams, but also reviews some of the successful practices and techniques like walking skeleton, process miniature and so forth.
Wednesday, July 29, 2009
The 70-433 will be my first Microsoft certification test. There are two main reasons why I've decided to take on this quest.
The first reason is to "fill in the cracks." Even on fundamental topics I've found myself saying "oh - I didn't know that" while taking a training class or studying a technical book. Having reviewed the material covered for the 70-433 Microsoft SQL Server 2008 Database Development test, I fully expect to learn some things and get clear on others.
The second reason has to do with the economics of information: There are information costs to get accurate information about someone. I think having a certification lowers the information costs for future employers and business partners. Employers face some of the same dilemmas that a single person does while dating. A candidate wants to highlight strengths whether real or imaginary and diminish weaknesses. The information that's most readily available about a candidate isn't necessarily accurate. More information is needed to verify and clarify the reality. So what if one has 10 years of experience? Perhaps some of that time was merely wasted? In my view, I want to make it as easy as possible for others to do business with me - so I'll take on the costs of time, effort and funds to get certified - and I think that's worth something.
Joel Spolsky openly admits that he lifted the addage "smart and gets things done" on what to look for in a job candidate from Microsoft. However, he also added "not a jerk." So put that together and you get "smart, pleasant and gets things done." Notice that "certified" isn't on the list. However in Spolsky's book "Joel on Software" suggests that "smart" can be verified to some extent by looking for some kind of selective entrance - like an ivy-league school or elite military group. Certifications follow the same logic. So, no - the certification won't prove that I'm pleasant or that I get things done, but it does show that I'm smart enough to pass a pretty challenging test and that I'm versed in the knowledge covered by the test.
So I went out and got the official Microsoft Training Kit and am now plodding through with SQL Server 2008 installed on my laptop. Unfortunately, we're not on 2008 at work yet - but plan to soon.
More posts will follow as I work my way to the completion of this challenging quest. Wish me luck.
Tuesday, July 28, 2009
The Mirra by Herman Miller seems to make the short list in the world of the web.
Also highly regarded out there is the Perfect Comfort Ergonomic Office Chair - a reasonably-priced option.
The Herman Miller Equa XR is on my personal short list.
One resource I've found is a nice comparison chart from the University of North Carolina found here.
In addition to Amazon.com, another online site to check for task chairs is HighTechSeating.com. Check them here.