Veterans’ Day

Every year I like to thank those Veterans close to my family and me:

Retired:

• Roland F. Chapman (Grandfather -b1910-d1987 - Navy)
• Robert D. Boss (Dad - Navy)
• Michael J. Boss-Hill (Brother – Air Force)
• Stephan J. Hill (Step Dad – Navy)
• Fredrick R. Chapman (Uncle – Army)
• Mark Hanson (Uncle – Navy)
• David Bishop (Navy)
• Charles W. Hobbs (Navy)
• Dawn Meiers (Navy)
• Chuck Norris (Navy)
• Arthur Pignataro (b1944-d2011 - Army)
• Dodd Schock (Navy)
• Ronald Steele (Navy)
• Rick Kolde (Navy)

Active Duty:

• Kevin P. Boss-Hill (Brother – Marines)

There are many more in all of our lives.  Thanks to you all.

Till next time…

Software Environments: Separation and Configuration is Key

I just left a meeting with several folks from the server group, the web services group, and my applications group.  The discussion was around environments and promotion of software through these environments. Let me tell you, there are some very different ideas out there regarding this process.

I thought I would let you know how I prefer to make this work so that there is the best opportunity for a successful installation. Now these concepts are not specific to internal software development where the customer is part of the same organization as the group developing the software. These concepts are the same for shrink wrap or cloud based software.  I have worked with all of these types of software development projects and have been successful utilizing these concepts.

The first, and arguably one of the hardest to implement, is the concept of a separation of environments. The separation of environments from step to step should encompass all pieces of a software system wherever possible. This means that each environment should have, where applicable, a web services server, an application server, a database instance (server if possible) to name a few. 

At a minimum a team should have three such environments; a development environment, a test environment, and a production environment. Each containing a distinct and atomic system that requires gates to be passed in order to achieve entry.

These gates should include automated unit tests and code analysis. The code deployed in each environment should have been proven in the previous environment. The automated code that does the actual deployment to each environment should be exactly the same in each environment so you are always executing the same thing from environment to environment and not creating unnecessary variables.  This allows you to have the experience of many deployments prior to the one crucial deployment to production, thus mitigating and alleviating most risks of deployment.

One of the single most important aspects of achieving separation of environments is Configuration Management. Configuration Management is the management of all pieces of a software product’s lifecycle from initial coding through deployment. Configuration Management as a discipline in software development is getting more and more respect these days, for which I am very happy. This is a very challenging aspect to any software development project.  A properly maintained and automated configuration management system is a must for any organization that puts any product into production ands wants to do it as efficiently as possible.

It is the details of each system where a configuration management engineer earns his money. Each will be different based on the product, but the concepts are the same.  One of my favorite books Software Configuration Management Patterns deals with some of these concepts and how source control management is an integral part of the process.

No matter what system you are working on, try to keep your environments separated and remember: automate, automate, automate.

Till next time…

Technorati Tags: Configuration Management,SCM,release planning

ASP.Net – Code Behind and the Times

In 2001 Microsoft gave us ASP.Net.  The successor to what we now call “Classic ASP”. This brought the full power of the Visual Studio IDE to web development. Allowing us to write “Code Behind” in our favorite language, either Visual Basic or C#, for WebForms development inside Visual Studio.

This was a significant improvement to Classic ASP and to the developers ability to quickly produce web applications based on Microsoft Technology.  Up till then we had to use Visual Interdev. And was that a mess or what?

While I was an engineer at FM Global back in 2001, I was on the team that adopted .Net while it was still in beta.  (I know, pretty progressive for an insurance company, huh.) We had Microsoft consultants on site what seemed to be 24/7. We were learning a completely new way to code in a completely new IDE. Visual Studio .Net was simply amazing to all of us.  We were all Visual Basic developers then and being able to code using VB in this new environment was fantastic.

A couple of years later we were building an extranet application for our clients to be able to access their insurance information on the web.  We had been programming in .Net for a while but we were still VB programmers.  We were writing procedural code in an Object Oriented world.  There were some Code Behind methods that were several hundred lines of code long and full of spaghetti.

This is when we started learning about how VB can be a fully object oriented language and about utilizing Agile development techniques to help with the quality of our code.  It all started to come together. Our designs improved because we started to design our code to be testable. Our time to build and release methods were being revamped so we could be more efficient.  We were using code generation tools. It was a time of great learning.  We made our share of mistakes but all-in-all it was good.

Why do I reflect on such times?  I was reminded about these times because I am currently working with a group that is in a very similar situation.  Folks who are mostly COBOL programmers learning ASP.Net for the first time or are early in their object oriented programming learning and none of them have any Agile exposure at all.  I am sharing my experiences with them to help them grasp some of these concepts.

While doing a code review, one finds an asp button with an OnClick event that has 300+ lines of code in it, one is reminded of these times.  I am coaching my team in the craftsmanship of Agile Software Development, Object Oriented Programming and ASP.Net. So it behooves me to try to remember where I was and remind myself that there was a time when I wrote 300+ lines of code in a single method.  Well, maybe not that much but still…

