Wizards of Smart

With my current mindset that things are broken, I dive into my current readings including The Goal and The Toyota Way.

The Goal: A Process of Ongoing Improvement

I read The Goal back in my business graduate school days (about 5 years ago), but now its reading has a whole new impact. I am seeing more into the book after 5 years of working in software than I did as a fresh college graduate. Some of the mental exercises the protagonist in the book is going through I am going through as well. As he wrestles answering questions concerning his factory, I am wrestling with the questions concerning my software projects.

The first exercise is to define ‘the goal’ for his company and all companies. Of course the protagonist takes a long time to come to the logical conclusion that it’s to make money.

Every company’s goal is to make money.

As a software consulting company, how do we make money?

We make money by winning a bid for a project and then performing the work to complete the project within budget.

That seems pretty simple. Nothing about data access technologies, TDD, user stories, or any sort of architecture or design pattern.

If you need X done and will pay $Y then we should do X for less than $Y.

Why is it so hard to deliver on that? Define X Estimate Y …something Profit!

If we scope a project then we need to know what X is. Simple to say, but man is it difficult to capture!

X is always in motion, a moving target. The client changes their mind, we have scope creep, and what appears simple always ends up being more complex. We all know this! Its the one constant with software development. Things are going to change.

From my perspective, SOLID and design patterns focus on writing code that is more adaptive to change.

SOLID and design patterns in of themselves do NOT move us towards our goal by reducing the cost of writing software.

SOLID and design patterns move us towards our goal when our software has to change because the cost of the change has been reduced.

The principles and patterns also provide a common language for developers. That common language moves us closer to the goal because current and new developers can grok more of the design in less time. And time = money.

Where does testing fit into all this?

Testing allows us to keep track of the quality of our production. Or.. does it? After some re-examination I want to say testing adds no quality. That will have to be another post.

Testing provides a way to measure our progress towards X. We know we are moving towards X because we can have tests that verify we are delivering towards our promise. When I mention testing I am using a broad definition and including all sorts of tests from UAT testers to automated unit tests.

So what does Test Driven Development (TDD) provide? TDD focuses every bit of code towards satisfying a test. If every test is relevant towards progress towards X, then TDD focuses our development towards productive work. Logically any work not moving us towards delivering X to our clients is unproductive work.

Where are we now?

Well the goal of a software consulting company is to make money. We make money by completing X under $Y. One of the important steps is to then define what X is. We know X will change so we should write code that is adaptive to change, but we need to balance that with only writing code that moves us towards delivering X.

We achieve more flexible and understandable code by using SOLID and design patterns.

We measure our progress towards X by passing tests.

TDD focuses our coding towards productive work.

I started to write about estimation in this section but have decided to move it to another post. After thinking about estimation, it has nothing to do with knowing what X is. Estimation has to do with what we think $Y is. X is what X is regardless if it takes you 3 hours or 3 months to deliver.

I love talking with Ryan and others passionate about new technology and languages. Lately though I have been increasingly jaded with anything ‘new’.

How many different data technologies do we need? ADO .Net, Nhibernate, Linq-2-SQL, Entity Framework version.. whatever. We have been connecting to databases for over 20 years so why are we still worrying about this?!

The sheer number of UI frameworks is reaching the point of ridiculousness. I was reading the WPF Disciples Google Group and ran across this post. Paul Stovell listed all the MVVM, MVC, MVC frameworks he knew of (around 11). Then everyone was commenting with their own ‘me too’ response.

Am I the only one who finds that utterly hilarious? How many frameworks do we need?!

Ryan is extremely involved with Ruby, Python, F#, and the other ‘new’ languages to the .Net Framework. I have been delaying learning Ruby for too long, because it’s hard to get motivated to learn a new language. I see the potential and the possibilities, but I quickly get discouraged and uninterested.

I have to ask myself… why am I jaded? Why am I disinterested in things that used to excite me?

The more I thought about it, the more the conclusion became crystal clear. Every project I have been a part of has had the same problems. None of the problems were technology related.

Why would I get excited about a solution to a problem I don’t have?

Reminds me of Karl Pilkington’s comment about this picture of twins on one of the Ricky Gervais podcasts. Karl saw a picture of a set of twins on an office desk (obviously the kids of the guy sitting at the desk). His great idea was since they look alike and are dressed alike, the parent could just have the picture of one of them and save space. Ricky Gervais then commented something like :

What you have there is the best non-solution to a problem that doesn’t exist.

And that is pretty much how I feel about most of the technological innovations these days.

For example: can someone explain to me how Oslo is going to help me? I am also not sold on RIA or anything Cloud related. The technology is interesting, but I can’t justify where I would use any of this stuff.

