It’s a tough world out there for .NET developers and software teams. Just when you think you’ve mastered the latest technique, technology, or framework — along comes something new to rattle your cage.

How many developers conquered the Entity Framework after a long struggle, only to turn the next corner and bump into LINQ? Perhaps you spent months learning WPF and Silverlight 3, just to discover that .NET 4.0 and Silverlight 4 will RTM very soon. It never ends. You just adapt to the shock of the new, learn the necessary skills to thrive, and move on.

So we hope that today’s news is a big win for .NET developers and teams everywhere. 

I’m delighted to announce that InnerWorkings is adding Pluralsight to our list of trusted partners.

I’m sure many of you know Pluralsight well — we have always been most impressed by their combination of top tier instructors, premium video content, and active participation in the .NET community.

Empty announcements are just annoying, so I’ve got something else to add today….

I’m really pleased to announce that Pluralsight is kindly offering InnerWorkings users and affiliates 1 week of access to the Pluralsight On-Demand! .NET training library. And I should add that this exclusive offer is entirely free, gratis, libero, frei.

So don’t look a gift horse in the mouth — get on over to the InnerWorkings offer page on the Pluralsight website and sign up for your free .NET training today. Simply use the activation code 27-1-YHRA-KDST to unlock your access to the Pluralsight library and start learning new programming skills today. Enjoy!

Add this post to:             

You hear plenty of talk about the importance of good team communication in many professions. From my writing background, I know that the relationship between writers and editors is extremely important (and complex in many ways).

When it works well, editors communicate their revisions and overall feedback to writers with clear and well considered arguments. Writers honor those edits in the spirit of their work, if not always to the letter, and discuss contentious issues directly with the editor.

At the end of the process, both sides should feel that value has been created, the piece is better than before, and the sum of writing and editing skills are reflected in a work of quality.

It’s really not all that different in the world of software development. In fact, software development is largely a team activity involving a complex chain of roles including business analysts, architects, developers, testers, team leads, and development managers.

Many people buy into the stereotype of the software developer as a loner, grinding out code in isolation, and rarely coming out into the light of day. While those developers exist (somewhere), most professional programmers today function in small to mid-sized teams, working on shared projects that require a high level of communication and peer review.

In this context, it’s easy to see how poor communication can wreck software projects, teams, and entire companies if allowed to take hold and fester. If this subject interests you, I encourage you to read Johanna Rothman’s short article titled When Teams Break Down, Business Loses.

She explains how competing teams within a data visualization company failed to agree on a uniform way of accessing the database. Roll on a few years and you’ve got a messy product with multiple library calls, unhappy customers who find the lack of standardization for data access unacceptable, and ultimately a failing company.

Johanna tells another war story about a large insurance company where different software teams simply could not agree on a standard iteration length for their agile process. A two month delay ensued from this basic failure to communicate with other teams and find a resolution, costing the company of over $2 million in revenue. Ouch!

So what am I trying to say here? With a rough economy, tight margins, and ever increasing competition in the world of software development — you overlook teamwork and communication across software teams at your own risk.

Add this post to:             

Most analysts covering the software space predict that 2010 will be the year of the cloud. There’s certainly no shortage of theories circulating about how quickly enterprise software organizations will adopt the cloud, and it’s notable that Salesforce.com passed a major milestone recently in hitting the $1 billion revenue mark.

Just a quick glance at the truly established cloud players like Amazon, Google and Salesforce.com — not to mention other cloud advocates like Microsoft, IBM, Sun, Rackspace, and VMWare — and you can see what direction the software industry is tilting. For those who are interested in digging deeper, Cloudtweaks.com presents a pretty comprehensive list of 85 Cloud Computing Vendor Players.

To get some perspective on the cloud today, I highly recommend this excellent article from M.R. Rangaswami titled 2010: The Year to Crystallize Cloud Strategy. It lays out a thoughtful and well reasoned perspective on the cloud today. I agree with all his main points that enterprises will adopt a hybrid approach to the cloud, using it as an extension to their existing datacenters, while SMBs will be much quicker to jump in with customer facing cloud offerings.

Rangaswami also predicts that open source software is well positioned to grow alongside the cloud, as the majority of current cloud offerings are already based on open source software stacks. Lastly, he points out that Cloud-Standards.org is building an impressive list of standards development to regulate cloud activities.

