This past Saturday was the Austin Code Camp. I had a great time and the general consensus was that it was a success. Kudos to Jeffrey for organizing the event. I just wanted to follow up with some links to resources that were mentioned in talks and try to tackle a few questions. Other than one Ron Burgundy moment in my code smells talk, I thought things went pretty smoothly. I'll definitely submit only one talk next time though. The content for all the presentations and the sample code will be posted at http://adnug.org.
Depressing, but Common Comments
- How can I convince my management to let us do [insert process or practice here]?
- Schedule trumps everything
We heard from several people who are working in less than ideal circumstances in shops that don't really do things well. I don't mean "they stink because they aren't doing pure XP exactly like Kent Beck says," or "they're CMM level 1!" if you prefer. I'm talking about shops that aren't even using source control or aren't doing any kind of unit testing or most importantly, developers are getting crushed with too many hours. Yes, schedule trumps everything, but I loved the line my colleague, Steve Donie, used in his talk - "I don't have time to sharped my saw, I'm too busy cutting wood!" If you're in a position like that at a company with poor software development approaches, you've got two choices:
- Be a self-starter, learn about better ways to build software that would help your shop, and try to be an agent for positive change. If you can do this, my hat's off to you.
- Vote with your feet and jump ship to a better shop. You might get to learn a lot more at a shop with good practices and strong developers. I learned a heck of a lot more when I jumped out of a dysfunctional development organization into a very strong software consulting company. Both about coding and about software craftsmanship in general. I wasn't the dominant technical talent anymore, but it was a lot more fulfilling.
As far as selling management on new practices, I don't have a clue. What we've learned in the last year is to just do it. Don't wait for permission, start doing more build automation, crank up the test automation, and control your own work practices whenever you can. All most management cares about is productivity anyway.
Code Smells
I wrote a longish blog post last year about removing little code smells from your code as you go: Use a refactoring checklist to pay down Technical Debt as you work
More Stuff on Dependency Injection
Model View Presenter, A.K.A. "The Humble Dialog Box"
This pattern for organizing user interface logic came up several times, and for good reason. It's the best way that I know of for creating a user interface code base that's easy to test and maintain. At some point in the nearish future I've promised another post on using MVP for WinForms development. In the meantime, try these links for more:
Books I Mentioned
There's never time to read everything, but here's a rundown of the books I mentioned or recommeded during the talks.
- Refactoring by Martin Fowler - The canonical work on refactoring, but a great book on coding in the small as well
- Refactoring to Patterns by Joshua Keriesvky
- Applying UML and Patterns by Craig Larman - Still my pick for a great introduction to Object Oriented Programming. I think the latest version scales back the RUP stuff.
- Working Effectively with Legacy Code by Michael Feathers - Best book I read last year
- The Pragmatic Programmer