Sometimes I feel like a lone engineer shoveling coal into a furnace on a runaway train. I don’t know where we are going, where we have been, and all I hear is FASTER, FASTER!

When I scream for help, I get delivered a better shovel.

I don’t want a better shovel, I want to know why I am shoveling so much coal!!!

Can’t we do more with less? Can’t we slow down? Do we even know why we are in this train?!

Lately the murmurings on different blogs, podcasts, and developers has been that software development has gotten too complicated. How can that be true when we have tons of tools and frameworks that should make life easier? jQuery makes Javascript easier. Pick your favorite Data Access tool / ORM makes data access easier. Any number of UI frameworks makes UI construction easier. So why do we think things are more complicated? Shouldn’t our life be easier?

The majority of projects are always behind, always over budgeted, and always unclear on where they are and where they are going. This has been my experience spanning multiple companies and multiple positions on different teams. I am fully humble enough to recognize that “I” might be the problem, but I doubt it. There is enough shared pain through my conversations with other developers to recognize its a industry wide problem.

The only project I was a part of that didn’t feel this way had a full time Project Manager and a team full of very skilled developers. To me it didn’t feel like the project was better run, it was just we had enough skilled team members to overcome any poor execution or poor planning. That isn’t saying our PM wasn’t an all star because he was. My point is that although the project was a ‘success’ I didn’t feel like it was successful because we had a great methodology. We just powered through any complications.

Every project (including that last ‘successful’ one) always had mad dashes of insane hours of work followed by listless lulls as we waited for one thing or another. I never felt I had enough time to do my work and other activities related to work (ie blog, present, create frameworks)

Where am I going with this? I wanted to capture my state of mind and why I am re-examining how and why I develop.

The status quo will burn me out.

The ole definition of insanity : Doing the same thing over and over again expecting different results.

I am tired of doing the same thing, so what can I do different? Why is there this constant pain? I know there are solutions and it’s time for me to document my mental journey as I search for answers. Maybe my breadcrumbs will help those that follow.

What I am starting is a mental exercise exploring how my view on software development is changing. Since this is a basically a brain dump, treat it as such. Feel free to comment on what I say… offer advice and opinions. Maybe there is something you can sympathize with.

What has started me thinking along these lines has been my recent readings of The Toyota Way and my re-reading of The Goal.

The Toyota Way

The Goal: A Process of Ongoing Improvement

Both readings have me re-examining my career and software development. Asking questions like, Are we focused on the right things?

Anyway here are the posts:

• Jaded .Net
• The Goal
• Estimating the Impossible

Here is the problem, we have a list of ‘commands’ we wish to show depending on what view model / entity is active. If we just had a collection of ICommands, we could show buttons but what would their content be?

My solution is to use the decorator pattern to decorate commands with a Name that can be used as the content for the buttons.

My decorator looks like :

public class NamedCommand : ICommand{    public NamedCommand(ICommand decoratedCommand, string name)    {        _DecoratedCommand = decoratedCommand;        Name = name;    }

    readonly ICommand _DecoratedCommand;    public string Name { get; set; }

    public void Execute(object parameter)    {        _DecoratedCommand.Execute(parameter);    }

    public bool CanExecute(object parameter)    {        return _DecoratedCommand.CanExecute(parameter);    }

    public event EventHandler CanExecuteChanged;}

I then created an extension method on ICommand :

public static ICommand Name(this ICommand command, string name){    return new NamedCommand(command, name);}

So in the code I can now do:

Commands.Add(new ActionCommand(OnOpen).Name("Open"));

For my WPF visual, I have a DataTemplate :

<DataTemplate DataType="{x:Type Commands:NamedCommand}" >    <Button Content="{Binding Name}"            Command="{Binding }" /></DataTemplate>

Anyone who has worked with INotifyPropertyChanged knows that this simple interface can be a royal pain in the ass.

To try and eliminate the pain, people have created some great solutions using AOP : IL weaving (PostSharp) and using a proxy (Castle Dynamic Proxy).

PostSharp has a little too much voodoo for me atm. I think I will warm up to it though and re-examine using PostSharp on my next solution. But for now, I wanted to use Castle Project’s Dynamic Proxy.

Naturally since Castle also has a very popular IoC container in Windsor, most examples marry Dynamic Proxy and Windsor to form an AOP INotifyPropertyChanged solution.

Since I am using StructureMap for this project, I endeavored to create my own solution using Dynamic Proxy.

My first attempt I shared at the Virtual Brown Bag look liked it worked but in reality I was constructing my objects twice.

Once with SM and once with the Proxy generator.

