Recently in General Information Category

Hello, its sure been a while since I have had a chance to blog about anything.  This summer sure has gone fast, with migration after another.  Personally, I'm sure glad the semester has started, so I can get caught up on other things.  Today's topic is maintenance programming, that is art of developing software to maintain existing applications and/or services.  At my previous job at Raytheon, that used to be the kiss of death.  Comments like, "Oh he is doing maintenance, well that's it for him" used to be commonplace.  Reality is, I have a friend who is doing maintenance on the same software application that I worked on 12 years ago.  My friend knows its a real killer, but he has all of the experience so his skill is needed.

As of the last two years, I am finding myself in the same boat, just doing maintenance programming.  Needless to say, I know how important it is, but in a word it can be just boring.  How do you make it exciting, other than the obivious resigning?  Well what I try to do is see if I can apply a new technology or programming language in a way that will enhance the functionality of the application.  Of course you do not want to do technology for technology's sake. 

Here is an example of where some new technology could make things better.  We have some applications that provide APIs that when called returned XML documents.  Back in the day, when I developed them, frameworks, SOAP, Web Services and so on were just in their infancy.  So doing things with a simple HTTPS POST and rolling your XML was pretty much the solution.  Now today, we have things like Web Services, and REST.  So for some of the newer enhancements, I will be looking at those technologies.  Hopefully that will make maintanance programming more exciting.

I'm not sure I will keeping this blog around or not.  That's another thing I have been toying with too.   

You are probably asking yourself, which Portal?  There are so many things out there today with portal-like features, that's it hard to tell one from the other.  The Portal that I am referring to, is the Penn State Portal @ https://portal.psu.edu/.  As many of you know a long time ago, I was the primary developer for the Portal.  I'm not going into all of the historical stuff, I already did that in a previous post. 

When we looked at the portal concept, a number of us felt it was great idea.  One place to go to for all of your stuff, whether its Penn State-related or external like CNN.com.  And for a period of time, we had some traction.  The portal was the place to go for a number of things like RSS feeds and chat.  When we were doing our design, we make a conscious decision that we were going to settle on using RSS for content-type channels.  At the time the specification was in the hands of Netscape and the version was around 0.91.  Software to take RSS and convert it to HTML existed, but its performance was not very good.  So we ended up writing our own parsers using compiler tools (Lex and Yacc).  Then for chat, we had a Java Applet (yes an Applet) that supported Jabber in the portal.  Another thing that we can up with in the portal was the concept of your personal bookmarks.  That way a person could log in and always have access to their bookmarks.  Again another great idea at the time, now with sites like del.icio.us, you may not need a capability like that.

So where have things gone?  Well today, everybody and their brother has their own RSS aggregrator (News Reader).  I personally use NetNewsWire.  And for things like chat, we just launched a Jabber Alpha/Beta that supports native clients.  A web-based version is on the way.  So there are  a number of things out there that replace the functionality of the Portal.  I will be the first to admit that. I have not checked usage numbers in years.  But, people still use the portal.  Why you may ask?  Well it gives them something that many other sites do not, personalization and customization.  Your portal is personalized for you, because we know a little bit about you based on your directory information.  This is a pretty neat concept that still has merit.  Customization of course will allow you to go in and pick and choose the concept you want to see. 

Back to my original question, is the Portal dead?  I think it is on life support, but not dead.  People at Penn State and other Universities still find value in the portal concept.  Remember a single place to go for all of my stuff.  If I had my way, what would I do to resurrect the portal?

1. Complete rewrite to make it Web 2.0/3.0.
2. Make content publishing more user friendly.
3. Try to make it the hub for all Penn State applications.  Those applications do not have to be wholly contained in the portal, just use the portal as a launching point for them.
4. Make things easier to use (look at Google's Portal for example).  And you maybe asking why not just use Google?  That question has been asked in different forms before, because Penn State content should stay inside of Penn State.

Since others and myself have spent so much time on the portal, I sure hope we can save it and breathe new life into it.

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).

