Category Archives: Software Development

Frameworks and Austrian Economics

Inception

An interesting thing happened to me a few years back while sitting in a Sprint Retrospective. A nameless developer on our team voiced some frustration with our UI Framework. Person X stated that that the UI Framework was too constraining. Since I was largely responsible for this aspect of the system I was interested in hearing the developers concerns. When pressed to describe the areas Person X felt were too limiting, it became clear that the developer was trying to work out of band and out of pattern. The developer was trying to introduce a new UI pattern not yet discussed or agreed upon by our team and users.  It was in this moment it occurred to me that while frameworks need to support the needs of the system, they should also prevent developers from introducing things that are not well understood at a whim.  This particular conversation was the seedling for my particular view of how frameworks should support applications. I call it Framework Organics.

What is the Role of a Framework

This question will likely elicit 10 different answers if you ask 10 different people. And though you did not ask here is my answer.

A framework should box developers into the understood and agreed upon patterns while allowing for the necessary changes agreed upon over time.

In greater detail a framework should provide support for concepts that are relevant to the system being developed. In stark contrast a framework absolutely should not support any random concept a developer can dream up. It should limit the ability of developers to travel to far off into the weeds. Protecting your users from cowboy coders who are spinner happy!

Along with limiting developers from introducing new concepts, a well-designed framework should be able to adapt to change over time. It should be resilient and extendable to meet any reasonable need that may arise throughout the development lifecycle. This does not mean that you need to build an over engineered goliath of a framework that supports every possible permutation possible. Because you can’t and no one I have ever met can.

Organics and Austrians

One of my favorite economists F.A. Hayek wrote an entire book called ‘The Fatal Conceit’. In this book he makes the case against socialism. Political affiliation aside his premise is worth mentioning here. Hayek believed as many Austrian Economists did/do, that it was impossible for central planners to understand that millions of interactions of the millions of people they govern. He also argued that any attempt to plan around these interactions was a form of conceit that was doomed to fail. Austrians believe that the framework of society was grown overtime in a free market sort of way. If problems came up they were addressed and solved, it was this sort organic evolution that Austrians feel allow us to strive as we do today.

Again this is not meant to be a political rant. But parallels can be drawn between concepts in software design and economics.  The Agile Method and the various approaches of iterative development it has spawned clearly harness the power of organic growth over time. Short cycles of problem/solution/repeat are much more in line with Hayek’s ideas than they are with say the Keynesian approach to planned government. In contrast the Waterfall methodology is more in line with Socialism. Waterfall is far more plan centric it’s ridged, and less adaptable to change over time. Waterfall does what it can to make sure change is as painful and costly as possible. It’s no wonder at all why that methodology is for the most part dead.

Bringing Back In

Ok so I am not an economist and I really do not want to be tagged a right wing radical because of this post. But the point here is simple, frameworks should evolve organically overtime. Yes this means constant refactoring of your core code throughout the life of a project. When new patterns are introduced, your framework will change and code sweeps will need to happen. As your product grows so will the level of support your framework provides but on an as needed basis. Keeping in mind the framework should also limit developers to the current set of patterns that are supported by the current revision of your framework.

The benefit of framework limitation should not be underestimated. By limiting concepts allowed in your systems users start to learn and understand stereotypes. As a result new screens seem familiar to them, less support questions arise, and your application is usable unlike ITunes for the PC. The benefits are not only seen by users. Developers now have a common language when designing new screens. “This fits our Master Detail pattern”; “This fits our search pattern”. And if a scenario does not seem to fit existing patterns perhaps the introduction of something new is needed. And the cycle continues in a nice organic sort of way!

 

Enjoy

Do You DoEvents?

Often times during the development of enterprise software requirements arise stating that specific operations need to be handled both synchronously and asynchronously. A perfect example of this is printing. Perhaps a user wishes to print a document and wait for confirmation of a successful print operation before moving on to the next step of their business process. Or perhaps the user wants to request a print operation for multiple documents in a fire and forget fashion. In one case we should provide some sort of user interface cue as to the status of the print operation and in the other we just fire and forget, while hoping everything works out.

Thinking Synchronously

So we have a WPF window with a Print Button we also have a label to indicate the status of the running print job.

Some XAML

<Window x:Class="WpfApplication2.Print"
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Title="Print" Height="300" Width="300">
 <Grid>
 <StackPanel>
 <Button Command="{Binding Path=PrintCommand}">Print</Button>
 <Label Content="{Binding Path=PrintStatus}"/>
 </StackPanel>
 </Grid>
</Window>

Code Behind

using System.ComponentModel;
using System.Threading;
using System.Windows;

namespace WpfApplication2
{
    /// <summary>
    /// Interaction logic for Print.xaml
    /// </summary>
    public partial class Print : Window, INotifyPropertyChanged
    {
        #region Private Data Members

        private string mPrintStatus;

        #endregion

        #region Constructor

        /// <summary>
        /// Initializes a new instance of the <see cref="Print"/> class.
        /// </summary>
        public Print()
        {
            InitializeComponent();
            DataContext = this;
            PrintCommand = new RelayCommand(PrintExecuted);
            PrintStatus = "Ready";
        }

        #endregion

        #region Private Methods

        /// <summary>
        /// Prints the specified parameter.
        /// </summary>
        /// <param name="parameter">The parameter.</param>
        private void PrintExecuted(object parameter)
        {
            PrintStatus = "Print Executed";
            //Long Running Print Operatoin
            Thread.Sleep(1000);
            PrintStatus = "Print Completed";
        }

        #endregion

        #region Public Properties

