Agile Development: The Wrong Analogy (Again)? How about this one?

Analogies are very powerful, either to mislead or to instruct.  For many years people (including me for a short while) have used the analogy of building a house—or a bridge, or a skyscraper, or anything else—to understand how to properly build software.  I recently came across another example at one of my favorite database-related web sites, SQL Server Central.  Here it is, followed by what I think is a better one:

Read the rest of this entry »

Calling Reporting Services’ CreateReport() from Powershell

The specification for CreateReport() provided by Microsoft is inaccurate, as far as I can tell.  In c# it won’t matter, but it does in Powershell, due to the oddities in how Powershell handles empty arrays.

The specification says that CreateReport() will return an empty array if there are no errors or warnings.  I believe that in SQL Server 2008 it actually returns a null.  Maybe later I’ll find a flaw in my thinking…but maybe not!

Look at this code:

Read the rest of this entry »

Powershell: nulls, empty arrays, single-element arrays

One of the biggest gotchas for people new to Powershell is the handling of null, empty arrays, and single-element arrays.  If you come from another language such as c# you’ll be shocked.  And even for an experienced Powershell writer, the behavior can lead to ugly bugs.

Other people have covered this topic before.  Here’s a good discussion by Keith Hill.  But I wanted a short reference with examples of the strange (to many people) behavior, so I’m writing this today somewhat for my own benefit.  But maybe someone else will find it useful.

Read the rest of this entry »

Localizing SQL Server Reporting Services Reports

Bret Hill recently published an article on how to localize a Reporting Services report.  This is an important article because of its completeness.  If you’ve ever tried to localize a report for a controlled, load-balanced web site, you’ve probably spent a lot of time with Mr. Google, because you have to read a bit here and a bit there to get all the pieces of information you need.

Read the rest of this entry »

My Powershell Surprise Of The Day: An Array’s -eq Operator

I’m always discovering stuff in Powershell.  I know I’m not a guru but I don’t think of myself as a novice either—and yet I keep coming across something that makes me think, “how could I have missed something so basic?”  Today it was the –eq operator for an array.

Read the rest of this entry »

Testing A New Syntax Highlighter

This is a test of a new syntax highlighting plugin that works for WordPress-hosted blogs.  I think I’m going to like it!  I’ll post here the same code as in my previous post.  In that one I couldn’t get it formatted acceptably by my previous favorite, Code Snippet so I had to try something else that I didn’t like but at least was readable.  This one seems to work much better, probably because it was specifically designed to work with WordPress.

Read the rest of this entry »’s Tip Of The Day–Avoid Use Of Set-StrictMode In Production? No Way!

I appreciate the Powershell tips from

But the Monday, 3/21/11 tip recommends avoiding the use of Set-StrictMode “latest” in production, and I think that’s bad advice.  Here’s a quote from the tip:

However, Set-StrictMode should only be used on development machines. You should never use it on production machines or in production scripts as PowerShell will not complain about non-existing properties. Have a look:

Dir $env:windir | Where-Object { $_.Length -gt 1MB }

Read the rest of this entry »

Scripting IIS7 Application Pool Configuration in Powershell

I knew that scripting the configuration of a whole environment seemed the right thing to do.  But when we were building up our testing and production environments I was new to some of the technology and we were in a hurry and…you know the rest.  I only did the easy parts.  But now we’re looking at some changes that will require a ground-up reinstall/configuration of our web and application servers.  This time around I’m going to script much more, I hope, subject to time constraints I can’t control.  Today’s topic:  IIS7 application pools.

Incidentally, for a good argument for scripting configuration, see the book I blogged about earlier, which I’m still reading.

We take most of the defaults for IIS7 app pools, overriding a few.  I plan to use Powershell code similar to this: 

   1: if (@(Get-PSSnapin | Where-Object {$_.Name -eq "WebAdministration"}).Count -eq 0)

   2: {

   3:     Add-PSSnapin WebAdministration

   4: }


   6: $cred = Get-Credential "MYDOMAIN\THEuserACCOUNTforTHEappPool"


   8: $userName = $cred.UserName

   9: $password = $cred.GetNetworkCredential().Password


  11: if (Test-Path IIS:\AppPools\MyTestAppPool)

  12: {

  13:     Remove-Item IIS:\AppPools\MyTestAppPool -Force -Recurse

  14: }


  16: $myNewPool = New-Item IIS:\AppPools\MyTestAppPool


  18: $myNewPool.processModel.userName = $userName

  19: $myNewPool.processModel.password = $password

  20: $myNewPool.processModel.identityType = "SpecificUser"

  21: $myNewPool.processModel.idleTimeout = [TimeSpan] "0.00:00:00"

  22: $myNewPool.managedRuntimeVersion = "4.0"   # or 2.0

  23: $myNewPool.recycling.periodicRestart.time = [TimeSpan] "00:00:00"


  25: $myNewPool | Set-Item


