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

Visionary and TV Commercial Genius

Steve Jobs passed Wednesday night and he left a void in technology that will not be soon matched. On the web, on twitter, on Facebook and even at Disney tributes are still being posted. He was an amazing man with an amazing story.  How did he affect me and my life?

in 1984 I watched the super bowl. I was 17 years old. I watched a commercial with a big head speaking to a zombie like crowd and a woman in red shorts with a hammer being thrown and marching men chasing after her.  It was amazing!  My seventeen year old brain wanted what ever it was advertising.  The affect was not on me alone. Millions of people wanted one too. But, alas, my family could not afford one.

I took a Fortran class in High School that spring but what I really wanted was a Macintosh. I had a Commodore 64 attached to my TV and I could make the TV change colors and play a few games but to have a Mac would have been something entirely different. I knew I wanted to work with computers and this TV ad had a lot to do with that. I went another way initially but never lost that urge. It was powerful enough to bring me back in the early 90s when I got into the technology industry. But I became a PC guy.

Fast forward many years and I found myself in many a PC v. Mac discussion. One of my good friends, Mike Pereira, and I had many of these discussions.  Me being the PC guy and him being the Mac guy. They were always friendly arguments and we had a good time touting the benefits of each.  I am sure Steve Jobs encouraged these types of discussions across the globe.  So much so that he produced the now famous PC Guy v. Mac Guy commercials.

There were many other ways that Mr. Jobs affected all of us. I will leave those to all the tributes around. I just wanted to add that I liked his commercials a lot. I know there were marketing teams involved but without the product to back it up, the commercials would never have been made.

Thanks Steve!

Till next time…

Technorati Tags: Apple,Macintosh

Retrospective: Does it help?

In the world of Agile Development there is this practice known as a Retrospective. A Retrospective is when teams get together to reflect on what happened during the iteration that just completed.  it is a time for the team to answer a few questions about their process, the result, the engineering, anything that may need to be reviewed by the team for approval or improvement.

If the team is serious about its commitment to self organize/govern then the Retrospective is crucial to the teams success. Being able to discuss openly what you may need to improve on is a great tool to improve efficiency. It has been my experience that this takes a couple of iterations before the team really can see the results of their efforts.

On the other hand, I worked with a team late last year that got it almost right away.  The QA team member was not on the same page as the other team members and that came out in the first iteration’s retrospective. suggestions were made for improvement and some strategies discussed. An action plan was implemented.
At the next iteration’s retrospective the team was openly thankful to the QA team member for his role during the iteration.  They also were all encouraged by what open communication and review can do to help the team be more efficient. It was demonstrable for them. It was tangible.

There are many ways teams implement retrospectives. I like to answer three questions:

1. What did we do well?
2. What do we need to improve on?
3. What will we actively work on and how?

I find these three questions as a starting point to move teams closer to efficiency. What are some of the ways retrospectives are utilized in your Agile team?

Till next time…

Technorati Tags: Agile,Retrospectives