When hiring for a "hot" technology

I ran across this article, which outlined a manager's thought process when deciding whether to overpay some entry-level developers due to skills in a particular technology:

http://itmanagement.earthweb.com/entdev/article.php/3921006/Should-Younger-Developers-be-Paid-More.htm

When going over the pros and cons of hiring these developers, the author failed to look at the fact that these entry-level developers with skills in mobile technologies are still just entry-level developers.  Many of the skills learned in the course of programming are easily transferable from one medium (web, desktop, mobile, etc.) to another, and these skills are usually best learned through experience.  So what else could the manager have done?

I think this is a perfect opportunity for the company to hire temporary workers.  These workers could be paid relatively large amounts of money without needing to worry about having over-paid employees on the payroll when the supply for mobile developers catches up with demand.  This has the added bonus of making the salaries more justifiable to existing employees, since it is reasonable to pay your current employees less salary in exchange for more stability.

What other options do you see available?

Background for a CIO

Recently we had a discussion in one of my classes that focused on a young business manager (named Claire) who was offered a high-level executive position of managing a company's entire R & D efforts.  Claire did not have an engineering background, so was at best only qualified to serve as a director for the efforts, and at worst was completely over her head.  The assignment was to determine whether or not Claire should take the position.  There was little discussion over whether or not she could do her job adequately, instead discussion focused on what Claire needed to do in order to be successful.

Since most companies (and most MBA students) would have conniptions at the thought of CFOs with little to no knowledge of finance or COOs with little to no knowledge of operations, why do we find it acceptable to have CIOs with little to no knowledge of information technology?

I think at least part of it has to do with the fact that people in technology seem to value knowledge of technology over everything else.  There are plenty of technologists, at least in the software development realm, who spend a lot of time and energy studying patterns, practices, languages, etc.  Yet being an effective technologist goes beyond his or her skill in writing software, configuring servers, setting up networks, etc.  Technologists must also work at communicating technical needs with non-technical people and focus on solving problems with technology, rather than choosing technologies that solve problems.

This is not a small change to make.  If technologists were to truly make this shift, conversations about technology (such as user group meetings) would start with business contexts, job interviews would focus on problem-solving skills more than specific technology implementations, and technologists would spend as much free time learning about finance and operations management as they do new technologies.  Moving in this direction would almost certainly help align IT and business objectives.

If we were to make this shift, companies would still need pure technologists, since technology changes so quickly we will need people who can keep up with these changes.  However, we need to do a better job developing the business skills of our technology professionals.  One way to do this would be to encourage more business training (like the MBA) for IT professionals, and make such training required for many management positions.  What else can IT professionals do to encourage business-context thinking in our day-to-day work?

What business people need to know about software development

Claiming ignorance of information technology in this day and age is just like claiming ignorance of accounting.  Every manager must have a basic knowledge of IT just like they must be able to read a balance sheet.  Determining what, exactly, every manager must know is difficult, though.  Like most things, it depends on the context.  I'll start with what business stakeholders need to know about software development, in large part because this is my specialty.

Basic Terminology:
User Interface - This is the term for the way in which the software user interacts with the application
Database - This is software that stores the data in most scenarios
Server - This is a computer, usually with a large amount of memory, that hosts the software or database
Hardware - This refers to the physical components of a computer
RAM - Think of this like short-term memory in humans: it stores information that might be needed in a few minutes, but does not hold information in the long-term
Refactoring - The process of rewriting working code to make it more readable
Data - Another name for "information", though "data" is plural

Development Process:
Writing software does not follow a predictable method or process.  If it did, we could write software that could write software for us and save everyone a lot of time and money.  (Most good programmers will do that when and where it is appropriate.)  Because software writing is a highly creative and unpredictable process, nailing down solid estimates can be tough.  If you try to force your developers to stick to their original time and cost estimates, you will likely create a contentious atmosphere which will get in everyone's way when trying to get work done.  Instead be flexible to estimate changes.  If it looks like a task or component is taking too long to complete, decide if it is worth completing after all.  If so, keep in mind that the next estimate very well might be too large and you'll be even in the long run.  If not, it is better to stop a time-consuming task early to avoid throwing good money after bad.

