Why Fundamentals are Important to Microsoft’s Bottom-line

Justice Gray recently blogged about his concern of lack of SOLID coverage at TechDays despite how Joey Devilla blogged about SOLID principles (and then went on to say that “Maaaaaaaaaaaaaaaaaaaaaaaaaaybe” SOLID would be covered in the TechDays Canada tracks this year).  Joey Devilla retorted with an open letter.


Justice’s concerns are well founded; TechDays is a “showcase current Microsoft tools and technologies” and that’s primarily what it does.  Most sessions cover how to use Microsoft tools and technologies.  But, most sessions don’t do it in a way that exemplifies what many consider fundamentals.  Most sessions cover using Microsoft technologies procedurally.


What is really missing from TechDays sessions is how to use these technologies beyond the syntax and beyond procedurally and how to use them and how to design and architecture the rest of your application or system with generally accepted fundamentals.


So, why?  Why shouldn’t Microsoft simply sell its wares?


Attendees to TechDays aren’t writing software that simply uses a single Microsoft technology, they’re writing systems and applications where that technology may be but a single part of the entire system.  That system also needs to be based on generally accepted design and architecture principles and newcomers to a technology also need to know how to integrate that into systems such as this.  Coming away from a “demo” session where none of the demo code is useable in a software shop that *does* follow SOLID doesn’t add much value to the attendee.


A community who knows only how to use a technology based on demo code doesn’t produce robust and easy to maintain software.  Worse case, this leads to a community known for poorly written, low-quality, hard-to-maintain, slow-to-market software.  This drives people away from the technology into the arms of other technologies.  I’m sure many people can think of at least one Microsoft-based technology not well viewed by the industry.


A community that takes a leadership role in producing quality software inadvertently sells the technology it uses.  It’s easier for new people to join the community and get productive sooner.  This has a snowball effect as the community grows.  This is nothing but positive to the bottom-line.


Microsoft-technology-based communities already have a reputation for cowboy coding and lack of good fundamentals.


What TechDays needs more of is how to properly use Microsoft platforms like Visual Basic and C# and how to integrate other technologies into those platforms using generally accepted fundamentals.  Simply knowing the syntax of a technology doesn’t mean you know how to integrated into the rest of your system.


kick it on DotNetKicks.com

Thread.Sleep is a sign of a poorly-designed program, redux

My post on Thread.Sleep was a slight generalization.  I say that Thread.Sleep is a sign of a poorly design program because *usually* when Thread.Sleep is used it used for timing and not used for what it’s can safely be used for.


Using Thread.Sleep with a timeout other than 1 usually means the developer doesn’t understand what Thread.Sleep does.  A value other than one means the system might pause the thread for that number of milliseconds.  In reality it might be less than the requested milliseconds and in all likelihood it will be more–potentially much more.


I won’t get back into the consequences of using Thread.Sleep.  I’ll just touch on one way (which I think is the only way) to use Thread.Sleep correctly.


Thread.Sleep accepts one parameter, the recommended minimum milliseconds to relinquish control of the CPU.  That value has three special values: 0, 1, -1.  -1 (or Timeout.Infinite). in typical Windows form, means infinite and can only be awoken by aborting the thread.  0 means relinquish control of the rest of the time slice to another waiting thread of equal priority and go into a ready state–potentially returning immediately if no other threads are waiting.  A value between 0 and infinite means relinquish control of the CPU for a recommended minimum milliseconds and return the thread to a ready state after that amount of time.


Since the value given to Thread.Sleep is a recommendation and that the actual period depends on the CPU’s clock resolution and the granularity of the Windows scheduler, Thread.Sleep can’t be used for reliable timing.


One useful thing you can get out of Thread.Sleep is to pass it a value of 1.  This has the same effect of Thread.Sleep(0) but allows *any* waiting thread to get CPU time.  This is a nice way for an application to “play nice” with the rest of the system, essentially saying “if anyone needs the CPU, I don’t need it right now; help yourself”.  In applications that need to loop-test for things, this is a good way to avoid having them consume 100% of the CPU.  But, there’s often a better design to loop-testing.


1 really means the rest of the time slice because of the granularity of the scheduler; but I like the convention of “1” to make it distinct.


A recap of the advice I’ve given since “Thread.Sleep is a sign of a poorly designed program”:


  • For scheduled logic, use a timer–don’t use Thread.Sleep()
  • For accurate delays, schedule them; don’t use Thread.Sleep()
  • For the most accurate timing, use the native multimedia timers; don’t use Thread.Sleep()
  • And to clarify: Thread.Sleep(x) is a sign of a poorly designed program where x != 1.