Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

My Official ALT.NET Recap

It took a week, but I finally got around to finishing my recap of the ALT.NET Open Spaces event from last weekend.  I can honestly say that this was the best experience that I’ve ever had at a technical conference.  I’ll mostly pass on name dropping just because I’d end up leaving someone out.  I met a big chunk of my OPML and put some faces to URL’s.  I also got to catch up with a lot of friends and former colleagues from Austin.  I don’t remember more than a handful of minutes of boredom the entire three days.  I got some bigger posts out, but I still have a bunch of little things that came up in conversations over last weekend.

The earlier recap stuff that’s already escaped my hard drive is here:


Action Plan for ALT.NET

The first ALT.NET conference is in the books and it’s time to start thinking about the next one.  I can’t give you any concrete announcements because I flat out don’t know, but this is what I’m seeing or hearing:

  • One of the complaints or suggestions from Austin was to get an online repository going just to make it easy to find content.  There’s been a tremendous amount of content generated on our blogs alone over the last couple years, but there’s no way a new user could easily find the nuggets buried underneath the rants.  I’m proposing, and may just do myself, a small link library akin to the old articles repository at the Agile Alliance website
  • Seattle is the city I’m hearing most for the sequel event, followed by Austin again in the fall.  Absolutely nothing stopping you from doing another one yourself.
  • I think it would be relatively simple to do a low key event in the New York City area.  Enough of us are here to do it, and Microsoft has volunteered their facility to host it in the past.  I think the Open Spaces format makes this kind of event relatively easy to pull off.
  • There’s a Yahoo group going at http://tech.groups.yahoo.com/group/altnetconf/ that’s generating quite a bit of traffic at the moment.  It’s wide open to anyone who wants to join and might already be your best bet for .Net centric discussions of BDD, DSL’s, and DDD.
  • Spend an inordinate amount of time trying to figure out a different name.  The current name is divisive and contentious.  The other proposed names are pretentious.  Google and Technorati are already indexed on ALT.NET.  I expect no movement on that front.  Hopefully that dies down and we can get on with defining what we’re about and it turns into just a random collection of letters.



Testing through the User Interface

I had a couple conversations and a couple email queries about automated testing through the user interface itself.  I’m mostly speaking here about testing WinForms clients because that’s all I’ve done in the past year.  Let me run through this subject in bullet point form:

  • You’ve got two basic options for testing the user interface.  You can either slice the view itself as thin as possible and then use subcutaneous testing to work over the screen behavior from the Controller/Presenter level down.  The other option is to use some kind of tool that can interact with the user interface itself.  Testing web applications is far easier  because of the plethora of testing tools.  With WinForms, I simply start up the Form I want and interact with it directly or with NUnitForms.  My experience is that subcutaneous testing works great with reporting applications, but data entry screens or screens with a lot more behavior need to be tested through the screen itself.
  • It’s all about the design.  Actually that pretty well goes for large scale automated testing of basically any piece of code.  Even when I’m testing through the screen, I try to open up only that one screen without the rest of the application hanging around.  Each screen is roughly an MVP triad plus whatever service providers that the presenter needs to communicate with.  All dependencies from the Presenter back to the rest of the application are expressed as abstracted interfaces, so I’ve got an automatic testing seam.  When I’m testing strictly screen behavior I’ll use StructureMap to set up the individual screen I want to test with stubs in place for the services, repositories, and application controllers that make up the rest of the application.  That strategy allows me to quickly set up screen scenarios inside the tests and keep the tests from getting bogged down in manipulating widgets just to get to the screen I care about.
  • Smaller tests are far simpler than bigger tests.  Whitebox testing is far more efficient in terms of effort to reward than blackbox testing.
  • Should you test against the user interface at all?  There’s a line of argument that says the acceptance tests should test against the actual domain model only.  After giving this some though, I don’t think this is pragmatic.  Practically speaking, the average non-technical person understands the stuff that they can observe on the screens better than any domain model.  In my previous two projects we had a lot of screen behavior that frankly makes the difference between an adequate user experience and an application that’s likeable.  A great deal of event driven screen behavior that can spawn bugs and regression failures like no other type of code.  Once the behavior gets complex, only unit testing the Presenter’s just doesn’t cut it anymore.  I write acceptance tests for my TradeCapture applications for each trade ticket screen and it’s done wonders to tamp down on regression problems. 