Early detection of problems is important
If you notice something strange in your application, especially if your data looks wrong or missing, find out what the cause is soon.  Chances are that there's something wrong with your user interface and your data is fine, but if there's something in the application that's corrupting the data the sooner you can find the problem the easier it can be corrected.  Lost data can be recovered from backups, but most companies only keep backups for a certain period of time.

Early detection is also important for problems like software slowness.  If your software is slow, it is not likely going to speed up on its own, and will likely get worse over time.  Fixing the problem early before complaints start coming in will save both you and your developer time and frustration.


Know what will change in your business requirements...and what won't
Many developers would disagree with me on this one, but I think it's important to communicate which of your business requirements will never change and which ones will certainly change over time.  For example, if you have an e-commerce site that sells shirts, you might expect to add colors to your offerings, but you will not likely add sizes.  The reason for this is that most developers will program non-changing requirements differently than ones that will change often.  The non-changing requirements can be coded in such a way to make it easier and faster to write the first time, but harder to change going forward.  The opposite is true for the changing requirements.  This concept isn't critical, but it is something to keep in mind.


When problems arise, adding more bodies is probably not the solution
If a software project falls behind schedule, resist the urge to request additional resources to get it done.  Why?  Since, as I mentioned before, software writing is a relatively complex process, it will take time to get new resources up-to-speed on the specific requirements of your project.  This not only means that these new resources will not be as effective as your current ones, but your current resources will be less effective than they were as they help bring the new resources into the project.  Your best bet is probably to adjust your expected finish dates.  If that is not possible, then adjusting the number of features to be added should be the next option.

It was working before....

Refactoring is an important part of the software development process.  Adding features adds code, and unless you change existing code so everything makes sense to the developer you will eventually end up with a tangled, unmaintainable mess, to put it mildly.  Therefore, most good developers will spend some time rewriting code to prevent this from happening.  Every time this happens, the developer runs the risk of breaking something that was working before.  There are ways of mitigating that risk, such as writing and running unit tests, but the risk cannot be completely eliminated.  If you are testing changes made to your software, try to test areas that might be affected.  Also, if you get complaints right after changes were applied about functionality that was working before, take them as seriously as any other.

Know the general limitations of your approach
I am not suggesting that you become a programming expert by any means, but you should be aware of the limitations of the software delivery method you choose.  For instance, applications for a hand-held device might be difficult to move over to other brands of devices.  Desktop applications are hard to update with bug fixes or changes.  Web programming is limited by the fact that most of the processing must be done by the server.  (Going into more detail would require another blog post on its own.)  Being aware of the limitations will help you ask for features that are appropriate for your medium, and will make the conversations you have with your developers about changing features much more productive.

Keep in mind that you are a team
Finally, keep in mind that most programmers, no matter what their background, experience, or skill level, want to write good software.  Their focus may be different (most software developers I know will often over-emphasize quality code creation at the expense of the software as a whole), but in the end they want the same thing.  They want the software to be successful as much as you do.  From what I've seen, many of the problems between business and IT could be mitigated if everyone remembered that the end goal for everyone else is the same.  Build trust, and good things should follow.

Tips for mentoring others

LHere is a great blog post that was written about mentoring new programmers, but could easily be applied to other disciplines and experienced hires too:

http://blogs.techrepublic.com.com/five-tips/?p=212

These tips are rather incomplete, though.  I'd like to expand on their tips:

1. The issue with mentoring seems not to be lack of will, but lack of time.  More on this in a bit.
2. Make sure your road map covers more than just the first few hours.  It is all well and good to show the new employee the location of the documentation, but have a plan that covers at least the first six months.  This plan should include ways to make the employee more independent as time goes on.
3. Be tolerant of mistakes, but try to prevent common or serious ones.  Confidence building is key.
4. Try to assign projects at first that have a training purpose as well as a practical purpose for the company.  This should be a mixture of easy projects to give the employee confidence and stretch projects to keep him or her engaged.

