November 22, 2017 at 2:06 am
Comments posted to this topic are about the item The Pressure to Perform
November 22, 2017 at 2:35 am
Not a lot to say to that apart from - amen. I know that without technical consistency the systems we provide could not function, and that such consistency is not compatible with slotting in new people to look after said systems at the drop of a hat. It takes 6 months to a year to really understand what's going on.
November 22, 2017 at 3:21 am
From Code Magazine .... Legal Notes: Should Software Developers Be Subject to Professional Standards of Ethical Conduct?
http://www.codemag.com/article/1711041 ... to summarize, why would you want to subject yourself to (frivolous - my word) lawsuits
November 22, 2017 at 7:45 am
What is the function of a salesman? For many organizations, it is "Get the customer's signature on the bottom line and the check in the bank." The salesman's job is done at that point and other people take over.
Now, this will result in unhappy customers, which eventually will kill their business (customers get the wrong product or something they don't need and they blame the organization - correctly - for the salesman's behavior).
The function of a developer can analogously be set down as "close tickets", or "write lines of code". This will result in similar behavior and similarly unhappy customers.
I suppose my point here is that the organization can set numeric goals for salesmen easier than for developers. It also helps that there seems to be about 20 people who think they can be good salesmen for every person who thinks they can be a good developer.
November 22, 2017 at 8:03 am
mark.magagna - Wednesday, November 22, 2017 7:45 AMWhat is the function of a salesman? For many organizations, it is "Get the customer's signature on the bottom line and the check in the bank." The salesman's job is done at that point and other people take over.
Now, this will result in unhappy customers, which eventually will kill their business (customers get the wrong product or something they don't need and they blame the organization - correctly - for the salesman's behavior).
The function of a developer can analogously be set down as "close tickets", or "write lines of code". This will result in similar behavior and similarly unhappy customers.I suppose my point here is that the organization can set numeric goals for salesmen easier than for developers. It also helps that there seems to be about 20 people who think they can be good salesmen for every person who thinks they can be a good developer.
I agree... I think that if I ran a company, I'd want my sales people to become the representative for making sure that whatever customers they brought in were taken care of so that they continue to be customers. I'd measure sales people's performance based on the duality of brining in new customers AND keeping the customers they brought in.
And spot on about Developers. They're not always the ones to blame for the " just get 'er done and off my plate" attitude. It's also the reason why a lot of times they become non-dedicated 9-5'ers.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 22, 2017 at 8:12 am
Jack 49290 - Wednesday, November 22, 2017 3:21 AMFrom Code Magazine .... Legal Notes: Should Software Developers Be Subject to Professional Standards of Ethical Conduct?
http://www.codemag.com/article/1711041 ... to summarize, why would you want to subject yourself to (frivolous - my word) lawsuits
... especially when you, as the Developer, may (frequently) not actually be in control of the quality or the ethics of others. Contrary to popular belief, there is no such thing as "innocent until proven guilty". Frequently you have to prove your innocence against (to use the same word) frivolous lawsuits and other such nonsense. It's like that fellow that got all beat up because of the Equifax penetration... it wasn't necessarily his fault... the whole bloody system of requirements, checks, balances, verification, and reporting failed.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 22, 2017 at 11:43 am
I once worked in an organization where the top manager in the company idolized Steve Jobs (including the unsavory A-hole that Mr. Jobs seems to have been). This guy had a zero error policy - if a customer called in with a bug report, the developer responsible was fired. Three months into the job, I let a bug slip through and a customer called - I was fired the next morning (after I had fixed the issue, of course). Thank you Mr. Jobs, you were obviously an A-hole to be emulated. That is one position I will never regret losing.
November 22, 2017 at 11:57 am
Of course quotas don't work out too well for salespeople either. It was just this year a big scandal hit Wells Fargo because of people creating fake accounts to be able to fill sales quotas. It's even more difficult to measure the work a developer does than it is to measure sales.
November 22, 2017 at 12:00 pm
mark.magagna - Wednesday, November 22, 2017 7:45 AMI suppose my point here is that the organization can set numeric goals for salesmen easier than for developers. It also helps that there seems to be about 20 people who think they can be good salesmen for every person who thinks they can be a good developer.
I think that's very true. For this reason, I don't like the idea of hard goals that might impact employment. I do think goals and accountability are important, but there has to be some understanding of the types and nature of the work for that measuring period.
November 23, 2017 at 12:19 am
You get what you bonus for. It is very hard to design any benefit or incentive scheme that achieves its aim without highly undesirable consequences.
An example would be Payment Protection Insurance in the UK, endowment mortgages and with profits policies.
If you bonussed IT on bugs corrected you'd just get buggier software.
Most people abide by the spirit of a system but enough people game the system to break it utterly. There will always be a few that will far exceed the bounds of morality or even legality.
I have seen people being richly rewarded for shadow IT activity and IT be the lucky recipients of the support duties. Then IT get blamed when that solution broke, tool time to"fix" and thereafter bled at least one day a week out of resource for what they were budgeted to do
November 23, 2017 at 7:27 pm
David.Poole - Thursday, November 23, 2017 12:19 AMYou get what you bonus for. It is very hard to design any benefit or incentive scheme that achieves its aim without highly undesirable consequences.
An example would be Payment Protection Insurance in the UK, endowment mortgages and with profits policies.
If you bonussed IT on bugs corrected you'd just get buggier software.
Most people abide by the spirit of a system but enough people game the system to break it utterly. There will always be a few that will far exceed the bounds of morality or even legality.
I have seen people being richly rewarded for shadow IT activity and IT be the lucky recipients of the support duties. Then IT get blamed when that solution broke, tool time to"fix" and thereafter bled at least one day a week out of resource for what they were budgeted to do
Agreed. I've seen this a lot. I find that the things that are easy to measure are the most likely to be what you are graded on, never mind what bad outcomes those measures encourage. Sadly I have also found that the easiest things to measure are usually the ones that add the least to the value of what you are contributing.
So when you encourage speed of delivery over quality (because quality is *hard to measure*) and then you reward those who fix bugs (even if they caused the bugs), you can't really be surprised by the consequences.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
November 27, 2017 at 1:48 pm
Jack 49290 - Wednesday, November 22, 2017 3:21 AMFrom Code Magazine .... Legal Notes: Should Software Developers Be Subject to Professional Standards of Ethical Conduct?
http://www.codemag.com/article/1711041 ... to summarize, why would you want to subject yourself to (frivolous - my word) lawsuits
This is different from the original topic of measuring performance, but I actually do believe that all software developers (and sales people) should be subject to professional standards of ethical conduct. At the end of the day, all professionals are subject to lawsuits regardless, we always have been, but it would be nice to have a standardized and transparent set of rules to define the boundaries. Personally, I'd like to see regulations pertaining to securing and legal use of PII applied, not just to specific industries, but universally to organizations, governments, individuals, and machines of all types and sizes.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply