I’ve been thinking a bit more about the list of disruptive technologies on Richard’s list, and then I watched Dan Pink’s TED talk on the surprising science of motivation. There must be some relationship between the list, which is comprised of almost all open source software products, and Dan’s assertion that the 20th century reward system won’t work for the cognitive tasks performed by workers in the 21st century. What is it, though?

We develop open source software to scratch a personal itch, ease the pain in performing a certain type of task, or create a more compelling alternative to a commercial product. While the professional open source model has emerged the last few years as a way for the open source community to create a sustainable business model, none of the open source technologies on the list were initially developed that way. They were developed in response to need. Ant because Java lacked a good build system. Spring because Java EE was cumbersome and bloated. JUnit to help increase quality. In many cases, these tools have grown to become defacto standard technologies widely used by enterprise development teams.

In Dan’s mind, the new incentive program within organizations must revolve around three things - autonomy, opportunity, and purpose. We must be given autonomy, or the empowerment to make our own decisions. We must be given the opportunity to master something that matters to us. And we must be given purpose, which is the desire to do what we do in the service of something larger than ourselves. Dan notes that financial incentive is also important, but is not the decisive factor in what motivates us.

There are a lot of ways to connect the dots between the open source products so prevalent on Richard’s list and Dan’s point about incentives. I’ll allow you the opportunity to connect these dots any way you wish. A few that immediately come to mind for me include the way commercial software is sold, corporate incentive programs, empowering developers, and flaws in corporate culture. But here’s something else to chew on.

In most of the cases, it was the developer who spurred adoption of the most disruptive application development technologies of the last decade. We weren’t motivated to develop or adopt these great products because of financial incentive or a reward system. Sure, in some cases that’s a positive side affect, but it is not the force that motivates. Instead, we were motivated because they make our jobs a little bit easier and our software a little bit better.

Developers are fighting like hell to create better software. While a lot of commercial vendors are selling shelfware (they aren’t selling it to the developer, mind you), developers are driving adoption of the technologies that are making a difference. Developers seek autonomy,  opportunity, and purpose. Given corporate culture, it’s not always easy to find. But if the last decade is any indication, we are finding it, developers do have a voice, and that voice is being heard.

The Agile 2009 program is live, and it’s going to be a great conference. Thank you to the Developer Jam review committee for all the effort they put into helping select the sessions. The selection process for Developer Jam was not easy due to the quantity of amazing submissions, but I’m confident we put together an exceptional program. Whittling down more than 100 submissions into less space than we had at Agile 2008 was challenging. In the end, we had enough space for just 26 sessions. I’m certain that Developer Jam would have been a great conference of it’s own. Any takers on organizing this conference?

In addition to the sessions you see listed, we’re also putting the finishing touches on Programming with the Stars, where select conference attendees will be paired with legendary agile programmers to perform live on stage before a panel of famous (and outspoken) judges. The audience will participate in the judging contest. Be sure to stay tuned to the Agile 2009 conference site for additional details on Programming with the Stars.

We all like metrics, statistics, and measurements that let us know how we’re doing. Released about a week ago, the 2009 Standish CHAOS Report should have plenty of numbers. Jim Johnson, the guy behind it all, cites some numbers pulled from the report. It appears failure is on the rise. In fact, it’s the highest failure rate in over a decade.

I’ve always liked the Standish report. It’s packed full of interesting and high impact statistics that can really help drive a point home - especially when you’re on stage presenting. But you also have to be careful about reading too deeply into those number. It’s very easy to metriculate, and some have challenged the accuracy of the numbers within prior reports.

About 10 years ago I recall studying profusely so that I might pass my Java programmer’s certification exam. I purchased a copy of an exam cram book that had sample questions similar to what I might encounter on my certification test. I recall dealing with questions like the following:

• Can an abstract class be subclassed?
• What interface does TreeMap implement?
• What is the output of the following code snippet?
• Identify the compile errors in the following code snippet.
• What are the different access qualifiers?

I’m sure many of us are familar with these questions, as well as others of similar ilk. Of course, I’d taken similar exams prior to this for a variety of technologies, but the Java certification exam was the last one I’ve taken. I’d come to the realization that time spent studying for these exams is largely a waste of time. I was no better at developing software systems in Java after taking the exam than I was before. I simply possessed a bunch of useless knowledge that I could have easily gotten by looking at reference material.

The skill that I needed to develop enterprise applications could only be obtained by developing applications. It could be found no other way. There are no shortcuts. Making mistakes and fixing them. Discovering new ways of doing things that worked better than what I had done before. Knowing what assumptions I could make, and those I could not. The reality is that certifications exist largely to sell training courses, while the marketing that surrounds them leads organizations to believe they are relevant. A while back, the agile alliance issued their public policy denouncing agile certification. They state:

Knowledge is a wonderful thing, but businesses pay for performance. Performance requires skill.

A skill is not as simple to acquire as knowledge: the learner has to
perform the skill badly, recover from mistakes, do it a bit better, and
keep repeating the whole process. Especially for the interrelated and
interpersonal skills required of Agile software development, much of
the learning has to take place on real projects. It is that learning
that a certification should vouch for.

And unfortunately, it is that learning and skill that certifications do not provide nor account for. In fact, this is exactly why the software craftsmanship movement has begun to gain so much traction. Through trial and tribulation, a software craftsman has obtained the practiced skill required to develop great software. Of course, it’s easy to dilute the notion of craftsmanship if we are not careful.