While most of us would agree with these tips, very often they're not followed.  Why?  The biggest reason seems to be that people usually aren't hired for a potential need, they're hired to fill a current one.  While that approach lowers the risk for the company of hiring someone who will need to be laid off, it also makes it harder for managers and experienced co-workers to get the employee up to speed in a fashion that benefits both the employee and the company.  The easiest way around this that I can see is to keep track of potential future needs (perhaps by using risk modeling tools such as these) and hire based on that.  Outsourcing and contract-to-hire positions can mitigate the risk of over-hiring, if needed.  Good mentoring is a lot easier when one feels like there is time to do it well.

Determining if a project is worth the money

In a hypothetical scenario, let's say I have the opportunity to take or reject a project, that will cost my company $200,000 this year, and is predicted to get my company the following yearly profits:

This year (2010): $0
2011: $20,000
2012: $50,000
2013: $100,000
2014: $80,000
2015: $30,000
2016: $0

Should I take the project?  On the surface, the project seems to bring in $80,000 profit for the company.  But I should take into account the fact that most of the profits come in years 2013 and 2014.  To see why, imagine that the bank on the corner is offering an incentive to start an account.  Just bring in $1000 and you get $100 cash on the spot.  Would you take that deal?  Now imagine that bringing in $1000 now will get you $100 a year from now.  That doesn't look so good.  Would you take the deal if you had to wait 20 years for the $100?  Probably not.  So how should I go about determining whether the delay is worth it?

It's easiest if I start by figuring out what rate of return I would like from this investment.  (You'll see why in a moment.)  If I work for a publicly traded company, I could use the Weighted Average Cost of Capital (WACC) as a starting point.  The WACC basically tries to answer the question: if my company wanted to raise money for a project today, what interest rate would I expect to pay?  I won't go into the details about how to calculate it, but it tries to predict what people would pay for new stocks and bonds issued by the company.  (While I recommend having someone calculate the value for your company if you were to use it for something important, http://www.wikiwealth.com/ seems to have numbers that are close.)

Now, I said that the WACC should be a starting point.  The reason is that it doesn't take into account any specifics of the project.  If this particular project involves a lot of risk (maybe the sales estimates are uncertain or the estimates are based on the economy continuing to grow) then I might want to adjust the rate higher.  (Riskier projects, stocks, bonds, and most other investments require a greater return if more risk is involved.)   Finally, keep in mind that since the WACC is the rate a company would pay investors for capital, it is essentially the break-even point.  Accepting a project that has returns that match the WACC would be like taking a bank loan at 6% to buy an investment that returns 6%.  In the end that investment has no net gain.

I think that my project isn't particularly risky so I'll just use my company's WACC.  For this example, I'll use both the WACC for Microsoft (9%) and CitiGroup (14%), as determined by www.wikiwealth.com.  I could then find the present value of my profits using Excel.  The present value is essentially a way of telling us the value of a series of cash flows for a given interest rate.  For example, if I wanted to determine how much the project is worth for Microsoft, I would enter:

=NPV(0.09, 20000, 50000, 100000, 80000, 30000)

Where the first term is the interest rate, and all the subsequent terms are the expected profits from each future year.  When I enter this, Excel returns a present value of $213,822.93.  Since this is more than the $200,000 investment for the project, I should accept the project.  What about CitiGroup?  Here is my present value calculation in Excel:

=NPV(0.14, 20000, 50000, 100000, 80000, 30000)

Which returns $186,461.87.  It looks like I would not take the project if I worked for CitiGroup.

I hope that gives you a little bit of insight into some of the finances behind decision making.  As you can see, the process is somewhat subjective (such as determining the interest rate and estimating the profits), but it does give you a relatively easy way of comparing the value of two different projects.

Hiring good programmers - Part 2

In Part 1, I outlined some problems with common practices in hiring programmers (or anyone else for that matter).  What can the hiring manager do about these problems?

I would start by defining the tasks the position requires as honestly, realistically, and specifically as possible.  This isn't as easy as it sounds.  For example, many openings that I've seen for programmers require someone who can complete code "on time, within budget, and bug-free".  If a company is having trouble finding programmers who meet these requirements, what is the problem?  Yes, skill deficiencies in the programmers themselves can cause any or all of these issues.  But so can poor requirements, poorly controlled scope creep, poor communication, etc.  What exactly is the need?

A better approach might be identifying which aspects of the finished product are most important.  A programmer trying to be one of the first to create a game for a new mobile system might be more focused on time and budget than bugs.  To contrast, programming for medical devices would require much more focus on creating bug-free software.  Along with this, be aware of any road blocks within your company preventing programmers from getting work done.  Do the programmers frequently get poor requirements?  While improving the requirement gathering and documenting process, I would focus on getting programmers with enough of a business sense to be able to extrapolate missing information from the requirements.  Are projects frequently under time pressure?  Then finding programmers who can get work done quickly should be a priority.

Once the tasks have been defined, I would then break each of the tasks down into Knowledge, Skills, and Abilities (KSA).  For the sake of example, I'll start breaking down a few of the tasks and KSAs needed for a completely hypothetical mid-level ASP.NET developer position.  This position might be for a mid-sized company looking to add onto a web application designed to track inventory within a supply chain looking to add a developer to a team that can handle simpler tasks to free up some senior developers to work on other projects.

Tasks:

1. Creates reusable, maintainable, reliable components in C#
2. Tracks down bugs with little assistance from more experienced developers
3. Integrates third-party components into web applications

Task 1 could be broken down into the following KSAs:

1. Working knowledge of Object-Oriented Programming concepts
2. Experience creating effective unit tests
3. Makes intelligent decisions as to when a component should be broken down into sub-components

Task 2 could be broken down into the following KSAs:

1. Can read and understand code in C#
2. Can read and understand documentation
3. Can refactor poorly written code into more usable/readable components
4. Can write unit tests to reduce the amount of time testing through the user interface

Task 3 could similarly be broken down into the following KSAs:

1. Can read and understand third-party documentation
2. Can integrate third-party code into a larger application as seamlessly as possible
3. Can anticipate problems with third-party components and comes up with reasonable work-around solutions

A real KSA breakdown would include many more tasks and KSAs, but hopefully you get the idea.  Now that the needed KSAs have been identified, it is time to identify the important ones.  Reading and understanding C# and documentation are common KSAs, as is seeing how small pieces fit into a whole, and writing effective unit tests.  Not found is the need for keeping up with the latest technologies or understanding large-scale structural issues.  (Keep in mind this is a hypothetical position - these skills may be needed in other ASP.NET positions depending on the company.)

With this information, you can design questions for interviews.  Since we need to identify people with an understanding of creating reusable, maintainable components, here are some questions that we might ask:

• If you are asked to fix a method that has a return type of an object and returns a due date if the user is valid and 'false' if not, how would you go about doing so?
• If you have some functionality in one of your classes that is needed by another, what is the best way to move that functionality to the new class?
• If you are using a third-party library to send information from several different ASP.NET pages to a third-party store, where do you put the logic?

These questions are all specific and are all targeted to certain tasks I would need the interviewee to perform.  I have my ideal answers for each and can evaluate the interviewee consistently.  It is important to ask several questions that get to the same point because of the possibility of miscommunication or misinterpretation on either side.

It is also important to evaluate employees by watching them do work that is representative of the job they would be hired for.  I might run into someone who can talk about different technologies or approaches fairly well, but when they get to doing the job, they fall short.  I would take a similar approach to designing the test as I would designing questions; I would identify important KSAs and create tasks that would require them.  Taking this one step further, I also like to break down my tasks into three categories: tasks that every person ought to be able to do, tasks that require skills that are "nice to have", and tasks that I don't expect the candidate to complete.  This way I can get a deeper sense of the understanding a candidate has for particular skills.  A candidate who can complete some of the tasks in the last category will have an advantage over those who don't.

Finally, you may be wondering about how to determine cultural fit.  Unfortunately, cultural fit is tough to pin down and therefore it is difficult to create good questions to get at it.  To make it even tougher, many of the questions that could be asked to ascertain cultural fit open the door to discrimination lawsuits.  I don't have any good ideas here.  If anyone has any ideas, please feel free to leave a comment.  I'm certainly open to ideas.

Hiring good programmers - Part 1

