22

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
Improve this question
1
  • 2
    This is definitely not a duplicate of "Metric by which to hold developers accountable".
    – Didier A.
    Feb 12, 2015 at 0:20

4 Answers 4

Reset to default
43

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.

Improve this answer
4
  • 4
    +1 Excellent answer and one I'll share with some of the higher ups in management!
    – Walter
    Dec 22, 2010 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, 2010 at 14:04
  • 2
    +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, 2011 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, 2012 at 9:52
8

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...

Improve this answer
1

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.

Improve this answer
2
  • 12
    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, 2011 at 7:27
  • 1
    These goals might apply to the CEO of a company. The first could be applied to the head of sales and marketing. The second one, maybe, to the CTO, depending on exactly the scope of the "cost of business". Like if that includes money spent by the sales team, or money spent because the sales team demanded more features, it's not the CTO's job. For a random developer, these goals are totally outside their control and unfair.
    – rjmunro
    Mar 15, 2019 at 9:34
-1

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

Improve this answer
5
  • what's KLOC stand for?
    – RYFN
    Dec 22, 2010 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.
    – Jagmag
    Dec 22, 2010 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, 2010 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.
    – Jagmag
    Dec 22, 2010 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, 2010 at 11:26

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