In the Celebration of the SAP standard code for dummies I expressed some of feelings about why we should reuse SAP standard as possible. Well, that is nothing new. We all know why we use SAP over home grown system. I received quite many comments under that blog and even some personal emails and tweets` that made me really happy, so I am here with the continuation.
I was asked for some personal tricks of mine. That is something that could help the beginner, I can understand. It could also be a good catalyzer for an expert tricks exchange (I would really love to learn the tricks of the others, I am far from being perfect ABAPer, very VERY far…). So I promise I will deliver some tricks, but not today.
Today`s blog will be about why it is important to do what I described in the last blog from our hearts (ok, pathetic, sorry). There were two comments that inspired me for today`s blog. Thanks go to Sharad Agrawal and Michelle Crapo. The topic for today is QA review + management and time pressure.
QA review of the development + management
“Mature ABAP shops normally have a Pre QA review process in place to approve specific DDIC objects (mainly tables, views and structures) before they are created in Development Box. (…). Though the individual developer is important part of the equation but the responsibilities also lies on leadership (development manager/director). The leadership should embrace and reward the principle of development of reusable code rather than finishing the current assignment fast and move on the next” said Sharad Agrawal.
QA and management. We all have heard about them. But how often they do what I described? Does your boss check if you use “enough” standard? I don`t believe it, sorry. If he would be that good to be able to do that in ten minutes (it`s a boss for god`s sake, he does NOT have time), he could do that by himself in the same time. Do your QA guys check if you reuse DDIC structures or call forms and functions instead of copying the code and blah blah…? I don`t believe it either. Why? It`s not difficult to figure out – if they can do that in a short time, why didn`t they built the things? This can`t be done quickly. It could mean that the effort/ time/ costs are doubled. Can you afford that? Can your customer afford that?
Because to judge if you reused enough standard code and objects mean that you understand the task, you understand the approach of the solver and you understand what, where, when and why he is doing things.
By the way, not all companies are rich enough to afford a big QA department. Some projects are not “big enough” to have access to QA quality procedures. Some development is outsourced, and then whose QA is to be used? QA of the both partners or none of them?
Let`s assume for a second that you have the right people, you can afford them and they have time. And they do thorough code checks and overall development scans. Then it`s up to them if the ratio of reusable code is high enough right? But what if they have no idea about the concept or the way of checking this? Then the situation is reduced to the previous case. It is a mission for every single SAP staff member to understand and learn.
By the way do you consistently apply your QA procedures on support projects? Then you might be cleaning the original project`s team mess? I don`t think so. Do you apply QA on emergency repairs and quick fixes of various kinds?
“But when it comes to the end of timelines…”
“…projects need to be done. Reusability slips. I tend to write what needs to be written to get the job done” commented Michelle Crapo.
Yes, time is always a problem. And money. Money is ALWAYS the problem. Let`s say you have cool and punctual management, great QA procedures. But you lack time. But let me tell you a different but a similar story in a way. Authorization concept. You care about security so you decide (boss of your boss decides) to invest some money (plenty of money) into building a new authorization concept. You wait months or even years, you spend hundreds of thousands or millions and at the end you get your new, nice and shiny authorization concept. It goes live one day.
Second day after the go-live at most first change requests arrive. Your very precise and take your time the first day. Second day. But sooner or later you do a careless repair, quick fix or an emergency repair and things start moving the wrong track. After weeks (months if you`re lucky) you realize you`re where you were few months before (and few million richer).
My point is even if you have superb QA and management and 80% of your development is neat and clean there is always 20% that spoil the effort. Your QA guy is on vacation. You`re only quickly repairing something . You ask your new junior guy to do the quick fix for you (changing few lines of ABAP is way to easier than build the thing from scratch, right? How many have you heard this sentence before?). Boom.
I don`t suggest you produce better code on your nights and weekends, but learn how to do that, remember it when doing the development and if it`s really impossible to make it, tell your manager/ customer. Standard code reuse is similar to the documentation in a way: We will do that when the times allows. Means nearly never.
ABAP kiddos, managers, you all should educate yourself on the topic
Now your question is “why is he explaining the obvious”? For a good reason. I am trying to make my point that it is very important topic for the “ABAP kids” as well as the managers. As I said the last time: the thing I regret the most in my career is that I didn`t care enough about the standard, that it took me so long to understand. If you`re an ABAP kid, thing about it, get the feeling of the importance and try to spend some extra time in this direction.
Even if that sound unlikely I don`t think I spend more time reusing standard than I would spend building things from scratch. Why? Well, when you research the standard (something you have to do to be able to reuse it, right? We don’t know all dark corners of the standard from hearth), you think about things, you understand how are the built, what are the limits, opportunities and threats. You plan the development in your head. You realize how much you have to build and how much can you reuse. That comes handy many times in future. That time is not a waste.
I promise I will write a blog about my tricks how to debug and reuse the standard, so if you want to compare your ways with mine, we can do that soon. If you have no clue how to start, hope my coming blog will help you to start.
Make researching on SAP standard a part of your personal development strategy. There are plenty of blogs about how to work on your skills and grow. Like the one by my friend, Learning and using new technology. But you must not wait for this to come to you. You can expect your boss to teach you. First step is to realize the importance and the second one is to do things the more difficult way so you learn new stuff. Ask for code reviews WITH explanation. Maybe even review the codes of your friends and/ or colleagues and ask them question: “why did you do this way instead of that way?”
If you`re a manager, development team leader or a quality assurance guy, it is your responsibility not only to prevent others from transporting fluffy stuff to the QA and PROD systems. It is also about helping the developer understand why they should do this and shouldn`t do that. If you don`t educate them, how can you blame them?