One thing that I've struggled with, and I know I'm not alone in this, is how to accurately decide if someone will be a good programmer for a company or not.  Traditionally, companies will first screen resumes, looking for particular experience, skills, etc.  They will next have a phone screen to further weed out candidates.  Finally, the candidates will be brought in for a face-to-face interview.  How effective are these methods, and what can we do to be more effective?  In Part 1, I will outline issues with common current methods of evaluation, and in Part 2, I will suggest an alternative.

What about the resume?  Many companies will pre-rank candidates (either explicitly or implicitly) based on the quality of the resume and the information presented on it.  There are a few problems with this.  First, I don't have a reliable source handy, but I recall hearing that 50% of people lie on their resume.  50%!  Couple with the proliferation of sites (such as fakeresume.com) that are intended to give advice to people who want to get away with lying on a resume, and it's tough to know which resumes to trust.  Second, many of your potential employees will have hired a professional resume writer in order to get your attention.  Great resume?  Is it because they are a detailed worker or just hired a great resume writer?

What about a degree?  Most of the jobs posted on the major job sites for programmers ask for some sort of technical bachelor's degree.  This certainly should be a consideration for an entry-level candidate.  However, in observing a number of people in a number of different industries, I've come to the conclusion that the benefits of the quality or type (or even presence) of a degree decreases severely after about 1-3 years of experience.  For experienced candidates, the ability to learn new concepts and apply those concepts in new situations becomes a much more important asset than the quality or source of their original education.  Putting it in another way, does the candidate have 10 years of experience, or 1 year of experience repeated 10 times?  In fact, I might be more inclined to hire the person with the poor quality of education who somehow managed to become a good programmer, since they have the proven ability to learn and apply concepts in less than ideal circumstances.  (Or maybe I just think that because I'm a self-taught programmer.)

What about the interview?  A lot of good information can be gotten from an interview, but a lot of misleading information can be gotten here, too.  I'll speak more about interviews in Part 2, when I actually start talking about methods that can help you find good candidates rather than merely eliminating bad ones, but I will mention here that you should always be aware of the implications of what you are asking even if the legality of questions weren't an issue.  As an extreme example, I read an article on BNET that quoted a hiring manager saying (and I'm paraphrasing) that they hired someone based on the answer to this question: "If you would be a character from 'The Wizard of Oz', which would you be and why?"  What can you learn from the answer, assuming you get one?

1. The interviewee thinks well on his or her feet and handles the unexpected well
2. The interviewee has an active fantasy life and empathizes with characters easily
3. The interviewee is a huge 'Wizard of Oz' fan
4. The interviewee trusts you that you know what you are doing, even though you are asking a question that seemingly gives you no insight into his/her ability to do your job or him/her insight into their fit into your culture, making him/her a likely "yes person"
5. The interviewee does not have the ability to sense when something is or is not a waste of time and would be a poor choice for leadership positions

You could legitimately make a case for any of the five.  #1 is definitely a plus for your company, #2 may or may not be, depending on the position, culture, and point of view, #3 is completely irrelevant, and #4 and #5 would be considered negatives for most positions out there.  I can't see how the interviewer in this case learned anything worth knowing from this question given the uncertainty involved.

Finally, many companies have some sort of programming exercise as a part of the interview processes.  Even a poorly designed exercise will likely separate the completely incompetent from the competent programmers.  For example, what does having the programmer show all the prime numbers from 1 to 100 show about his or her ability?  You may need someone who can think mathematically, but you may not.  Here again, the best designed exercises will have specific goals and will not be some generic problem designed to eliminate the worst programmers.

In Part 2, I will demonstrate some methods for getting at the heart of the job position which will hopefully make it easier to scan resumes, design interview questions, and design programming exercises.

Should programmers be middle managers?

Recently, I wrote about whether programmers should get an MBA here, and said that an MBA would be helpful for the programmers who wanted to get into management.  Related to that, I came across an article on CIO.com about the inherent skills needed for programmers, middle management, and executives.  I don't have any particular insight into the article, or what it means for I.T., other than it's an article worth reading.  I think I might put the book on which the article is based on my reading list.