Why you should have your own style(guide)!

[Florian]

Hi all,

Today's blog is about something I’m thinking quite a while how to create it.

We, as ABAP-Developer , didn't have such a problem or better, not in the same way a lot of others programmers had to face it.

What I want to say, is when you have a look at a SAP-Transaction everybody of us know normally how to navigate. There are the well known Navigationbar, Execute and all the Standard-Buttons above an ALV.

I think, you know what I’m talking about. So what is this blog for? I recognize that developing in ABAP make a huge change at the moment (ok, it is more a process and yes it's more a general thing). That’s why we face problems, we didn't know before and one is the Design-Styleguide.

I just want to collect some facts why all of us should have a Design-styleguide as an additional document to the coding-guidelines.

Everybody of us know the Coding-Guidelines and I’m pretty sure, I will not find one person around here saying it is not necessary to have a document like this. Of course, some are a bit over the top, but all in all it is a great instrument to lead all people into the same direction.

Now, when I would say that a Design-Styleguide is also necessary a lot people saying to me, that it’s not important.

Why do I get this reaction? I mean, of course years before, when just the dynpro was developed by SAP you just could choose between a hand full controls and a predefined icons to create your screen. That was awesome, because all of the programs had the same look and feel. I think that was one of the success-factors of SAP. Keep it simple and similar might be the thinking behind.

But developing has changed and of course the elements we can use today are a lot more. I don't know where here on SCN I have read the sentence “A 23 year old employee don't want to use a 20 year old software” and that is so true. Additional to that, I would say that also the rules of developing has changed and so today also we, the SAP developers may need more than just a coding-guidelines.

Now, how to start…what to do? This is how I want to start and hey, miss the counting in my blog? Me too :lol:

1^st point Use existing style guides

This is a very important point. Before to start with the own one work through other styleguides. All the companies out there especially in the mobile sector have one and I’m pretty sure SAP also got one, so if anybody knows where it is located, I would love to have a link in the comments :wink:

2^nd point Keep it short and simple

I read a lot of different blogs about this topic and I decided for me, that a good styleguide should not have more than 4 to 6 pages. In my opinion I’m pretty sure, that a lot of people saying that it is not necessary (as mentioned in the beginning) and out of that I’m pretty sure that it is a absolutely success factor that the guide is as simple as possible. Don't add tons of links, keep it simple, we all are creative people and I if something is not clear, make it easy to ask.

3^rd point Example-package

Provide a package of examples that leads through the different designs. That’s a way you can make similar feeling and by the way after investing some money you can save it afterwards with a multiplier :cool:

4^th point Easier to test (or 3.1)

What?  A styleguide should make my programs easier to test? Yes, it does. People will feel comfortable with the handling and so it will be easier to hand over some testing to another. Also keep in mind that the other worlds (UI5 / River / POWL) swap on our desk and it is not just a trend. It’s the future.

5^th point Easier to develop and to prepare (or 3.2)

A styleguide also helps the responsible persons to prepare the documents for developing. All people in the chain got a similar expectation of the program from the first sentence in the whole process. This will take time in the beginning, but I’m pretty sure in the end it will result in lower bugs and lower maintenance cost on each side.

6^th point Shared vocabulary (or 3.3)

This is a point, I humble sometimes over. I see 3 different programs with similar (custom)data in it and there are also three different data-elements used. I know, this won't be fixed in summary by an styleguide as well, but I’m pretty sure, that a active styleguide in an company leads to more sensitive searching before creating new elements.

7^th point Invest time

That isn't just a phrase here. I’m pretty sure that it will take more than two meetings to complete the process. I think it needs a lot of time to walk through the company and ask a lot of people how they define it and collect just facts. Afterwards pin all facts at a whiteboard and go on to point number eight. :razz: Of course, it also will take a lot of time to create the sample packages (Webdynpro, BSP, UI5), but this is also a nice doing to get in touch with all the things.

8^th point Onboard young employees

This document should be created by the young employees. They may add their points without having the company glasses on. No need to argue, but I think the “older” employees should have the second check on the document, so everybody has the chance to add something but in this case all voices are at the same level and if there are arguments, it will be early enough to add these to the document.

9^th point Catch the feedback

In my opinion I think it need a period to have an “beta-test” on the document. After the examples (or during) are created it should have a group of people to try the handling, if possible people without any experience of programming. They will deliver clear voices if they think all the different examples give the feeling to be always on the same highway. I think you know what I mean.

10^th point Love it or leave it

If you have worked through the other 9 points and ended here I just have to add, that I do not know anything other to add.  I know that this will end in a lot of discussions and it might not be easy to deliver such document. So I think you have to love the idea behind and see the necessity. And I hope I delivered that point with this blog :lol:

Conclusion:

Have a look around in your company and I’m pretty sure there are always people trying to put things in a row, let documents look the same and try to publish the brand in the same way. So this is exact the same what a styleguide tries. All we have to learn is that a styleguide today is normal and when I talk to people with other software in the back, it is usually a must have, except if I talk to SAP-guys.

I think it is time to leave the leaf or do I see things wrong and most of you got one available?

(Comic comes from here: xkcd: Donald Knuth http://xkcd.com/163/)

Thank you for reading to the end. Feel free to add something I missed or just to leave a comment.

Cheers

Florian