Recently in Process Category

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.   

Hello...

Its been a while since I have had time to do a posting.  Actually, I really do not have that much time this morning, but I figured I would get something out there.  For me these days, I'm dealing with lots of projects (blogging server, FPS, Workflow, Departmental Identity, IAM, ITANA, and so on).  So lots of things are happening at work these days.  Actually in the future post, I will attempt to dissect what happened with the FPS outages.  Its a very good example of just bad a software failure can be.  But like I said, that's for a future post.

Today's topic is about a reality check.  A check with what you might ask?  Well, with development of a software application.  As of late, I get invited to a number of meetings about a variety of projects.  Most of the time, I sit in the back and just listen.  Listening is a really important skill and trust me it took a lot of time to hone that skill.  Of course going to the IT Leaders program and having a great coach really helped too.

Anyways, so I sitting in the meeting, and I hear things like:

"Well let's just scrap what we have and rewrite it"

"We can do this in 2 months right?"

 You get the idea right?  Most of these are prime examples of problems that face people in industry too.  So what do I do?  Well, I am typically, but not always the voice in the back of the room saying "Reality Check Time People!"  You cannot rewrite a complex software application with dependencies on software that either

a) does not exist

b) does not work

You just cannot do that, actually you can but your results may not be what you want them to be.  A lot of people feel that I am dinosaur when it comes to software development because of many of the ways/processes that I promote.  Maybe I am.  Coming for a structured world like the defense industry has really taught me a lot about developing software.  Yes, I know process is important and I'm not advocating that everyone do full specs for tiny web apps that a couple of people use.  However, you need to do something.  We are actually using aspects of Agile Development with WebMail.  We have been doing that for a number of months now.  How's it working out?  Pretty good actually.  We have really short development cycles and I feel we are pretty out a really good product.

So back to the topic of this entry, the reality check.  As developers, web professionals, managers, and so on, you have to ask yourself when you are in one of those meetings, just whether the tasks at hand are do-able.  Do a mental reality check of the knowns in your own mind vs. what you are hearing.  If stuff does not jive, try to express your point in a very constructive manner.  Keep in mind that maybe you do not know all of the knowns from everyone else's point.  But, hey that's good too.  That opens up another key aspect of process, communication.  People need to learn to communicate more.  So ask questions, but again doing in a manner that is constructive and helpful to the entire project.

What's next?  Well more entries when I get a chance (I hope).  There are some topics of could be touchy, that I will tackle.  One of them will be my take on a blog posting at Coding Horror a while back about making developers managers. 

For those of you who are forgetting, I entered into marriage with Sheri Vail (now Sheri Vuccolo) on May 5, 2007.  Sheri had two children, Courtney and Tyler.  Our daughter, Courtney is going to Penn Tech in Williamsport where she is a senior in an IT major.  She will have her Bachelor's next year.  Anyways, she is working on her senior project.  The aim of which is to develop an application from the ground up using everything she has learned during her past three years of schooling.  It is a very interesting activity.  The reason that I am writing about it, is she showed me a copy of a questionnaire she had to fill out before she could submit her project idea.  I found the questions to be extremely interesting, in that they really have  broad application to some of the process work that I and others are trying to do at Penn State.  So I acquired a copy of her homework questionnaire and decided to post it for comment.  I'm going to fill it out using a project I just completed, so you get an idea of how useful it can be.  So here goes:

1. State the name of your domain (for our purposes this would be our problem area). - My domain is protected web space.
   
2. What, at this moment, do you plan to do in this domain? - I plan on developing a solution for students/faculty and staff to be able to indicate certain web-content as restricted.
3. What tools are you thinking to use in your project?  Since the project is web-based, it will use our enterprise file system, Perl, HTML, JavaScript and CSS.
4. What possible problems or difficulties are you thinking about which may obstruct your smooth development of your project? - I would have to say lack of time and resources.
5. At this moment, how do you wish to handle these problems stated in #4? - Well, I plan on re-using existing designs, farming out as much as I can to other capable personnel.
6. Why did you choose your domain (problem area)? - In my case the problem area was chosen by outside forces.
7. Do you plan to work further in the project in the future? Yes/no.
8. Who and how large will be the population that will be affected with your project? - The university at large.

As you can see, Courtney's first assignment really makes you think about your project.  It asks those basic questions: Why are you doing this project?  What is the project?  How do you plan on solving this project?  When will you have things done?  Of course there are other valid questions to be asked as well.  Two key points to be remembered about all of this:

1. Ask the questions or be ready to answer them.
2. Write done your answers, preferably in a tool like a wiki.

So I imagine, I will have further updates on how this little project is coming along.  I have a couple more good posts in the works, that I will get out there as soon as possible.   