I had to go back to the drawing board and posted my problem at the SM google group. http://groups.google.com/group/structuremap-users/browse_thread/thread/1a6b19ce8152db1b?hl=en

I believe the syntax given to me was an older version of SM. For the record, I am using version 2.5.3.0

But it did direct me to the general idea on where I should start looking. I ended up needing to create an IBuildInterceptor.

public class MyBuildInterceptor : IBuildInterceptor   {       public MyBuildInterceptor(Type concreteType)       {           _ConcreteType = concreteType;       }

       readonly Type _ConcreteType;

       public object Build(BuildSession buildSession, Type pluginType, Instance instance)       {           var constructorArgs = _ConcreteType               .GetConstructors()               .FirstOrDefault()               .GetParameters()               .Select(p => buildSession.CreateInstance(p.ParameterType))               .ToArray();

           var interceptors = new List<IInterceptor>                                  {                                      new NotifyInterceptor()                                  }                                  .ToArray();

           return new ProxyGenerator().CreateClassProxy(_ConcreteType, interceptors, constructorArgs);       }

       public IBuildPolicy Clone()       {           return InnerPolicy.Clone();       }

       public void EjectAll()       {           InnerPolicy.EjectAll();       }

       public IBuildPolicy InnerPolicy { get; set; }   }

To register my ViewModels I created a convention using a TypeScanner

public class MyNotifyConvention : ITypeScanner{    public void Process(Type type, PluginGraph graph)    {

        if (type.GetInterface("IViewModel") == null)            return;

        var interfaceType = type.GetInterfaces().FirstOrDefault(i => i.Name.Contains("ViewModel")                                                            && i.Name != "IViewModel");

        if (interfaceType == null)            return;

        graph.Configure(r =>                        r.ForRequestedType(interfaceType)                        .InterceptConstructionWith(new MyBuildInterceptor(type))                        .TheDefaultIsConcreteType(type));    }}

I then used a Dynamic Proxy Interceptor that I basically copy and pasted from Serial Seb’s example.

public class NotifyInterceptor : IInterceptor{    public void Intercept(IInvocation invocation)    {        // let the original call go through first, so we can notify *after*        invocation.Proceed();

        if (invocation.Method.Name.StartsWith("set_"))        {            string propertyName = invocation.Method.Name.Substring(4);            RaisePropertyChangedEvent(invocation, propertyName, invocation.TargetType);        }    }

