Gáspár Nagy on software

coach, trainer and bdd addict, creator of SpecFlow

Re: Rapid Feedback

by Gáspár on April 11, 2011

I’ve read yesterday evening the post of Attila Domokos about rapid feedback that made me thinking. Here is my reaction that didn’t fit to a regular blog post comment.

I think no company should afford wasted time and having a development environment that is determined to waste time is a usually forgotten, but important factor in this. The scenario that has been described by Attila is known to all of us. Well known. Though the story can end many different ways. For Attila, Rails was the “solution”. For me it is BDD and good practices. (I’m not against Rails at all. Rails is fine, but these problems have to be solved within .NET for most of us.) I’m absolutely agreeing with the idea however, to use the right tool (framework) for the right job, but it would be very sad if it would turn out that WPF development cannot be efficient. (I’m not sure though… I know another Attila who would immediately tell me that it cannot, but I’m still hoping.)

[BTW: I’m pretty sure that there are a lot of devs (not the ones working with me fortunately), who actually love this situation and use the compilation times to read the daily newspaper.] 

As a developer and developer coach, I always try to ensure that the team is taking the time (early enough) to setup a development environment where you can get rapid feedback. For a WPF-frontend .NET app, here are my suggestions (I’m not saying that we can always do all unfortunately):

  • Do BDD/ATDD in a test-first, outside-in way, so that usually you don’t have to start up the application for testing the functionality. (We do this with SpecFlow of course. :-)
  • Consider testing the functionality at the controller level (as well?), in order to get feedback about the implemented functionality without the slow UI automation. (At least until we have a good test framework where the automated UI testing is really easy and fast.)
  • Do TDD for your inner components. Ensure that the unit testing environment and practices are confortable and helpful. If the tests are executed only after the run-and-test round has been done, you did not win too much.
  • For WPF, (try to) make sure that your controls can be seen in the VS designer or blend (aka “blendable”), so that you don’t have to start the application for pixel proofing. There are infrastructure for design-time data, but introducing it late is very hard.
  • Implement shortcuts to your application that the run-and-see test can be also done more efficiently. For example, you can make a stub authentication/authorization provider that bypasses the login screen.
  • Optimize the build process to be fast – review and remove projects, post-build events, slow signing process, etc. from the build configuration that you use for development. (Be very careful with post-IL tools, like Code Contracts or PostSharp.)
  • Measure the difference and argue for faster development machines, solid-state drives.

Still, it can happen that you have to wait. Personally, I’m using this waiting time for “development”: Even if I’m not doing TDD, I always follow the practice of “making a small piece work” and then “making it better” (refactoring). So while it is building, starting up, etc. I’m already thinking about the refactoring possibilities. Try it! It’s a little bit exhausting, but fun!

Comments are closed.