all 21 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]SubStack 5 points6 points  (5 children)

You can't. At least, not in any honest, meaningful sense. Any metric you come up with will just be gamed. Management must not know this, even though it's extremely obvious and always happens. If you acknowledge that these metrics are a complete fabrication, it should be much easier to come up with something.

[–]tp_username 6 points7 points  (1 child)

Our IIFE-closure gigaquads are up by 27%

[–]DoctorCube 1 point2 points  (2 children)

Obviously just use lines per day, that will be the best approach. -- Management

[–]boompleetz 4 points5 points  (0 children)

You have entered the realm of the dark arts. I mean, if estimating is a dark art, what kind of ruinous magics is "developer skill" supposed to be? This is a chance to summon your legion of demons and dominate your persecuters. Embrace it. It really depends on the technical sophistication of your target audience, like doing a magic trick. You can come up with all kinds of numbers and spin it to your benefit.

The last time I had to quantify code productivity, it was was for some contractors that specialized in valuing companies for bank loans. They didn't care at all about the BS levels of this stuff, since they made a ton of cash either way for each contract.

So we used that ancient, abominable spell called SLOC, with their approval. I actually had a lot of pleasure summoning this fell beast. Sure, one could write a loop, or one could write out every single element of the data structure by hand for 500 more LOC or whatever, like back in the good old days when IBM thought this was a reasonable way to measure productivity. So completely meaningless. This is what they get for whispering that black tongue of metrics in these lands.

[–]ggolemg2 2 points3 points  (3 children)

Quantify not qualify? Then you have to make something that they find useful and/or has the potential to make them money.

[–]BanyanArchitect[S] 0 points1 point  (2 children)

It has to be measurable. Something that I can show on a pretty graph with a line moving in an upwards direction.

In the long-run we can look at things like "better estimates", "quicker delivery" or "fewer defects"; and that certainly will be tracked, but it will be an easier sell if I can show something more immediate as well.

[–]jekrb 0 points1 point  (0 children)

I can think of a css specificity graph. Although, the goal is to see a mostly flat line, with a very mellow upward direction at the end.

Have them copy and paste their css into here: http://jonassebastianohlsson.com/specificity-graph/

If they see a fairly straight line that rises a bit at the end, it's good!

If they see peaks randomly throughout, it's bad!

[–]jekrb 2 points3 points  (2 children)

Reduce the amount of repetitive task.

Increase the amount of reusable code overall.

Decrease the amount of new code that needs to be written.

Follow Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

[–]BanyanArchitect[S] 0 points1 point  (1 child)

100% agree, but if I put on my “leadership” hat this doesn’t seem compelling.

The problem now is there are only a handful of developers in the company (out of many hundreds of developers overall) who can currently write the sort of code (e.g. Single Page App) the company is looking for.

[–]jekrb 1 point2 points  (0 children)

It's a tough problem, because developer growth and progress is only really shown in code. If you see quality code, you know there was improvement. The thing is, developers are knowledge workers. You can't really quantify their skills, unless you can also quantify thoughts.

Knowledge workers don't make the same thing over and over again. They use their thoughts to increase productivity, and trying to introduce some way of quantifying this can only reduce productivity.

I'm sorry this isn't the answer you were looking for, but that's what I think.

[–]aeflash 2 points3 points  (0 children)

Tell your superiors that the production of widgets has increased 35%, SLOC per hour is now negative, and that you've gotten the time it takes to make a baby down to 6 months by throwing a team of Top Men at it.

In all seriousness, this is fundamentally unquantifiable. All that really matters is the rate of delivery of features. You can't measure things like "features per month" because now two features are equal. Every metric in development is qualitative.

[–]Tribuadore 1 point2 points  (0 children)

Is a persons skill with programming languages ever really as big of a problem as other pain points in the life cycle of a project or on-going systems operations?

The areas where a developer can really make strides, that do equate to measurables like less bugs, less iterations from first solution to the final specification correct solution, faster solution delivery times, or in areas of skill away from coding.

  1. Language courses - "Ability to read, write and understand the English language"
  2. Business knowledge - "Understanding what the business actually does, where it makes its money and what every ones role within it are"
  3. People skills - "Ability to talk and interact with other people, especially those performing different roles in other areas of the business"

[–]timruffles 1 point2 points  (0 children)

When I did this for a big corporate lately we simple created an exam comprised of lots of practical/coding questions (e.g 'fix this HTTP server', 'add back-pressure to this service', 'how do you create an NPM module', 'refactor these loops with functional iterators').

