Developing Dane

Update 10/2016 - This posting is better viewed in my new blog . I came across something that grabbed my attention the other day.  I was working with a Silverlight application and had bound TextBox controls to two separate decimal properties of a ViewModel class.  I was using the default formatting for display and was quite perplexed when I found that even though both properties had the same value, i.e. 100, one TextBox displayed 100.00 and the other 100.0000.  After doing a little digging I found that the root cause of this behavior is that decimal types in .NET carry not only a value but that value's precision as well (apparently since .NET 1.1).  To see this in action take this case: decimal d1 = 100; decimal d2 = 100.00M; Console.WriteLine( "d1: {0}, d2: {1}, Equal={2}" , d1, d2, d1 == d2); The result will be the output "d1: 100, d2: 100.00, Equal=true" which is to say that the two variables have equal values but different precisions and thus the T

EOM Update 10/2016 - This posting is better viewed in my new blog .

Update 10/2016 - This posting is better viewed in my new blog . I've been playing around with xaml technologies for several  years now and it's given me the utmost respect for truly good UI designers. In the era up to and including Win Forms I'd always thought of myself as a competent UI designer but xaml has change all that.  Quite simply there are so many options available in xaml UI design that I've realized I just don't have the aesthetic sensibility to create top tier UI any longer.  My hat goes of to the many many designers that do.

Update 10/2016 - This posting is better viewed in my new blog . When I first started developing software professionally I remember occasionally finding older code and thinking "how could someone design something so poorly?" I've been writing software for the same company now for more than a decade.  A few years back I first came across a piece of code I'd personally written years before and realized that someone looking at that code right then would probably think the same thing.  I knew the code in question was not badly designed.  At the time of its writing it was well thought out and fully met all requirements.  The "problems" arose over the following years as the landscape in which that code lived changed dramatically.  In those years the company grew several times larger, the application increased in complexity by orders of magnitude, multiple new technologies had to be integrated and industry trends and requirements changed continually. At tha