June 2007 Archives

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.

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) 

Still striving to find the solutions to our software woes, I continue to spend my mornings and evenings (like tonight) reading the trade rags, and Internet to see what's hot.  Some of things that I'm reading about include:

• Practices vs. Processes (this one is very hot!)
  
• Model-driven development
• Test-driven development
• ESSWork (Ivar Jacobson's work)
  
• XP (not Windows XP)
• and many others

The world is changing rapidly and what I am noticing is that Waterfall has its place, but other methodologies should be considered mainly because of quick schedules and current staffing. 

My Little Story...

Along those lines, I'm still having another group within ITS gather requirements for a follow-on to WebRAT.  From what I am seeing from EMails, I see that people are following into the trap of taking the requirements one step further into design.  For example one of the requirements for the new system, is if a person is going to be in all roles for the system, then they should be in one master role.  At that point the people gathering the requirements should stop, that statement is the requirement.  They should not engage the user about how that role is named.  That is getting into design not requirements gathering.  The user should not care what that name is, only that if they are in all roles for the system, then that will be represented by a single role.  With experience will come this knowledge.  Requirements of course will change throughout the project, that is just the nature of the beast.  Its those initial requirements that form the foundation for the development of the system/service.

Well like always, keep posted for future developments. 

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

Its interesting trend that I am seeing these days where programmers (who think they are engineers), write something, proclaim it works and then make statements like its "time to write the documentation".  Quotes like that really scare me.  Why you ask?  Well, when the code is completely written that point in the project is not the time to starting writing documentation.  The documentation (specs, test plans and so one), should have been written well before one line of code is written.  Too often, I see situations like this where people try to force-fit the documentation based on what the program does.  Studies by many of the real pundits in Software Engineering show that this methodology will fail for a variety of reasons.  The biggest of which is not addressing the customer's requirements.  Remember the customer is the one who is paying for the software, they expect results.  Keep that in mind when you are in your office just writing code...

A while back I heard about SQLite from the App Engine folks in my group.  They were using it to provide database service to people, since load balancing database software is a real black art.  Anyways, for those not in the no, SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine.  More information about SQLite can be found at their home page.  The nice thing about it is the database is one self-contained file.  In addition, it has most of the features you would expect from a database like DB2 or Oracle.  So where I am using it?  Well, I needed a data store for the index information for the WebMail project.  If you remember from a previous post, I mentioned that I am writing a searching library for WebMail and was using inverted indexing.  I needed a place to store that information and had a number of options:

• flat file
• dbm and/or DB file
• SQLite

After usability and timing tests, SQLite proved to be the clear winner.  Of course that is in a debug mode.  In the real world I'm not sure.  I may have to re-adjust my implementation based on the results of further testing.  Back to SQLite, if you app needs a self-contained database, give SQLite a try. 

Your software is buggy.  We had a software failure which caused the outage.  A glitch in the software caused the accident.  All of these quotes are pretty commonplace these days, when it comes to discussions about failures.  Wikipedia defines "a software bug (or "bug") is an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect result)."  An incorrect result, could be something as minor as a video game locking up or as major as people dying due to an over-exposure of radiation during an X-Ray.  All of these failures are significant in their own way.

What are some of the common causes that lead to software failures:

• Bad or incorrect design.  An example of this would be a failure on the part of the developer not understanding the user's requirements, which then is turned into bad design.
• Failure to translated the design to code.  This statement pretty much says it all.  The developer has a design that meets the user's requirements, but when it comes time to code he/she makes glaring errors in writing the code.
• Inadequate testing.  Need I say more on this one?  Well I think I will, this could cover simple things like not making sure the test cases satisfy the requirements.  Poor test coverage and the list could go on and on.
• Failure to integrate properly - See any of the above for examples of problems related to this.

Like I stated above, these are only some of the reasons we have failures.  As software continues to become more complex, the probability of software failing also increases.  This is just a common fact of life in Information Technology.  You are probably going to guess how you can limit the amount of failures based on my previous posts.  And yes, you are correct.  Having a software process can really limit the amount of failures/bugs/glitches and so on that your software has. 

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.

This morning I am going to chat a bit on the concept of portability as it relates to Web-based applications.  I have always been a big supporter of this concept.  You do not want to disenfranchise your user community by telling them, your application only runs on Windows.  As most of all you know, I was married on 5/5/2007.  On Sunday my DJ sent me a link to a site that had photos and some of the music from the reception.  I thought to myself, this is a pretty good idea.  Well I went to visit the site, and it told me I needed a plug-in.  So far, I was still OK, I realize there are things out there that need the advanced features of a plug-in.  I attempted to download it and then I became frustrated.  The plug-in only works on Windows.  At home right now, I have anywhere from 2-3 Macs depending on the day of the week and a Linux box.  As a user, I was totally frustrated.  I really wanted to view this video.  Why would the vendor do something like this?  That is a question I will not be able to answer (they have not responded to my question).  Anyways, when it comes to developing applications around keep a keen eye to portability. 

Back in the day at Raytheon, we did most of our development on Solaris and then ran some porting back to get a Windows version of our application.  That sounded like a good solution until I heard about the cost.  It was upwards of $10,000.00.  Now at the time that was the best thing out there.  Then came Java 0.1, yes I started my developed with the zero dot versions.  I developed a little hello world program on Windows and took the class file to Solaris and it just ran.  No re-compilation,  no nothing.  Now I do not plan on starting flame wars about just how portable Java is, because I know others feel differently.  But I do have a few example of software I developed here at Penn State that is still running and very portable.  The Accounts Interface is one really big Java Applet, that runs on Windows, Solaris, Linux, and others flavors of UNIX just fine.  The signature stations are an another example.  They are currently running on OSX.  My Boss and others want to move them to Linux and they are concerned about whether they will run there.  As it turns out, the signature stations started out on Linux.  My code from my Mac runs just fine on Linux. 

Of course, I just provided you with a couple of simple examples.  The same things apply to Web Applications, do not select technologies that are browser-specific.  In the long run, you will really pay for it.  My advice, is always remember your customer, because there is one of them out there probably still running Windows 3.1 or even Windows Me.  You do not want to exclude them because they are just as important as the user running the latest version of Vista.  So always be sensitive to the portability of your application.  This whole area should be addressed in your requirements and your test plans and procedures.