|
The low score explains why so much software sucks! But Marketing getting a score of 0.0% is a good trend! 
Will Rogers never met me.
|
|
|
|
|
The product manager, whether it is a formal position or not, or even if the actual pm differs from the official one, is the one I listen to.
The reasons are simple: he knows the product, he has stakes in it and the responsibility of managing its direction. Therefore I can and will provide my expertise and my opinions but ultimately the choice and the repercussions aren't mine.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Why even bother to include this on the list? Nobody in their right minds (as seen by the zero votes for this option) listens to marketing, for any reason if possible.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Defer to the person who you determine to be the SME in the decision and has some investment in the outcome (i.e., some "skin in the game"; is a stakeholder). For system-level architectural decisions, someone in the architect role is a natural choice. For product-level decisions, the Product Manager has the ultimate decision making authority (within reason). For technical decisions, a senior developer is a good source of wisdom and best practices. Ultimately, however, all decisions have to be made by yourself--even if the decision is to defer to a SME.
|
|
|
|
|
One major problem that has plagued me for all my professional life: How to get anyone, whoever they might be, to give any decent feedback at all. It is like when you send out any document for comments on the technical contents: Two thirds of the reactions span from spelling mistakes to unintended double space characters.
You propose an API, and they bring up a long discussion about the names of the formal parameters. You have used a GUI prototyping system for presenting a functional demo, and the main feedback is that the boxes should have rounded corners. Things like that.
That is if you get them to say anything at all. It really is difficult to get any significant input at all, something that matters, in specific questions. General rules are no problem ("In method xxx you are not honoring our company indentation rules" or "Our company's software should follow ISO standards so-and-so"), but essentially, those are things that neither team members, managers nor marketing people need to see my specific code, those specific decisions I have to make. They are all general, specific-decision-independent statements.
If you are lucky, you get a chance to present your alternatives to actual users, and to explain to then the consequences of choosing A rather than B. Then you might get some decent response. But very few of us get at real chance to meet users at that level, and given the freedom to ask for their input. (I am obviously talking about non-technical users - not the kind of software and users where you can ask them to generate a pull request with the proposed changes.)
|
|
|
|
|
For most decisions, my answer is: 1) the team lead (me), 2) the project architect (me), and 3) myself (me). Others may have input but it's mostly me.
It's a small team, but I'm not solo. Others are more involved for the big decisions but those only happen once every 4 -6 months.
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
Depending on the situation, different people's input will be given different weight. But I will make the final design decisions, because those are my responsibility.
|
|
|
|
|
That some people's purpose in life is to serve as an example. It's also important to understand who not to get development advice from.
|
|
|
|
|
I'm the team lead, so 2 apply for me. I listen to the Product Manager because they, like me, were a user of the product at one point and have actual domain experience. I also listen to two other team mates, both of who have been supporting/developing the product longer than me. The rest of the team mates all take direction from me.
That 5 answers:
* team lead
* myself
* product manager
* (some) users
* (some) team mates
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
I am 100% in the same situation. We work with product and design decisions but technical decisions typically come from the other technical lead and myself.
Pete McNamee
"True knowledge exists in knowing that you know nothing."
|
|
|
|
|
The question should be specified more! What kind of decisions? In-app architecture? Then I will probably ask my team mate. Enterprise architecture? Then probably the architect is the person to talk to. Features? Totally different story!
|
|
|
|
|
|
For design decisions - myself
For UI/UX - the UI/UX specialist
For features - marketing
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: For UI/UX - the UI/UX specialist
For features - marketing
That's the most common problems in software development, right there... 
|
|
|
|
|
I'm well aware of it, but that's the way my employer works.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Are you working for Microsoft? Because a lot of development decisions seem the have been make by marketing and U/X folks, and not actually by technical people that know what they are doing...
|
|
|
|
|
Some marketing folk are fine. I used to work with one who had technical experience in our products and really understood our customers' businesses and needs. We should all be so lucky.
|
|
|
|
|
Ralf Quint wrote: Because a lot of development decisions seem the have been make by marketing and U/X folks, and not actually by technical people that know what they are doing.
Exactly.
And if you need any evidence to support this, just look at the gross failure of Microsoft, versus the tremendous success of the technical expertise based software of the *nix communities, in non-technical markets.
|
|
|
|
|
I guess that the higher the FOSS level, the higher the percentage of "No one but myself". If you include "Your team members" and "Other developers", just about everything is covered.
The evidence for this can easily be found by just taking a brief look at more or less any FOSS "product".
That is also the explanation why FOSS software never made much of success outside FOSS environments, e.g. on the desktop.
|
|
|
|
|
I don't like your comment so I will fork my own version of it!
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
...since I'm the only one here who understands how this mess I inherited works. But, sometimes I'll let the powers that be have a say in color or something.
Zach
|
|
|
|
|
I actually don't even hate to say it. But if the person who is paying the bills is happy. Usually everyone is happy. I have quite often in the past had a PM or other go between miss-hear what the money person says. When I double check(annoys the go between) I end up with a clearer picture and the go between actually gets a clearer picture as well.
Money talks and BS walks people
To err is human to really elephant it up you need a computer
|
|
|
|
|
I listen to my boss(es), since they sign my check. They also set my priorities, which helps me spend my efforts where they do the most good.
I listen to my coworkers, since we cooperate well and respect each other' domain expertise within our products. In one case that respect extends farther into general issues since he's a smarter programmer than I am.
I listen to my users, because I do the UI's for our products. UI/UX development has the same basic precept as writing: consider your audience. If you fail to do that, it's immaterial what you've implemented.
(yes, I know 'depends on the situation' covers this case)
Software Zen: delete this;
|
|
|
|
|
if it is a good idea, I don't care where / who it comes from...
if it is a bad idea, it depends wether he / she sits higher than me in the hierarchy and/or is possible that he/she have a look to the code and understand enough to see I ended doing what I wanted and not necessarily what I was told 
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Just to know exactly who's the bugger to blame.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