        /// <summary>
        /// Gets or sets the print status.
        /// </summary>
        /// <value>The print status.</value>
        public string PrintStatus
        {
            get
            {
                return mPrintStatus;
            }
            private set
            {
                mPrintStatus = value;

                var handler = PropertyChanged;
                if (handler != null)
                {
                    PropertyChanged(this, new PropertyChangedEventArgs("PrintStatus"));
                }
            }
        }

        /// <summary>
        /// Gets or sets the print command.
        /// </summary>
        /// <value>The print command.</value>
        public RelayCommand PrintCommand
        {
            get;
            private set;
        }

        #endregion

        #region INotifyPropertyChanged Members

        /// <summary>
        /// Occurs when a property value changes.
        /// </summary>
        public event PropertyChangedEventHandler PropertyChanged;

        #endregion
    }
}

Looking at the code here you can see that the intended behavior is as follows.

  1. User Clicks Print Button
  2. PrintCommand is executed
  3. A label used to show the print status is updated from ‘Ready’ to ‘Print Executed’
  4. The long running Thread.Sleep is called simulating a synchronous print operation
  5. Once complete the status is again changed to ‘Print Completed’

This sequence of events does actually happen, the problem however is that it all happens within the execution scope of the  PrintExecuted method. Since this method is blocking until completed the user never sees the nice status updates we provide.

Before Click

Before Click

When the window is loaded the status is set to ‘Ready’ as seen in the image on the left. Once the print button is clicked we want to change the status to ‘Print Executed’ and finally when the PrintCommand is complete to ‘Print Complete’. However since the updates to the status all happen while the UI thread is blocking, the status of ‘Print Executed’ never makes it to the user. Instead the status will transition from ‘Ready’ directly to ‘Print Completed’  upon command completion. This presents a pretty serious issue if you need to give the user meaningful feedback about what is going on. On interesting way to get around this is to use DoEvents.

Do a What?

If you came to the wonderful world of WPF DoEvents was something new to you. In fact when I first presented this problem to a colleague with a strong Win Forms background he was quick to mention this. So what is it?

Take a look

To make a long story short DoEvents allows you to interrupt current event processing in order to process waiting events in the message pumps message queue. The good/bad news depending on your view of such things, is that if you need to replicated DoEvents in WPF you can. Because  WPF and WinForms both leverage the User32 message pump. the solution ends up to be very simple Lets take a look and what our PrintExecuted method might look like.

#region Private Methods

        /// <summary>
        /// Prints the specified parameter.
        /// </summary>
        /// <param name="parameter">The parameter.</param>
        private void PrintExecuted(object parameter)
        {
            PrintStatus = "Print Executed";
            Application.Current.Dispatcher.Invoke(DispatcherPriority.Background, new ThreadStart(delegate { }));
            Thread.Sleep(1000);
            PrintStatus = "Print Completed";
        }

        #endregion

This approach give us the desired behavior of all of the status updates being presented to the user. Why this may not be a great illustration of proper use of an admitted hack. It is always good to have another tool in your toolbox.

Enjoy!

A Better Sandwich!

When considering topics for blog posts more often then not I filter out ideas based on their technical merit. I try my best to offer solutions to problems that I face everyday as a software developer in an attempt to repay the many others who’s blog postings have helped me. This post however does not fall into that category. So feel free to ignore it.

In a recent dinner with my wife and her parents. I retold a story that my wife has heard many times before. This particular time however, I managed to make some correlations to software development that had not previously occurred to me. So before I go any further let me retell the story…. Again…

In the beginning…. Wait wrong story.

When I was in high school I was dating a girl who in all accounts was much smarter then I was. However since I was a rocking guitar player and all around rebel she found my charms irresistible.

*The statement above is a complete embellishment except for the fact that she was indeed much smarter then I am*

One night while the two of us sat in my parents kitchen, I decided to take full advantage of the refrigerator filled with all of the parental subsidized food you could imagine, and make us some sandwiches. I grabbed some lunch meat, lettuce, tomatoes, mustard and all the other standard sandwich fixings available. I reached for the bread box to grab the bread, and the sandwich making commenced.

First up my sandwich (because I am selfish). I slapped down two slices of bread and started to add the fixings. On one slice went the meat, and on the other slice all of the fixings, salad, mustard, onions etc. Once all of the fixings were in place I grabbed each fully loaded slice and tried my best to marry the two without dumping the fixings all over. I managed to get the sandwich together like I had with all sandwiches before. After all I was not at all new to the art of sandwich making with free ingredients. I took a look over at my girlfriend expecting a look of awe as she basked in my artistry. Instead I got a look of utter confusion mixed in with a little disgust. She said, “Really? That is how you make a sandwich?” This was the beginning of the end for use as a couple. She then continued to tell my how much easier it would have been if I put all of the fixings on one slice of bread, and simply placed the second slice on top.

Her words flipped my world upside down. I could not believe what she was saying! It was a perfect solution. A perfect solution to a problem I never thought existed! I then proceeded to make her the most efficiently crafted sandwich I had ever made. It was a work of art that would bring the likes of Picasso to tears.

And that is the story. My story of a better sandwich! So why blog about it?

Well at that moment when my girlfriend pointed out the problems in my process I realized that had she not done so, I would have continued making sandwiches that way. Who knows how long or how many sandwiches would have fallen victim to my intellectual laziness. The reason this horrible process would have continued is because despite its short comings it did in fact work. At the end of this process I could always partake in some tasty sandwich goodness.

The point here is simple. You can go years and years doing what you do the way you always have. The results after all in this case were just fine. The same is true in software development. We can follow all of the patterns we have always followed. We use all of the best practices we have spent so long learning and mastering over and over again. And as long as we do that and nothing major changes we can turn our brains off and churn out application after application, object after object, and pattern after pattern. And all along never even considering that there may be a much better way to make a sandwich. And if we are not looking for ways to make our sandwiches better, what the hell is the point!

Enjoy!