No, not with me, how about each other?  Everyone has an AIM account, maybe even a Yahoo one too.  The problem with all of these accounts is your are known by names like starblade2000 (my brother-in-law) or jimmyvPSU (me).  Wouldn't it be nice to use your Penn State Access Account in a secure manner to chat with other Penn Staters?  Well folks, guess what?  We have resurrected our old Jabber server.  Back in the day the Jabber chat only worked by logging into the portal (https://portal.psu.edu/ ).  Now we have a new service (that's in alpha/beta), that is load-balanced, secure and uses Kerberos.  All you need to do is point your favorite Jabber client to chat.psu.edu.  Your jabber id will be your access-id at chat.psu.edu (jvuccolo@chat.psu.edu is mine).  By default we are set up for TLS and SSL, so all of the chats will be secure.  Client-wise there are so many out there to choose from (iChat, Adium, Spark, Fire, Pidgen to name a few).  In addition, because its jabber, you can inter-operate with people who have google talk ids, jabber.org ids and so on.  We also have a conference server up at conferences.chat.psu.edu.  Again, try it out and see what you think... 

People use that expression a lot when they talk about a time when things were just perfect for them.  There are times when in my IT career, I miss the good old days.  A time very long ago, when my title was Senior Engineer.  Engineer, of what you may ask.  Well Software, of course.  I was at Raytheon and I was engineering new software following tried and true practices and procedures.  Ah, the good old days, such a great time.  I was a Lead Software Engineer (LSWE as we called them), on a number of projects.  That was a good thing too, I had resources available to me, but I did not have to worry about their performance reviews or personal issues.  Unlike what I do here as an IT Manager.  Even though my real title says, Manager, Research Programmer.  You really cannot escape that Manager part, trust me I have tried.

Wait a minute, people are probably thinking being a manager is better, you have people and you can use them to get things done.  Well, folks hate to burst your bubble but it doesn't work that way.  As a manager, you have to deal with the human side of things.  All of the talks, and training courses really cannot prepare you for a lot of these things.  I remember when I became a manager, I was dealing with so many issues my head was spinning.  Then I took courses like Mastering Supervision which only made situations worse because I tried to use some of my new found knowledge.  Some things worked, others failed miserably.  Things that I learned from the IT Leader's Program (ITLP) were actually more useful.  Having a coach like Brian McDonald (MOR Associates) really was another big win for me.  So know you are probably concluding that being a manager now is great.  Well not really...

I truly do miss the good old days.  I am finding that most of the software that I write these days is of the maintenance variety.  Trust me folks that is not really Software Engineering.  About the only new software I have written lately was helping my kid write some Java for her class.  The reality is, I'm not the only one feeling this way.  I have friends outside of Penn State that are still doing maintenance on software they wrote 20 years ago.  I did that maintenance type of work at Raytheon for about a year and then resigned.  I'm not saying that type of work is not important.  Maintenance work keeps machines moving and airplanes flying.  So what I am saying?

Well, I personally missing the days of being a technical lead and having the ability to write new exciting software.  Do I see opportunities for something like that in the future in my current job?  I am not sure, that's the truth.  I do enjoy having the ability to blog about issues like this and I'm guessing there are other "IT Managers" out there that feel the same way.  Will I leave because of this? (dead silence)

I know a good friend of mine, told me I was nuts for going doing this route of IT Manager.  At that time, I really did not believe him, because the glory and the prestige of the title of manager was in front of me.  Now if he would make that comment again, I would probably agree with him.  Oh to yearn for the good 'ole days.

Today's posting is about a time when I was working at (HRB) Raytheon.  Sometimes stories have a lesson to them that apply to today's problems.  Anyways, I was at HRB maybe for about 5 years, by then I was an Advanced Engineer.  It was during the lean times when budget cuts in the defense industry were rampant.  So I was assigned to a new project to write some software for a follow-on to a large contract.  There was a team of 6 people all with software backgrounds.  We were under the leadership of someone I will call Jane.  This was Jane's first leadership role and trust me it showed.  But at the time, I was more concerned with my own problems of having to deal with a new project and a new boss.  Anyways, Jane and I got along fairly well, and as a team we really gelled.  In addition to being a leader Jane was assigned her own items to code.  One of them was a temperature sensor system for our racks.  So I have done serial communications before and I did mention that.  So after reading the instructions for the device I was able to get it to work.  At that point, she was elated and turned to me and said "this is great now how do I code a switch statement?".  Here we have the leader for the project, the mentor to the team asking the most basic of questions.  At the time, the team felt differently towards Jane.  Should we have?  In retrospect the answer is no.  We cannot expect everyone to know everything about all programming languages.  We are a team and we need to support the individual members do their job.  From my ITLP class, I learned that anyone can be a leader, and in situations like this that is so true.

