This summer I went to a the Kansas City Developers Conference (April 27 and 28th, 2012). It was fun and I learned a lot. I have been 3 times before and this is my first time blogging on it so here goes.
What I saw:
Zen of Architecture, SpecFlow, Troubleshooting Software in Production, The Kanban Game, Improving Java & .NET Developer Collaboration, Clean Code – Writing Code for Humans*, From the Steps of The Ivory Tower, Lessons Learned: Being Agile in A Waterfall World, CernerHealthWins.com – A website that got a community to live healthier.
Richard Campbell and Ted Neward gave the keynotes. I found their predictions for the future encouraging and motivating. All in all it was a good conference.
*I really liked the speech on Clean Code but I could not find a link to his presentation on his blog. Here’s a related topic on his blog though: http://www.bitnative.com/2012/04/23/not-enough-time-to-do-it-sloppy/
I also missed the presentation on Reactive Extensions. The speaker wrote the book on the topic. Really, there’s only one book and he wrote it. Also he has an interesting library on Git Hub based on Reactive Extensions. I don’t understand his library yet but I look forward to learning more. Here’s a link to a presentation he gave at another venue (I hope it is similar – I haven’t watched this one yet): http://www.infoq.com/presentations/Reactive-Extensions-and-ReactiveUI. I hope to learn more about this and hopefully post my findings.
The conference seemed to ask developers to be flexible about the look of our workplaces and applications as well as our next task or our use of technology while being diligent to record our progress, communicate to other developers, and make our intentions well known. There was a healthy dose of new technologies discussed but by far the most popular class I attended was the Clean Code class (standing room only).
Organizing our offices around tablets instead of desktops was an interesting concept discussed by the opening keynote speaker, Richard Campbell. He envisions an office with far fewer cubicles because cubes are set up to facilitate the keyboard and mouse interface dominant among desktops. Because of the increasing popularity and diminishing cost of touchscreens cubicles will no longer be necessary. What will offices look like? Richard says it will probably look a bit like a cafeteria with private corners for heads down work and open spaces for collaboration. It is hard to imagine some jobs without the traditional desktop, mouse, monitor (mine for instance). Perhaps as we grow accustomed to working in cafeteria workspaces while using touchscreens we will feel differently. Until then, I’ll stick with my keyboard, mouse, and monitor (even if I know I will be writing touch screen software). Another point he made I thought was quite poignant was the increasing importance of how we approach the task of writing code. It was a theme I heard throughout the conference.
For example, this theme was repeated in Patrick Liekhus’s speech on the Zen of Architecture. There we identified 5 pillars of software architecture: 1. the IT Environment (employers, groups, responsibilities), 2. Design 3. Human Dynamics (political baggage, stakeholders) 4. Quality (“12 ities” such as flexibility, usability, availability, etc.) 5. Business Technical Strategy. We started with an introduction to the Zachman Framework and TOGAF to build an overall strategy then we looked at development management techniques such as prototyping, spiral, and waterfall. Every year I have been to KCDC there are agile experts and enthusiasts. It’s hard to find a real critic of the Agile framework at KCDC. This year Patrick told us in his lecture that “Agile frameworks have advantages of all three aforementioned frameworks”. He suggested that we investigate Kanban which is similar to how we do things in my office. He then listed several tools to help developers with various stages of the development strategy, organization, and lifespan. Before making recommendations I would agree with his statement that you should be sure that the tool solves a specific problem or answers a specific question you need answered to avoid using these tools like Maslow’s Hammer. Among his recommendations he included:
- Balsamiq for rapid prototyping
- XAF another rapid prototyping tool by DevExpress
- SpecFlow for Unit Testing
- XPO an ORM by DevExpress – I’ve used this several years ago and I liked it.
- NHibernate another recommended ORM
- He also recommended that even a small development shop should have automated builds (this concept was also repeated by several speakers later over the weekend)
The SpecFlow lecture was good too. We started by identifying Brittle Tests as those tests that are difficult to automate and when automated require more maintenance because of their tendency to break for reasons unrelated to what the tests are trying to prove. Or as the speaker put it, “Your tests are slow and broke because of stuff you don’t care about”. Since these are the most expensive they should be less of them. The cheapest unit tests to maintain are the isolated method by method unit tests but they are often so incremental that many of them are needed and they mean little to nothing to end users.
Enter SpecFlow. It reads more like acceptance test but is not as brittle. The primary goal of SpecFlow is to be living documentation of your requirements which get to live by running as unit tests although they sound like Feature Requests or Specifications. SpecFlow is made up of Features which contain one or more scenarios. Features read like agile stories: In order to (Goal) As a (Role) I want to (Function). Scenarios consist of 3 pieces that read like this, “Given (some precondition) When (some action or function) Then (some reaction to when or result of when)”. He said that since it is living documentation you could make SpecFlow the primary source for requirement documentation. However the scenarios are laid out in more detail than most feature requests and user requirements I work with. This makes sense because they are fleshed out to enough detail that they can be interpreted by the SpecFlow Engine and run just like Unit Tests.
How does this all come together? SpecFlow can be written void of any actual code in a human readable format, see above. The C# unit testing code uses attributes to tag all given, when, and then components referenced in SpecFlow’s scenarios. If a scenario has all of the required components in attributes in the code the SpecFlow engine will run the test. SpecFlow even supports code reuse by allowing given, when, and then attributes to be used by multiple tests. It supports complex scenarios by allowing for multiple givens, whens and thens in a single scenario.
Since SpecFlow uses markup to find the appropriate methods to call it integrates nicely with other Unit Testing libraries and or any custom libraries. Since I am a big fan of TypeMock Isolator I like the possibilities this opens up. There are some tools that come with the SpecFlow library such as support for creating mock array tables on the fly which looked useful. Hopefully I can flesh out some ideas I have about this in a future blog entry.
Finally Jon von Gillern left us with some his best Unit Testing Tips:
- Red, green, refactor (obligatory TTD reference here)
- Statics are evil unless you’re testing
- Parameterize your steps so you can find them again using RegEx
- Break Scenarios into small reusable pieces
The speech on troubleshooting by Patrick Delancy had me writing a few things down I think are common sense but worth repeating such as: Establish a performance baseline and keep track of it. Sure it costs a little performance to measure performance but it’s worth it. Keep your changes stable, localized, and be able to communicate what you are doing and what you have done. Never re-throw an exception because you loose valuable stuff when you do that; but if you do never swallow an exception without at least logging or recovering from it because you loose valuable information there too; not to mention this will raise the potential for logic errors. The difference between an accident and a solution is knowing what you did to fix the problem. Being capable of reproducing the solution if a similar problem is encountered is your proof that you have a solution and not an accident. If you create a solution instead of a happy accident you can turn a negative (losses related to the problem occurring in the first place) into a positive (gains related to understanding a lasting solution). Then he recommended several tools:
Though I did not attend them, I did find links to the following presentations given at KCDC:
(Some links go into more depth than others) Business Oriented Development, Intro to python, Getting to the point with Sinatra, Open Source RESTful Search Solr / Link 2, Domain Driven Design and Unit Testing Patterns and Antipatterns, Android Scripting
Presentations I missed and could not find any resources online. Help!
Software Quality is everyone’s responsibility, Enterprise Scalability, What makes a strong
Here’s a link to the entire conference (see here for other topics I missed and some presentations and speakers may be linked to from this site): http://lanyrd.com/2012/kcdc12/
Other presentations and blogs from speakers:
I believe I will return next year. I seem to get more out of this conference every year I attend. Were you there? Did I miss something truly excellent? Did I misunderstand some of the details I shared here today? Please let me know.