In this week's KDE Commit-Digest: kdesu, the KDE application privileges manager, gets long-awaited support for the sudo method. Strigi gets .rpm and .deb package contents indexing capabilities, and can now index UTF-8 encoded text. Guidance gets a new power manager applet. Code import for the Physiks educational Summer Of Code project. Amarok gets support for MTP media devices. Work starts on porting KGoldRunner to KDE 4. Rewrites begin in the KReversi game and Oskar media player. GUI optimisations in KTorrent and KTU (KDE Translation Updater). Experiments using Kexi as a database backend in KPhotoAlbum, and rendering SVG in Unity.
Dot Categories:
Comments
Actually, your reply is crap. Actually, only part of it is crap since part of it is indicative of the problem.
In rhetoric, it (the part which is crap) is called a straw man. We aren't talking about developers taking offense at people telling them that their application is crap. If people do that, they have every right to take offense.
What we are talking about is people either telling developers exactly what they think is wrong with the app, how the app could be improved, that there are design flaws (such a suggestion is not "gratuitous" if it is specific), or exactly why it doesn't work. Such comments should be taken as helpful. The problem is that developers with too much ego take such comments as attacks -- even as personal insults.
You said it; they consider their application to be their "baby". This is the problem; they have too much emotional capitol invested in their app to be objective about it. They need to get over this because it is detrimental to making a better product. This isn't somebody's baby, it is our product.
I do know of KDE developers that have too much ego (when it comes to their work), but it wouldn't be fair to them to single them out here.
Example:
Suggestion: It would probably be be better if the menus in you application conformed to the KDE UI guidelines.
Response: I read them once and never looked at them again.
Yes, there is a problem. It would be better if you offered suggestions on how to address it rather than rhetoric designed to deny the existence of the problem or to make excuses. The problem here is simple; it is the 'go start your own project' syndrome. And, surprise! that is what has happened.
Maybe my reply is crap.
When you write that "people either telling developers exactly what they think is wrong with the app", that can means stepping the developer's toes as well. And who knows how big are his toes? I know some people, who no matter how polite you talk to them, it will be taken as hard critics.
And I believe you misunderstood some of points I wrote before. I don't deny the existence of the problem. I don't make excuses about it as well. I merely suggested the theory (I'm not surprised should you think my theory is also "crap" and "rhetoric") which may explain the cause of the problem. You can stamp it as an excuse if you want, although I thought engineers believe that finding the cause is the first step towards the solution.
And so you do know KDE developers that have too much ego? Fine. Then our experiences varied, cause I never got such response before. You can always claim that "developers have too much ego", it's your opinion after all. But I will then always also write "no, that's not true".
Let me play the sensitive developers side again. I spent sleepless nights writing this wonderful FantasticFoo program and thought others might find it useful as well, and I then released on my site so people can grab it. And suddenly one chap that I don't know before tell me how the design flaw must be fixed because it's important to make a better product. And it isn't my baby, it is our product. Oh, since when it's suddenly become OUR product? And YOU are supposed to tell ME to fix the flaw? And how are YOU going to do that? With e-mails saying that I have my ego and must get over it? Ask me to write hundred times that I have to get over my ego? Or perhaps just flip a switch? Convincing a heavy smoker to stop smoking with hundreds of research papers has better chance than this.
It would be better if you offered suggestions on how to address the problem rather the same "the developers need to get over this" statement as it has been posted here again and again. Or perhaps I understood it wrongly. Is this statement perhaps one of your suggestions?
I believe that I have stated the problem. Developers have too much emotional capitol invested in their apps. For the good of the project they need to get over this. Or perhaps it is better stated that the project needs them to get over it. How to do this? I don't know. I can only tell you that engineers somehow learn to do so.
I don't see treating developers like prima donnas as a reasonable way to do things. Developers shouldn't behave like prima donnas. How are such prima donnas going to react when they receive a usability report written by the usability people or a UI guideline compliance report written by the HIG people. This is a large project, lonewolves aren't going to fit in too well.
But to get back to the point: users "telling developers exactly what they think is wrong with the app". This is called feedback. Developers should welcome such feedback -- it should be taken as what it is: one person's opinion. Now > 90% of it will probably be crap, but that other 10% might have some good ideas. And occasionally someone might tell you exactly why your app doesn't work -- certainly that shouldn't be considered as an attack (but it is).
Money. Engineers do something they are told to do and that they don't want to do because they get money for it. With the money, they can buy food and leisure time to work on something they want to do, like working on an application for KDE.
Obviously you are not an engineer. And from what I have seen, you never will be one.
Your suggestion is absurd. You suggest that engineers use efficient methods only because they are being paid. I am still an engineer -- still use engineering methods -- despite the fact that I am retired. I have not become an undisciplined hacker just because I am not being paid.
I suggested that developers should take personal responsibility for their own product. Your reaction was to post this:
http://www.valdyas.org/fading/index.cgi/hacking/tqm.html
where you demonstrate your total ignorance by showing everyone that you have no idea what so ever what TQM is. Under the standard management model only the quality control people are responsible for quality and they tell the other workers what to do to *try* to achieve it. However, under Total Quality Management, _everyone_ is responsible for quality. This is (to use Tom Peters' favorite word) empowerment; it is not, as you wrongly suggest, some kind of subjugation.
Workers prefer TQM to the old and inefficient quality management methods, and it improves productivity -- this is why I said:
"Someone posted that TQM had to be forced on people. Possibly, but the question is whether after it is forced on them that they ever want to go back to working without it."
I think that what you, and others such as you, really object to is that, with TQM, you are responsible for the quality of your own work.
> I'll be damned before I'll allow myself to be managed. Especially by someone
> who hasn't earned my respect at all. And there's no way, short of taking
> away my CVS account, you can force me to comply.
I presume that by that you mean that you will never be willing to take responsibility for the quality of your own work.
> If someone whose work I admire tells me to fix this, do that, or pull up my
> socks and start producing better code, I'll probably heed him or her. But
> that's the only kind of management I'll accept.
So, you also admit that you do not judge suggestions based on their merit -- no meritocracy for you! This is your loss, not mine.
Clearly, you are illustrative of the problem I have been describing.
You also appear to be one of those people that equate knowing a computer language with knowing how to engineer programs. The corollary to this is that some people appear to equate doing the GUI for a program with writing the program -- there needs to be a working program under that GUI.
You are probably even good at writing code -- perhaps even as good in C++ as I was with FORTRAN (numerical methods programs are not usually written in C or C++). But if you don't learn how to design programs you wind up with code that has a slick GUI and runs OK, but doesn't do the correct things. Such software does not impress me at all.
Perhaps it is my background. There is no question in my mind that a numerical analysis program that has a wonderful GUI but gets the wrong answers is worthless.
Your logical argument is absurd. WHEN an engineer is paid to do a crappy task, THEN he must do that (and overcome his ego, yada yada). But nothing stops him from doing that crappy task (although he's not obligated to) even he is NOT paid. To said otherwise is a fallacy.
Open source development, like Boud asserted, is a voluntary work. And as many others who do voluntary works, mostly it's about having some fun. You can give some developers a very nice feedback but if they aren't convinced that it's going to be fun, they can just ignore it (no matter how amazing, constructive, brilliant and wonderful your feedback is).
Is this an egoistic point-of-view? Perhaps yes. Is it a problem? For some people, it is. But is it natural? Of course. Tell me how we do feel if our (spare time) hobbies are not fun anymore. Many will choose to spend time with their kids, families and/or friends instead.
Perhaps I can have some fun applying engineering methods to my unpaid hacking sessions. But some others do not feel like that. They won't reduce their sleeping time just to experience another nightmares. And they also can tell me to do something that I really hate as my hobby.
I think that you missed what BR meant. He refuses to use TQM methods. He refuses to do so despite the fact that they would increase his productivity. He wrongly presumes that engineers use such methods only because they are paid.
Or, he could have meant that engineers take responsibility for the quality of their work only because they are paid for it. This is not the case and it is why I said that he would never be an engineer.
Yes, people will do crappy tasks because they are paid to do them. But, that does not mean the people won't do them unless they are paid to do them. Socrates' cat is not a dog, after all.
We presume then that part of the work needed to have a software project 100% finished would be classified as "crappy tasks" by many developers, and that developers won't do crappy tasks. This idea means that all Open Software projects are doomed. Perhaps it does explain why many projects never get past the 90% completed point.
OTOH, it does not explain why some developers react so negatively to feedback and offers of help. And, that was the original question which has nothing to do with whether engineers are responsible people only because they are paid or not.
Look, I did not and never did comment on Boud's opinion on TQM nor your analysis of Boud's opinion on TQM. What I have written above is about my disagreement in understanding Boud's statement posted before (not anything about his blog entry).
Boud wrote: "Engineers do something they are told to do and that they don't want to do because they get money for it". When I read this, I understand that money is definitely the cause that makes the engineers do this and that. But I do not conclude that the engineers are forbidden to do this and that if they are not paid, i.e. no money is involved.
On the other hand, you replied "Your suggestion is absurd. You suggest that engineers use efficient methods only because they are being paid". Furthermore, you wrote "He wrongly presumes that engineers use such methods only because they are paid" and again "that engineers take responsibility for the quality of their work only because they are paid for it". Compared to my understanding, you have made a gross extrapolation here by putting the word "only".
That what I meant in the first paragraph of my previous reply. You even seem to agree because further down you wrote "But, that does not mean the people won't do them unless they are paid to do them." And you think I missed what Boud meant? Care to elaborate?
As for the original question why some developers react so negatively to feedback and offers of help, you have your own theory already: "developers have too much emotional capitol invested in their apps". I have offered my explanations as well: "you step their toes and their toes are big" and "they think you spoiled their fun". Boud has his own reason: he won't allow himself to be managed, especially by someone who hasnt earned his respect at all. Do these all answer that question or are you not yet satified yet with the answers?
The word 'only' is a major part of the point but perhaps what I meant was not understood.
BR suggests that engineers do things because they are being paid to do them that they would not do otherwise. If being paid is the cause of them doing these things, then they do them 'only' because they are being paid to do them.
I have asserted that this is not true:
1. That people will use efficient methods because they make the task easier.
2. That people will take personal responsibility for the quality of their work because that is the right thing to do.
3. That people will do "crappy things" either out of a sense of personal responsibility or for the delayed positive reinforcement of a job well done.
and that people will do these things even if they are not paid for what they are doing -- at least good engineers will do these things.
I do not understand why people reject #1 because using efficient methods should be intrinsically reinforcing. And, I do not know how to instill the values of #2 & #3 in developers -- obviously it would improve the project if we had more developers with these values.
IIUC, we are in basic agreement on why some developers take offense at feedback and offers of help but we have no solution for the problem.
It is an unfortunate situation because I am willing to do "crappy things" to improve the quality of the product and those that reject such help are probably not willing to do them, yet my offers of help are rejected because ... . Well, I guess because I act like engineers act -- I am direct to the point of being blunt.
I'm also going to be blunt. Look, you can present your problem descriptions again and again. Yet, they won't solve the problem. Worse, you further alienate yourself and the developers that you criticize.
Human relation is not an exact science. You may come to me and give a very genius feedback, but if I think you're a jerk, I may refuse to listen to you, ignore you and attack you back. You can argue until the end of the world that you're right and you have lots of experience even with punch cards, and I should judge the comment based on the merit, and all this method should make my life easier, and positive feedback should not be taken as an insult, and it's my own loss not to hear you, and I have to get over my ego, and I have to learn how to do things like engineers, and so on. But the fact is, every time you say so, I will be less motivated to listen to you. You can only use a stick to frighten kids, not me.
Why? It's simple. You place yourself as if you were not in the same boat. People do no listen to strangers (Social Skills 101). A beggar is not likely to take advices from a millionaire (not that I ask you to be a beggar or treat the beggar as a prima donna). It does not matter if the millionaire is 100% right and the beggar is 100% foolish, it just won't happen.
People have (fortunately) different tastes, thoughts and opinions. What you think as an efficient method might be torturing for me and thus makes me reject it. You can argue again (and post the arguments here) how this method beautifully solve the design flaw, but by doing so I may become more and more suspicious. Do you really want to help? Or do you just want to show off your skills? Even salesmen know when to stop bragging.
Personally if I help someone but he does not seem to accept it (or even when he curses me back), I just ignore it and move on. Personally I don't bother too much to show him how my advices can improve his life, unless of course I just really want to impress him and others. Personally I don't have time to analyze his mental behavior in depth, as I'm sure I still can be of some help for other people. In any day, I won't aim for 1000 db SNR.
You can't please every single soul in this planet. Don't even think about it. Just take care of those who are pleased.
You aren't being blunt. You are talking past me.
BR is so intransigent that he won't take responsibility for the quality of his code. And, he won't try my suggestion of using TQM even if it would allow him to write better quality code with less effort. Why? The reason is ego.
You can't argue with people such as that -- people that know that what they think is right all the time. And don't say that applies to me because I am only repeating what people more knowledgable than I am have said (about TQM and software engineering).
You do not alienate such people by confronting them. They are already alienated. That is, you can't have a working relationship with them -- at least not a real one. Sometimes confronting them works and they will have a breakthrough (an epiphany). Otherwise you can only treat them like a prima dona and have a one sided and phony relationship.
I am not in the same boat because some of the KDE developers don't welcome people into the boat. There is a difference of cultures. I am a professional engineer and they are self taught hackers. The self taught hackers are much more proficient at C++ coding than I am and they know how to write GUIs. However, what some don't seem to understand is that underneath the GUI is a program and a program is a program no matter what language it is written in and what it does -- programs are all based on logic, arithmetic, and string manipulation.
I have many years programing and design experience. The fact that it is in a different language for other types of programs makes little difference. I thought that I could contribute some of this experience to the KDE project, but I realize now that I am wrong. There are some nice people in the KDE project that have appreciated my work. But, I never know when I will be on the receiving end of an ego attack. It is unnerving. I have an ego too when people start personally insulting because they don't like my technical advice -- doesn't really make much sense does it.
So, this is why I am going to be moving on and will be doing most of my work on another Open project.
I would not call Amarok half-baked at all. \
I would call Kaffeine under-baked, but it's quite usable. I am running it as *the* application on my HTPC at the moment because it's *more* usable than *every* other multimedia application (specifically DVB play/record, DVD and movie file playing) I've found.
Outside of lack of DVB support, Codeine really is more usable.
I concur regarding Amarok. ;)
I don't think that calling apps half-baked helps to correctly states the issue. There are apps in development that probably are only half done, but the problem is really that we have too many 80% to 90% baked apps.
The problem with the 90% baked apps is that they never seem to get the last 10% of the time in the oven. Possibly this is because that last 10% takes considerably more than 10% of the work and that work isn't much fun.