To me efficiency means the ratio of output resources to input resources, and the problem as you noted is how best to measure the input and output. You've come up with several specific ones that apply to IT development, but a problem of bias arises when measures are taken individually. One solution to this is to estimate economic efficiency. In my line of work we often use a concept known as generalized cost in which we estimate and/or calculate dollar values for just about anything you can imagine - it's the only way to do some of the modelling and simulation in transportation planning (for interest, the other most common generalized cost unit is time, but it is often much more difficult for people to convert things into units of time). Though I hasten to add that it is just as simplistic a view as any other, it has the benefit of combining normally disparate measures.

In your examples then, one could use generalized cost to calculate the values of different approaches to a specific project (subject of course to one's ability to reliably estimate things like development time and maintenance costs) and come up with different ways to satisfy the same set of project goals. In the extreme it could end up with a choice between hand-coded assembler running on a 80386 (high development and maintenance cost but low CPU and RAM cost) and perhaps Perl on a present-day off-the-shelf system. While the choice may be a no-brainer to most readers, it still may be an interesting exercise and could reveal something surprising about the project specifications, and how they may be altered, remembering that efficiency depends on both the input and output, and it may be a mistake to fix either side of the ratio too early.

After the best analysis however, one is still dealing with the real world, where a project honestly intended to be a temporary fix ends up in use for years. For this reason, any planning exercise based solely on calulating efficiency and effectiveness will be doomed to fail, unless a good effort is expended on examining the sensitivity of each assumption to unexpected changes ("what happens to our maintenance cost assumption if ...", or "what if our compiler vendor ..."). The project may still fail, but at least there will be a better chance of anticipating the failure and mitigating the losses.

--
I'd like to be able to assign to an luser

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.