A few things to mention:

  • I have verified the correct properties in IIS Manager, and it starts fine, but nothing is using it yet.  I will update this if necessary.
  • You’ll see in the code that I’m setting the pool’s identity to a domain user.  If you do this, use the minimum possible permissions.  Consider using Application Pool Identities instead for greater security.  In fact, for the web servers (not application servers) I plan to experiment with this.  I was not familiar with it until yesterday.
  • One of the links I read seemed to indicate that using this method would leave the password in plain text in the IIS config file.  I tested it, and no, the password is encrypted as it should be.
  • Also note that I’m prompting for the credentials to use for the identity.  This keeps passwords out of the script.  In real use, the user name will vary between environments so I’ll need to pull this information from somewhere.

As is often the case I had to poke around a bit to find the information I needed.  Here are some useful links.

Have You Forgotten A Critical Attribute Of Your Development Project?


Forget about what customers want—or at least, what they say they want—for a minute.

People with software development experience will want to talk about non-functional attributes, such as performance, scalability, capacity, usability, flexibility, maintainability, etc.  They may not be familiar with Tom Gilb’s "Principles of Software Engineering Management,” a favorite book of mine (see, but they would probably agree with his statement on the importance of managing critical, non-functional attributes:


The Achilles’ Heel Principle:

Projects which fail to specify their goals clearly, and fail to exercise control over even one single critical attribute, can expect project failure to be caused by that attribute.


Software architects often struggle to convince other stakeholders that strict attention to non-functional attributes is vital to project success.  But even architects and senior developers often miss one of the critical attributes.  In fact their regard for it sometimes resembles the sales team’s regard for something as meaningless (to them) as maintainability.

The neglected nonfunctional requirement? 


Operability:  i.e., the ability to actually support the software after it has been launched.


To consider whether operability is being overlooked on your project, think about your answer some questions—there are more, but here’s a starter:

  • Are operations specialists (network and database administrators, customer support teams, any others who will be running the show when it’s in the hands of its users) involved throughout the entire development process?
  • Do they gain frequent experience with the software by deploying it into production-like environments?
  • Are you delivering functionality to customers in small increments? (Just as “big bang” doesn’t work well for customers, it’s usually a disaster for operations.)
  • Do developers need permission in the production environment to see data, logs, etc., on a regular basis (or, heaven forbid, to “fix” data or configurations)?
  • Is deployment to the production a nail-biting experience?
  • Does customer support know how to use the software?
  • If customers need training, has it been done, and using what materials?  Has the customer support team (and the development team) gotten feedback feedback from these sessions?


Like most of the other nonfunctional requirements, operability provides no "business value" to the marketing team.


Until you have actual customers, that is.

Then we find that everyone wants operability.

TFS Source Code Permissions Affect Branches


Today I solved a pesky problem with Team Foundation Server:  sometimes, some developers (but not others) could check into a branch even though all permissions had been denied.

My group does all development in the source code trunk, then branches at the end of any iteration that we intend to take up to our production environment. After early bug fix work on the branch we lock the branch down. Thereafter, developers have to ask for permission to check into the branch. This ensures that we know exactly what is being checked in, and when.  And we can decide, on a case-by-case basis, whether to allow it–no one wants a surprise going out to production.


So why could developers sometimes check into the branch even though all permissions had been denied?


As the TFS administrator (for the first time), I had beat my against this without ever getting anywhere. And recently I figured out the problem.

The key was to realize that the problem was described inaccurately.

Incorrect definition: sometimes a developer could get into a branch when I had (or thought I had) denied it.

Correct definition: that developer could ALWAYS get into a certain part of the branch, but not into other parts. Other developers might be denied in some areas but not others, too, but not the same parts as the first developer. Since all developers may sometimes work in any part of the branch the end result seemed somewhat random but that was not the case.


How does it happen?


Our source code tree is rather cluttered, and when I cut the branch intended for production, I end up actually branching several separate parts of the trunk, based on a common label, into a new, single destination root for the branch. I administer permissions to the branch at the root of the branch.

The problem: some subtrees in the trunk had explicit permissions granted to them rather than inheriting from higher up the source tree. These explicit permissions carried over into the branch, overriding the permissions I set at the root.

Very simple, once I understood it.

The solution was to keep an eye on where permissions were explicitly granted in the trunk, and remove those permissions in the branch so that all permissions get inherited from the root of the branch.  It would also be helpful to see where I can eliminate those explicit permissions and allow inheritance to do its work.

This fits the needs for my group, based on our local needs and the structure of our source code (which I inherited and do not like but am probably stuck with for a long time). It may not fit yours–but understanding that explicit permissions in a subtree of the trunk carry over into a branch may help you fix your own problems someday.