Tag Archives: development

You Are Not The Most Interesting Developer in the World

Where I work, we deal with developers who were apparently dropped on their heads at a very young age.  Repeatedly.  Onto concrete.  Repeatedly.  I also work with project managers who apparently had the same thing happen to them.

The reason I point this out is because some people truly believe there is a cost savings in combining development, test and production in to one happy little world.  You know, because every developer does everything right the first time. Or at least combining development and test, because, really, those are one in the same.  I actually had a PM tell me this in the last week.  As my father used to say, “That boy is about as sharp as a sack of wet mice.”  I’ll simply add, “Bless his heart”.  Because thinking it can be all in one is the coding equivalent of “Hold my Beer”.

For the uninitiated, the development area is the place where the developers can make multiple horrendous mistakes, or develop, take you choice of phrasing.  The test area is a place where you actually make sure that whatever you have developed installs as it should and that everything should be working as it is designed to.  Production is that area that everyone actually uses and they don’t take kindly to things changing or not working as designed in the middle of an actual transaction.  If you think they do, then I’ll give them your number and you can be a customer service rep as well.  Have fun.  Some groups also include a fourth level – User acceptance testing, or UAT.  This is an environment that your test group of actual business users beat on to make sure everything works to their standards after QA, but before production. I personally fond of the four-tier layout, because It brings the business in on the final product, and anything found afterwards in on their heads, not the development team’s.

Now in this multilayer fiesta there are some points that as operations, I demand.  First, all environments  should resemble production in the fact that the server structure is the same, and you have the same basic software running in the background, because there are indeed differences between, say, .NET 3.5 and .NET 4.5.  Really, there are.  That’s why they are different numbers.  Someone at Microsoft didn’t just decide to change it because they were bored.  If your production server is running .NET 3.5, then why are you developing on something else? Do not talk to me about upgrading on the fly because of backward compatibility.  Sorry, it is something that may work 90 percent of the time, but that remaining ten percent always bites you in the ass.  Replication applies to your databases as well.  Table structures need to be the same.  Change one thing, it needs to go through the whole set and it needs to be tested.  Yes, it is a pain in the neck.  Yes, it takes time.  Why all these restrictions?  Because you are not a cowboy.  You are in IT.  You want freedom, move to Montana and raise dental floss.  But do not ask me to hold your beer.