Tom DeMarco also published an open letter to Cutter IT Journal expressing his dismay with certification. The debate on certification certainly is not new. But with the Scrum certifications, among the many others that abound today, the debate is still relevant. Where do you stand on certification? Would you rather work with a craftsman or someone with a wall plastered with certifications?

By the way, if you stand on the side favoring certification, and would like to get an agile certification, then maybe you should visit Agile Certification Now to get started.

The Agile 2009 CFP is open. This year, I’m the stage producer for Developer Jam. As you can see, Developer Jam has an impressive review committee. We’re hopeful that 2009 will be as successful as 2008.

Once again, we’re planning to run a series of clinics. They’ll be hands-on, instructor led exercises that will teach attendees something practical. If you have an idea, write up a submission, but don’t wait until the submission deadline of February 15th. Doing it sooner ensures increased visibility with the group of reviewers, and that means greater likelihood that the session is accepted. Of course, there are no guarantees. As a bit of additional incentive, be sure to check out the speaker compensation rates.

Software failure statistics are abundant and serve as clear evidence that we must reform software development. While industry claims an IT labor shortage is the motivating force behind outsourcing, the greatest factor is directly related to our inability to deliver value-add software. As organizations continue to lose faith in IT as a trusted partner, the services we offer are little more than an ample commodity, and the search for cheaper labor will persist. But, there is no IT labor shortage.

Read more

Some of you may have seen this video explaining the placement of phony job ads that are subsequently used to prove to the Department of Labor that there is an IT labor shortage. Lou Dobbs also got in on the mix as shown in this YouTube video, or take a look at the transcript. This ammunition is used to secure green cards for H-1B Visa workers. It’s repulsive. Bottom line - there is no IT labor shortage.

Here are some more numbers from the Dobbs video. Universities are pumping out over 300,000 bachelors, masters, or PhD degrees annually in computer or information science, math, and engineering. The Department of Labor predicts the average yearly job creation in those fields to be 120,000 jobs.

I’m a believer in competition, but it must be fair. Data suggests that on average, H-1B Visa Holders are paid between $12,500 and $20,000 less than their American counterparts. I’m not anti-H-1B. I’ve worked with a large share of very good developers who were H-1B visa holders. Unfortunately, the H-1B visa program is being used to replace the jobs of U.S. IT professionals with cheaper labor.

A two pronged approach is required to fix the problem and requires a professional code of conduct between employees and employers. The result is a win-win-win situation for all involved. First, we need not eliminate or minimize the H-1B visa program, but instead must bring the salaries of visa holders up to levels equal to that of their American peers. Second, we must reform IT through incremental delivery of quality software. Until these happen, U.S. citizens will continue to suffer job loss due to anti-competitive and fraudulent practices.

There is no IT labor shortage in the U.S. There is no dearth of software developers. Instead, this shortage is reinforced through repetitious pronouncements by industry of the impending labor crisis, and is used as outsourcing ammunition. In reality, organizations outsource because of two simple and related factors:

• Business believes IT costs are too high and by outsourcing IT labor, cost is reduced.
• IT doesn’t deliver value-add business software.

Read more

March 31st marks my first day as an Analyst with Burton Group working in the Application Platform Strategies group. To an extent, this is a career change for me. Since I’ve been in IT, I’ve worked exclusively on enterprise development projects. Over the years, I’ve played most roles on the software development team, but my favorite has always been as the guy who gets his hands dirty writing code. Through writing and speaking, I’ve enjoyed sharing these experiences with others. To this point, however, any writing or speaking I’ve done has always been an extracurricular activity, making it feel like I’ve always had two jobs instead of one.

My role as an analyst means I’m no longer a software developer working in the trenches. The reality over the past couple years is that I was working less in the trenches anyway. As I continued to shape and express my software development beliefs, I also began to gravitate more toward leadership roles, though not always intentionally. Whereas I once coded all day every day, I now code only a few hours each week. Instead, I spend more time mentoring developers, evaluating emerging technologies, and guiding teams through the process improvement quagmire. But yes, through it all, I still code even if it’s of my own accord.

My new role offers some exciting opportunities. Foremost, I’ll be working for a great organization with a stellar reputation. I also feel I have a single job that that combines my passion of technology, software development, and software process with that of my desire to learn and teach. I’m excited for what lies ahead, knowing that I must be careful to remember the important real world lessons I’ve learned. I intend to continue writing code, hopefully experimenting with new languages, platforms, and tools. I look forward to working with new organizations, and meeting new people.

Since I’m moving onto what feels like a career change, I’ve also decided to update my web sites (Yes, I love to hack!). First in queue is this blog, which now has a new skin. I’ll also be moving content away from my home page and onto this blog. Eventually, the code I write will reside on Google Code. Probably other presently unforeseen changes too. I’m excited about what lies ahead, and my expectations are high.

I got blasted for the following quote in a recent eWeek article:

“If you’re in a large environment that is bureaucratic, filled with politics and has a [software development] process like the waterfall flavor of RUP [Rational Unified Process] what do you do?” Knoernschild asked. “It’s been my experience that the number one thing you can do is continuous integration. That can spawn so many business benefits.”

The blaster suggested that I have no idea what I’m talking about because there is no “waterfall flavor of RUP”. What I believe the blaster missed is the tongue in my cheek when I made the comment.

As is often the case, the quote didn’t capture the context of the statement. Many teams, when transitioning to an iterative process, commit a number of mistakes. One of the more common mistakes is to establish iterations centered around the traditional lifecycle phases. When I made the comment, I also pointed out that the “waterfall flavor of RUP” typically consists of the first iteration being the requirements iteration, followed by the design iteration, followed by the construction iteration, followed by the testing iteration, etc.

Next Page →