Notwithstanding the software industry’s tendency to see new trends around every corner, all the indicators I see point to a continued growth of cloud platforms and services in the coming year. To quote Steve Ballmer in a New York Times interview,  “Anything that has been a server needs to be a service.”

Add this post to:             

Now that the dust has settled on PDC 09 in Los Angeles, we’ve landed squarely in the frenzy of closing year end business. Less than 1 month to go and many budding customers to be brought on board, not a bad complaint!

Maybe the economy is picking up at last, but if I hear the term “green shoots” one more time…

Before we move away from PDC 09 entirely, I wanted to share David Worthington’s article titled Partners display development tools at PDC 09.

In this piece, David outlines a number of new partner innovations unveiled at the show. Congrats in particular to Gizmox on releasing their Visual WebGui application platform for Azure — this news got lots of kudos from show attendees.

David also covers our own InnerWorkings CodeBox release. We’re jazzed about the upbeat reaction that folks had to CodeBox at PDC 09, and we’re looking forward to a full launch in January 2010.

Stay tuned — and please contact us directly if you’d like to be included in the CodeBox beta program.

Add this post to:             

At InnerWorkings, we’ve always said that people are at the heart of software development. Tools, platforms, and frameworks will come and go, and there’s no denying that they play a vital role in software advancements.

But at the end of the day, people foster innovation within the software industry. When it comes to creating business value, software team leads & developers deliver highly effective software projects on time and within budget. It really is that simple…

Serhiy Kharytonov recently wrote an article titled Software Development: It’s About the People — essentially, he argues that while a successful software organization has many moving parts, “people” should be at the top of the priority list. And while this applies to all software organizations, Serhiy contends that it’s particularly important in the context of outsourcing.

So how do you put people at the heart of your outsourced development operation? Serhiy makes the point that “an outsourcing partner should provide its own structured, effective system for training and developing its employees with the education, certifications and experience they need to acquire the most advanced hard and soft skills.”

Of course, you still need to do your homework before deciding to outsource software development in the first place. Serhiy recommends the following questions as a litmus test of an outsourcing vendor’s capabilities:

Is their staff made up primarily of coders or do they have more technical and architectural education and experience? What was the attrition rate on the projects they were involved in? Did the vendor tend to have to replace team members frequently?

He also counsels you to look closely at how outsourcing vendors keep their developers’ collective skills sharp and relevant in this ever-changing technology landscape. Don’t overlook the important question of ongoing, effective skills development and practical learning support:

Ask questions about any additional certifications provided internally and how the company trains and promotes its employees. Does the company go above and beyond external certifications, enriching employees with additional training and internal certifications, and does it make a point of giving them experience with a variety of projects? Are their certifications based on real-world experience and accomplishments or simply course or text book learning?

This last point about focusing on “real-world experience” rather than “text book learning” is particularly astute. At InnerWorkings, this issue of practical, experience-based skills development is a central challenge for so many of our customers.

For a company to be successful (and deliver true business value from its efforts),  there needs to be a rigorous model for advancing developers, teams, and software organizations which puts people at the center of the software function. It really is about people power in the final analysis.

Add this post to:             

I wanted to let you know about an upcoming webinar that InnerWorkings is hosting next month — see below for details:

Agile in the Enterprise — .NET Development & Beyond

• Date: Thursday October 8, 2009
• Time: 11 AM PT/2 PM ET
• Duration: 1 Hour
• Partner: emergn

Given the explosive growth in Agile adoption over the past few years, we’ve decided to sponsor an open and in-depth discussion on the topic. As Agile matures, it is starting to gain a reputation as a project approach with a proven track record of delivering greater business value than traditional methodologies.

To add some definitive industry perspective, we’ve invited our partner emergn to share their thoughts on the Agile movement. We’ll be peppering the discussion with real-world agile case studies and customer war stories, so don’t miss this webinar! It promises to be a lively and spirited discussion covering the following topics:

• Challenges facing enterprise software organizations today
• Limitations of traditional approaches to software development
• Tangible value of adopting Agile for your organization
• Roadmap to Agile adoption and greater development efficiencies

You can register now to attend this webinar on Agile in the Enterprise. Hope to see you at the live event.

Add this post to:             

I read an interesting post today by Nima Dilmaghani on How best to announce a new technology. It got me thinking about the many different ways companies bring new products and technologies to market. Microsoft clearly favors the big splash approach, saving up product news and software release goodies for big tent events like MIX or PDC.

