Marc, I was not aware of it – cool blog that I will follow

http://www.castrader.com/

 

You can leave a response, or trackback from your own site.

I know, WinForms is soooooo 2006, but we will not start WPF for real until there are non-beta tools available (orcas/ blend).

Jeremy has a post few a few days back on writing testable win forms apps. My answer is a simple one. Minimize the stuff in the “hard to test” user controls.

• * User Controls/ Composite user controls often – implement some interface. The purpose of this interface is partitioning, NOT for someone else to extend it per se.
• Let’s say we are writing a “trade blotter”, our interface might have methods like:
• Trade[] GetSelectedTrades();
• void MarkTradeInEdit(int tradeId);
• void SelectTrades(int[] tradeIds);
• etc.
• * We externalize the “automation” of the calls to the UI using 2 kinds of “commands”.
• Presenter Commands – their job is to intersperse calls to the UI interface and calls to the “Background Commands”.
• Background Commands – the commands that have nothing to do with the view. These commands often act agains services like:
• BookTradeCommand
• SaveTradeCommand
• GetTradeCommand
• * The view has a reference to s single Presenter that it gives “named gestures”. If someone wants to Click a button and ask to load some trade data, we say something like:
• presenter.HandleGesture(”loadTradeClick”); 
• * The Presenter ”wires together” buckets of commands to a View. This means that for any named gesture, you can “wire it” to some command in the presenter’s bucket. If the View is some winforms implementation of ITradeBlotter, so be it, the commands will automate it. If it is a mock ITradeBlotter, so be it. In the past Spring has been the main device to do this all and it has worked out great – the wiring together commands to named gestures.

Generally, this model is very simple. You can have some developers go off and write a UI component according to some interface you talk about. This helps the team decide what the UI component should do. Before, after or during that process other people can be writing commands to automate the UI via some commands that just talk to an interface that is their view. You get extreme reuse out of the “background commands” that simply do units of work. Whenever you need to change a behavior, add a behavior, etc, you can often just create some new commands and the view stays the same. It is all very very testable in this case. The big win of testability is one, flexability is another, and the ability to work well in a team environment – partitioning the work is a huge win as I see it.

There is lots more I could say about all this. This is certainly NOT 100% automation of the UI tested. It has been in the past “the best we could get”. I would love to have a more complete answer, but this has proven useful to me. I have yet to see a more testable UI development methodology.

-Chris

 

You can leave a response, or trackback from your own site.

In general, “architecture” is a word that carries some heavy connotations in the “agilist” community. We all fear the unfortunate problems that BDUF brings with it. We do not believe it is wise to start off by defining a big detailed design up front. What happens is that once you begin the learning (working) process, your BDUF plan changes anyhow, often A LOT. In this case you are either forced to

#1 Change your BDUF substantially enough that it was a waste of time.

#1 Conform to your BDUF even though it is no longer fit for the work you are doing.

Neither of these things is particularly nice. The agile view is that you let your architecture emerge. You put lots of tests in place, and your system is rapidly changeable. This is all well and good, but the larger the systems get, and the more dependencies there are, the larger and larger the “rework” becomes. For truly non-trivial distributed systems of applications (enterprise application portfolios for example) NEED some contracts between them. The volatility INSIDE one of the specific systems can change a lot easier than the contract that a system has with the systems that depend on it.

The general idea with “architecture” is that for small systems, you need a little, for medium systems, you need a little more, for large systems… etc. You DO want to allow the architecture to emerge, but you also need to coexist in a network of dependent systems. What are we to do?

I will add one more dynamic to the mix. In general, you want to be oriented to delivering “end user effecting behaviors”, not “software elements” per se. The general idea of “slicing the work vertically, not horizontally” has been spoken about a few times before, and it is something that I preach all the time. The basic idea is that you DO NOT want to build your system layer by layer, then arrive at the “end” or “top layer” and finally see it all come together. This is a model of failure for several reasons:

#1 The vaporware problem. Long periods of time pass and you have “vaporware”. You may well have developed a great resource access layer, transports, middleware, etc., BUT if you do not have anything visible and meaningful to an end user – it is STILL vaporware.

#2 When you get to the top layers, you get the fun of seeing the “things you missed” that you need from the upper layers and these changes have to ripple back down anyhow (aka, you were not really done with those lower layers as you thought). This leads to “hidden work”. “I thought we were done with the DAO, why do we keep going back to it”. You have a fake understanding.

#3 You get to see the incongruities between layers later.

#4 You are getting feedback from end users later. You are learning later.

In stead, we slice the “work vertically”. We in stead focus on delivering “user stories” or end user effecting features. We then work on the parts of the system that we need to in order to meet this goal. In this model, we are able to get feedback and learning faster. We are able to evolve the architecture each iteration. We have emergent architecture behavior. We are able to focus on “the prize” that really matters – delivering end user functionality.

OK – sounds good, but what does this have to do with Plinko and architecture? In case you missed “The Price Is Right” era; Plinko is a game that looks like this:

The basic idea is that you drop some disk like thingys in the top, they sort of “plinko” their way down into some predefined buckets at the bottom. Lately I have been using this game as a sort of metaphor for how I have been thinking about software architecture these days. The applications/ ecosystems of applications that I have been working on are large. Investment banks have very very large interconnections of software that is related, codependent, etc. There is obviously the need for some level of architecture. We ALSO want the emergent architecture behavior. In order to reconcile the 2 models, Plinko makes a lot of sense to me.

