My Pex has not flexed recently. Peli has dropped a new version of Pex with a few breaking changes and I’m two revs behind him on implementing. One thing that I’ve come to realize is that I can’t manage the churn taking place for the code under test. The last few sprints have introduce large amounts of change in our persistence model and that, well, just screws the pooch when you’re trying to keep things updated. I’m trying to figure out the best way to manage the churn in my testing libraries – and hopefully Peli implemented some of my hidden feature requests he noticed a while back.
In addition to this a framework for Silverlight UI testing dropped (twice) during my last sprint and this was an interesting and valuable distraction from Pex. However, in Pex’ defense, it is very easy to rebuild anything you’ve constructed so far but my advice would be to version your custom code. I built up many stubs and factories for Pex to use when it needed to build up certain types. Most of that code I can keep since the interface changes were limited in some areas. Other areas it was not, and that code will just get dropped.
My strategy will probably revolve around the UI and service implementations and balance when they are getting close to “done-done”. Most of the Pex setup work can be done on the “not-so-done” elements and then will get fleshed out when they arrive at “mostly-done-done” stage. We have a mocking library as well which has a lot of code that will change as well, but for the most part isn’t adding much value while Pex is duplicating some of this effort. The library we are using works with Pex, so I may have the libraries join forces and/or just build my own PUTs for the “mostly-done-done”, this would be on the service implementations.
That still leaves the Silverlight unit testing work, it’s very automated as well and can using the A-A-A model for building tests like Pex suggests. Oh, and the bread crumbs I need to leave behind for the sustainment folks as well have to be straightforward otherwise I’ll be building tests that won’t be used in the future for regression. Pex helps with this, but folks will need to (want to) understand how that happens. All of this to aid in getting us closer to CI – more rapid feedback for all to see and use.
More later.
Last night I finished my first SketchFlow project last night. I was using the (free) first chapter of an upcoming book “Dynamic Prototyping with SketchFlow in Expression Blend”. This copy doesn’t look like first draft stuff, it’s stuff that you can use right now. The free chapter gets you grounded with how you can put SketchFlow to work for you.
The first thing I did was set aside what little I knew about prototyping. I’ve used many napkins to layout an app and that makes total sense. The examples do as much but have added color to their napkins (sketches). While building this first project I wanted to make things click and move, add behaviors, “oh, I can make this spin or flip!”, you get it. Resist that urge and wait to satisfy those “demons” when your layout is finished.
Taken from the “Who Should Read This Book" section
If you’re a software architect or developer that often finds yourself thrust into playing the role of a designer in your projects and day to day activities you’ll find that the techniques put forth here will enhance your ability to do better work. This book shouldn’t however be regarded as a replacement for having the capability and skill of a professional designer on your project team.
Bingo. I won’t feel too guilty about wearing a designer hat for my own projects, but my designs shouldn’t go much further than something that has a Balsamiq look (which it can do OTB), nothing polished but still conveying intent. That’s what we’re after right? Not even being a devigner (or Deselepor as they said on C9 yesterday) myself, it was hard not to stay out of the behavior folder. But I did. If you’re the hard core designer, you probably have more business in that behavior folder than I but get the layout right and flowing first. Let me rephrase that, get your sketches laid out and flowing, first. Adding navigation is a snap and once I wired the navigation for each object in the SketchFlow Map surface (the pane on the bottom with the colored shapes) it worked. After I started exercising the the flow navigation when I ran the app a few things happened: more/better ideas for the flow and layout started appearing; I dropped a shape and added two; made a few navigation connection swaps on a few shapes which made more sense after walking through the app; I came up with a better name for some shapes. Two words: rapid feedback. Two more words: love it.
I followed along in the first chapter until the author begin importing assets. Then I scanned my own sketches I had done a few nights before during a trip to the library with my kids. Within an hour I had things snapped together and the SketchFlow Navigator was moving me around the layout. The export to Word worked as advertised. I’m going to take this back to see if I can enlist some folks using Blend for the first time to help build up the application. This will mainly be an exercise to help move myself and someone else forward using this technology. I’ve already added the few initial user stories to my AgileZen backlog so I ready to go.
Lessons Learned
- Scan as grayscale if using #2 pencil and regular 8x11 paper
- Ink pens or Sharpies work better but don’t have erasers
- Can add some color for emphasis using Sharpies
- Multiple sketches on one page can be imported as Sketch01, Sketch02, …
- Multiple sketches on one page, then use Paint(.net) to crop into individual sketches
- Import cropped sketches, images, etc. into appropriately named folders with descriptive names
- Cropped sketches with real names that match SketchFlow shapes helps with Assets display later on.
- If possible use generic names for sketch components so they can be composed on multiple shapes
- Try to keep Sharpie tips off of the library table tops
BDUF was especially interesting when I heard Peter Provost and Billy Hollis speak on this topic during their presentations at the PnP Summit last year. Both made points that I could definitely relate to. You see the (embarrassing) thing about this post is that I didn’t know what BDUF was, and was living it everyday, but waterfall was supposed to be OK? I never heard anyone say BDUF until I hooked up with .NET a few years ago (I wrote my first line in December of 2003), even having done a few tours with Java (1.1) and VB6/ASP. Instead it was a place I had spent many years living in, remember The Truman Show, like that.
I was driving home today after a very long day of WCF unit testing for a current project I’m helping with and realized why the day was so long. I wanted everything to work like it was a BDUF project. I thought everything I was working against in the DAL was done, that’s what you finish first, right? A very awesome coder who is our technical leader is cranking out some awesome NHibernate bits for our DAL. But we’re using Agile to make this solution happen. My first sprint planning meeting I was biting my tongue to keep from asking BDUF questions, this was the first sign that this BDUF was very deeply engrained in this developer’s habits and thoughts. Maybe I’m making it sound worse than it is. But having done so much BDUF development which never really had a great design to begin always looked like something else, and didn’t really hit the target, budget, or timeline. I’ll stop there, I won’t throw anyone under the bus – teams succeed and fail together.
I thought it was worth throwing out a few words on the topic since I’m really enjoying the Agile development and the community is by and large running with it (slowly) as well. But, to a point that Billy Hollis made, waterfall development has a place in some shops projects. He gave an example on building rule-based systems where the rules needed to be defined before the system construction could start. And in that example, his team was successful and the customer was happy with the result.
However, in my experiences, I’ve seen and been a part of the teams that left a wake of poorly written code that couldn’t be maintained. How could this happen? I think that some folks believe that it’s far less expensive to support a system than to (re)build it. I heard Michael Feathers discussing a Strangler System on Hanselminutes. I can see this approach working for some of those systems, however the date on the article is June 2004. Just like Truman I was fast asleep and no one was trying to wake me up back then. If the community was thinking about Strangler Systems, we were probably aware that the waterfall might not be a great thing.
This sprint is going very well so far and it’s still early. The customers are asking great questions, providing awesome feedback during the cooldowns – and we are not reacting, but we are responding. And my part of the sprint will be going even better once I get back to my desk and comment out the code that really shouldn’t have been written in the first place. Refactoring code that doesn’t even serve a need yet, geez! But with BDUF you are always in that 9th inning push to clean the bases and bring everything home. Like Ted Williams, I’ll just try to get my three hits each game, win or lose. Someday I’ll get to Fiji, the airfare in my part of the division is getting cheaper by the sprint.