ISWIX, LLC View Christopher Painter's profile on LinkedIn profile for Christopher Painter at Stack Overflow, Q&A for professional and enthusiast programmers

Monday, February 14, 2011

Software Entropy

Recently, someone suggested to me ( putting it mildly ) that our build automation should ignore failed unit tests in order to get further down the process.  I instinctively bristled at this notion.   Later I decided to google the subject to see if anyone else in the world was actually entertaining such non-sense.  There was an answer on StackOverflow that referenced a story from the Pragmatic Programmer called Software Entropy.  It's an interesting story about the effects of Broken Windows on a building and what it means for software rot. (See Active Rot )

There's a few expressions I like to use:    (Fair warning, these are cynical and/or sarcastic)
  • Entropy is a bitch
  • Once is an exception, twice is a pattern
  • Death but a thousand cuts
  • What's the problem with a little poo in the installer.
  • Garbage In, Garbage Out
  • Fix the installer and not the application.  That's a great idea.
The point of this is it's really hard to maintain high quality installers when forces are constantly acting to bring chaos.   This is why I bristle at comments made about how Agile Installation means everyone can contribute and you don't need specialists.   I've seen developers contribute to installs... contribute chaos.   This is what happens when you bring people to the table who don't understand MSI.    They understand things like Regsvr32, Regasm, SC.EXE, InstallUtil and OSQL.exe and then try to wedge them into the installer.  

Every one of those things is a broken window and frankly, I don't allow broken windows.   Unfortunately, that doesn't always make me a very popular person because developers are often quite self-convinced that their solution is acceptable. 

So back to my initial comment about unit tests failing builds.  For installs this is Windows Installer validation and I suggest custom ICE's to enforce quality standards.   I suggest writing tests that enforce  your coding standards.   Don't allow selfReg?  Write an ICE that checks the SelfReg table.   Don't allow InstallUtil CA's?  Write an ICE that scans for those.  Allow only sanctioned DTF custom actions?   Write a unit test that reads in a white list file and make sure only those custom actions exist.

Enforcing standards through automation is the best way to fight entropy that I know.


  1. Chris, I largely agree with your post here, but i'm interested in one of the items you specifically call out - osql. We use SQLCMD, which is by and large the same.

    I understand the rationale for the rest - don't implement something as a CA which is going to require its own unique transactional behavior when MSI can do that for you.

    But sadly, MSI doesn't provide you with anything for SQL - we've found it to be an entirely roll-our-own process. Granted, I can use a managed CA instead of SQLCMD, but I perceive that as shades of grey on the same ultimate problem. If there's something large we're missing out on, enlighten the masses, please! :)

  2. I don't know what tools you use or what database engine you are connecting to so I'll just say in our environment we use InstallShield to handle our SQL Script processing. Basically they are well tested data driven custom actions written in unmanaged code and support MSSQL, Oracle and MySQL. WiX provides a similiar concept except that they only upport MSSQL.

    With InstallShield the IDE exposes the concepts of SQL Connection/Requirements, SQL Script and SQL Text Replace. This maps to 7 custom tables that allow you to describe the SQL story for the installer.

    I call these types of patterns 'quasi-standard actions' as the infrastructure is developed and maintained to high standards by someone else. I only have to focus on the details related to the setup I'm working on.

    So basically I would change your rule to include things that your tools can do for you not just what MSI can do for you.

  3. I also largely agree with what you said IF everything "further down the process" is dependent on what has been built "upstream" in the build process - and that may be the actual scope of your build process.

    Where I'm at now, the install build is separate from the core product source code builds. It contains both Windows Installer packaging builds, the generation of Linux RPM and tarballs, as well as the creation of ISO and download files. Our build engineers don't want me stopping the entire build because an MSI package doesn't build properly. They want the entire build to run to completion and then report all build failures so that the MSI, Linux, and media portions of the build are always run. Basically, they don't want an MSI break to stop the build process and potentially hide the fact that there's also a problem with either the Linux or media portions of the build that wouldn't be found otherwise because an "upsteam" part of the build stopped the overall build process.

  4. Chris, thanks. We use SQL 2008 and InstallShield, but we actively stay away from anything proprietary, to the point that we'd rather roll our own that find out we have vendor lockin - at least, beyond MSFT.

  5. I guess I'm a little confused by the proprietary comment and the fact that you use InstallShield to build the install. It seems like you are saying we'd rather not have functionality that we paid for because one day we might want to use something else so instead we'll just go write our own and pay for it twice.

    Eitherway The WiX SQL stuff is ultimatly just some custom actions and custom tables so it's really easy to 'borrow' it and use it inside InstallShield. It's FOSS so shouldn't be any concerns there.

  6. My thought against using the InstallShield CA's for database tasks is that it creates a new system (and point of failure) that not everyone understands.

    My preference is to use the same tool that developers/technical support/etc. are using to build the databases so we're all able to troubleshoot any issue.

    We built a custom, relatively easy-to-use tool in managed code that I call in a managed CA, but if the process is a batch script that calls SQLCMD I would use that in 'black box' form to avoid having InstallShield have its tentacles in yet another area.

  7. Well, you do have a pattern so that's good. Now imagine someone coming up with a competing pattern and then injecting it into the MSI. How would you feel about that? :-) That's kind of the real point of this post.

  8. Chris, what I mean by proprietary is that we use installshield primarily as a way of manipulating the MSI. Should we choose to go to Wise or even WIX, we could do so without the baggage of having to find a replacement for any vendor's IP (again, other than MS). What one sees as paying for twice, another sees as insurance. :)