As this New York Times article outlines, Apple is famously paranoid about leaks pertaining to its product announcements, and the company runs a tight ship (or lip) in controlling the news agenda leading up to their big announcements. That is hardly surprising when Apple’s business thrives on creating near hysterical enthusiasm for its new products from a crowd of Apple devotees. Tuaw (The Unofficial Apple Weblog) likes to quote Steve Jobs as saying, “there is no theory of protecting content other than keeping secrets.”

We’ve come to expect a different perspective from Google, and their cerebral approach to making product announcements is suitably unique. Nima’s blog takes the perfect example of Google’s App Engine which was released to an invite only group of developers at Google Campfire One last year.

Rather than unveiling App Engine at their big annual developer conference, Google I/O, they chose to distribute it to a small and influential group at the Campfire event. By the time Google I/O rolled around a month later, this key group of developers had already begun using the App Engine development stack to build and host their own web apps. The Google I/O audience had enjoyed significant exposure to App Engine before the conference, and attendees had more meaningful responses than “wow” or “bah” which is what you typically hear at traditional launch events.

So “Big Splash” or “Invite Only” — which approach is better? I think that depends on your audience to a large extent. Enterprise software buyers are notoriously laggard in adopting new technologies, so Microsoft likes to make a big public splash about a new technology long before it is market-ready. It’s fair to say that this approach has many critics, but perhaps it’s effective for their primary audience.

Azure is a case in point — it was announced at PDC 2008 in a keynote by Ray Ozzie and is only now taking shape in terms of scope, pricing, and service-level details. Perhaps this is a clever ploy by Microsoft, because they enjoy 12 months of drip-feeding the slow-grazing enterprise market with a new technology, while the press keeps Azure alive in the minds of cautious enterprise buyers.

Once Azure is ready for prime-time (soon, by all accounts), the market is well primed to receive a more familiar, less threatening technology that has been in the lexicon for some time. In fact, you could argue that Azure has almost achieved the status of a released product due to the level of coverage in the technology press, well before the vision has come within spitting distance of reality.

Google, on the other hand, works through their powerful developer community to build niche technologies and disseminate them early. Rather than rolling out a shrink-wrapped solution, developers will build on the App Engine platform and adopt it to their needs. This approach taps into the wisdom of crowds, leveraging the momentum of community-based development, and it relies less on PR than it does on grass roots adoption.

Different strokes for different markets perhaps, but as we all know, the lines between Enterprise and Consumer are blurring every day. You would need one hell of a campfire to warm all the seats at PDC 2009, but perhaps the blow-out conference model is starting to change. Now that Steve Jobs is back at the helm, I wouldn’t count on more low key announcements from Apple, however. To each their own…

Add this post to:             

Buying enterprise software is a bit like buying a house — it can cost a truckload of money and there’s plenty of paranoia to go around. Will the pest report be clean? What if my mortgage broker can’t secure the loan? What if the seller strips out the brushed steel socket covers and adjustable light switches before we move in?

The relationship between enterprise software buyers and their vendors can also be complex and lacking in trust. Enterprise license agreements often involve a pretty sizable multi-year commitment to a vendor who has yet to prove that they can sustain the relationship and not run off with the fixtures and fittings. Somebody somewhere is putting their professional neck on the line…

With high stakes like this, transparency is often an issue for enterprise software buyers. What if that young vendor tries to get us locked into long-term contracts with unforeseen maintenance or consultancy costs? What if they can’t scale up their support organization to handle a global deployment?

As an enterprise buyer, it’s bad enough that you don’t really know the vendor, but the fear of getting sold a piece of enterprise software that turns into a cost sink of support, maintenance, and upgrade costs is enough to send any buyer off to the pub to procrastinate.

Throw in a really lousy economic environment and you have rolled out a perfect welcome mat for the financial year 2009. So where are the conscientious enterprise software buyer and hard-pressed vendor to turn in these ‘challenging times’?

Here’s one suggestion — check out Ray Wang’s blog as a starting point. Ray is a highly respected analyst from Forrester Research who has quite a healthy fixation on the trials and tribulations of purchasing enterprise software. Ray has created a detailed ‘Bill of Rights’ for enterprise software buyers that addresses many of the issues discussed above — it’s a carefully crafted effort to define the needs and wants of enterprise software buyers, with a set of nice flowcharts and visual aids. Clearly, Ray doesn’t do this stuff in his spare time.

