The 2 day Heartland Developers Conference (HDC) in Omaha was again full of a variety of topics. The keynotes and breakout sessions covered everything from Agile Practices to Build & Test Automation to Architecture Patterns. HDC 2014 delivered a great conference again!
Driving Technical Change
There were a variety of sessions on Agile Practices, but the keynote “Driving Technical Change”, presented by Terrence Ryan captivated me. The keynote opened describing how we all feel after we go to a conference, read a blog or a book. We get excited about something new and can’t wait to use it, but there is always something or someone stopping us from using that new thing. It could be co-workers, managers, architects, stakeholders or anybody in the value stream….I think we can all relate in one way or another.
Now that we can all relate to the problem, the keynote took a turn into a bit of a psychology lesson. The people who hinder adoption of new technology, or just people in general resisting change, tend to have behavioral patterns. Each behavioral pattern responds to change in different ways, so tactics to drive change varies from behavior to behavior.
As developers we are in the midst of driving change, whether it is agile processes, build & test automation, the latest and greatest technology, etc…We are continuously faced with these challenges. Take a look at the slides to take a deeper dive into the behavioral patterns and the tactics for each pattern.
Personas are for Wusses
Another great session, “Personas are for Wusses” by one of the founders of Hudl talked about engaging the end users. Hudl writes software for coaches, players and fans to view film from sporting events. Hudl started with football and has expanded into many other sports. The approach Hudl uses takes the “Build, Measure, Learn” philosophy of agile to another level. It was fascinating to hear stories of how they engaged the users.
There were many humbling experiences from user feedback. Developers releasing a new feature and then watching a real user fail to understand it, was a real “punch in the gut”. To engage user feedback, developers, testers, product developers would:
- Watch Practice – Practice won’t stop for your software, it has to be quick and easy
- Game Day – Watch, listen observe how people interact, work and use your software
- Be in the locker room
- Be on the sidelines
- Be in the coaches box
- Sit in the stands
- Ride the bus
- Focus Groups – Ask for feedback, discuss usability, discuss desired features
- Bring coaches in house or go to coaches
- Webex/GoTo Meeting with players & coaches
- Social Media
- User Voice
- Blog Post
- Customer Support – Everybody takes turns working customer support, including the Chief Product Office
Hudl models their teams after Spotify. Tech Crunch has blog post describing Spotify’s Agile Teams organization and interaction.
A session called “Iteration 48”, was about finding innovation in unexpected places. The session was an inspiring story of how “Iteration 48” engaged the entire company around a 48 hour hackathon. The hackathon was kicked off by the CEO, anyone could participate, anyone could submit any ideas, and teams were self-organized. Each team was responsible for creating an idea and delivering “working software” in 48 hours.
“Pragmatic Software Development, curing the architecture astronaut” was part 1 of 3 of Architecting Applications for the Real World in .NET pluralsight course. The jist of the session was choosing the right level of architecture, Level 1 vs. Level 3. The presenter describes Level 1 as the simplest software to build and Level 3 architecture was described as the full blown SOA, Domain separation, etc…
As software engineers we default to complex solutions. The presenter had great metaphors for simple vs. complex solutions and was trying to shift our thinking to “It Depends” for the answer. There are certain situations when complex solutions are necessary and sometimes when simple solutions are the right fit.
Check out the slides to see great comparisons of simplicity vs. complexity and start defaulting to “Level 1” (Simple) and use “Level 3” (Complex) when necessary.
Build & Test Automation
Another fun session was on GIT. This session provided some back ground on using GIT for source control. The presenter shared great learning resources and how their team got over the learning curve and how they feel after making the switch. Slides & resources can be found at: What’s the big deal with GIT?
Last but not least, there were multiple sessions on automated build and deployments. The sessions were using Team City.