THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Andy Leonard

Andy Leonard is an author and engineer who enjoys building and automating data integration solutions. Andy is co-host of the Data Driven podcast. Andy is no longer updating this blog. His current blog is


This blog has moved! You can find this content at the following new location:

Published Monday, August 9, 2010 8:00 AM by andyleonard

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Chuck Rummel said:

Your analogy brings up a few questions.  Speaking from a control systems view, what, if anything for these examples could/would be an influence to make it a more critically damped system, to smooth out the oscillations earlier?  Second, does this assume no other outside forces are acting over the duration?  I could see things settling down when an outside force applies an impulse which causes higher oscillations again.  Third, as an extension of the second and as a worst case scenario, what situations would cause this pattern to reach its resonant frequency where oscillations would get worse over time instead of better?

August 11, 2010 12:53 AM

andyleonard said:

Hi Chuck,

  These are outstanding questions. As someone with controls knowledge, you realize one solution is to introduce Proportional/Integral/Derivative (PID) feedback. Finding (proper) analogues with managing software teams is the challenge before me now. I have some, but I am taking time to work through some good examples (test-driven blogging?) before I write more.

  If you have thoughts on the topic, please share.

:{> Andy

August 11, 2010 1:26 AM

Chuck Rummel said:

Ok, I'll give it a shot.  I asked the questions because I could see this idea turn into its own full post, or just rat-hole off on its own tangent.  I'm not sure how well thought out my ideas are, so here's a rough sketch of what was starting to go through my head.  Plus, it's been a while since I've really had to think about control systems, I could hear the rust falling off the grey matter.

First, there will always be some measure of oscillation and volatility due to current iterative dev approaches (agile, scrum, xp, etc.), and the fact that we're human, we have good days and bad, and there are always those things which are completely out of our control no matter how much we wish it were otherwise.

So to abbreviate my previous questions, I'll label each as follows and consider them for each of your headings.

q1: critical dampening?

q2: external impulses?

q3: resonance?

Code churn:

q1: I think you achieve dampening through an experienced team familiar with problem domain and tool set. You know what the problem is, you have enough experience and/or forethought to mock out a good framework, then go out and build it.

q2: An example would be new directives mid-stream, such as "ok, but now make it do this other thing instead" which wasn't in the original plan and requires going back to the original architecture.  Things might have been settling down before but now you have to adapt to the new input.

q3: An example of resonant code churn would be loss of project direction, or a spray and pray dev model, or teams building pieces in isolation that when integrated blow up and you have to go back to the drawing board, or projects initiated to build a tool to do x but then it morphs into something else and each time it goes through another iteration it has to do something else, where code reusability basically goes out the window.

Bug rates and severity:

q1: Probably the same answer as q1 under code churn.  I suspect there's a strong correlation between code churn and bug rates, but maybe not.

q2: An impulse to cause a jump in bugs here could be new tech, like adopting cloud or new languages.  Or maybe someone runs a new security tool against it and finds a new set of vulnerabilities you have to address.

q3: Resonance could if people start introducing more problems than they fix.

Developer enthusiasm:

q1: As I said above, people are variable, and similar to answer for the other headings.  The goal would be to increase enthusiasm yet still have the "been there done that" mindset to prevent the highs or lows.

q2: Impulses on enthusiasm could be + or -, + if there's new found support from upper mgt, - if beta users blast it, or mgt suddenly says it needs to launch next week when there's two months' work left.

q3: Resonant enthusiasm, that sounds like manic depression or something.  Or perhaps an unstable environment, perhaps due to recent layoffs, etc.

So there you have it, for better or worse.  I see a bit of recurring patterns and variation on a theme, which I guess could all be neatly summed by the idea of adaptability.

August 12, 2010 12:04 AM

Leave a Comment


This Blog



My Latest Book:

Community Awards

Friend of Red Gate

Contact Me


Privacy Statement