For some added industry perspective on Ray Wang’s ‘Bill of Rights’, I’d also encourage you to check out Michael Krigsman’s article titled Evaluating the enterprise software buyer’s ‘Bill of Rights’. Mike quite rightly argues that the vendor’s perspective is equally important, and enterprise software buyers must make key contributions to their own project’s success.

As Krigsman articulates, “Customers and vendors can both learn from this bill of rights. Relationships are successful when all sides recognize and respect the others’ legitimate rights and responsibilities.” Very well said and, from my experience of the enterprise software world, I couldn’t agree more.

A cynic might say that’s a bit like discovering the people who sold their house to you have left a bottle of champagne in the fridge and an unclaimed flat screen TV in the den. Dream on you might say — or maybe Wang and Krigsman combined are really onto something here…

Add this post to:             

Have you noticed the buzz surrounding a promising open source JavaScript library called jQuery? Adoption has been nothing short of astonishing, with the likes of Google, Microsoft, Apple, and Dell using jQuery to build out their JavaScript frameworks.

At InnerWorkings, we’ve been dissecting and analyzing the relative merits and advantages of jQuery, sound in the knowledge that developers find plain old JavaScript programming boring, difficult, and frustrating.

Listen to the following 3 minute video presentation from Michael O’Brien, head of development at InnerWorkings, on what jQuery is and why we like it so much:

I’d also encourage you to check out Scott Guthrie’s blog which offers some excellent insights into jQuery and why Microsoft has bundled it with ASP.NET MVC. Good to know…

Add this post to:             

In my previous post I revealed that, to craft a great (technical) presentation, I deliberately use storytelling techniques borrowed by contemporary screenwriting. I leverage the power of story to stimulate an emotional response, even a new behavior, in the audience.

This approach comes from the realization that, although important, rational thinking has its limits. Even if we have facts that prove that we are “right”, it doesn’t mean that people listen to us.
By framing a subjective point of view, however, a story can influence perceptions, reinterpreting and directing what those facts mean to our audience.

If you happen to believe that stories are just for entertainment, think again. Stories are powerful, even frightening, weapons of influence. They have been used for thousands of years to persuade masses to join religions and wars, to unite and divide, to discriminate between “right” and “wrong”.

I’m often told that storytelling is too difficult. Yet, we unconsciously tell stories to others and ourselves on a daily basis. We tell who we are, what we have done, what we value, etc. We strip out all the unnecessary details and use stories to package our experience, or the experience of others, for easy consumption.

Aristotle observed that traditional narrative is structured around a dramatic story told in 3 acts: beginning, middle, end. I was surprised to discover that, after thousands of years, Hollywood-style screenwriting is still firmly grounded around this structure.

In a future post I’ll examine it in more detail, but for now, I’ll just state the obvious: a good story starts with a good idea.
What’s a simple definition of a good story idea (to be told in 3 acts)?

Someone wants something badly and goes after it against great odds.

I learned this definition by heart (and I wish I could recall where I found it). This simple sentence embodies three key elements of a good story: Character (”someone”), Desire (”wants something badly”), and Obstacles (”and goes after it against great odds”).

Implicitly, this definition also elicits the dramatic question: “Will he/she succeed?”

I’m just scratching the surface here, but watch a movie tonight and see for yourself.

It might seem obvious, but the story ends when the answer to the dramatic question is revealed.

When I performed my “Agile Tales” presentation in Stockholm for the very first time last year, I distilled a story from my own experience. Back then I didn’t know anything about storytelling.

Coincidentally, I had a character (me), plenty of obstacles (IT project from hell), and strong desire (I didn’t want to fail!). It’s a classic case of something that works without knowing why!

The story was about overcoming obstacles using agility, effective communication, and deliberate creativity.
Early in the presentation, I explained that I was involved in this impossible IT project. All the odds were stacked against me.
The setup was excellent, wasn’t it? But then I said:
“Amazingly, project from hell was a success. Maybe this is why…”

Do you see what I did? I made a rookie mistake.
I resolved the dramatic question too soon, effectively releasing the tension I created.

Several months (and more than 50 screenwriting books) later, I said instead:
“Project from hell was threatening me. This is what I tried…”.

The facts were exactly the same, but I plotted the story differently. This simple modification allowed me to preserve the tension until the end.

Next time, I’ll continue this fascinating exploration into the world of storytelling by revealing a technique I learned from a two-time Pulitzer Prize winner.
Stay tuned.

Add this post to: