(You Gotta) Fight, for Your Right (To…
… create clean, self documenting, highly-performant, technical-debt free, non-redundant & re-usable code!)
Sadly, The Beastie Boys couldn’t get anyone at their record label to sign off on this track and we had to suffer their re-worked version. However, the underlying message is one I’m keen to re-iterate to our vast global ABAP community.
As a moderator of the ABAP space here on SCN, I see a LOT of shall we say “interesting” discussions, where it is apparent a relatively junior coder is struggling with how to answer a functional requirement or deliver on a specific set of functionality. I’m not talking about the “I’m new to ABAP, please tell me how to tie my own shoelaces” posts – I mean those people who now know enough about ABAP and SAP to question the requirements they are given but don’t quite feel confident or experienced enough to question why they are being told to do what they are.
Your job isn’t to say NO, it is to point out there may be a better way
I saw this tweet just a few days ago and felt it was very relevant to this post’s topic. Many people will devote most of their efforts to learning new and exciting technical abilities, but will ignore inter-personal and social skills. As a result, they get into a situation where they don’t know how to deal with someone asking them to do something they firmly believe is wrong. I see it especially in the off-shore side of our industry, where “leads” appear to be making shocking decisions on what should be built and how it should be built, and the poor “junior” is left stuck between doing what they are told, or what they know is better.
So, for the sake of your own longer term career and for the sake of the SAP system you are working on, please learn to stand up for your own opinions when it comes to bad design. Just because you are the junior and your lead has told you to do something, really doesn’t make it right. There are lots and lots of documented examples of where this just isn’t the case here on SCN.
I’m not advocating arguing with your lead over everything but as the tweet above suggests, it is about educating those around you that there is a better way. Sadly, in some cases this may end with the lead pulling rank and just telling you to do what you are told – in such cases, I’d suggest you start to also brush up on your CV writing skills and get networking on LinkedIn, as that isn’t the sort of Lead you want to be around for long… I’d also suggest you make sure you document your objections in an email to your lead, so that if/when the proverbial hits the fan you can at least defend yourself.
This isn’t much of a technical post, however that’s kind of an underlying point – being good at ABAP (indeed anything) isn’t just about knowing the language inside out. Devote some of your efforts to softer skills and develop the ability to deal with conflict and disagreement in a team. You never know, you might just find yourself taking up the role of lead 🙂
good one !
Gareth,
"Just because you are the junior and your lead has told you to do something, really doesn't make it right"......Well Said.
K.Kiran.
And this summarizes my predicament 😐
Ummmm... I hope they don't read the comment. Anyway - I'm sorry. There are times when it is hard to change jobs. Linkedin is a wonderful place to start.
Really loved the quote. Most people just don't like hearing "no" (surprise! 🙂 ), so presenting our ideas differently (e.g. "this is all fine, but I know how we can make it more efficient / cheap / <whichever people want to hear>" is something we all may need to work on. It is easier said than done though. 🙂
Great advice on saving the emails and other communication. In the most sensitive cases I specifically ask to put everything in writing (which sometimes gets things reconsidered, fortunately).
Some "leads" both never write themselves and concider idea to "ask to put everything in writing" from the client side - "not customer-oriented". 🙂
The problem comes when you are the lead and you have to face customer's tech lead who wants to have things done like 15 years ago.
It's frustrating, because you really try to improve and put your best skills at work to do a clean and nice job, but each attempt is killed at start.
Real and simple issue: direct input vs BAPI. Customer ask to use direct input and not bapi because the users always used it.
Or "not use OOP, it's more quickly for us to read the old perform code" (and then you look at existing code and found 3 FORM for 3k rows of redundant code...)
An old colleague of mine who works in the HCM space, was pinging me a few months ago for advice about some customer work he was involved with. The customer "architect" was stipulating the most out of date, rubbish approach to a particular piece of code - it was the age old ABAP argument about "FOR ALL ENTRIES" vs inner joins...
No amount of arguing, pointing out content here on SCN or in SAP official documentation, etc. could change the customer lead's opinion.
It can be SO frustrating, and in my experience usually comes from people who just don't know what they are doing and are in over their head but are too stubborn to listen and be educated.
Cheers,
G.
In my case, i know the referent pretty well and he's a really nice person.
Just he's overhelmed by user requests and he fears he loose the control over the system and... stucks on what he knows.
But it's still frustrating 🙂
Sadly I don't get to work a lot with the consultants from whom I can learn, but I can totally see how someone would just want to keep things simple. We've been dealing with a revolving door of ABAP consultants who obviously learned some bad practices. Same thing - I have to fight with them over using FAE instead of JOIN. It's a bit easier for us since we're a customer and can just jam our code standards down their throat, but it's no less frustrating.
Aaaah! An end customer pushing her standards on poor consultants! Run, run for your life! 😆
i also can see your point of view and you are right: you have to choose between consultant and consultant.
Only a couple of them really gave me some good hints to learn something (and still i know i've lot to learn).
On the other hand - as a consultant I've had to fight with in house tech leads over using joins rather than FAE so it swings both ways. I always say let the database do what it's good at. However, there are times when you cannot join two tables because of their type.
As for jamming your coding standards down consultants throats, one of the things I think each consultant worth his salt should be able to do is to adopt the coding standards of whatever company they are working at - it's part of the job!!!
i do not -totally- agree.
Yes, as consultant you have to be flexible and to adapt customer's standards.
But you should be able too to show him when he's wrong and try to not regress your tech & quality level to meet his obsolete standards.
One thing is maintaining something old, other hand is a whole new project - application - procedure: why stick with old tech (select....endselect, sapscript, bdc)?
I think you'll find that the majority of clients these days are well aware of what is old tech and new tech, but I will agree with you on pointing things out that may make their way of working easier, and also that which as you say is obsolete.
However, even if it is a new project, you should still adhere to their standards even if some of them do stick in your throat.
Does any company really have the development standards that include obligatory use of SELECT... ENDSELECT or BDC / SAPScript? Our guidelines don't govern such details at all and it's usually good ol' SAP Standard that doesn't give us any better choices than BDC or SAPScript.
From all the comments it looks like "good" consultants get "bad" customers and vice versa. Life is not fair... 🙁
SELECT...ENDSELECT is an exageration, but i lately got specific requests to use BDC instead of BAPI "because users know it".
[quote]
From all the comments it looks like "good" consultants get "bad" customers and vice versa. Life is not fair..[/quote]
Nah, it's just common telling the worst or the best situations we face.
So we see the extremes 🙂
That's very true - probably only 10% of all engagements for customers or consultants fall into this extreme category. It's just they really stick in the mind!
Mmmmmmmmmm... Are you sure your way is the right way? Who has to support the code after you are long gone? The customer may not use OOP and then they have to struggle with anything you created. Be a little understanding with that. Join vs. for all entries, I wasn't aware anyone had settled it. I think it depends. Think about your data. Can you eliminate some of the first table before you have to pull the second. The join is 3 or 4 tables. Is it easy to change? read?
Consultants??? I have met many that I just like a ton. I still stay in contact with them. Sadly some are really not the experts they say they are.
The experts that are experts, even their code will need changed. No code ever just stays the way it is. (Or next to none.)
[Gasp 😯 ] Michelle, of all people I can't believe you are saying such blasphemy! 🙂 Any reopening of the discussion of FAE virtues is currently # 3 on the list of reasons to get post rejected in ABAP forum.
Regarding readability - I find that dispensing with aliases (AS ...) and using the actual table names (e.g. vbak~) in JOIN improves it greatly. When aliases are used - yes, it becomes a maze after two tables.
Hehehehehehe............ What can I say? I go with the best option for me at the time. I haven't seen this one - I'll have to comment.
Michelle, i can partially agree with you.
We are all working in IT, where a constant improving and learning it's more than a requirement: it's a need.
A need for consultants as well for end customers.
It's my proud writing a clean code, well documented IN SAP as well OUT SAP (i.e. words files) so, yes, OOP is a pain to learn, but nothing too hard after a couple of times (and if a dumbass like me can learn, i'm pretty sure almost everyone can do it).
I'm not claiming my code is perfect or will remain unchanged, at all!
For my first assertion, i'm the first one who wants to kick my butt for the code i wrote in the past.
But, without sounding a boaster, at least i recognize my old code should be changed and improved.
Not everyone, i got evidences, agree with this.
PS
i gladly leave the tag "expert" to many others here around, i'm just a... code artisan 😛
Yup - I agree. Learning is VERY important. I've taken steps to make sure I've learned OOP. However, not everyone has done that. Little time, lots of projects, the direction of the company, the manager's preference. The list goes on and on.
By the way - I've jumped backwards to 4.6C. Let me tell you developing and using basic object here is a pain. And the direction of the company IT department is to NOT use objects. Bummer. Now once they upgrade to a newer version - then I can easily show the advantages of using objects. In 4.6C the advantage of learning them was to be prepared for the future.
A little add because i re-read my reply and it sounds a bit rude 🙂
What send me "mad" is always trying to find something that justify the status quo manteinance.
"Oh, i'll not use X because Y always worked"
"No, i'll not try Z because it would take time to master it..."
And so on.
And this hurts me on many levels, mostly on my hunger of improvement and learn.
i LOVE to try new things 🙂 and i DIE to try how effective they are.
And being constantly bashed by someone who should think at the future but prefer to keep his past, well... [sigh] i lost a bit the focus of the topic 😀
Please, Michelle, if somehow i offended you, it wasn't at all in my mind.
Please, i beg you, take my previous post as an appassionate defence 🙂
Nope - not offended. Very little does that. Topic - there was one here wasn't there? 😉
I tend to get wordy as well - I bet you couldn't tell that.
I think you've raised a few valuable points Michelle, and I should have been a bit more diplomatic. For me, the ideal customer/consultant engagement is where both sides come away having learned and improved their own knowledge and skill set. Hopefully after that all systems they touch are improved.
I love working with customers/consultants/anyone who can teach me "stuff". I hate working with people who are unwilling to change/learn/share/teach.
More importantly, the underlying point of my initial thoughts were targetted at the more junior ranks of the ABAP world. Those people who bump up against "bad" leaders often due to the mechanics of out-sourcing in our industry, that maybe just need a little boost in confidence to be able to say "that's a great idea and I've seen in other places how other people have done similar but in a slightly different way, which is better."
Of course, as their confidence and experience grows, they can just say "No." 🙂
Cheers,
G.
This was the post I needed couple of years ago :-). Some folks consider themselves all in all and they never entertain any suggestions which might be better then theirs.. Sort of bullying young folks.. to the point of threating with year end appraisal.. 😛
Yep, that's the exact behaviour I'm talking about. Sadly it is something that happens in all industries, across all geographies. The advantage we have in the SAP world is that we have the community of SCN to help fight our corner, where there is so much knowledge and expertise to be leant on.
Cheers,
G.
Gareth,
Great post and an inspirational tweet!
Getting bullied or letting get bullied happens to a functional analyst and leads too.
(from personal experience) I try to propose the best solution (I know) from a long term perspective but sometimes there are so many tasks to be done and you can not continue trying to persuade the client or client's IT manager. So you let it go...because you don't want to get confrontational or in bad books. You know that later, you might need his "favor" or might have committed a mistake...and for the unknown and scarcity of time, you let your self get bullied.
Knowing your craft well is one of the keys, when you have the depth of experience and expertise then you can "point to a better (or several) way(s)". So technical competence is one of the prerequisites to disagree and "confront"...or champion good ideas/suggestions.
I have written and thought about courage success in interviews - part 1: Process
but it is so easy to crawl up below your desk and not stand for something you know can be done better. It happens will cannot say no to meaningless meetings, unnecessary time wasting activities etc.
TW
Loved this one.
When there is a functional person who knows the technical side. Oh boy. Talk about hard to work with. (There are some very good ones to work with too) In the end, after trying to convince them that it really is a better way to do it,I usually do it my way and don't argue. Then I do it in something "newer" like objects. They can't read it, and don't know if I did it there way or not. (Yes, I try to explain first) Again love my new job. I get to do the technical and functional side. So I guess I could argue with myself. 😆 MMmmmm.... I do argue with myself sometimes.
Here's an interesting thought. I've jumped backwards a couple of versions in my new job. I say something like there is a cool object for that. Oops not in this version. You have to remember the version you are on too.
Gareth - there are times when you have to just hide under your desk. Trust me.
Also remember there are a million different ways to do something. There is a possibility that the way you want to do it, isn't the best way. Be open to what they are suggesting. Listen and maybe even do some quick testing.
Did I say I love my new job? Another thought - expressed above - update your resume and find a more open environment.
Again, you've hit the nail on the head - the "bad" leaders I've experienced could take a massive dose of advice from this reply.
Especially "Also remember there are a million different ways to do something. There is a possibility that the way you want to do it, isn't the best way. Be open to what they are suggesting. Listen and maybe even do some quick testing."
I could not agree more, as long as it works both ways!
Cheers,
G.
Agreed. It has to work both ways. I've learned great things from our consultants. I've also had some REALLY bad ones. But I won't talk about those now. The great ones would challenge me to learn more, expand what our standard's included, and just plain made working with them fun. Sometimes readability led to some very open discussions.
.. nice words from a professional point of view I would say "you're absolutely right." From a human point of view I would say "you're wrong completely."
Professionally, it is important to pursue the idea of perfection, preventing errors being committed.
Humanly errors can not be avoided but it is mainly from the mistakes that arise ideas and revolutionary solutions.
That said it must then consider that to talk and dictate, in a capitalist system based on the market value, the idea has to respect hierarchies so it is useless to propose that the foot to the brain to go right. If the right brain says it will go right.
Bye!
I'm quite confused what does it have to do with capitalism and why it is hierarchy-driven (isn't it driven by free market, in theory?), but expanding the brain/foot analogy - if foot steps on a rake then brain would get a signal that it's not a very pleasant experience. Then next time when the eyes see a rake they would send a signal to the brain: "hey, let's not go there, let's go the other way". And feet would get a signal accordingly. If the brain somehow didn't get a memo about stepping on a rake or if it insisted on stepping on it again despite previous experience - that would be one very sick body. 🙂
Of course, no healthy brain would give hands a signal to chop off the feet for sending back a signal about stepping on a rake, so it's clearly not the best analogy for the corporate world. 🙂
When I was a student I was thinking just like that. From a rational point of view I fully agree from the start of the discussion. But my thought is realistic,.. Probably because here in Italy if someone, a politic man in that case, that could be a manager too, get hurt its feet, he continues because "its feet" are not of his body but of someone else and when he gets enough money he disappears 🙂
And I'm quite sure that in the world economy is going like that. Capitalism pushes to the limit a man until he's good for something...If you are smart enough then you escape before with money ,, When someone is no more useful to a company, it's time to burn him like old wood - Great America
The question is... You've got to fight for your rights but rights are not the same for all or better "rights are the same for poor people" 🙂
So pleased this has generated such great discussion... Been meaning to post it for ages.
mmmmmm I like this .....
Hi Gareth Ryan,
Good One..!!
In addition I would also request you seniors to suggest some ways to tactfully deal with one of the common problem of IT Industry
--> "The task has been done by you and some one else drops a mail to stack holders claiming that he/she has done it" 😕
Here, you can't write a counter mail claiming your ownership,, well basically I don't know how to react,, its really frustrating to see your smart idea being sold with some other's label..!!
Would invite other seniors / friends to share there opinion..!!
Thanking You All..!!
"common problem of IT Industry"
Common ?? Where do you work ? I have always found that credit is given where credit is due.