CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Eric Wise

Business & .NET

November 2006 - Posts

  • Note to self: Firefox Windows Authentication

    To enable windows authentication on your domain.

    1. Open Firefox

    2. Navigate to the url about:config

    3. Locate the following preference names and put as the value the comma separated values of the address roots.

    network.automatic-ntlm-auth.trusted-uris

    network.negotiate-auth.delegation-uris

    network.negotiate-auth.trusted-uris

    Your value should look something like this: localhost,server1,server2,serverX

  • Joel swings and misses

    You can read his latest post here, go ahead, I'll wait.

    http://www.joelonsoftware.com/items/2006/11/10b.html

    While Joel is absolutely right about his observations on bad metrics, not having any metrics at all is just as sinful. Yes, you can have metrics in development/knowledge worker positions.  Yes, crafting them is more difficult than in a factory situation where you can just count the number of widgets worker x produces.  Yes, if you don't match metrics to organizational goals you can get workers abusing them and actually hurting the company instead of helping (number of lines of code anyone?).

    This is why you need good management in place that can balance the organizational goals of the company with the motivations of developers.  As far as I'm concerned, in a development project you normally have 4 major categories to develop metrics around.  They encompass long term and short term goals:

    Short Term Goals

    Long Term Goals

    Initial Development Cost

    Maintainability

    Timeliness

    Effectiveness

    When you look at this grid, it should make a lot of sense to you as a developer. Your end users want software delivered on time and management wants it delivered at as low as cost as possible. In the long term, you realize that maintenance is costs are about 9:1 over initial development costs so you want the application to be maintainable. Everyone wants the software to be effective, increasing productivity and helping the business.

    The reason I choose this grid is simple. What do you do when cost/time starts over-running?  You cut features (lowering effectiveness) or cut out aggressive logging, strong code reviews, testing time, etc (Maintainability). On the other side, maximizing effectiveness and maintainability takes time and money.

    The point to be gained from this is that every organization has its own weight for which of these metrics are most important on a given project. Is it a temporary bandaid/throwaway project? Then timeliness and cost will trump maintenance and effectiveness. If it's a critical business system that will be used for years to come, the weighting will shift more towards effectiveness and low maintenance costs.

    This is ultimately where you metrics come in for your developer team. You can build metrics for timeliness and cost (hitting deadlines, milestones, accurate estimations) and you can also build metrics for effectiveness and maintenance (bug tracking, change management, end user productivity, etc). Joel is right in that there's no single bullet proof set of metrics out there, because companies have different needs and goals. You can develop metrics that make sense to your organization.

    Just keep in mind that measuring only developers is a recipe for failure. IT in an organization is a supporting process that is designed to increase profitability through maximizing the effectiveness of the principal users at the lowest cost possible. Measuring that effectiveness and ongoing costs is the best way to evaluate whether your IT staff is performing as well as it should be.

  • What I don't see enough of in job ads

    One thing that I don't see enough of in job ads in my opinion is requests for developers with specific domain experience. Quite often I just see generic "junior/senior C# developer with ASP .NET" postings and then when you dig into who the hiring company is they are in a very specific industry like insurance or health care.

    Industry specific domains can gain a lot by hiring developers that already have work experience in them. For one, they're already familiar with the terminology they need to effectively communicate with end users. In addition, in a world where developers have a lot of complaints about the lack of quality of specifications they get for projects, by having domain knowledge they can better assist the principals (end users) in crafting better specifications and being able to sniff out flaws in the specification instead of just blindly following it.

    Finally, if your principals know that you have an understanding of their part of the business and make an effort to understand the facets of their jobs, it builds a trust relationship that is incredibly valuable over the course of your employment.

    I'm not advocating not hiring a talented developer because they don't have domain experience in your niche, but if I get two resumes of relatively equal development skill but one has domain experience, I'm calling that person first!

  • Evaluating a major/minor release (developer metrics)

    Developer metrics are hard. We all know this.  Development is part science, part logic, and part creativity. As such, it is difficult to measure how well your developers are doing their jobs. Personally, on my teams I tend to manage by results. If the releases are on time and of sufficient quality, I'm a pretty happy guy. How do I measure quality, you ask?  Well I'm about to show you how I've done it on teams I'm leading.

    I'm pretty big on developers caring about doing some of their own Q/A.  Even when you have a testing team available, it's no excuse for writing shoddy code and I think developers should be in the habit of writing bullet proof code, regardless of having a testing team or not, because it saves time on the Q/A side, saves developer time by not having to go back and review old code, and helps the developer think about usability and how to keep the application from crashing or not making the interface intuitive enough for the user to use without causing errors to be caught. With this in mind, when the senior developers or Q/A team do their first review, they use the same form that shows up from users after the release. By comparing the results of the Q/A and developer review to the release into the wild I can determine whether the internal review process needs improvement.

    To achieve this, I break all of the functionality in the release into logical blocks.  An example of this in a financial application would be Invoice Management, Payment Facility, Reports, etc. Each section gets their own heading in my master sheet where everyone collects and interprets the bug reports. Bug reports have "point values" which are as follows:

    Critical 15 points: Pretty rare really, a 15 pointer means that a bug crashes the application.  Prevents critical work from being done, and has no workaround. This type of bug is a "show stopper". When this type of bug gets into the wild, you need to have some meetings and accountability to figure out how it got out and how to make sure it never happens again.

    Severe 7 points: Fairly uncommon in a good shop.  This type of bug doesn't crash the application but can corrupt data or make important features unusable. The only thing keeping this from being critical is that a work around is available, but it is time consuming or cumbersome.

    Moderate 3 points: Application runs, with minor errors. This is usually where validation checks are missing or some 'nice to have' features are unavailable. The critical portions of the application are stable and errors do not occur if the software is being "used properly".

    Minor 1 point: Clunky usability, nice to have features not quite working the way the customer desires, graphical/display issues that don't greatly impact the users or only in a small percentage of scenarios.

    The overall quality of the release is determined by the total number of points that are assigned to the incoming bug reports. In general I like to weight the quality target by the complexity and size of the area in question, but my base line is something like this:

    Meets Standards- 24 to 30 points

    Exceeds Standards- 12 to 23 points

    Outstanding- < 12 points

    Obviously these can be moved around however it fits your shop, the skill of the developer, and the size/complexity of the module.  I should also note that a critical error merits an automatic "failure" in the review book even if it's the only bug in the whole module.  Continual review is key to quality software.

     

  • How to handle the 'dreaded salary history' question

    One question that seems to consistently bother people is how they should respond to the "salary history" question in pre-screening and interviews.  I for one, refuse to ask this question, because:

    1. Previous salary has nothing to do with potential salary, and has very little to do with what is fair for the current position.

    2. Frankly, since an employer is rarely up front about posting what their willing to pay for a position, it's none of their business about how much you used to make.

    Regardless, many employers ask anyways, and depending on the situation here is how I respond:

    Pre-screening: This is where an employer asks you to send your salary history and requirements in your cover letter.  The proper response to this is not to lie or exaggerate.  However, just posting numbers can hurt you as well since if you were underpaid or there were extenuating circumstances (like a killer benefits package in lieu of salary) you need to make that clear as well.

    I tend to respond to the history/requirements by giving my title, description of my duties, and my start/end salary for the position.  I also make note of any perks like telecommute days, education, conferences, bonuses received, etc since they all affect what I'm willing to accept as compensation.  For the salary requirements, I try to give a wide range with wiggle room.  For example, if the minimum I would personally accept is $80,000 / yr, I like to say that my expected salary range is $80,000 - $95,000 dependent on the entire benefits package offerred. This basically tells the employer my salary is flexible, and if they throw some intangibles / non monetary perks my way, I'll take less salary.  It also helps to take their job description/title and run it through a site like salary.com and point out what you perceive as the fair range for the position.  Realize that if your high end matches their low end of their willingness to pay, you'll get the lowest they are willing to pay and your highest amount.  In negotiation terms this is "fair" but you did shoot yourself in the foot.  That's why a wide range is a good thing, since it will put your high end past what they would be willing to pay but your low end should be inside their range.  You may be surprised how good an offer can be if you impress in the interview.

    Direct Question in the interview

    This one causes a lot of people to freeze, especially if they are embarassed about their current salary.  You have a couple of options here:

    1. State that your compensation was $X which was fair for the position/duties and that you expect to continue to be paid a competitive/fair compensation for future positions.  If you are leaving your old employer because they don't pay you enough, be up front that you feel that you are more valuable than you are being compensated for.  Never, ever lie.  The only risk to this is that you didn't really answer the question which might annoy the interviewer.

    2. When giving a number you expect to be compensated, try not to settle into a definitive value until the final stage.  As a starting point for the negotiation, give that wide range I talked about above, and say that you would need more information on the whole employment package before you could commit to any number.  This puts the ball back in the employers court without offending them.  If an employer is too forceful about getting number X without giving you the information that makes you comfortable, you probably don't want to work for them anyways.

    Negotiation is more of an art than a science.  It takes courage to negotiate with an employer, especially when you really want or need the job.  However, by being open, honest, and flexible, you can not only impress your employer, but also get what you really want/need.

  • Yet another thing not to do in your interview process

    Having been going through a lot of hiring lately at the company I work for, I have been once again been observing the behavior of candidates when interviewing for tech jobs.  I have posted on this before, but it bears repeating:

    When you are interviewing, and they ask for your salary requirements.  BE HONEST.  If you give a range, and the employer makes you an offer within that range, they expect you not to come back and ask for 10-15% more now that you've "hooked them".

    If you can't give an honest answer about your salary requirements, how can I ever trust you to give honest answers about budgeting and time estimates?

More Posts