I’m reopening “Build your own CAB” just to hit this subject a little better and actually explain how I’m testing my user interface.  I’m starting up the content on testable UI’s as soon as I publish this post.



You have to make the argument in terms of economics

There was a lot of moaning, both at the conference and on blogs later that management just won’t go for this stuff.  You just can’t say “it’ll make the code easier to read and more maintainable” to management and expect them to do anything.  You’ve got to connect your arguments to economics.  Doing this will lower the cost of ownership.  Doing this will make it easier to test and therefore to finish.  Doing this will keep the expensive rewrite away for longer.  Enhancements will be cheaper.  If there isn’t an economic impact in your favor you don’t have an argument anyway.


Too Many Bulls in the Pen

Can more than one strong developer coexist in a small project?  Can two or more strong personalities coexist?  I say yes because I’ve done it.  You’ve just got to be prepared to compromise.  A little bit of mutual respect doesn’t hurt either. 


Language Oriented Programming

It’s veering off in many forms, but there was one very apparent trend in the topics of discussion and interest at ALT.NET.  We’re all trying to express or specify the behavior of the code in the language of the domain problem itself.  It’s the never ending climb up levels of abstractions.  I think of it all as just trying to hide the ugly machinery behind the right abstractions to focus more on the problem instead of the mechanics.  Domain Driven Design is pushing us to think in terms of the problem domain instead of data structures and coding goo.  Behavior Driven Development is a positive evolution of TDD.  Nobody quite seems to agree on what BDD is or how it should be done, but I like the content and thought in this paper on BDD from Tom Adams.

We talked a lot about Domain Specific Languages in all of their forms.  I’m leery of trying out external languages with something like ANTLR myself, but you can write that one off as cowardice.  I had a good discussion about the viability of graphical DSL’s, but I’m still dubious about the general applicability of these.  My main interest is in embedded or internal DSL’s.  Everybody is waiting for IronRuby to get its expressiveness, but Boo might be the thing to use today.  I desperately wanted to fall in love with NBehave, but the syntax in C# 2.0 is just too verbose.  Language Oriented Programming just isn’t going to take off in widespread usage until we change languages.

I do think, however, that there is still some real value in selectively using Fluent Interfaces in C# 2.0.  Jimmy Bogard has some more to say in that regard in Fluent Interface endgame.


Why ScottGu and Co are doing it right with the Model View Controller Thing

We only saw an hour introduction, and there’s a lot of unanswered questions and missing details, but what I saw of the new MVC web framework was more than enough to start salivating. 

  1. ScottGu had me at “Separation of Concerns”  The talk started with a slide on the design values and goals of the MVC framework.  I don’t remember the exact wording, but it included all the magic words like “Separation of Concerns” and “Testability.”  It wasn’t just the slide either because these things came up over and over again.  I honestly think they’ve done the right things here.
  2. As I stated in an earlier post, they’re obviously seeking out lessons from other MVC frameworks like MonoRail
  3. The HTTP runtime objects are, drum roll please, mockable/stub-able.  Amen.
  4. It’s easily extensible.  I think there’s going to be a lot of activity to build specific “opinionated” frameworks right on top of it.  It isn’t a drop in replacement for Ruby on Rails or MonoRail.  I think the apples to apples comparison is with just ActionPack from Rails.  That leaves a lot of other things like scaffolding alternatives and deployment recipes ala Capistrano yet to come.
  5. The view rendering engines are swappable
  6. You’ll be able to use the IoC tool of your choice.  Not a make or break reason, but hearing ScottGu say “Windsor or Spring or StructureMap” out loud was nice.



Executable Requirements

Much more on this in a  later post.  I still think this is one of the last pieces of outstanding business in Agile development.  There’s so much advantage, but the challenges always seem in surmountable.  While introducing this topic in my session, I compared Executable Requirements to the oil sands in Canada.  This giant source of oil we just can’t seem to get to economically.  I was promptly corrected by the Albertans in the room that the oil sands are now producing, so maybe there’s hope.


