- 15 Non-Certified IT Skills Growing in Demand
- How 19 Tech Titans Target Healthcare
- Twitter Suffering From Growing Pains (and Facebook Comparisons)
- Agile Comes to Data Integration
CIO - Early on a Thursday morning, three blocks from the Michigan State Capitol in Lansing, I park in an underground lot, punch a secret code to get through the door, and enter a world that's part fantasy convention and part tech conference.
There's no registration; you can't buy a ticket at any price. Of the half-dozen visitors to the event, five must sign an NDA promising not to reveal what they see. (I'm the only one who doesn't have to sign.)
Start with a dozen development teams that contain every role needed to ship software. Each team works on a different product or service, but most share technical architecture. The teams continually experiment and refining their process - but how you do get the teams to talk and share ideas, to push the good ideas out to a larger audience and share them?
That's the goal of DevCon, a one day, 99 percent employee conference for the technical staff at Techsmith. (The company also has a one-day, company-wide conference called EvCon.)
What does a conference like this look like? Is it worth the investment? Should your company do something like this? That's what I came to find out.
Once I get in, I pick up a schedule, map and ID badge at the sign-in table. Nothing unusual there - other than the staff wearing cloaks and carrying battle axes, it could be any technology event. Almost.
Bryce Hauptman and Jennifer Dyni (top) help at sign-in, while Larry Hahaie and Eric Pearson (bottom) make sure that "none shall pass" - without a badge, that is.
After sign in, I find a seat in the main conference room, say a few hellos, plug in the laptop, watch the "Welcome to DevCon" Lord of the Rings-themed video and take a look at the conference program.
Excited Employees Get the Goods Before the Session
My first session: "Whole-Team Test Automation: What is ATDD?" with Clint Hoagland - ATDD being acceptance test driven development, a method by which teams come up with examples of the code, and automate the run, before writing the production code.
Hoagland demos an open source .NET tool called SpecFlow that lets the team create examples in something like English. His whimsical example involves a Fortress Alarm:
SpecFlow can take a raw English sentence and create "skeleton code." It's then up to the technical team to write the plumbing to connect that code to the software under test, run the test and report the results. That separates the process of creating the examples (in near English) from the process of creating the code to check.
Indeed, just making up-front examples, in any language, can prevent the arguments over what the software should do that are so common in software development today. Hoagland points attendees to Elisabeth Hendrickson's paper on ATDD, which has much more detail on the concept.