April 2008 Archives

Types of Code Story (Waterfall):

Back in the day, when I was at Raytheon I was involved with writing a number of proposals for a variety of things.  Sometimes the work was interesting other times it was real boring.  One part that was interesting were the line of code estimates.  For a paragraph of text that describe a particular function, you would have to come up with a line of code estimate for it along with the percentage breakdown based on type.  Then the financial folks would take that number and determine a cost.  Sometimes the estimate would give us a win, others times not so much as my friend Mark Miller would say.

The types of code that we would use had three categories: hard, medium and easy.  The productivity of each one was 10 LOC/day, 13 LOC/day and 15 LOC/day respectively.  So you are probably wondering what the heck?  A person is only going to develop 10 lines of code in a single day if the code was deemed hard.  Well, in a word yes.  Those numbers included more than just writing 10 lines of code.  It included all of the up-front design, reviews, coding and testing.  So in the end you were getting fully tested code.  Back then we were a waterfall shop and now from what I hear things have more on into other methodologies.  Here are some examples of each of the types of code:

• Hard - device driver development.  Yes, back then we did that since we built and engineered our own hardware.
• Medium - interface development.  Writing X11 programs at the time was not very easy.
• Easy - simple utilities.

WebMail (Agile):
Now in present day, we are doing some great strides with Agile techniques for WebMail.  Our development cycles are typically 2-3 weeks.  Within that time, the planned features are discussed, code is developed and full regression testing is performed.  I am very pleased with the product that our team has put together.  On May 12th, we will be doing another launch of WebMail.  This one which has been in beta since Spring Break, will enable us to turn off WebMail2.  The new version of WebMail will have all of the existing functionality of WebMail2 and loads more.

My final story (SCRUM):
And finally my story, one of the tenants of the Agile project management process known as SCRUM has to do a lot with how the team functions and communicates.  We (Applied Information Technologies, Emerging Technologies and others) participated in a SCRUM effort a while ago and probably none of us knew it.  The task was to take Shibboleth, and use that as the basis of authenticating with Napster.  Shibboleth enabled our Penn State students to authenticate at Web site and have only that they were a student passed onto Napster.  Napster never knew who the student was, just that they were a student. There are many parts of shib and I really do not want to go into them this morning.  Back to the SCRUM portion of the post, we (AIT) never worked with Shibboleth, heck for the longest time, I could not even spell it.  ET had a pilot already going, but now we had to ramp up for large scale production and we had less than 30 days to do it.  There were so many unknowns with performance, like how many machines do you need?  At the time, Kevin Morooney was the Sr. Director for ASET, he of course realized how important the project was, like all of us did.  However he did something novel which is part of SCRUM.  We would meet for 10-20 minutes every morning go over the day's objectives and previous day's results.  Then at the end of the day we would meet again to see how we did and plan the next day's objectives.  Let me tell you, this method worked out great.  How often do you find yourself in a situation where you have a major effort going on and you are only meeting weekly, bi-monthly or even worse monthly?  If the effort is critical, you need to take a page out of SCRUM's play book and do the daily meetings.  It worked out great for us.  After all of the planning and testing we did, when it came time for that first student to log in, we were watching the machines and things worked.

So there you have it, the past, present and the future all wrapped up in three little stories.   

What a title?  RISK (even in uppercase), pretty scary isn't it?  I did a quick google for some definitions and I really like this one:

Risk: The uncertainty of an event occurring that could have an impact on the achievement of objectives. Risk is measured in terms of consequences and likelihood.

By the way, I am not talking about the game of Risk, which was the first hit from google.  No, folks I talking about risk with regards to a project.  All items of risk should be taken into account during all phases of a project.  In addition, the affects of risk should be accounted for in the overall schedule.  Here are a couple of examples of risk that can affect a project:

• Dealing with an vendor that delivers hardware that is either missing or not functioning.
• What do you do if you technical lead or other key player decides to resign or worse becomes ill (the hit by a bus scenario).

And you can look on-line to find many more examples of risk.  When I was working at Raytheon all of the proposals that we wrote had a special section in them to list the risks associated with the project.  For each risk we also had to list how we would mitigate the risk.  This of course affected our bottom line, and being a profit driven organization it was all about making money.

So what do you do about risk?  Well first off, you need to acknowledge that it exists.  You would be a fool not to.  Look at the all of the external forces that can affect your project.  Each force represents a risk, whether its a hardware vendor or the company doing your copies.  You need to acknowledge the risk and come up for a plan to mitigate said risk.  The same thing applies for internal forces too.  Risk exist there too, things like staffing and commitment all affect the overall project plan.  Risks, like everything associated with a project needs to be constantly evaluated, because at different stages of the project the level of risk could change.  Early on in the project, the technical lead leaving would have less risk than later during the overall development. 