Verdict on the Open Spaces Format

The Open Spaces format rocks.  It’s been said elsewhere, but I’ll repeat it here.  The best part of every technical conference I’ve ever been to happened in the hallway conversations and in the interactions with the people that you meet.  On the other hand, the talks themselves are usually just so so in terms of holding my attention.  With the Open Spaces format you basically skip the boring parts and get right to the interaction.  The self organizing nature of the format led to sessions where the participants were fully engaged.  Interaction, conversations, and even arguments are more fulfilling to me than watching slidedecks go by.  I can’t wait to do the next event along these lines.

I do think the format only worked because we made it work.  You have to come ready to stand up and actively participate.  You only get out of it what the group as a whole puts into it.


Microsoft isn’t the answer to everything

I couldn’t find any trace of it on the web, but I remember learning a fable in school about a king whose subjects depended upon him for everything.  One day the exasperated king ordered his guards to dig a hole in one of the main thoroughfares leading to town.  Into this hole was placed a bag of gold and a large rock was set on top of the hole.  Anybody passing down the road couldn’t help but notice the rock blocking the way.  Various passersby saw the rock in the middle of the road and promptly went to Microsoft, er, the king, to ask him to remove the rock from the road.  The king despaired until a young man walking down the road finally thought to roll the rock off the road so wagons could run unimpeded.  I don’t remember what happens next, but I assume that the young man lived happily ever after.

There’s another debate going on in the altnetconf group.  Should ALT.NET try to work from within the existing .Net community structures like INETA or .Net user groups, or skip that and do our own thing?  I frankly don’t know.  On one hand you reach more people by staying in the mainstream.  On the other hand we might not be able to make things happen within INETA or the existing user groups.  The one thing I don’t want to happen is get bogged down waiting for Microsoft to make everything better for us.


Microsoft’s Agile Portal

Did you know that MSDN has a web portal dedicated to Agile development?  Neither did I.  Or all of the non-Microsoft employees in the room when they told us about it.  I took a look tonight and there’s plenty there.  It’s in an odd place, but it is there.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in altnetconf. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller


    That’s the first suggestion that I’ve liked.

    Of course some turkey’s gonna say that the NeXT was a commercial failure then somebody else will say it was the coolest thing ever and off we go…

  • Brian Sullivan

    In regards to the name issue, (if it’s not been suggested before) how about “.NEXT”? I think it conveys that the movement is about moving forward, helping the .NET community to “come of age” and embrace mature development practices. I don’t think it’s divisive. Pretentious? Maybe. But just about anything we come up with that adequately reflects our goals will sound pretentious to some people. Just my two cents. Thanks!

  • http://www.lostechies.com/blogs/joe_ocampo Joe Ocampo


    Just be careful with you assertions. I know you have the best intentions on delivering cost savings but you may incur impediments along the way from a bureaucratic perspective that will prevent you from reaching your goal. The problem lies in that management will impose these impediments but will still hold you accountable on delivering your 40% cost savings.

  • http://www.flux88.com Ben Scheirman

    I’d like to echo that tip on speaking in economic terms. Managers don’t care about agile practices unless it will make *them* look better. The person paying the bills doesn’t care unless it saves him money. Speak in these terms and you’ll have more success. But it’s important to actually tie these claims to actual numbers. They don’t have to be exact, but gather some data from past projects and come up with a formula that will tell them HOW MUCH money they will save.

    Saying “it will make our code more maintainable” is a loose statement that won’t get you anywhere. Get some data behind you and make a claim like “My estimates show that our maintenance costs will be reduced by 40%, saving us $250k per year” –this will perk the attention of managers.

  • KG2V

    Ooohhhhh – I’d LOVE to do something in NYC. My BOSSES won’t pay, and I might have to scramle for child care – but YES (Agile Newbie that I am can use all sorts of tips)

  • todd brooks

    I believe #4 on this page is the fable you are referring to: