Is quality-management helping me in my daily work as developer?

[Florian]

Hi all,

today's blog is a deeper insight in “The 4^th point: think about your developing twice” published in Some recommended Points everybody should remember when developing (ABAP) - featured title "Be a bett...

As a quality manager it is also part of my daily work to share knowledge and to onboard new employees. Out of that I have a lot of different views from people which aren't much influenced. That means I get a lot of different views to code quality and how the different people think about it.

A funny thing is, when I tell them, that I’m part of the quality team, a lot of them are saying that this isn't effective or even they got not that good stories to tell. A lot are saying it is very abstract.

In other words they are saying that this is too far away from the daily work and it is not helping them to improve the code quality.

That’s why I thought, I will share ten facts about developing things.

( Be careful, it is not doing your work and maybe you need more time to get it done :lol: )

1^st point Functionality

Does your code do what you want to?

Of course, everybody of us is doing that in a way, but did you ever thought about it before starting developing?

I mean all the stuff you discovered before starting developing saves you time. So take your time and find your spots to implement your additional coding. If you have a Greenfield development you might save more time by drawing a class diagram with all the relations between, but that is another story to tell :wink:

2^nd point software reliability

Does your code affect other processes?

Make sure, that your code is not affecting other processes. Of course, if you answered point one with yes, you might have already checked this too, but just because most of us implement that in the first mentioned  point, it is an extra point and I need to mention it.

3^rd point usability

Would a user understand it easily?

That is a really big point and no, this is not your business. It is your business and I tell you why. We develop the things and we also need to take care about the usability. A simple example:

You see, take your time and think about your screens you develop, no matter which technique you are using. Just because all necessary results show up on the screen doesn't mean that it is a good program at all.

4^th point efficiency

What about the run duration of my program?

This is also a big point and it needs a bit more explanation. It is not just the run time, which is affected. It is more a design-fact on how well-written your code will be. Good to know before starting coding are the answers to the following questions:

Do I have a customizing, which is needed in the beginning?

Does a user use the program more often in a row?

How many users will use this program?

With these three questions it is possible to make a decision. If a program is used a lot of times you might read your customizing just once and save it in globals to not need to fetch it again. I think you know what I mean and so I don't want to waste your time here… (You know, all about efficiency in this point :razz: )

5^th point changeability

Is it possible to add additional logic to your coding without having devastating consequences?

Easy point, isn't it? Just make sure, that you implemented your code good and it is possible to change it in an easy way. For example, if you added source in different places and one of it cannot exist without another spot make sure you have a reference.

A very effective way to handle this is to implement unit tests. With a unit test you are just one click away :cool:

6^th point transferability

Is it possible to transfer my code to another spot if needed?

Try to make your source as unattached to the spot as you can. Use all the advantages ABAP (or even your programming language) gives us to develop things. Use interfaces, pass the values and extract your code in own classes / functions as much as you can.

7^th fact readability

Is my source readable if I would see it for the first time?

2. If you answer this question with yes, just ask the developer next to you and prove yourself :twisted:
3. I think it is an easy point and no need to explain it in a long story.

8^th point understandability

Will I understand the source in 6 month again?

If you answered the readability question with yes you might say isn't it the same? In my opinion no, because just I can read a source does not mean I understand it. Everybody of us saw a lot of coding and I’m pretty sure most are pretty sure, that it isn't easy to work through a snippet and get the idea behind. You need to see your source in a big picture and here it is needed to understand it. Perhaps you aren't that sure now, so you might add some comment-lines to your source and also describe the methods in a few sentences.

9^th point learnable

Would I teach someone to code like that?

What? That might be right now in your mind, but this is pretty important. If you see your coding in front of you and you scroll through it, you just should think about all the small details and ask you the question mentioned above. If you think you won’t teach someone developing in this way you might think about it more than twice and change it to something you would teach. That is the fact here.

10^th point needed

Is my code needed?

Ok, that is not a real question you should ask you after developing your stuff. Might save a lot of work :smile:

I just want to make sure, that you are really pretty sure that your developing is needed, if you have any doubts, that might be the implementing is not needed out of any reason ask your questions. I know a lot of developments out there which aren't needed in the end and just wasted time for everybody involved….

and ten facts sounds a lot better than nine facts :cool:

That’s it.

These are my personal  ten recommended points to think about twice. Keep these in your mind I’m pretty sure you will save time, perhaps not during the developing, but afterwards analyzing changing or even enhancing your source.

The bridge to the quality management:

Do you think these are points we should consider?

Yes?  Here is the fact: The first six are out of the ISO 250XX (Old one ISO9126). Now you might not say again that the quality management is not helping you in your daily work. It is always present but most of us don't recognize it as quality management in a classic way, in my opinion a good thing.

A summarization might be:

Just combine beauty and functionality.

Feel free to leave a comment and happy coding :smile:

Cheers

Florian