The Futility of Developer Productivity Metrics 203
snydeq writes "Fatal Exception's Neil McAllister discusses why code analysis and similar metrics provide little insight into what really makes an effective software development team, in the wake of a new scorecard system employed at IBM. 'Code metrics are fine if all you care about is raw code production. But what happens to all that code once it's written? Do you just ship it and move on? Hardly — in fact, many developers spend far more of their time maintaining code than adding to it. Do your metrics take into account time spent refactoring or documenting existing code? Is it even possible to devise metrics for these activities?' McAllister writes. 'Are developers who take time to train and mentor other teams about the latest code changes considered less productive than ones who stay heads-down at their desks and never reach out to their peers? How about teams that take time at the beginning of a project to coordinate with other teams for code reuse, versus those who charge ahead blindly? Can any automated tool measure these kinds of best practices?'"
Refactor... (Score:5, Insightful)
Refactor, refactor, refactor
KISS technology, nothing beats it.
Re:Refactor... (Score:5, Informative)
Application design (have someone think about everything in broad lines, set out a main architecture-model in ADVANCE.)
Iterative design.
A good project manager prioritizing and communicating current development shielding programmer from clients (who during the "waiting time", are fantasizing changes).
In contrast, in debugging and QA, free way between the client and the developer (more efficient and gives more motivation to the dev as to slave for )
Realistic expectations: don't get your devs running around doing "quick" jobs left and right while they're trying to keep a tight schedule.
Keep everybody current: short standup meeting in the morning
Motivate communication; devs tend to get absorbed in their coding-problem (nd prioritize being "productive") but forget to be a team
The right personality on the right segment of a project: developers have their strengths and their weaknesses.
...
Re:Refactor... (Score:5, Interesting)
Refactoring and metrics are often rarely agree. I remember one job I came into, I was given this steaming horrible piece of php (ugh) mess to fix up and add a bunch of features for the client. I took one look at it, and said "I need a good two months to fix this code" and demonstrated a series of horrible vunerabilities and fuckups in the code. Realising the vunerabilities (hint, demonstrating security holes in existing code is a REALLY good way to convince management you need to spend some quality time refatoring it) where just plain dangerous, I got given the go ahead.
A couple of weeks in, the manager called me into the office asking "Shayne, this is very strange. You know we take a metric of how many lines of code per hour are written into account here?". "Yes" I replied, "You also know I think its idiotic". The guy said "Right , well your registering a highly negative score on this. I dont even know if this is working right?".
The reality was this code was written by someone who really didn't "get" databases. A table would be loaded in, then iiterated over, and each pass would issue new sql calls for data, which would then be loaded in and iiterated again. I'd just delete all of the twenty+ pages of code, write a half-page winner of an SQL query, drop it into a mysql stored procedure, and select from it, then spending half a page formatting it and displaying it. It was robust, safe, and fast as hell. I went through the whole code like this turning hundreds of pages of code into tens of pages, all neatly commented, scrubbed of nasties, isolating out the design from the logic, putting models into model classes, views into templates and controllers to glue it all together.
And the end result was every day the code would lose twenty-thirty pages of code and develop 2 or 3 pages of terse, clean, maintainable code.
And as an end result, my metrics where fucked. I tried to argue that they needed to look at more sane metrics, like what was coming out of the CI software, and if they wanted to be really clever, things like complexity metrics and the like.
Ultimately however ,they still wanted the "codes of line per day" metrics because as non technical people it made them feel like they understood what was going on, but ultimately they didn't. My suggestion to them however was "When developing fresh new code, that number should increase, when refactoring code, it should decrease. But only if the coder knows what he's frigging doing."
Writing for reuse is lacking use case (Score:5, Interesting)
more reasons than just reuse. (Score:5, Interesting)
Writing for reuse can be excessive, but there are a number of reasons to move in that direction even if you don't intend to reuse that specific code block:
1) Unit Tests. If you abstract your functionality in a way that allows reuse, it also abstracts in for extremely easy unit testing. And unit testing will save you an incredible amount of effort in code maintenance.
2) Consistency. If you follow the same design pattern for all of your abstractions, all of your developers should be familiar with it. This makes it significantly easier for different developers to step into projects as the hopefully don't have to learn another person's style for abstraction.
3) Replacement and isolation. Need to implement a functional change? If your code is abstracted, like it would be for reuse, the functional change is limited to a single block, which is easily identifiable and if you're doing it right, unit-testable.
4) Just in case. Most of the time abstracted code doesn't get reused, and event when it does get reused it's usually a copy and paste job instead of a reference. Even so, if anyone ever does need the same functionality, it allows them to quickly rip off the exact piece they are looking for as opposed to trying to strip out your programs logic to get the tiny bit they want.
-Rick
Re:more reasons than just reuse. (Score:4, Insightful)
It's easier to just refactor for re-use after the fact than try to design upfront for something that might someday never happen.
Re:more reasons than just reuse. (Score:5, Insightful)
And the "reusable" version very often isn't reusable at all, since the original coder didn't properly envision what other use cases would look like.
Re: (Score:3)
If you don't have a use case for reuse, you shouldn't try to code for it. To many 'interfaces' are single use, see 'servlet' vs. 'http servlet'.
This is an especially good policy if you're a contractor paid by the hour.
It's tricky (Score:5, Insightful)
It almost seems better to measure a bunch of things and use a secret formula to determine productivity.
Re:It's tricky (Score:5, Insightful)
Re:It's tricky (Score:5, Insightful)
Or you could just communicate with your developers, be aware of the work they're doing and judge their performance based on their effective productivity from your perspective. I've heard this called "management" before, but I know that word has been twisted to mean something more sinister as of late.
That won't work, because we laid off all the middle managers years ago. Developers are all exactly the same - we just need to know which ones to slot into the critical path.
Re: (Score:2)
Or you could just communicate with your developers, be aware of the work they're doing and judge their performance based on their effective productivity from your perspective. I've heard this called "management" before, but I know that word has been twisted to mean something more sinister as of late.
That won't work, because we laid off all the middle managers years ago. Developers are all exactly the same - we just need to know which ones to slot into the critical path.
Sounds like you did it right. Most places I've seen laid off the developers, out sourced that work, and added a layer of management to manage the over-seas team.
Re: (Score:2)
The sad thing is to be honest that fear-based management is indeed fundamentally flawed. Next step would be to hire better developers with passion for the job.
Re: (Score:2)
And probably compensate them using things like options. This way the need for things like lay-offs are reduced.
Re: (Score:2)
...and judge their performance based on their effective productivity from your perspective.
Your perspective will taint those assessments and assign different values to whoever you dis/like most. That's why we use metrics: they are quantitative and objective.
Re: (Score:2)
Yes, they do measure something, the problem being "...if interest".
Re:It's tricky (Score:5, Insightful)
Yes, they are objective and quantitative. Managers love that, because being objective excuses them from forming the kind of bias people used to call "leadership", and being quantitative they fit into nice formulas where they can convey no information at all to higher managers that are too insecure to ask what it means.
Just don't expect those quantitative and objective metrics to be correlated with the overall profit of your business.
Re: (Score:2)
It seems you never had to deal with a crappy or unfair boss. Brotip: when you find one, document the crap out of everything. It'll be hard for him not to look like an asshole when you make your point with real data and he ignores it.
Re: (Score:3)
You deserve to be modded up, you do.
The fallacy is that any metric (lines of code, number bugs reports closed, mean time to complete fixes, etc.) or a combination thereof can differentiate between the programmers that should be promoted and those that should be fired. The assumption is that "good programmers" write more lines of code, fix more bugs, make the code run faster, or even write code that optimizes some arbitrary complexity metric. In fact, a "good programmer" does none of these things.
A "good p
Re:It's tricky (Score:5, Insightful)
Yeah, I've come to realize that nobody understands what a manager is supposed to do anymore. Most people's concept is that managers exist to play the part of the PHB, but they don't do anything useful.
More and more, I think no one even understands the value of having a knowledgeable person make difficult decisions based on well thought-out judgments. People want procedures that they can just give to anyone and assume that the outcome will be the same, and then they want metrics that they can use to measure the outcome without knowing anything about the situation.
The proper role of a manager-- aside from particular responsibilities he/she might have on top of this-- is to understand the people working for him and understand his unit's role in the greater context of the company, and then to eliminate obstacles that prevent the people working for him from performing their roles. This might mean protecting the people that work for you from upper management, it might mean recognizing and rewarding good performance, or it might mean all sorts of other things. But to do it right, it takes a lot of work and it takes good judgment.
Re: (Score:2)
Don't you see several complaints around here that managers treat developers as gears in a box or stuff like that? Do you really think that is restricted to tecnicians?
Re:It's tricky (Score:4, Insightful)
Yeah, that's my point. As a manager, it's your job to learn about the people who work for you, to help them understand what they should be working on, to help motivate them, to judge their strengths and weaknesses, and to coordinate/arrange things so that their weaknesses don't keep them from doing their job well. Then you have to weed out people who aren't going to do a good job, and meanwhile reward, foster, and develop the employees who have potential and do good work.
That's a lot of work, but that's the work that a manager is supposed to be doing. Too often they shirk that work and instead treat their employees like "gears in a box". Sometimes it's laziness, but a big part of the problem is that our society/culture doesn't recognize the work/judgement of a good manager as valuable. We instead expect people to be interchangeable, which is a problem.
Re: (Score:3)
That's what modern (from 1911) "scientific" management is all about. That's "best practices". That's ISO 9000, TQM, and all the rest of the alphabet soup. You break the work down into a number of tasks. You measure alternatives and find out the best way to do that task. You document that be
Re: (Score:2)
Yes that's the only effective way, but it doesn't scale to huge numbers and doesn't fit in with the corporate bean counters who like to see graphs and statistics...
Re: (Score:2)
Yes we've tried entirely subjective management, that's why we're trying to find objective criteria. Nothing like a manager that can set pretty much any performance rating he likes, that would surely not be gamed or abused. Combine that with most everybody thinking they're above average software developers and you got the scene set for feeling unjustly passed up. Not to mention the total lack of transparency, ability to compare with other teams or to measure the performance of the managers. Neither side is e
Re:It's tricky (Score:5, Insightful)
Whatever you measure will be gamed. Measure bugs fixed, and you will find people wasting time listing each tiny variation of a bug. Measure lines of code, you will get spaghetti code.
It almost seems better to measure a bunch of things and use a secret formula to determine productivity.
In my book there are only three ways to measure code:
Emphasis on any one and the others suffer. They're goal should be on bug-free code which meets a spec. Writing code is like practicing medicine, every patient is different and has its own demands.
Re: (Score:2)
Perhaps you've got a few pages missing. Usability, functionality, reliability...
Re: (Score:2)
Perhaps you've got a few pages missing. Usability, functionality, reliability...
That's the end product. This is about the actual writing of code. You can apply any or all of those in respect to the end product independently. A coder could write very neat code, fast code, or compact code, which has any kind of interface or performance.
Re: (Score:2)
I think you're missing a few:
Modifiability - This captures the extent to which a programmer correctly anticipates future changes that the code will need. It wouldn't be wise to judge a developer on this track record for just a single program, but with larger sample sizes, it could be useful.
Time-to-develop - If you ignore this metric, you're unable to distinguish between a program that gets written in a day vs. the very same program getting written in a year.
Now, you could argue that these two attributes a
Re: (Score:2)
In my book there are only three ways to measure code:
For speed
For size
For readability
But not for correctness? Security? Robustness? Scalability? Flexibility? I think a test class I took suggested something like 15-20 separate criteria. There's a reason you can write whole books on what "good code" really is. And none of those really cover if your architecture is borked, even if the code in isolation is pretty well done.
Re: (Score:2)
Re:It's tricky (Score:4, Insightful)
Actually, in my book there is only one feature that i wanna to see in every program/module/library. To.Be.Debugable. If i cannot debug it......sorry, but your code is crap.
Unfortunately, if you can't debug it, it's your source code that's crap. Because if you're debugging it, it's yours now . . .
Re: (Score:3)
Whatever you measure will be gamed. Measure bugs fixed, and you will find people wasting time listing each tiny variation of a bug. Measure lines of code, you will get spaghetti code.
It almost seems better to measure a bunch of things and use a secret formula to determine productivity.
A secret formula like, oh I dunno, customer satisfaction (maybe "how many bugs make it to the customer")? Every piece of software is written for a customer (of some sort) so maybe time could be spent actually thinking about how effective the code is AFTER it's used. Speaking as someone who doesn't write much code, but lives and breathes the consequences of good and bad code every day, I can say with confidence that quality would go up if the only coding "practice" was severe punishment of anyone who intro
Re:It's tricky (Score:5, Insightful)
So, you want to reward Wally? He probably doesn't introduce much bugs...
Re: (Score:2)
So, you want to reward Wally? He probably doesn't introduce much bugs...
Neither does he produce. If the PHB weren't so inept he wouldn't be there.
Tell me you've never been in a workplace there didn't have a goldbricker like Wally.
Re: (Score:2)
So, you want to reward Wally? He probably doesn't introduce much bugs...
If his projects are rated as satisfactory by management (this "metric" ALWAYS comes first, no matter what the development style is) then sure. Sometimes the zen of knowing what not to do is more effective than having the energy to code 10,000 lines of something that is buggy and ultimately unneeded.
Re: (Score:2)
Your policy would certainly render quality code... eventually. In the mean time you would be forgetting that nasty issue called "time to market".
Remember: if you are not ashamed of showing your code, you waited too much to promote it.
Re: (Score:3)
Re: (Score:2)
Coming up with a developer value metric is NP hard. The best you can do is use human intuition (AKA, a formula so secret even the user isn't sure what it is) to approximate a reasonable result and then look at metrics to see why the intuitive approximation is/is not valid. It cannot be proceduralized without hand waving.
Note to managers?: You don't WANT this proceduralized or YOUR manager will replace you with a spreadsheet. Watching your former employer tail spin into the water might provide some brief sat
Re: (Score:3)
Whatever you measure will be gamed. Measure bugs fixed, and you will find people wasting time listing each tiny variation of a bug. Measure lines of code, you will get spaghetti code.
Two things:
1. Your point - which is "Tell me how you measure me and I'll tell you how I'll behave" - with the addition that it's so natural/visceral a reaction that one doesn't even need to intend to game the measurement, the behavior of the measured will alter
2. I'm firmly on the opinion that code is value-spent and is not value-created. From this point of view, seems very strange to me for one to use metrics of cost to measure productivity. Efficiency should be measured in how small the number of lines
Re: (Score:2)
No serious developer thinks measu
Re: (Score:2)
Whatever you measure will be gamed. Measure bugs fixed, and you will find people wasting time listing each tiny variation of a bug. Measure lines of code, you will get spaghetti code. It almost seems better to measure a bunch of things and use a secret formula to determine productivity.
The important thing to do before trying to figure out how to measure something is to decide what it is that you want.
Short answers (Score:4, Insightful)
But what happens to all that code once it's written? Do you just ship it and move on? Do your metrics take into account time spent refactoring or documenting existing code? Is it even possible to devise metrics for these activities? Are developers who take time to train and mentor other teams about the latest code changes considered less productive than ones who stay heads-down at their desks and never reach out to their peers? How about teams that take time at the beginning of a project to coordinate with other teams for code reuse, versus those who charge ahead blindly? Can any automated tool measure these kinds of best practices?
It bitrots. Yes. No. Maybe. Probably. Definitely. Possibly.
Re: (Score:2)
Lets see...
Metrics suck in any job (Score:2)
Re: (Score:2)
Re: (Score:2)
I guess you were never assinged that kind of job.
Problem (Score:5, Insightful)
Re: (Score:3)
First, if a system is that good, then managers won't be able to game it to play favorites.
This is the most likely reason I see why no performance metric that works would actually be picked up. The ideal rating system for a corrupt manager is one where everyone is rated poorly, and then you selectively absolve bad performance metrics for anyone you don't want fired.
Of course, one also has to be careful in this situation and not have employees discuss their performance ratings, and especially don't have anyone else in management discuss performance rating absolutions. Think of the horrible legal s
Re: (Score:2)
First, if a system is that good, then managers won't be able to game it to play favorites.
This is the most likely reason I see why no performance metric that works would actually be picked up. The ideal rating system for a corrupt manager is one where everyone is rated poorly, and then ...
An ugly world (I know it from my past experience)... I mean the world in which a manager doesn't compete with other managers (on budgets, prestige, etc) based on successes, but is "chosen to be a manager because we need one and... let's see who's the most notable and less-covered-by-shit on the floor".
In the last case, the chosen person will be the most-full-of-shit-and-willing-to-spread it one... you can imagine how the managed team stinks.
Re: (Score:2)
Re: (Score:2)
Second, writing code for future use is always harder than writing code specific to the problem. .
It's nearly always wrong, too. YAGNI. You Ain't Gonna Need It.
Re: (Score:2)
On a recent project there were two developerss fixing bugs. "A" would fix a bug in 4 hours rewriting 50 lines of code. "B" would fix the a bug in 9 hours rewriting 1 line of code. They let B go because A was more productive. Funny thing is they never ran out of bugs.
Re: (Score:3)
Gollum, is that you?
Re: (Score:3)
ICs will game metrics much more than managers. Good managers rarely have a vested interest in favoring one developer over another except to the extent that one developer contributes more than another to getting reliable systems meeting requirements to the customer.
If you have metrics that "managers can't game", it means that ICs can game them because they
Project leader responsibilities (Score:3, Insightful)
Wouldn't it be the project leader who monitors these on an individual basis? If a coder isn't pulling their weight its up to the project leader to address it up to the point of termination. Above that you have a suit who monitors the project leader's team performance and decides how well the project leader is doing. Of all the places layered management doesn't work, coding is not one of them. It's a challenge to hold a developer accountable because there are so many different approaches to the same problem in coding and a lot have definitive pros and cons.
Pfft (Score:5, Insightful)
Can any automated tool measure these kinds of best practices?
No. The - for the sake of politeness, let's call them "people" - who invested time and effort into devising these schemes have actually built a complete chain of negative productivity by doing so. Remarkable.
Measure the objective not the code (Score:5, Insightful)
Personally I am always happy with the guy who can get things done with one line of code instead of a hundred, but what I really care about is that objective is met and we don't have a host of bugs that require 10 times the cost of the development just to maintain. Its not hard stuff but it does require common sense and a hard nosed attitude both of which can be scarce commodities these days.
Re: (Score:3)
That's really the key to it. Focusing on objectives.
Are outputs matching estimates for time? Are programs being deployed/shipped on schedule? Are bug report rates with in acceptable ranges? etc...
And once you get good at that, start looking for ways to improve on the metrics. Reducing bug counts, getting more accurate estimates, and pushing for shorter (but still reasonable) estimates.
I knew a programmer who once solved a problem that was going to be addressed with a $100,000 inventory management system, wi
Re: (Score:3)
Re: (Score:2)
I can write a bug-free one line perl solution, but what happens when someone needs to maintain it?
If it's in perl? You sacrifice to the voodoo gods whenever you need to maintain it, of course.
Re: (Score:2)
Perl is write-only. You ask someone what the code is supposed to do and rewrite it.
Re: (Score:3)
At a high level, absolutely!
I don't know how many project charters have come across my desk that have the project goal as "To create software that..."
I work at a food company. A multibillion dollar food company. We do food research. We sell food. We do NOT turn a profit writting software. So no project should ever come to me with a goal of creating software.
You are correct in that the only metric that matters to the business is the profit. But in order to determine individual contribution, you can't just lo
Re:Measure the objective not the code (Score:5, Insightful)
Personally I am always happy with the guy who can get things done with one line of code instead of a hundred, but what I really care about is that objective is met and we don't have a host of bugs that require 10 times the cost of the development just to maintain. Its not hard stuff but it does require common sense and a hard nosed attitude both of which can be scarce commodities these days.
I am also REALLY happy to have "that guy" that has absolutely shit productivity, but somehow manages to pick up on every time a "solution" is proposed by the rest of the team to a problem that doesn't exist or doesn't matter, and stops THEM from being really efficient at doing the wrong thing.
I'm also really happy to have "that girl" that doesn't seem to really be doing anything, but take her out of the team and everyone else starts floundering because she's actually constantly helping them be a lot more productive.
"Meeting the objective" is actually potentially just as bad as any other metric, because it depends on how you define the objective, and meeting it. What the customer asked? What the customer wanted? Or what the customer actually needed?
Re:Measure the objective not the code (Score:4, Informative)
Personally I am always happy with the guy who can get things done with one line of code instead of a hundred, but what I really care about is that objective is met and we don't have a host of bugs that require 10 times the cost of the development just to maintain. Its not hard stuff but it does require common sense and a hard nosed attitude both of which can be scarce commodities these days.
I am also REALLY happy to have "that guy" that has absolutely shit productivity, but somehow manages to pick up on every time a "solution" is proposed by the rest of the team to a problem that doesn't exist or doesn't matter, and stops THEM from being really efficient at doing the wrong thing.
I'm also really happy to have "that girl" that doesn't seem to really be doing anything, but take her out of the team and everyone else starts floundering because she's actually constantly helping them be a lot more productive.
"Meeting the objective" is actually potentially just as bad as any other metric, because it depends on how you define the objective, and meeting it. What the customer asked? What the customer wanted? Or what the customer actually needed?
That guy and that girl are generally called project/team leaders. Don't fret, You raised an important issue. The guy you don't want on the team is the one that comes up with ridiculous edge cases and is needlessly obtuse. Like someone who invents coders that are doing the work of managers and senior managers then complains a measurement tool doesn't capture their contribution, or goes into a recursive loop trying to figure out what the objective should be.
Developers will cook the books anyway (Score:3, Insightful)
If they know their productivity is being measured, it becomes a contest to see who can cook the books the best anyway.
Re: (Score:3)
If they know their productivity is being measured, it becomes a contest to see who can cook the books the best anyway.
Yes. And this would be a Good Thing if the metrics actually measured the right thing. The problem is, the metrics represent something that isn't actually what you want, so developers are motivated to do something that isn't actually what you want.
So if you are going to be using a metric at all, the first questions you should ask yourself is what the metric measures, and if that is actually what you care about. For example, you could measure how many lines of code people produce, and reward people based on t
We need metric metrics (Score:5, Funny)
metrics provide little insight
If only we had some kind of.... metric metric.
Re: (Score:2)
metrics provide little insight
If only we had some kind of.... metric metric.
Sounds like ISO9000.
Re: (Score:2)
By analogy with metadata - data about data - "metametrics" was what sprang to my mind. And like most things that do after I've had a few jars, it a) already exists [mac.com] and b) is far too shit to deserve such a goshdarn clever name.
What about non-coding time? (Score:3)
What about all the time you spend not coding: meetings, documentation, training users on how to use the system, working out the design before you start coding, answering emails, sending status reports, filling out time sheets, coordinating work with other developers, coordinating things with others in IT so your program will have a server to run from, being the go-between for the IT server team and the customer when the server goes down, creating database layouts and writing SQL?
Re: (Score:2)
Surely writing SQL qualifies as coding.
Re: (Score:3)
Not according to some of the developers around here. Of course, these are the types that put "select * from table" into their Java code, then try to filter data in the application layer. Then they whine that their application is slow.
Seriously.
Re: (Score:3)
Well, that's just ignorant, then.
I write SQL most of the day, and in my opinion, it's more difficult to do well than traditional programming. If I'm writing a webapp somewhere, I only have to keep the individual logic i'm working on in my head - with SQL, I may have to know how a single dataset is processed over a half dozen steps to get the result I want.
Re: (Score:2)
Design is about as clearly non-CVA as it comes. Implementation is CVA. This is pretty much the whole philosophy behind agile.
lazy management (Score:5, Insightful)
Which is more fun, getting a better handle on what Dave is doing, or researching fancy new software tools that might get you all sorts of praise from metric-craving executives?
Dave's job, which was once about creating a quality product, now shifts to merely satisfying the metrics.
Re: (Score:2)
So even if Mr. Manager has good intentions, he really is prevented by other duties from doing his job to the fullest extent. It sucks, but I wouldn't feel right
Re: (Score:2)
What applies to Dave applies to Bill, Jane, etc just as much. Now they're all more interested in looking good on the metric of the day than on producing a decent product. Any who make the mistake of focusing on the product will be eliminated systematically by the metric.
Repeatability (Score:4, Insightful)
Why are metrics so damn important (Score:5, Insightful)
Re: (Score:2)
... Do authors get judged by the number of pages they write in a day, no they get paid by the success or failure of the book. You can't judge by the number of lines of code, bugs per line ratio or anything like that, because it is all subjective and has little to no bearing on the end product.
Many successful novels, started out as magazine serials, which were paid by the word. Usually, though, they are edited before they are put into book form.
I've seen a bunch of movies, where I thought, "This would be a great movie, if they just cut half of it, then sped the result up by 1.5x"
I've often thought that coders should be paid by how *little* they write, as long as it does the job.
Hmm (Score:3)
Not everything that matters can be measured; not everything that can be measured matters.
-- Einstein (or maybe it was Franklin)
This is BS (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Before the cabinet was built there was a request for the cabinet that stated how the cabinet should be built including things such as appearance, function, and durability.
I am not a coder, but I would think that the only metric that matters is does this product meet the specifications that it was intended to comply to?
If you need metrics to know who your stars are ... (Score:3)
... you are already doomed. You've gone so far down the wrong path there's no hope of recovery.
Re: (Score:2)
Re: (Score:3)
Yeah, that's an upper management failure in my book. They should be connected well enough to know what is going on at least two levels down, not one (enabling them to check the calibration of their direct reports). If that's not possible, the branching factor is probably too high.
How much time is used on this tps report like BS? (Score:2)
This sounds like some PHB how only knows how to be manger wanting numbers and having no idea about how developing works.
Seriously (Score:2)
Code metrics are fine if all you care about is raw code production. But what happens to all that code once it's written?
Seriously, does the author has to ask? Or anyone that does software development for that matter? Sadly, apparently they have to ask.
You never get to a point where you can say "code once it's written". Code changes after deployment, there are new releases, bug fixes, shit like that which crops up in real life.
So assuming you are gathering metrics the smart way and in a manner that your particular project and organization, then, you simply keep gathering metrics as you re-factor your code, add new feature
Measure Effectiveness, not Productivity (Score:4, Interesting)
I think the idea of "productivity" is a hold-over of the Industrial Revolution that does not pertain to many of today's jobs; jobs where the unit of work is hard to define, and ultimately irrelevant. Are you telling me you pick your doctor by how many patients he can see in a day? Probably quite the opposite!
In terms of software development, I find that the *effectiveness* of a developer is more important, where effectiveness considers the following (not an exhaustive list):
- Appropriateness of solution
- Thoroughness of implementation (logging, exception handling, graceful failure, input validation, etc.)
- Well-written, parsimonious code that is easy to read and descriptive of what it does
- Works right the first time, no kickbacks from QA or end user
Give me someone who is effective but slow over someone who craps out junk quickly any day of the week and twice on Sunday! In the end, I don't care about productivity metrics, I care that the end users get a useful piece of software that does what they need with a minimum of headaches.
Start looking at the big picture and rely on peers (Score:2)
Instead of trying to micro manage your devs ("Oh, Frank, you created 10 lines less than Bob, you slacker!"), focus on the project instead. Check whether your teams meet their deadlines. Pit the teams against each other. And rely on peer pressure within teams to keep the productivity up and slackers from slacking. Are you judging your beancounters by the amount of bookkeeping lines they fill out per day? Do you gauge the productivity of your project managers by the amount of meetings they go to? No, you meas
the most important things can't be measured (Score:3)
Stop listening to the MBA and metrics nutjobs. Don't try to manage your people like the machines they operate.
Re: (Score:2)
Re: (Score:2)
No doubt you can measure quality of code or the competency of a programmer. But can you stablish an objective metric with fast results (remember, corportations are "this quarter" oriented) that gets it right?
Re:Coding is an art (Score:4, Insightful)
Re: (Score:2)
Engineering is the union of applied science, business and art.
Coding is just engineering. Most coders are bad engineers though. Still an immature field.
Re: (Score:2)
Yea, tell that to my art teacher that failed me.
It was the only class where I did actually do the work.
Re: (Score:2)