Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

Following on from this question, I wondered if folk might be able to suggest some samples of what might be considered a "good" objective in a periodic review cycle for a programmer?

Let's define SMART from the most popular definitions in the Wikipedia entry:

  • Specific
  • Measurable
  • Attainable
  • Relevant
  • Time-bound
share|improve this question

marked as duplicate by gnat, thorsten müller, Martijn Pieters, GlenH7, Kilian Foth Apr 13 '13 at 18:20

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

4 Answers 4

I have come to realize that SMART goals are best used when people have a deficiency they need to correct, and are not so good for times you want people to grow or go from good to great. If someone is not doing timesheets, for example, and this is hurting the company because you sometimes have to delay invoicing, you could have a smart goal like "over the next 6 weeks, at least 5 weeks' timesheets will be completed by 10am of the next Monday morning." 6 weeks later you have a true or false; the developer made it or missed it. Either the new habit is in place or you get to decide if you want to still employ someone who doesn't mind delaying your invoicing. Works for people who have other bad habits too: "over the next two weeks, at least 75% of your checkins will have a checkin comment that follows the checkin guidelines (link to internal document)." Again you have a nice crisp did/didn't at the end of that short time.

Where I find these constructs less helpful is when the timeframe lengthens, when the achievement you want is fuzzy (learn a language, be more helpful), or when it's ok if the goal is not achieved (you may value certifications, but if someone failed their test you probably wouldn't take disciplinary action.) Suddenly all the benefits of the smart goal fall away. Don't try to use them for anything other than corrective actions, and they're easy to write, they help the developer get up to the expected level, and they're easy to test for when the time's up. Having trouble writing them means they're not the right tool for this goal.

share|improve this answer
3  
+1 Excellent answer and one I'll share with some of the higher ups in management! –  Walter Dec 22 '10 at 13:33
    
Having worked under a fuzzy SMART scheme for quite some time I can verify that having vague ones are just pointless. –  Kevin D Dec 22 '10 at 14:04
1  
+1, this is an extremely insightful answer. I hadn't even thought about SMART goals this way but it's totally true. Now I feel like I have a better understanding of why it's so hard for me to establish SMART goals when I don't have a clear idea of something that needs to be "fixed." –  nlawalker Apr 8 '11 at 2:54
2  
I really like this answer, but I think it might be more appropriate as a response to the "original" question than this question. –  Pops Sep 11 '12 at 9:52

Since I'm about to go into an objective-setting conversation with my boss, I thought I'd add a few examples that are similar to some I'm considering suggesting for myself:

  • Increase test coverage for code in Project X to at least 95% by March 31st.
  • Complete and distribute first draft of Project Y Architecture document by April 30th
  • Collect review comments for architecture document, update where necessary and issue v1.-0 of document by June 30th

I expect additional work to materialise within the times I've specified (it always has before, after all) and that work may have an effect on the "Timely" aspect in particular. That shouldn't be a problem: objectives should be reviewed regularly to make sure that they continue to meet the "Achievable" criterion. I'll need to make sure that I keep my manager in the loop on this - nobody likes unpleasant year-end surprises...

share|improve this answer

If you sell software or a product with software in it...

Increase sales n%.

Really.

If the software didn't work, you would not sell much of it.

If the software worked REALLY RALLY WELL , you would sell lots.

(This will have the software guys watching the sales guys like hawks making sure they don't blow their performance bonus.)

If you software is an in-house system:

cut cost of business n%.

If the new software systems takes 10x as long it costs the company money. If the new system is fast and prevents errors, the company saves money.

This approach seems like it applies to sales guys or maybe the VP of business change process, but really, the software developers are the front line for both kinds of process.

My underlying idea here is to try to explicitly align the employees reward structure with teh best possible outcome for the company.

share|improve this answer
7  
This is easy to measure, but very hard to tie to the developers' actual work (as there ar so many other factors in play). And in most of the cases, it can only be realistic as a long term objective, which makes it even fuzzier. –  Péter Török Apr 8 '11 at 7:27

Implementation of X module within
+-10% of the estimated time (40 hours) within 5% range of 10 defects/KLOC

It is specific - as long as "Implementation" has an accepted meaning across the team.
Usually it refers to "Coding + Unit Testing"

It is Measurable - you can measure defects, effort and time

Achievable - As long as estimate is based on previous actuals from similar modules / expert judgement, it should be achievable

Relevant - Its specifically talking about a particular module

Time Bound - I think there could be an end - date added to it to make it explicit.
However usually in projects where people multi-task on different things at the same time, that's a lot more difficult to do. But as long as the tasks are prioritized correctly, it shouldn't really be an issue not having an end date in it

share|improve this answer
    
what's KLOC stand for? –  RYFN Dec 22 '10 at 11:17
1  
KLOC = 1000 lines of code. Just one of the archaic means of measuring size in a software project. Just used here as an example. –  InSane Dec 22 '10 at 11:18
    
ah I see. rather than using actual lines of code as a metric, you can use errors per lines of code to measure code quality. –  RYFN Dec 22 '10 at 11:20
    
@Zeus - Actually, thats what i was trying to convey as well when using "10 defects / KLOC" i.e 10 defects in 1000 lines. Might not have been too clear. :-) Depending on how projects measure their quality / progress, the measures will of course be different. –  InSane Dec 22 '10 at 11:22
    
@In Sane, sorry my comment wasn't clear either, I had just worked out what it was you meant :) –  RYFN Dec 22 '10 at 11:26

Not the answer you're looking for? Browse other questions tagged or ask your own question.