Tag: comparisons

  • Hours, Effort, Completed Tasks and Measuring Developer Value

    Hours, Effort, Completed Tasks and Measuring Developer Value

    It may be the line of business I am in (consulting), but it seems like finding how to evaluate developers is a common challenge.  There are discussions and even arguments about developer value that impact employees, projects, and even companies.  Although I do not have some divine insight to provide, I do have some food for thought as you consider this obstacle.

    Developer Value Varies Geometrically

    The most significant challenge in finding the correct mix of skills and adequate compensation is that the growth from low to high developers is not a straight line.  The increase in productivity is geometric.  Thus, a senior developer is often more productive than junior developers splitting the same compensation.  That means that pure math is not going to help you compare resources.

    We see this in the way off-shore teams produce when compared to local resources.  Not all off-shore teams are lower skilled than local talent.  However, they often are.  The whole model of off-shore is based on quantity over quality so you can get a team of developers for the price of a local one.  The odds would imply that this will always be a better approach (more is better).  Unfortunately, that is not the case.  Those lower cost resources are not going to bring as much value to the table.  There are a few cases where this will work out better, but those are rare.

    Solving Problems Is The Key

    The thing to focus on when evaluating software developers is that they are problem-solvers more than skilled technicians.  The ability to write more code in less time has no value if the code does not provide needed solutions.  I often use the terms coder and developer to distinguish between these skills.

    Therefore, the real developer value is not in their ability to write code or even understand a language.  The value comes from their ability to analyze and solve problems.  This is why coding tests are rarely useful in evaluating prospects.  On the other hand, interviews and long-form discussions will go further in helping you choose the best candidate for your team.

    Hours or Tasks?

    Now that we have looked at what gives the most developer value, it is time to consider compensation and bonuses.  This gets far more tricky.  Although you can argue on both sides of this (hours spent or tasks completed), it turns out that both are flawed.  Sometimes it takes many hours to slug through a solution,  at other times your best developer can crank out a solution in a tenth of the time of lesser skilled ones.

    I hate to say it, but I find that honesty on both sides is the best answer.  This also requires patience and understanding.  Even the best developers will occasionally lose hours of time on a minor issue or misconfiguration.  If you want to punish them for those “lost” hours, then you need to provide a bonus when they stumble across a solution in far less time than expected.

    Ok, Hours Works Best

    When you balance out the good and bad luck that impacts developers (and dealing with the mistakes of others) then it seems that hourly pay works best.  That assumes these things balance out.  The good news is that it reduces the level of scrutiny needed.  Hours are easy to track.

    When you want to compare developers, you will need to track progress over multiple challenges or projects.  If you have a small number of comparison points, then it is easier to make a mistake.  This is no different from any other form of evaluation.  You need to focus on their overall body of work.  This includes customer reviews and references.

    If you only check a reference or two (or see only one or two reviews) then the odds of making a mistake increase considerably.  Take your time and gather enough information to accurately assign a value to your developers.  It will help you build and retain the best team.

  • Configuration Vs. Coding – Modern Software Systems

    Configuration Vs. Coding – Modern Software Systems

    Over the years that I have been in the software development profession, I have watched solutions evolve dramatically.  The progress has gone from code to libraries to frameworks and now configurable systems.  However, there are trade-offs to consider when you look at a configurable system instead of one that allows for customization with code.  This is becoming a more common dilemma for businesses.  Thus, it is good to look at the pros and cons of each approach.  Here are some points to consider when measuring configuration vs. coding.

    The Power of Configuration

    Let’s start with the positives a configurable system brings to the table.  Configurable customization is where software of all sorts is heading.  Part of it is likely due to changing interfaces and keyboards becoming relics of the past.  However, there is far more value included.  I have found that the most significant value companies place in these systems is the lower cost of maintenance.  A configurable system constrains how changes are made.  Thus, it is easier to test those options thoroughly.  You also are less likely to have typo related issues.  The inputs can be highly constrained and validated.  For example, a drop-down selection item is not susceptible to a typo.

    There is also a lower technical threshold for configurable systems.  Administrators can often learn all they need to know with a few days of training.  As opposed to years required to build stable and scalable code.  This approach has the side effect of reducing the number of points of failure in many cases.  Less information has to be communicated across departments.  Thus, for example, a marketing employee can make changes to the system.  The alternative is to relate them to a developer to code.  Business users can focus on their business rather than how to communicate to the technical staff.

    Coding is Here to Stay

    With all that configurable systems have to offer, there is still a level of control given up.  The limits that make these systems so powerful also keep them from doing precisely what is needed.  A customer is also at the mercy of the vendor for these systems.  A required feature may be a long time coming, and critical functions may disappear.  These may be worst-case scenarios, but that is enough for many to choose a custom coded solution.

    Every business is different, and coding allows for software to be built to precise specifications.  Your priorities can be crafted into the software.  Then, it can change as your business needs change.  There is also ownership of the product to consider.  A custom solution is owned by the creator and not a vendor.  You can change it as needed and do not need to worry about the future stability of the vendor.  Better yet, any problems that occur are your own.  There is one place to look for solutions.   Thus, no time wasted on support calls to get a response to meet your schedule.

    Configuration vs. Coding – The Bottom Line

    I could list dozens more pros and cons for each side.  However, the decision is pretty simple.  A configurable system is the better solution in most cases.  One has to recognize that the 80-20 rule holds for these systems.  Therefore, configuration is an excellent choice.  The configurable piece of the solutions often allows a company to get 90-95+ percent of its needs met adequately while avoiding the costs and headaches of custom software.  It also allows you to buy the experience of the teams that created the software.  They used their expertise to solve common problems.  This may not get you to one hundred percent coverage, but it will provide tested solutions for eighty-plus.

    Finally, do not underestimate the value of fixed cost solutions.  Your vendor is providing you a solution that is complete.  There are no concerns of improper estimates, scope creep, or schedule overruns.  Therefore, the focus is on using the solution, not creating one.