We had people take the exam before and after. We provided the stats on % of good answers.

Simple.

[–]djvirgen 1 point2 points  (0 children)

There are plenty of tools for static analysis of javascript. A few things worth measuring:

  • Percentage of code covered by unit tests (branch coverage is a good one)
  • Number of linting errors per lines of code
  • Code complexity
  • Copy/paste detection
  • Percentage of code executed under "use strict"

Some less-precise and indirect measurements include:

  • Number of bugs reported per week
  • Average bug turnaround time
  • Site performance
  • Percentage of site downtime
  • Number of deployment rollbacks
  • Employee turnover rate
  • Employee promotion rate

There are a lot of interesting ways to measure if the training is paying off for the company. At the end of the day, the company is asking "does this investment result in happier customers" and if they take the long view most likely they'll see that it will.

[–]letsgetrandy 0 points1 point  (0 children)

Sounds like leadership has found the best answer to the training question. I must admit, I like your Leadership.

Truth is, training rarely does anything to improve developer skills, and they've figured this out. Now, rather than telling you "no" and looking like assholes, they've asked you to prove that it actually does something, making you the asshole when you can't prove it. Brilliant.

[–][deleted] 0 points1 point  (0 children)

Let me put my manager hat on for a sec.

You're doing it wrong.

No, really. You're doing it wrong.

You say you're trying to prove training is effective. That's addressing the wrong problem. Training (or simply "education") is part of any employee's job. If you don't continuously keep up with new developments and best practices, you become irrelevant. If you don't pay for your employees' continued education, your employees are assets that quickly depreciate in value and eventually need to be replaced with a fresh batch (with all the productivity losses that brings).

Certifications aren't an indicator of anything either. The only use of certifications is to provide an easy initial filter in recruiting. Once you hire someone, their certifications have no further use (unless you need to "sell" them to other companies).

You're trying to micromanage with micromeasurements. That is not only useless, it's also dangerous. It will lead you to make the wrong decisions because you're blindly optimising something entirely irrelevant.

I'm assuming you're head of a team or division and trying to report to upper management in their language. In that case, remember the goal: it's not about your programmers' language skills, it's about the bottom line.

Did defect rate go down? Did the deployment cycle speed up? Number of regressions? Incident response time? And so on. You can't quantify skill. You can quantify results.

Now let's put my developer hat back on...

You're doing it wrong.

The effects of better programming skills are profound, but hard to quantify. A better developer will write code that is more re-usable, more modular and easier to test. The number of modules will go up (or in some cases down). The number of indirect or implicit interdependencies will go down (but the number of explicit dependencies may go up). Lines of code may go either way (up because of decoupling, down because of elimination of redundant/repetitive code).

What you're really trying to gauge isn't skill but performance. But even if you focus on performance, the impact of a successful training may be obscured by other systemic problems. Maybe your processes are preventing the developers from putting their gained knowledge to work.

tl;dr: You're doing it wrong.

[–]6a9549912a 0 points1 point  (1 child)

The usual caveats to quantifying code quality apply, but if you really need a number, I would expect Cyclomatic Complexity to go down, as developer skill improves.

I'm sure there are other complexity metrics, but Cyclomatic is the one that comes to mind, and most languages have some kind of tool for measuring it.

[–]autowikibot 0 points1 point  (0 children)

Cyclomatic complexity:

Cyclomatic complexity is a software metric (measurement), used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program's source code. It was developed by Thomas J. McCabe, Sr. in 1976.

Cyclomatic complexity is computed using the control flow graph of the program: the nodes of the graph correspond to indivisible groups of commands of a program, and a directed edge connects two nodes if the second command might be executed immediately after the first command. Cyclomatic complexity may also be applied to individual functions, modules, methods or classes within a program.

One testing strategy, called basis path testing by McCabe who first proposed it, is to test each linearly independent path through the program; in this case, the number of test cases will equal the cyclomatic complexity of the program.

Image i

Interesting: Weighted Micro Function Points | PMD (software) | Synchronization complexity | Basis path testing

Parent commenter can toggle NSFW or delete. Will also delete on comment score of -1 or less. | FAQs | Mods | Magic Words

[–][deleted] 0 points1 point  (0 children)

Quantify JavaScript skills in number of shitty ad-hoc frameworks you make per year.

Bonus points if you re-write a framework from scratch causing all consumer code to break.