    void RaisePropertyChangedEvent(IInvocation invocation, string propertyName, Type type)    {        // get the field storing the delegate list that are stored by the event.        var methodInfo = type.GetMethod("RaisePropertyChanged");

        if (methodInfo == null)        {            if (type.BaseType != null)                RaisePropertyChangedEvent(invocation, propertyName, type.BaseType);        }        else // info != null        {            methodInfo.Invoke(invocation.InvocationTarget, new object[] {propertyName});        }    }}

Instead of looking for the PropertyChanged Handler, I create a RaisePropertyChanged method and use that. Although I could raise the event using the field method Seb was using, WPF wasn’t updating the binding. I didn’t really bother to investigate and just rolled with this solution.

So that’s my solution and I’ll start using it in my current solution. Naturally I will clean up the code some more etc. Feel free to use this for any of your own projects. You can also get the solution at my GitHub:

http://github.com/RookieOne/StructureMapAopNotify

JB here… Wow! Techfest was lots of fun! I got the chance to see and talk to a lot of my friends who I haven’t seen in awhile.

Also, it was nice to be finally finished with my two presentations. Both were fun but I will admit to liking my Evolve Your Code material a bit more than the WPF Input Validation. They were both a lot of work. Be sure to thank presenters. I knew work went into the presentations but I didn’t appreciate how much until I tried to do two. I learned a lesson with that decision. Never do 2 new presentations. It’s way too much work and both suffer from neglect. I will write a post on all my presentation lessons later.

Without the 2 presentations looming over me and my new job, I should be able to get back to blogging more. I love sharing what I know, even if its just to myself months from now when I forget everything.

For the slides I am trying out slideshare and am also using Git Hub for the slides and solutions.

Evolve Your Code:

http://www.slideshare.net/RookieOne/evolve-your-code

http://github.com/RookieOne/Evolve-Your-Code

WPF Input Validation:

http://www.slideshare.net/RookieOne/wpf-validation

http://github.com/RookieOne/WPF-Input-Validation

Ryan is the monad king. Ok.. well maybe not the king. But he has a big megaphone and drops a ‘monad’ bomb daily. He has been doing some fantastic work in F# and C# using monads. He shares his code and I just stare… going WTF is this!

I know the basic concepts of what a monad is mostly due to random discussions. I never put any solid research time into what it is… why I would use it… and where does it fit into the larger scheme of my personal development toolkit.

I started my adventure in learning where I normally start… wikipedia.

http://en.wikipedia.org/wiki/Monad_%28functional_programming%29

Whoa.. lots of new terms thrown at me. Here are some random notes and crazy thoughts I am pulling out (mostly for myself).

“a monad is a kind of abstract data type used to represent computations (instead of data in the domain model)”

That sparks some ideas. Anyone who talks to me on a regular basis knows I am a huge Greg Young CQS fan. I think I’ve always been circling around these ideas but Greg’s insights just pulled away the haze and brought into focus the essence of what always bothered me.

For more information on Greg Young’s CQS, I would suggest http://jonathan-oliver.blogspot.com/2009/03/dddd-and-cqs-getting-started.html

Jonathan has compiled a great set of links to get introduced to the ideas. I am by no means an expert, but I consider myself a CQS disciple.

Back to monads.

The idea of the ‘domain’ being a ‘computation’ or ‘action’ more than data makes me think there might be a connection to explore.

“Monads allow the programmer to chain actions together to build a pipeline, in which each action is decorated with additional processing rules provided by the monad.”

This makes me think of the ‘reconstruction’ of a domain object by processing its events. That would be a neat POC to put together.

“The return operation puts a value from a plain type into a monadic container of type M. The bind operation performs the reverse process, extracting the original value from the container and passing it to the associated next function in the pipeline.”

I am still unclear on the whole wrapping business. I think I will revisit this again after going to another location to learn about monads.

So I moved over to Channel 9 and began to watch:

http://channel9.msdn.com/shows/Going+Deep/Brian-Beckman-The-Zen-of-Expressing-State-The-State-Monad/

Here are some random notes / quotes:

“Only two types of variables. A bound variable and a free variable. Bound variable is a function argument. A free variable has to be looked up somewhere else.”

State monad takes a state and spits out a state, content pair.

“Composition is good”

“Mathematics is the art of abstraction and precision”

Is functional programming and monads a disruptive technology? Although it technically isn’t that ‘new’. I think it might be. The comments around an army of OO programmers and the difficulty for learning to think functionally just resonates with the idea that functional programming is a disruptive technology (even though functional programming isn’t new).

Ok… That was a pretty rough first day. Lots of terms and pictures and strange code thrown my way. It’s time to process the information. I’m pretty sure I will need to watch that video about 5 times in-between coding this stuff. I plan on trying Brian’s exercises along with watching ‘Don’t Fear the Monad’ (another Brian Beckman presentation).

Ryan already has completed the first exercise in C# and F#. I will work on my own version of the C# exercise and then look at his code. I don’t think I will dive into F# right now. I played with the language about 2 weeks ago but all I did was create ‘Hello World’. There is a F# user group meeting on August 27th where I ‘might’ try to code these exercises.

Glenn Block has an excellent post titled “The spirit of MYYM, it’s not a code counting exercise”. The post can be found at CodeBetter.

I thoroughly enjoyed the post and greatly appreciate practical discussions on WPF/SL application patterns. I am a bit of a WPF nut having lived and breathed xaml for over 2 years. I’ve been a part of 2 successful WPF projects (both in production). In both scenarios I acted as the defacto WPF guru.

This last project was a typical line of business application and we used the ViewModel pattern with Prism. I bring all this up to share my background with WPF and ViewModels.

Concerning the content of the post, I agree with Glenn on the majority of the content. The Commands and Parameters especially rings true. I found that whenever I went with option A [using element binding to a command parameter] I ended up refactoring it to option B [binding the ‘selected’ item to a property on the ViewModel]. Although a neat use of xaml, in practice the binding to the property just allowed more flexibility that indubitable becomes necessary with future changes and demands (not to mention testing opportunities).

With both projects we didn’t have the luxury of a full time designer. In both scenarios I argued there was plenty of work for a designer, but alas the resources just weren’t there. We were able to use a designer for a decent chunk of hours, but more could have been done. The applications were definitely better off for having every hour we could get from any designer resource. I believe the last project persuaded many that indeed there was enough work for a full time designer, so maybe I can hope for a designer with a future application.

I say this because I can not speak towards what its like having a designer in Blend all the time working on Views. When we used a designer resource, they would work in Blend and then a go-between developer / designer would take the xaml and integrate it with our ResourceDictionaries.

What I would like to address is the ‘no code behind’ philosophy compared to the code behind practicality.

Two years ago when I was floundering for WPF information and blogs, I ran across a blog post (I want to say it was Josh Smith) where the writer stated something like : “if something is easier to do in the code behind then its okay to do it in the code behind.”

He was arguing that a crap load of xaml vs a couple lines of code behind isn’t an argument at all. The code behind is the best choice. Naturally clearer intentions and code maintainability takes precedence over having a dogmatic “everything in xaml” approach.

With this last LoB Prism application, we had some choices to make when we were deciding on how the client should be made up.

Do we use UserControls as Views or (as Ryan Riley brought up) do we use Data Templates as views. I felt at the time the team wasn’t ready for that leap to Data Templates as views. I considered the code behind of a User Control as a placebo safety net for a team struggling with the WPF learning curve. What I did do was firmly encouraged a no code behind policy. A “no code behind” challenge if you will.

If I were to go back to the beginning and make that View decision again, I would go with the Data Templates as views. The team did very well without using the code behind. A Data Template view would have brought more benefits than the cost of having no code behind. Often we found ourselves thinking.. if this view was a data template and not a user control, then we could more easier do X.

I have championed the “no code behind” stance internal to Catapult and to other developers. Yes you can legitimately use the code behind to accomplish certain tasks. More often than not though (in my experience), the use of the code behind has more to do with the prejudices carried over from WinForms development. Having a strict no code behind stance forces developers to learn and change the way they think about coding functionality into the UI.

Glenn came up with a scenario (albiet a overly simplified one) of where he felt a code behind had some value. The scenario described is:

‘”The user clicks a Save button on the Edit Order screen which requires some UI cue to the user such as an hourglass while the order is saving, and another cue once the Order has saved.”

He argues that the code in the xaml is less testable. He even suggests the solution I made. He also recognizes others my disagree. Count me in the disagreement camp.

I created a simple project that uses Attached Dependency properties to accomplish this simple scenario. This isn’t a “throw down the gauntlet” sort of thing and I didn’t really write it for Glenn. A coworker emailed Glenn’s blog and I responded in an email describing my solution. He then asked to see it in action. So I coded it up.

He also asked me to post a comment on Glenn’s post, but I don’t really see the point especially since I agree with the information Glenn is sharing and his opinions are built on experience & expertise. I really had no disagreement and the solution Glenn already knows of. /shrug

Anyway.. you can find the solution here : http://github.com/RookieOne/AttachedAnimation/tree/master

Ayende tweeted a brief code snippet of some WPF he threw together (well I assume he threw it together).

You can see the code snippet here : http://pastie.org/568259

He asked : Someone PLEASE tell me there is a better way than this (WPF)

I tweeted a brief snippet response to improve that tiny bit. The snippet can be found here : http://codesnippets.joyent.com/posts/show/2221

But I couldn’t just leave it at that. I wanted to show a different approach to solving the same problem.

How can we make a control ‘read only’ through binding?

The solution can be found here on my Git Hub Repository : http://github.com/RookieOne/WpfTogglingReadOnly/tree/master

Ignoring all the other machinations, the money xaml is in the TextBoxStyle found in the Styles\TextBoxStyles.xaml resource dictionary.

<Style x:Key="TextBoxStyle" TargetType="TextBox">        

    <Style.Triggers>

        <DataTrigger Binding="{Binding IsReadOnly}" Value="True">

            <!-- Readonly Template -->

            <Setter Property="Template">

                <Setter.Value>

                    <ControlTemplate TargetType="TextBox">

                        <TextBlock Text="{TemplateBinding Text}" />

                    </ControlTemplate>

                </Setter.Value>

            </Setter>

        </DataTrigger>

    </Style.Triggers>

</Style>

As you can see I use the IsReadOnly property on the base view model as a data trigger and then completely swap out the control template for the text box. This allows for complete customization of the read only look. It also pushes this functionality out into a style to be reused through the entire application.

Other things to note with the project (for those unfamiliar with the following practices):

1. Data Templates as Views

<DataTemplate DataType="{x:Type PersonView:PersonViewModel}">

So whenever WPF tries to resolve the PersonViewModel in a container, it will use this DataTemplate since I did not provide a key but only a DataType.

So in Window1 I can do…

<ContentControl>

    <PersonView:PersonViewModel />

</ContentControl>

2. Expression for INotifyPropertyChanged

I am also using a LambdaExpression to implement INotifyPropertyChanged. Essentially achieving safe notification and eliminating those nasty magic strings.

public string FirstName

{

    get { return _firstName; }

    set

    {

        _firstName = value;

        OnPropertyChanged(this, m => m.FirstName);

    }

}

Anyway.. that was a quick project I threw together. I hope it was helpful.