The basic idea is that your architecture is the buckets at the bottom. The implementation of work items – that are “vertical slices” are the bits and pieces of development along implementing a story that “plinko” down and land in some predefined bucket. People working at levels that cross between systems, on system integration/ collaboration, internal service providers, API providers etc work to define the “buckets” that make sense and provide a basic framework for operation. The best case is that “scrums of scrums” collaboratively evolve the “buckets” of the “grand organizational plinko”. This is real work and there are non-trivial challenges to effectively doing this work. That being said, the idea is to focus on true “breadth” here. The higher level architecture definitions focus more on defining the buckets than worrying about the “depth first” implementation of any particular bucket. The implementers of any particular bit focus on delivering those vertical slices and letting them plinko to the correct place.

We allow our development teams to focus on iteratively delivering “end user effecting features” or stories. Their ability to deliver these is the primary measure that matters. Tested delivered features is all the business really cares about anyhow (yes, quality, fitness for purpose, etc., but basically that). The implementation level inside these buckets emerges. Things that seem to fall outside these buckets can work to evolve the more “macro” level archetecture. In the “scrum of scrums” model, the bucketing of the plinko board can certainly change, but these changes must make it onto the queues of work for any of the players/ teams.

The key here is to work on defining the buckets, but not getting too caught up in immense detail. Things WILL change. Too much definition of detail will be false anyhow. Setting up an architectural model that expects change and allows for implementations to drive the changes as needed is required. The end effect is a system of systems that can co-evolve. This is the real end goal. Building large class software is a challenge. BDUF does not work in general  – the learning that happens during development will change your design. Short sighted design decisions can hamper sustainability with zero design/ architecture. The Plinko Model allows for a bit of both, while allowing teams to “slice the work vertically”.

I’d love to hear any thoughts

Chris

You can leave a response, or trackback from your own site.

WPF/E’s new brand image = SilverLight, WPF browser plugin for XAML everywhere.

Research shows Exchange-Traded Equity Derivatives Set to Skyrocket

Cool stuff.

You can leave a response, or trackback from your own site.

I am currently tasked with a few challenging items.

1. Roll out an effective unit testing practice throughout the several-hundred-developer division of the firm.
2. Roll out an effective standardized agile process throughout the same several-hundred-developer division of the firm.

I am happy to undertake these endeavors, and even happer to have the high level firm support to enable these efforts. My current belief is that with top down guidelines and bottom up organic growth, we have a shot. If we had only 1 of those two elements, then we would be in trouble.

That being said – DOING these 2 things is hard

My first order of operations was to survey many areas of the firm and see what tools, processes, technologies and issues were in the wild. From there – I have gotten a group of TDD allies that are already doing TDD to some degree at least in the firm. Next – my focus is on the ‘development team leads’. My intent is to take the team leads and week over week, instill the ‘core developer values’ that will enable us to transition to TDD. Here is my short list of initial ‘core developer values’ I am going to focus on.

• SoC – Separation of concerns
• IoC – Inversion of control
• Limit use of static and global data
• Write tests 1st so you get the design benefits of TDD not just the “tests”
• Use mocks, actual mocks or ‘fakes’ are OK too.
• Make the code testable at all costs
• Make integration tests in your test harness
• In existing code that has no tests, write tests as you modify it now

If we can instill these beliefs, and teach the team leads to really do TDD, AND get them to feel the value, I believe it will spread virally. I have done this before, bring TDD to teams. The result is usually the same, something like - 10-20% just go for it, like it, persue it and get it. Some 10-20% hate it, fight it, etc. The middle of the distribution is – in the middle, hems and haws and eventually folds to the peer pressure and leadership and does it out of habit. Eventually, best case, event the ‘haters’ come to it if the peer pressure and leadership can hold on.

In a bigger organization, I expect the same basic distribution to hold true. It WILL be harder to get more and more of the middle of the roaders and haters on board just because of the raw #s. Having a team of advocates will help to monitor this transition.

The organization I have running this transition will be run as a scrum process. We have a monthly steering process, a virtual team of ~20 people, a prioiritized backlog of work, etc. Our on demand teams are focused on bite sized goals and we will empirically manage our progress.

My next post I will talk about how I plan on rolling out scrum… fun!

-Chris

You can leave a response, or trackback from your own site.

In preparing for helping some teams learn and move to TDD – I have been going over and over Working Effectively with Legacy Code. I am sure that whenever I suggest that someone’s code is ..ehm - “Legacy” they will not be so happy. That said – I love the definition from WELC on “Legacy code”

Legacy Code = Code without tests

That is actually the same as my working definition. In any case – this book is a wealth of reference for helping teams that have codebases without tests be able to modify their codebases, and get some tests!!! Practical, step by step refactorings for differing scenarios are just what some teams need, and this book has it.

-Chris

 

You can leave a response, or trackback from your own site.

Powerful and Simple

Common Controls

How to Design a Great User Experience

All excellent links from Microsoft’s area on designing apps for vista. In fact – they are just good UI Design guidelines. I have long said that MS spends the most $ on user experience studies, research and has the biggest user base in the world – so follow their guidelines !

-Chris

You can leave a response, or trackback from your own site.