I used to be accused of padding estimates when I gave them.  Why?  Well I knew some of the risks, and wanted to take them into account.  Reality is these days, I still do that.  Because worrying about risk and its affects, brings me to my final point.  Be Realistic!  Do not kid yourself that things will go perfectly, they never do.  However by acknowledging risk and its associated affects can make things easier when things just do not go right...

Communications can probably be best described as a tower of babel.  People are there and they hear you speaking, but what the understand and hear is completely different from the person sitting next to them.  Today's posting is going to be about communications as you have already guessed, not about some fancy software technology.  Communication in general is an integral part of any process including a software one.  So it is very relevant to the theme of my blog.

So how do we effectively communicate a new process to a group?  Let's look at a way not to do it first and then some suggestions how to effectively communicate.  As many of you know, one of my duties is being responsible for the architecture, programming and care of Penn State's LDAP servers.  I have been doing this for a number of years now.  Because of that, I am involved with a number of committees and I have to attend meetings about LDAP.  So its been probably three years now, I was called into a project meeting to discuss LDAP.  The meeting was supposed to be about how LDAP could be utilized for role-based authorization (another area of keen interest to me).  So of course I had many answers and comments.  People were asking questions and I gave them answers in painful detail to include how the protocol worked.  There were times I was having sidebar chats with my boss about how we need to do things in the future.  All of these things and many others did not nothing to facilitate effective communication.  In most cases, I probably alienated the audience.  Why?  Because my communications with them were flawed in many ways.  Trust me, it took a great course called ITLP to help me understand that.

Now for the suggestions on how to do better effective communications:

1. Its all about the message.  You need to frame your message so that the audience can understand it all levels and that they have the proper take-aways.  This is a easy one if you have an idea of who your audience is, but what about if you do not.  Well you start out simple and see where the discussion leads.  Remember you are there to help them solve a problem, always keep that in the back of your mind.
2. Keep the presentations so that only one person presents.  I know that tag-teaming presentations is a great concept, but in most avenues its confusing to the user.  You need a consistent presentation that flows from topic to topic.  Taking time for a new speaker to set up, causes the audiences attention to wander.  Do not believe me, just watch them.
3. Make sure you have a focused agenda for your presentation, and stick to said agenda.  The worse thing you can do is just wing it.  If you know something that your solution that is problematic or will not work, do not take vital time away from your presentation to sit there and debate solutions with your team.  Take the discussion off-line.
4. After you make a presentation to a group, try to follow it up with an email that re-enforces your important points that you just presented.
5. Take aways - In the world we will in, being Green is in.  I know that killing trees is a bad idea.  However in situations like this, giving the audience something they can take back to their office will not only re-enforce the presentation, but hopefully serve as a constant reminder of what happened.
6. When you are giving presentations and communicating with users keep the presentation portions short.  You do not want to dump extra detail on them that they really do not need.  Of course be ready to answer their questions if they have them.  But, make sure you keep those answers short.  Communicate to them a solution to their problem, but be light on the details.

There are many other great resources on-line about how to do effective communications.  I have a number of them bookmarked on my del.icio.us (keyword leadership).

For the longest time now, we have been doing code reviews the old fashioned way.  We would print out the code and two people would sit and review the code line-by-line.  Our notes were either attached to the code or written out and given to the developer beforehand.  This is was pretty much what we did when I was back at Raytheon, except we had more people involved. 

This morning, I came across a really good tool to help facilitate code reviews.  It is called Codestriker.  It is written in Perl and uses MySQL as a back end.  I put a version up on one of my Linux boxes and created a database on the MySQL cluster we have.  The tool is really feature-rich, in that it can work with CVS, SVN and other source code repositories.  I have at least three projects in the queue to review, and most of them are new.  So this morning, I uploaded the code to the tool.  Then I was able to review the code line-by-line.  To add a comment, all I needed to do was click on the line number.  Then when I review the code again, all of the lines that are in "red" have comments associated with them.  The benefits of this tool are:

1. You now have a history of all of the code reviews for a particular project.
2. It enables multiple reviewers to review code at the same time.
3. Developers can log in and address the codes prior to the actual review.
4. Did I mention its open source?

So if you are in the market for a good code review tool, give the striker a try.  I did bookmark on del.icio.us a number of other tools that are commercial products.