What I did learn about my experiences on that project is your really do not have to know all of the deals of the design to go off and write software for it.  CASE (Computer-Aided Software Engineering) tools just started to make their arrival in our world.  At the time, we were using Software Through Pictures (StP).  Our use of it was mainly as a fancy drawing tool.  So back to me, I'm new to the technology area, but not programming.  When it came time to code, I was given three units (a unit is a testable component of software) to code.  I didn't have the foggiest idea what they were to do.  All I knew is that I had to use "C", code and test them.  Another big 80-90s thing was the writing of pseudo-code (English-like statements used to describe a problem).  Well as it turns out, everything in my units was written in pseudo-code, which made my job extremely easy.  All of the hard work was done for me and all I had to do was turn it into actual code and test it.  So I would say at this point in the game, I would have been classified as a programmer, not a software engineer.  The lesson to learn from this little story is if you do your design correctly and detailed, you should be able to pass it along to programmers who will turn it into software.  This is how the system should work.  Yes, the programmers should know something of what they are coding, but they do not need to be bogged down in all of the design decisions that have taken place to get them at the coding stage.  I know these are pretty radical statements and I want to invite people to express their opinions one way or the other.

A tiny footnote, how did Jane do?  Well I run into her occasionally, she still works at Raytheon and is now a leader of about 40 people.  I hope those 40 people support her as a team should like we did back in the late 80s.  

 

This is going to be a pretty interesting post.  As of late, I have been consulted by a number of groups including OHR on what techniques I use to interview and hire programmers.  Over time, I have built up a pretty good list of things to do.  Back in the day when I was at Raytheon, we would hire anywhere from 80-100 engineers a year (during the good times).  We received a large number of applicants fresh from college.  One of my jobs was to help weed them out.  How things worked there was, the director/manager would pick the candidates and then there would be three interviews with technical people.  At the end of the day, we made a recommendation as to whether we would hire the person and why.  Over time, the number of interviewers dropped down to two and in some cases it was just me.  I remember one year, doing 68 interviews.  Now that was sure a lot. 

Anyways, back to the topic at hand, how do I interview a programmer?  Well it starts with the resume of course.  I will review that along with the application.  You would be surprised but the application contains a wealth of information regarding job and salary history.  Your goal as a manager or technical person is to fill the position with the best candidate.  So take your time reviewing the information at hand before bringing the person in for an interview.  One thing that I do and its really catching on at Penn State is require the candidate to bring in code samples.  If a person says they can code in "C", then I would like to see what their version of "C" looks like.  I consider it part of the candidate's portfolio.  I even have my portfolio that I keep up to date, just in case things do not work out for me at Penn State.  

So to recap where things are so far:

• Review the resume, cover letter and application
• Require code samples (a portfolio of sorts).

Now onto the actual interview.  I usually bring one of my staff with me to conduct the interview.  Its a good experience for them.  I will start off the interview with the introductions, a little bit about the job and then we dive into the reason why we are here.  My employee will ask his questions and I will ask my stock questions. 

1. What do you consider your strongest programming language and why?
2. I ask the same thing for the operating system
3. How do you go about solving problems?
4. What software methodology do you use?
   
5. How do you work within a team environment?

I always ask these questions and maybe a few others but those items are things that I care about the most.  How does the candidate solve problems and team environment.  One of my requirements that is sometime not met is that the candidate must provide the code sample before the interview.  I do not want to waste an interview on someone whose code does not look like its something I do not want.  Remember my statement about being proud of your code.  I'm looking for that when I review a candidates code.  And these days with tools like codefetch and Google code, you have to be careful about the candidate "stealing" code from someone else.  Trust me that does happen.  You have to look at the candidate's experience level and the complexity of their code sample.  Even take the time to search the sites to see if you can find the code on-line.