Till next time…

Technorati Tags: Visual Studio,Agile,Object Oriend Programming,Microsoft,ASP.Net

When you can’t get where you want to be.

Many times in my life I have wanted to be somewhere in my career or in my family life that may have been just out of reach. It is during those times that I have had a significant amount of growth and have met some of the long lasting fiends in my life.

Back in 1995 when I was a theater electrician working in the Fox Theater at Foxwoods Resort and Casino, I knew I wanted to be a computer programmer. Don’t get me wrong, I loved working in the theater. In fact, I continue to work in the theater till this day. But what I wanted was just out of reach. I had no formal computer training and I couldn’t stop working to get it.  This is a situation a lot of folks are in today, I’m sure.

So I was fortunate enough to hook up with someone else in the theater department who was doing a little computer work. He and I became fast friends and still are very good friends to this day.  (His wife and kid came up from Florida to visit us last spring and we truly enjoy each others company.) Pete and I did little things in the theater department with computers to help our bosses.  He started a daily log for the technicians and I started a scheduling program for the lighting group.  We were learning more and more as we went along. We stretched ourselves because we new where we wanted to be.

Our bosses started to notice, and fortunately for us, they were progressive enough at the time to see where this could lead the theater department.  Soon, Pete and I had our own office with the best computers you could buy in 1996 and a copy of Visual Basic version 3 or 4. We went to a couple of training courses and the next thing you know we are, well sort of, real programmers. 

This paid off for both of us when Foxwoods decided to centralize all the folks working in IT. Pete and I went on to work in MIS. We are both now far into our IT careers and I am very thankful to him, Bill and Brian for helping me get to where I wanted to be.

So the point I am trying to make here is that sometimes when you cant get to where you want to be, maybe the best place you should be is where you are.  Look around you. Take in what is happening.  See where you might be able to utilize a skill or technology that will help promote you to where you want to be. And notice the people around you.  Who has influence? Who can you help that may be in a position to help you out someday.

In my case, at the moment, patience is my greatest ally. Where I want to be may take some time. And some of the folks I am meeting on my journey are absolutely the best. So, Jane, JD, Marc, (to name a few) I thank you!

Till next time…

Estimation: why can’t we get it?

In software development shops across the world there is absolutely nothing more frightening to software developers than estimating a task. The fear stems from the unknown. The phrase “I don’t know what I don’t know” comes to mind.

The pressure of giving an estimate for a task in terms of amount of effort can be very heavy. Somehow telling someone how long it will take to get this task “done” has turned into a self defense mechanism. So-much-so that sometimes engineers “pad” their estimate to almost twice what they believe it will actually take.

And then, the project managers get ahold of the estimate and they pad another 50%. This brings the estimate to 3 times what the engineer actually thought the task was going to take. And you know what happens? It takes that long or longer, but rarely does it take shorter.

Why? Why do we always end up taking longer than we originally thought? In my experience there are a few reasons for this phenomena. Each of which has played out in development shops that I have been a part of.

The first is the self-fulfilling prophesy syndrome. This is when a developer fills the estimation time because he has the time to fill.  In this scenario, if you give an engineer 8 hours to do the work, he will take 8 hours to do the work. In my estimation this is the worst kind of situation a development shop can be in. Because this is a good indication that your engineers are bored and do not have a vested interest in the shipping of the product.

A second reason estimations are off the mark is because engineers don’t learn from what they have previously estimated. Even green engineers right out of college have some experience estimating. They do it every day of there live in college. How long will it take to get this homework done so I can head out with the guys and play Gears of War? When an engineer is able to take into consideration previous work/estimate relationships and contrast with the complexity of his current task, that engineer is already more accurate.

Another reason is because the task is to great to estimate accurately.  This is the one thing I see more often than anything else.  An engineer has not taken the time to break down the task into manageable chunks. I like to pose this question to my team: Which estimate is going to be more accurate? 1. How long will it take to drive from downtown Raleigh to downtown Durham given moderate traffic conditions? or 2. How long will it take to drive from downtown Raleigh to Times Square in New York City? Of course we all know the answer. Because when we estimate small chunks we are more accurate.

There are more reasons than these but these make up a great percent assuming it is the engineer giving the estimate.  If it is not then there is a bigger issue that needs to be addressed in the organization.  So when an engineer thinks a task is going to take 4 hours he should estimate 4 hours and not pad anything.  He should then take into account how long it did take and what happened during that time. He should use this knowledge the next time he needs to give an estimate. He should also learn to be breaking down his tasks into realistic estimate-able chunks. Some say if it takes longer than a day then it is more than one task. I am not going to be that stringent but I think that is a good target.

Estimating is a skill that gets better with practice.  In the Agile development world we give estimates every iteration and every day. It is the only way to get better.  Keep at it and don’t get discouraged.

Till next time…

Technorati Tags: Estimation,Agile