Slashdot Mirror
Slashdot Asks: How Do You Know a Developer is Doing a Good Job?
An anonymous reader writes: One of the easiest ways to evaluate a developer is keeping a tab on the amount of value they provide to a business. But the problem with this approach is that the nature of software development does not make it easy to measure the value a single developer brings. Some managers are aware of this, and they look at the number of lines of code a developer has written. The fewer, the better, many believe. I recently came across this in a blog post, "If you paid your developers per line of code, you would reward the inefficient developers. An analogy to this is writing essays, novels, blog posts, etc. Would you judge a writer solely on the number of words written? Probably not. There are a minimum number of words needed to get a complex point across, but those points get lost when a writer clutters their work with useless sentences. So the lines of code metric doesn't work. The notion of a quantifiable metric for evaluating developers is still attractive though. Some may argue that creating many code branches is the mark of a great developer. Yet I once worked with a developer who would create code branches to hide the fact that he wasn't very productive." Good point. But then, what other options do we have?
Judge them on bugs. If they are constantly trying to fix their code then you have a metric on when to seek a better one.
_ _ _ Go for the eyes Boo! GO FOR THE EYES!
Here's a clue:
It's NOT the guy who always gets called in at 3 AM to fix something that HE wrote.
He's NOT your "hero". He'e the moron you need to fire.
When he can keep deadlines within reason and deliver something that runs pretty well based on the specifications. Anything else is fluff.
There are a few ways. SCRUM/Kanban is an effective way to inundate your programmers with meetings and conference calls asking and tracking minute status updates for every commit or stash you can find. its perfect to ensure that changes to the codebase are governed by your personal fears and demons, not the best interests of users, because you too have to be fully invested in standing up in a conference room every morning and listening to a dozen or more different and often pedantic events transpiring in the cubes of people that know far more about them than you. Agile can be used to boost your title and sometimes salary while at the same time demeaning a team of programmers into thinking theyve signed on to some late chapter of Orwells 1984.
Or you can set goals, track them in a ticket system, and evaluate results based on what your users and teesters see and want. Call people in for meetings when there are big events, but otherwise keep your hand off the phone and use something called trust to ensure your programmers are "doing a good job" once the code is ready.
Good people go to bed earlier.
Jokes aside I'd argue there's actually a more fundamental question that stems from the question being asked.
Why aren't your senior/lead developers weeding this people out? That's their job, they'll spot bad developers by working with them based on a number of metrics from readability of code, number of bugs, performance, amount of useful code produced and so on, not just a single metric.
If your senior/lead developers aren't doing this then you've probably not paid enough, you've probably paid too little and ended up putting a low to mid level developer in what you've called a senior role.
If it's your senior/lead you're concerned about then you should just be able to go on track record - do they have a history of delivering high quality software in a reasonable timeframe? Are you confused about what a reasonable timeframe is? Look at other software on the market, how long does it take Microsoft to release a new version of Word? Adobe a new version of Acrobat? and so on. There is plenty of evidence out there as to how long it takes a succesful company to release a piece of software - find something with a similar scale to what you're doing and see how rapidly they release. If you're paying competitively against those companies, and your developer isn't delivering as rapidly then they're underperforming, if you're not paying as much as they are then don't expect them to be able to produce as much quality in as little time. If they're overperforming in quality and delivery speed and you're paying them less than the big boys then thank yourself that you've found a fucking star and spend a lot of time thanking them for giving you more for less money and do everything you can to make them happy and keep them, because if they leave, you might not be so lucky next time.
So this comes down to actually being a good manager. It's hard, and lots of people do it wrong / pretend they are good but aren't / etc. Ask yourself what you really want in a developer and then manage your team to that standard understanding that each member has their own strengths and weaknesses. Something like:
- Elegant and easily understood code
- Good at estimating and meeting deadlines
- Productive and participative in scrums
- Thoughtful and supportive of alternative views
- Etc.
Coders are people. They are a unique breed of people, sure, but if you want to gauge their worth, then you manage and treat them like people. Not monkeys at a typewriter. A small group of talented and creative coders can save a company millions in just a day of work. I've seen it. You need to appreciate their value by paying attention, not coming up with some arbitrary metric that makes your job easier.
I am not interested in articles about life extension advancements.
- Bill Gates
-Dave
There is plenty of evidence out there as to how long it takes a succesful company to release a piece of software - find something with a similar scale to what you're doing and see how rapidly they release.
Like all the other measures, it's not that simple. Is it code that the development team wrote themselves or did they inherit it? If they inherited it, how well was it originally designed, coded, and documented? Is the project using the best tools for the job or has it been forced to work around suboptimal tools for various reasons? Does the project have a solid design/direction or is the whole thing made up as it goes along? Are there defined use cases the developers can work against? Is there a clear customer stake that the developer can work with to better understand the needs and adjust the code accordingly? Do they keep getting distracted from the deliverable by support or tasks that should be outside their scope?
There are many reasons a good developer may be "under performing" through no fault of their own. Measures like lines of code, bugs, delivery time, etc.. rarely take that into account.
No, stupid. Pay enough to get sufficiently competent people from the marketplace in the first place. People with a track record of leadership in software development sufficient to command good pay because they do a good job. Many companies fail at this, pay below competitive levels and just fill their senior jobs with junior/mid-level staff then wonder why their software development department isn't competitive.
Of course throwing money at someone who is incompetent wont magically make them competent, why would anyone ever think that would be the case?
From what I have seen in the industry, it is very simple: Either there are no senior developers that deserve the name, or they are not asked on anything that is "management".
I fully agree with you. The job to evaluate technological skills must always be done by a chief engineer (or equivalent). If you do not have a chief engineer, then you cannot evaluate the technological skills of people, and that is it. Other engineering disciplines do understand this. But "coders" are often not even viewed as engineers these days, which is just plain stupid and just another facet of the same problem.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
"Senior" in most companies literally means whoever worked there longest.
It says nothing about abilities or quality.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
"They constantly say "I'm (almost) done, just need to test". A good developer will test as they go along. Once the coding is done there should be very little additional testing that needs to be done. You reasonably certain that everything will work by the time coding is completed."
I don't know what you do for a living, but I'm a developer, and I frequently say that. Of course I test tasks as I complete them, but what you say implies integration is trivial and requires little to no testing. This is simply untrue for anything but the most simple of projects. Integration testing is often one of the most difficult portions. Going in to integration level testing I have a pretty good idea of how rough it's going to be, but I never know for sure and sometimes what I thought was going to be simple turns out to be a bloody nightmare. And in almost all of these cases, the feature as developed and tested in isolation works flawlessly. But when integrated into the larger system will introduce some previously unexpected abnormality. If not for NDAs I'd cite some specific examples I dealt with last week. I can say one that I ran in to where on the production machine, things didn't perform the same way as on my dev machine. And yes, developing on production hardware would be ideal, but sometimes it just can't happen.
Also, late for work, early to leave and sleeping on the job, I've never had problems with. Some of the best devs I've worked with didn't get in till noon and would take off at 4. What you didn't see was when they came back at 8 or were working from home, or coming in on weekends. Also, if they get something done in 6 hours that would have taken me 12, as long as quality is there, what do I care? They get things done in a reasonable amount of time and to a reasonable quality, I don't care if they only work 1 hour a week.
Ah yes, 4GL... where you eliminate the easiest part of what a developer does (write code), make the most difficult part (specifying what it should do) harder and make it the responsibility of people who can't even grasp the easy part.
And as soon as you want to do something the 4GL language isn't designed for, your only option is porting it to a 3GL (or lower-level) language.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
That's precisely why you need to find a similar case, or ideally, many similar cases.
How are you supposed to know the intricate details of another company's codebase and development process to be able to judge if they are really similar or not? You can only guess and hanging someone's job on a guess is pretty crappy.
In terms of distractions, if you're in a lead development role then it's your responsibility to raise at the highest levels of management and evidence the fact that your team just isn't being given sufficient time to work on actually writing software and documenting interruptions as evidence isn't difficult. Similarly taking a poor specification up the chain and explaining why it's poor also isn't difficult - explaining where there are deficiencies in a specification is fairly easy to do if they are present. These are all traits in a good lead, and any lead not able to do these things is precisely the sort of junior to mid-level developed wedged into a senior role that I talked about - a good lead has to know how to get things done in the business world as much as they know development.
And how many times have we done just that and heard "we hear you, but ..."? I've spent my career jumping into shit projects and making them maintainable and extendable. Luckily I've mostly had managers that understood what I did for them and trusted me, but I've had a few that haven't and those jobs are miserable because they try to grade me like you suggest and it's unrealistic. I fix code and I make users happy (because I fix the code and simplify their interactions), but that all costs time and pain and management typically just sees "not much movement".
But most of these issues aren't about measuring developer competence, they're about tackling fundamental problems within a business - that's a separate issue.
It's not a separate issue as it directly impacts how efficient a developer can be. Until those issues are addressed (and they never will be) you can't fairly judge anyone on metrics impacted by those issues.
If you can't tackle those then you're fucked as a business regardless of how good or bad your developers are.
Welcome to the world of a real job working for a real company. Most companies have fucked up processes and policies.
I don't think that place would have been functional with any methodology.
Though I have noticed that teams where the SCRUM master is a project manager they tend to be filled with useless endless meetings.
When the SCRUM master has a real job like writing code, the meetings are pretty concise.
I was at a non-methodology place that was like yours. The manager has 20 direct reports, and never talked to anyone except in the occasional weekly meeting. Each person would go on a 5 minute spiel as the manager asked a ton of questions while everyone else sat around twiddling their thumbs. I would make sure to say as little as possible because I knew nobody else in the room gave a shit about what I was working on most of the time.
The weekly meeting too so long we started having it once every other week, then once a month. Which of course meant each person had more and more to report.
I'm a good cook. I'm a fantastic eater. - Steven Brust
Sigh. This is how great developers see bad managers and avoid them.
1. Defect Rate: The more experience, quality developers are given the more complex tasks generally and actually generate a large amount of defects. Defects are also a case of amount of humanity involved in the area developed. More defects in HMI code because of more eyes. Defects are also based on testing, so if a code is rarely used or testing only cursory, defects are not found. This information can be found and highlighted in the FREE Debugging course from Andreas Zeller at udacity.com (Nope not shilling but found this course very informational).
2. Just because someone is an experienced developer does not mean they can estimate a job. One of the hardest things that developers are asked to do is SWAG a job. The numbers are generally way underestimated due to our human overestimation of time in future (look it up, I dont have the time. heh). These times get filtered back through contracts and customers and come back even less time. Exactly how many projects have you been on that actually made time/budget exactly as estimated? There is a reason developers work a lot of unpaid overtime.
3. Testing as you go along. Are you stating all developers should do Test Driven Development? Okay, then provide hard, frozen requirements up front. Oh wait, you are AGILE so that cant happen for larger items. Oh.. there we go.. inch pebbles.. I think the best estimate is down to 3-4 hour chunks of time. Okay, so I established that ETC is hard enough, now do it constantly in a changing requirements weekly. Wait, Im almost done here.. give me some time to finish... I thought I would be done before lunch.. but Im not done yet. Management responsibility is to manage the developer to help them and the management to make realistic time.. so "almost done" is not done.
- Is it Soup? That is what I heard from my bosses when I first started in the game. Is it Soup? 20 minutes from me being first assigned a task. No real concept of the entire task. You learn to answer "Shortly" and they stop asking. 2 weeks if they ask me now.. no matter what it is. They learned to give me real time to get a much better ETC out. One of my early ETC was "3 months" from spending 2 hours on the ETC. When given 3 days, the ETC was a year and it took... a year!
4. Development and constant need to have stuff explained. Verify they understand the first time. Language barriers exist constantly. Yes, this is a decent enough metric but if they can follow computer language logic, they are not dumb. I am at a place where it is expected for new developers to work 18-24 months before becomes productive. Still.. this is one that I can see if you want to cycle engineers to get better ones and do not have a large learning curve for your products.
5. This is general employee issue. Not specific to developers.
KLOC metrics and defect metrics are shown to have real faults when using them to judge a developer.
Things that managers (or leads, including myself) do that slow down/hurt development:
1. Not listen. Most of the time, as a lead, we know it all BUT we are NOT listening and not HEARING why some task will not come close to what we think will happen in the project.
2. Micro Manage. Start the task with a known stopping date and get buy in. Dont go every to them 4 times a day, put them in a fishbowl, look at your watch if they take a longer lunch or go to a doctor, and tell others you dont trust developers as they need to be lorded over (yes, had a manager do this). The developer will come to you when they realize they have issues or need help. You help them by resources, processes, talking, etc but If you then look at them like they are insane.. you will no longer have that trust and you will have way more "Surprises". Here is a metric: If a developer never needs help and has surprises on time and issues... if you are not micro managing them, this issue lies in the developer and they need help on personal time management s
I can program myself out of a Hello World Contest!!
And for those of us without your patience, watching the junior guys struggle is so painful. I know, I know. They need to learn but can't they learn a little faster? Please.
I always tell more junior people that they need to *some* research when they have a problem, but that this is work not school and if they can't find a solution in a reasonable amount of time (15-30 min), they need to ask someone for assistance. I'll either help point the way, explain and/or provide an example. In addition, I don't mind getting 50 questions, but they need to be 50 *different* questions.
Things to remember: (a) Time is valuable, but my time is more valuable than yours :-) (b) Patience is not an unlimited resource.
It must have been something you assimilated. . . .