A Developers Lament
I think most developers will agree with the below remarks…
Why, oh, why do users keep raising issues to developer’s like: “It doesn’t work, can you please check it?”, and just leave it at that? No explanation, no example, nothing…
To all these users I would like to say:
We REALLY want to help, we truly do. But please, please, please just give us the information we need, to help you! Do not drop the question and expect us to be able to read your minds. We can debug a program, but we cannot debug you. When raising an issue, please add a clear description of what steps were taken and what the problem is.
- What happened and what was the expected result?
- Which transaction did you use?
- What message was returned?
- When did this happen?
- Can the issue be repeated? How?
Be as clear as you can be! It may take a bit of extra effort at the start, but in the end it will save us all a lot of time.
Please guide us through the steps with patience, because we are NOT functional people and we do not (usually) know the proper business way to do what you normally do. What is obvious to you, is not obvious to us. We may not even know the right transaction… And we do not go through the screens you use.
We are not trying to frustrate you by asking all the questions we ask, how silly they may seem.
We just want to help! REALLY!
Okay, now I probably have developers agreeing with me on this. Having not enough information is frustrating and makes it difficult to help efficiently. The reason for me pointing at the users, is only done because developers will recognize them as a known problem. If only we could work without users… But this blog is not aimed at users, nor written for users. It is written for developers.
Let us turn it around and let it backfire…
Now, if you are a developer and you recognize this problem (you do, don’t you?), then have a look at how developers post on SCN… I see many questions, by developers, to developers, in the above mentioned user-way.
Developers keep raising issues to developer’s like: “It doesn’t work, can you please check it?”, and just leave it at that. No explanation, no example, nothing…
To all these developers I would like to say:
We REALLY want to help, we truly do. But please, please, please just give us the information we need to help you! Do not drop the question and expect us to be able to read your minds. We can debug a program, but we cannot debug you. When raising an issue, please add a clear description of what stpes were taken and what the problem is.
- What happened and what was the expected result?
- Which transaction did you use?
- What message was returned?
- When did this happen?
- Can the issue be repeated? How?
Be as clear as you can be! It may take a bit of extra effort at the start, but in the end it will save us all a lot of time.
Please guide us through the steps with patience, because we are NOT sitting next to you and we do not (usually) know the what you did. What is obvious to you, is not obvious to us. We may not even know the right transaction… And we do not go through the screens you use.
We are not trying to frustrate you by asking all the questions we ask, how silly they may seem.
We just want to help! REALLY!
Good piece of advice. I agree with you totally.
Sometimes though I think the question is posted after an unfruitful debugging session and the guy is just too exasperated to add any details. While we hope he does realise his mistake and add a few important details about the issue he faces this may not always be the case.
Anyways what you are saying in this blog could not be stressed enough. It has been repeatedly said. Its critical that the developer give a brief the how , when and whats of the error, and only then can the forum assist him further.
Regards. 😉
Hi Edwin
A section of this blog is repeating.
Starting from: "To all these users"
Ending at: "We just want to help! REALLY!"
If it is not done intentionally, please correct it.
It was definately intentional. I could also have put it in a small program... But I wanted to get it across to the Developers!
😉
All developers will agree with what you have stated, however, when was the last time a user was on a forum like this.
You need to be submitting your thoughts to your users.
It's not intended for users. It really is intended for developers. Developers posting questions on SCN in a way that they know is insufficient... Because developers deal with the same problem every day (lack of info, lack of effort, throwing the problem over the wall).
A question with the subject: "Help!" is a common enough example... Unfortunately.
It appears to come across as User to Developer, not Developer to Developer.
Nowadays, if I get a question where clearly the first response will be a request for more information, I just reject it with a note.
Sometimes they come back.
Good one Edwin ! Communicating clearly and crisply about where about your issue is an absolutely essential quality a developer should have. Especially when you are a team lead/tech arch , Its very important that you communicate clearly to your managers, who usally might not be aware of techncal intricasies , but can understand the issue in a broader sense.
Well done. I am always having to go back to the users and say 'What document was that?' or 'When did this occur?' - and IMHO it's even worse on the discussion spaces because the poorly-phrased question lives on FOREVER, forever clogging up our searches.
Perhaps one solution would be to vote UP this idea? https://ideas.sap.com/ct/ct_list.bix?c=8A060447-ED55-41EB-905E-C077161D66AC
The general idea would be to have an 'Insufficient info' button, which if pressed N times would generate a message back to the Original Poster.
This was submitted by Jelena Perfiljeva as a result of a spirited discussion in the blog:http://scn.sap.com/community/coffee-corner/blog/2013/07/04/wouldnt-it-be-great-if-people-wanted-to-get-their-questions-answered--more-rant
I have used stackoverflow in the past for Androind related questions. If you question gets marked as a poor question, they you get blocked from posting until you amend your question and it is marked "as a good question".
Not the best way to run a tech forum.
Hi Susan,
Thanks for pointing out that idea! I voted... In favour of course!
😀 I like that.
Really nice blog and SO transportable to other fields, too. And really, it's not just the users (as you stated correctly).
A conversation today between a colleague of mine and me:
C (from his office across the corridor): "STEFFI!"
Me (not moving yet): "Yes?!"
C: "The portal! It's not working!"
I'm refreshing the portal on my screen to see if an error comes up. Everything looks normal.
Me (trying to get more information): "What is not working?"
C: "The portal!"
Me: -.-
After going to him it shows the navigation is stuck on a node instead of showing the clicked content, as the Ajax Framework tends to do sometimes. Refresh, click, everythings good.
So it looks like everyone turns into a user, when having a problem, completly ignoring what they will be ranting about later when another user comes with a problem to them and doesn't really explain what is going wrong. 😀
EDIT:
I'm just reminded of a saying: "Doctors are the worst patients."
Maybe you can translate that to "IT people are the worst users." ^^
Rather end-users are the worst users 😛
I don't know about that. My personal computer used to work fine, but ever since I took a job in IT, it breaks all the time. Of course it's always my fault because I tried to do something stupid 🙂 .
If IT people aren't the worst users, we're at least the most demanding ones.
Well Said Edwin .
Few users think that ABAPERs has got with them a MAGIC Stick or what , they can solve any problem without providing detailed information to them .
Even some Functional Consultants do the same, say a new scenario or requirement comes and if they are not able to find out solution Functionally , then they target ABAPERS .
Eg . Once there was a requirement to make the Item Description Disabled based on PO type and the Consultant immediately called me and told me to code BADI or related EXIT. But I was sure for a SPRO alternative for this , I discussed the same with my SAP MM friend and later explained the solution and so an unnecessary ABAP development was avoided.
Liked your document , small and concise 🙂
Maybe now this calls for another BLOG how ABAPers should communicate their issues to their supervisors and take them into confidence, especially those supervisors who aren't/weren't hardcore ABAPers. I have seen developers face this probelm of not being able to effectively translate their technical issues they are trying to resolve into plain English and so end up giving a more optimistic/pessimistic picture of the problem , than it actually is.
BR,
Shankar.
As someone had pointed out earlier(on SCN), "SAP is broken, call the ABAPer 😐 "
- Suhas
Or "SAP is broken, BLAME the ABAPer"!
Let me rephrase that again:
"I cannot work with this and it is not MY fault..."
Where to put the blame? SAP? The developers? Users? Or will it be: Lack of DOCUMENTATION!
There, I said the 'D'-word. Could not resist.
Or this:
http://sd.keepcalm-o-matic.co.uk/i/keep-calm-and-call-the-abaper.png
Felt as if I was reciting a poem when I read it... Well written.... I'm sure there is a poet in you...
Would have made a good piece on poetry had it been written in lines..
And yes.. Totally empathize with you....
Nice 🙂
Well spoken.
Not to mention that the possibility of ruining another functionality of the program while trying to fix something without the necessary information is huge.
Well done Edwin Vleeshouwers
Debugging is good, but should not be abused! Poor ABAPers 😐
Nice info ...
Seriously Edwin Vleeshouwers .. I am fully agree with you.
Even i also faced this issue.. Some Question like "" XYZ fm giving me short dump, Experts please help me ""..
How we all will be able to help them, without knowing where it is dumping in the FM..
Good Blog. 🙂
I will suggest everyone before posting something as question please provide all required details, it will save yours time as well as ours 🙂
..ChanS..
I guess this document needs to be included as a Mandatory Acceptance document at the time of new User Signup or before putting up a question.
Super this was 🙂
Reallllyy users should understand that we cant read their mind and understand their problems without knowing all the detaisl about it 🙁
Well written...:)
Regards,
Priyanka
True Indeed!! Everyone expects Abapers to be adept at everything(Functional and Testing included)..We are not magicians. I hope everyone sees this post and wakes up 🙂
Well written and kudos for taking this step 🙂
You are sure to be a developer?
As far as I know a complete developer needs to have second sight and the ability of thought-reading ...
No, just a joke, a great blog and a broad grin on my face ...
haha..good one 🙂
Mind-reading, yes. Often misinterpreted as 'The Art of Assumption'.
"I know what this person wants, even all those things that are not mentioned".
This blog is about the opposite though...
"I assume everybody knows exactly what my question is about. So why don't you just give me the answer!" 😉
Very well said. I totally agree with you. Not all the developers are expressing this. If they try to express clearly from both sides , it will definitely save time and reduce the stress in terms of fixing the issues quickly.
I also faced this problem many times.. But we can try to understand, by asking lot of questions... until we get the knowledge of what we are trying to debug in the ABAP Program.
Instead of Assumptions, if necessary manual manipulations and followed by explanations to others will really help to fix the issues. so that both can have the common understanding of the issues.