Of course the standard rules do apply when you interview someone.  Eye contact is important, along with how the candidate presents him/herself.  Trust me you will get a gut feeling as to whether you want to hire the candidate.  Trust your instincts and remember to check the references.

When i talked with OHR about this process for about two hours.  They said, "great but what do you do when you do not have technical people at a campus to review the code?"  That's a really good question.  What do you do?  Not only is this a problem for a campus, but also for departments too.  Since we are central IT, we should provide a service where we could help these people.  Not only them, but ourselves too.  We want to make sure we hire the right candidates for our jobs.

Yesterday, I was invited to attend a meeting about an endeavor called IntraSource.  Everybody is pretty familiar with sourceforge, which is the world's largest development and download repository of Open Source code and applications.  Well, IntraSource is looking the do the same thing except for members of the Penn State community.  I really see a lot of value in something like this.  We have an extremely large source code base because we develop a lot of software as opposed to buying in the box solutions.  This project will really help developers share code and also write code.  One of my hopes for this project is that it has features like codefetch, where developers can enter a few keywords and then snippets of code will be returned that meet the search criteria.  I'm looking forward to seeing where this project goes, and like one of my colleagues mentioned yesterday, even if its only used by ASET its considered to be a success.  Now

I'm going to take things a little further, back in the days at Raytheon we had code re-use down to a science, and there was one more thing we re-used and that was the design.  I'm not sure if something like that could ever happen at Penn State.  Design re-use represents a step in the right direction, but its really tough to accomplish.  Along with re-using the design, you can also take advantage of the existing documentation.  Of course all of these things are dreams of mine. 

Process, that is a term that I have batted a lot these days.  Dictionary.com defines process as:

proc·ess      /ˈprɒsɛs; especially Brit. ˈproʊsɛs/ Pronunciation Key - Show Spelled Pronunciation[pros-es; especially Brit. proh-ses] Pronunciation Key - Show IPA Pronunciation noun, plural proc·ess·es      /ˈprɒsɛsɪz, ‑əsɪz, ‑əˌsiz or, especially Brit., ˈproʊsɛs‑, ˈproʊsə‑/ Pronunciation Key - Show Spelled Pronunciation[pros-es-iz, ‑uh-siz, ‑uh-seez or, especially Brit., proh-ses‑, proh-suh‑] Pronunciation Key - Show IPA Pronunciation, verb, adjective –noun

1.	a systematic series of actions directed to some end: to devise a process for homogenizing milk.

2.	a continuous action, operation, or series of changes taking place in a definite manner: the process of decay.

 I really like both definitions, because they describe what a process is.  That's going to be the focus of this blog entry, a frank discussion of process and why its so important.  Process when it comes to software is analogous to having a methodology (waterfall, spiral, agile and so on).  To often software is just developed with one or two programmers sitting in a cube writing code.  When they are done and feel that the "thing" is adequately testing (in their mind), they and their management call it a service.  That is a serious misconception, because that thing may work for them but what about everyone else?

If they had a process for developing software, they would first start off with the most fundamental question what does the customer want.  Every software application has some sort of customer or user base.  They have certain requirements which must be addressed.  If the customer is not consulted how can companies expect people to buy their products.  The process is the thing that guides this whole thing along.  Starting off with talking to the customer, determining requirements, writing a specification, building software that adheres to the specification and finally testing the software.  All of these items are part of the overall process when it comes to developing software.  Now the nice thing about software development these days is there are many processes (methodologies) to choose from.  So regardless of whether you like waterfall or agile, that's not important.  What's important is you select a methodology and use it.

Why have a process?  Well, just do a quick survey of the news and you will see many failures (software, hardware and so on) that are all caused by not having a good process or having one and not following it.  A process is the cornerstone to good software engineering without it, you are just coding.  

Establishing a process within my organization is something of a personal crusade of mine.  Working in industry or higher ed, it really doesn't matter there has to be some process with regards to developing software, otherwise the ramifications will be extremely costly.  The good thing about a process is you can customize it to meet the needs of your organization.  When I was in industry, we had rigid procedures to follow.  Now that I am in higher ed, I'm not saying we need the same thing.  We just need something, otherwise we will continue to fail at many levels.