I was thinking about the team a little bit this morning and I agree 100% with Mairead's statement about having a sponsor.  That actually came up during an interview I conducted with a number of people for an IT Leadership project that I was a member of.  One person actually took things so far to state that "we need a champion".  The champion is the person out there waving the banner for the project, telling everyone why we need this project.

Depending on the type of application, you may need another person added to the dream team.  As of late, I am doing some development on a web-based application (Ugh!).  I did not say Ugh because I hated doing development, it was the web-based part that is boring.  Anyways, that aside I must remember the real purpose behind the posting.  Developing for the web these days is pretty much wide open.  However if you are going to do anything that you want to look good and potentially be compliant with standards, you really need to have a graphics designer on your team.  That member, will know how to make the interface look good and be portable within the browsers.  As for participation, the designer should have some representation at all facets of the project's life cycle.  Not only can they help with graphics, CSS, but they can also help with human factor's type issues.  Back in the day when the interfaces were character, then later X-based, there really wasn't much need for such a person, but the web has really changed how we interact with people.  You need to have someone on that team who knows the language of the web.  The reality is you do not want to waste your programmers time with learning how "to make things look pretty".  I hear that statement often in meetings.  And my standard response when I am told to do so is, "I am not a web programmer".  Programmers/engineers should be left to do what they do best, write software that solves problems, not worry about should the button be red or blue.  That's the responsibility of the graphics/human factor's person.

Let's see I am imagining that I am sitting in my office one day and my boss comes in to tell me about a new software project.  The excitement factor is pretty low right now.  Why is this?  Well I have to solve this problem with a minimal amount of staff, in some cases I have to write all of the code myself.  Anyways this time, things are different he goes on to tell me that I have unlimited resources to construct the team of my dreams to accomplish this task.  Now we're talking.  The team of my dreams.  First off, I sure hope that everyone knows what a team is.  You know those groups of people whose aim is to a common goal to solve a problem.  Those things really exist out there, trust me.  I have seen them and been members of them.  Anyways back to my ideal team, who would I have?  Well let's see if I can come up with a list:

• An Analyst - This person would be in charge of talking to the customer, determining their needs and conveying them back to the rest of the team.  The analyst would be critical in gathering the requirements for the new widget we are trying to construct.
•  A User Support Representative - Someone from the helpdesk.  This person is the who will deal with supporting this new product.  Answering the end-user questions and in a word, helping them use the new application/service.  So they need to know early on that this widget is coming.  Their participation on the team could vary based on their other duties.
• A project manager - This person is responsible for the project.  Making sure that deadlines are met and costs are under control.  The project manager (PM) would also help deal with staffing issues.
• A technical leader - What is a leader anyways (well check out my ITLP blog for more info on that).  The technical leader is responsible for all of the technical decisions regarding the project.  He/she is the one who making the assignments as it related to the project.  The technical leader can go by various names, speaking from experience.  I was called a Lead Software Engineer (LSWE) and Lead Systems Engineer (LSE) in a previous life. 
  
• One or more developers - these are people who will be writing the code for the application.  They will be responsible for design, code and unit test.  These will use a methodology to develop the software, whether its waterfall, spiral or XP.
  
• A Test Engineer - Again in our prefect world, this is the person who will be testing the software.  You do not want the developers to do this job.  Why?  Because developers are prone to test portions of their application that they know will not fail.
• Quality Assurance and Configuration Management - All important people to have on a project.
• The customer - they are part of the team too.  Why?  Because they are the ones that are footing the bill.  In the world of Extreme Programming (XP), they live with the project as it happens.  Not sure how that would work for some of the projects that we do around here.  I do not think we are going to want 80,000+ students sitting in a room with us while we code.
• Documentation Support - These fine folks take the documentation of the project and put into a form that the user can understand.  Let's face it, programmers write in who knows what language when they do documentation. 
  

So there is my list for the perfect team.  Are there other roles that are missing?  Probably yes.  Have I ever been on teams like this?  Yes.  Do these teams work?  You betcha they do.  Now comes the bigger question, with a limited staff how do you accomplish the project with the staff that you have.  Well people are going to have to share the roles, but a minimum you are going to need at least the following people:

• Customer (Without one of these, there really isn't a need for a project).
  
• Leader (Technical and Project Management Combo)
• Developer (Could assist the leader in the analyst role)
• Tester (we do not want developers to test their own code)
• Support (we still need someone to support this project.  This person could also do the documentation) 

As many of you know, I have multiple projects going on at the same time.  Some of them, I'm actively working on myself and others my employees are doing.  One of the critical activities that needs to be completed before any project is the gathering of requirements.  In the past, I would either do this exchange with the customer myself or have one of my employees do it.  The problem with this scenario is the exchange becomes very technical.  So I was recently given an opportunity to have another group of people, analysts talk to the customer.  This approach has merit in that the analyst is not there to prescribe a technical solution.  They are there to just listen and come back with their requirements.  We had one meeting to go over requirements and I thought of some solutions in my head.  Then as of late I asked for status and was told that use cases were being developed and was briefed on functionality.  Here is where the lines of communications need to be more formal.  When you move from requirements gathering to developing use cases you have to be careful to not cross the line into the responsibilities of the engineer.  The initial meeting with the analyst was a success, but that's where it ended.  There should have been a more exchange with the technical staff throughout the requirements gathering process.  Mainly to set expectations, in case the customer wants something that is not technically feasible.  So overall I think the whole idea of having an analyst talk to a customer is the way to go, however I think for it to be successful in the long run, there needs to be a more feedback loop with the engineering staff.  Like always, comments are welcome...

Most of you are probably wondering if I really do use a process when it comes to developing software, or do I just sit there and write code.  Well the reality is, I do follow a process, and what I do depends on the size of the effort.  For Friends of Penn State (FPS), I had a full-blown specification with detailed design and so on.  As of late, I do not get a chance to develop or be involved in software that excites me.  Right now, I'm developing some software for WebMail to aid in searching.  The problem is currently a search scans the full text of a mailbox looking for matches.  My idea is to use an index instead, actually an inverted index.  In a prior life, I used to do a large amount of AI/Natural Language Processing, so this problem is pretty simple to solve.  However, I did not just sit down and write code.  I spent some time talking with the developer and test engineer to gain some insight into the problem.  Then I turned around and derived some requirements about what the search would do.  When it came to the design portion of the effort, I ended up write prototypes for all of the functions that I will be writing.  I did not write the code, just some comments on what things are supposed to do.  Once I had agreement with the developers (my customers), I then proceeded to develop software.  Right now I am the point where I can test things, and I have written a test driver to help me do that.  However final testing will rest with the test engineer.  So you can see something as simple as writing a searching capability still requires a process.  I suppose I could have just written the code, but without having a process I would have had to talk with the developers more than I did.  Mainly to confirm just what I am writing.  Doing that up front not only saves my time, but also theirs.  So my advice for today is regardless of the size of the effort get into a habit of using a process when you develop your software.

This is one of my favorite stories and its an important one as it relates to the whole concept of process.  A while back I was in one of those meetings.  You know the ones, talking about a new project that was just assigned to you.  So with my employees, we worked together to come up with a schedule for a our first delivery.  I presented the schedule to management and even pointed out dates on the calendar hanging on the wall.  Later in the day, I met with management again about the project.  This time the deadlines changed, it seems that what I said and showed using the calendar as my visual aid, was interpreted differently.  After the meeting I checked with my employees and they confirmed my original deadlines.  This folks is a pretty common thing here and out in the big world.  How do you solve this problem, you ask?  Well its called a project plan.  You know those things with graphs and dates on them.  The plan has all of the detailed milestones (deadlines) on it, along with the resource requirements.  When you start a project, you need to come up with an initial plan and then you can re-fine it as the project progresses along.  But in no way, do I recommend just starting a project off like I did pointing to dates on the calendar.  Then you run the risk of having to revisit the calendar.  That really is not a fun activity.

We have all seen the movie Office Space, the tour de force movie about IT.  There was one character in the movie, Tom Symkowsi who when interviewed by the Bobs explained his job to be the person, who takes the requirements from the end users and gives them to the engineers.  He also made a statement about "you cannot have the customers talking to the engineers."  Now of course I am paraphrasing here, however this statement is pretty accurate.  Engineers, developers and designers all have a certain technical aptitude that in most cases biases them when they talk to a customer.  They tend to immediately want to give a technical solution even before the customer is still discussing their requirements.  Heck, I even have done this myself in the past.  So how do we solve this problem?  Well you need to have a person who can talk to the customer and use language that they both can understand.  The person who I am calling a consultant should not be there to prescribe a solution or solutions, their main function is to gather the needs of the customer.  Then those needs have to be conveyed to the technical personnel so that they can write the specification.  So to deal with customers whether they are students, faculty and/or staff, we need a mini-army of "Toms" to go out there and talk to them.  Of course this does represent a fundamental shift in the thinking at this University and within any organization, why you may ask?  Well because the engineerings/programmers are they technical people, they feel they are the only ones who can determine the requirements from the user.  So my suggestion to you my fellow engineers/programmers/designers, when it comes time to develop something new, send someone (like a consultant) to talk to your customer.