What is a bug?

I’ve been opening quite a high number of customer messages recently. All of them reached sacrosanct “development support”. Most of them came back with the mention “work as design”. And I began to ask myself this question that I asked so many times before: “By the way, what is a bug?”. Not that easy to find an answer. You might say “A bug is something that has to be fixed so that the software will work as intended”. Fair enough. But then, how do you know that something actually works as intended? Who can decide what “as intended” really means?

Maybe that will become clearer if we take a step back and try to transpose those questions to some more basic scenarios.

My car’s got four wheels

Imagine that you buy a brand new car to your favorite reseller. Everybody knows what a car is so there’s really no need to explain what you’ll got when it is delivered. However, on the day you receive your keys you notice that you’ve got your car, and your wheels, but the wheels are not mounted. You find them somewhere on the floor, with a nice little screwdriver next to them (called a “BADI” in SAP language). So technically speaking you’ve got every pieces you ordered, and you also got every tool you need for your car to be ready to go. So do you have any right to complain? And if you do, what will you say to the technician that is kindly explaining to you that he followed the instructions he was given (i.e. the car is meant to be delivered this way)? Obviously you can insist as long as you want, you’ll end up having a “dialogue between deaf people”.

My car can ride during daylight

Now imagine that you managed to mount your four wheels. So you can plan a very nice and long trip. But as night comes you notice that your car has no headlight. When you come back to your reseller, a few people are asking you many things because obviously they find it weird as well. So you show them your car, you give them your keys, you answer every question about where you wanted to go, what gas station you stopped by at, who was your passenger when the issue occurred, etc.: they go for a ride and try it themselves. After a week or so, they tell you that they need to forward your problem to some specialist… and you end up meeting the same technician as before. His answer couldn’t be more clear: “There is no headlight on this type of car, we made it for daylight use only — however we forgot to mention it in the users’ manual so we published a small addendum (called a “consulting” OSS note listing software limitations in SAP language) that you can download from our website”. Again: your car works perfectly fine during daylight, plus there is some piece of paper somewhere that says the car was never intended to be used at night: so do you have the right to complain? And if you do, what is the purpose of arguing with the technician that did nothing but following the specifications of this car?

My car was upgraded, now I miss my airbag

You love your car reseller. He’s a nice guy. So you didn’t hung up the phone when he called to sell you a maintenance package. What convinced you the most is the offer to choose any new option you like for your car, and have it installed in no time (called a “switchable business function” in SAP language). You decide to go for the steering wheel of your dream, the one with a deep and beautiful red carpet all around it. I must confess I love this one too. And here you go: new steering wheel was installed pretty fast (how cool is that?) and you feel so much sexier driving slowly along the seafront… until you realize that your airbag is no longer here. Of course you like your steering wheel, but you liked your airbag even more! So, you contact the same technician (again), and the answer is the same (again): that’s how the steering wheel was designed. In fact, for technical reasons he had to remove the airbag to put the carpet. Nothing mentioned in the documentation, nor in any addendum this time. But his explanation is very convincing: you cannot decently have both because you would risk suffocation with the carpet around your neck when the airbag comes out. Not to mention that the technician promised to find a solution to this problem for next version of your car. So do you have the right to complain?

If I can walk, do I really need a car after all?

You may be thinking I’m ranting here. But I’m not. I know SAP Support is doing a great job with its twitter channels (@SAPSupportCE and @SAP_GSupport), with the customer connection program, and there is even a channel on Youtube. I’m just trying to describe with a little bit of humor what I’ve been experiencing so many times, and that I’m still experiencing at this very moment. I don’t have all the answers, but I feel like in the end, it would make sense to have some smart guy between me and the technician to discuss some problems from a functional point of view before addressing the technical side.

In the end all software applications have limitations. Sooner or later you find something the application cannot do the way you wish and that it’s not easy to change. e.g. because it’s a function that is done by another SAP component..

Sometimes, an application is designed in a way that satisfies the requirements of some customers but not the requirements and wishes of other customers. If we change a specific feature to satisfy customer A, customer B will complain. Whenever possible badis can be a good option so that every customer is satisfied. But someone may complain about the fact that one has to implement the badi to get the applicaiton working as desired. In the HCM area (Spanish payroll) we have very frequent legal changes that involve changes in the SAP Standard, but sometimes it’s not clear how to implement those changes. For customer A, it’s clear how to do it but if customer B has the opposite idea. The instructions of the auhorities are often ambiguous which leads to that kind of discussions.

But a car must have wheels and lights!. It’s very important to listen to the customer’s necessities. Of course, to do enhancements SAP needs time and resources. Some changes involve little effort with a significant improvement

Of course I agree that something may satisfy customer A, not customer B, etc. What I’m talking about here is more related to some semantics concerning “this is the intended behavior”. According to me, that means “we made the system behave that way on purpose” (probably because that answered the needs of most customers).

Now when I’m asking: “OK, but who asked you to deliver a car for which you have to mount your wheels yourself?” at least I should get a valid response. That’s where the “smart guy” could chime in and explain to the technical guy that maybe its specifications were not correctly understood. Just a thought.

I also agree that every software have limitations: so every time I find the “technical” explanation very convincing, I’m asking to create an OSS note to make it known to other customers too, or at least to add a footnote in the online help. Because in the end we all want the same thing: make SAP a better software.

That’s why I also log many customer messages even after implementing the needed fix in my system, and describing my solution… but you would be surprised how many of them come back to me unresolved (see what happens with ANST when I logged some messages regarding a bad French translation that prevented us from using the tool: I would have closed it without your intervention).

In the end I wish “a bug” was not considered “a fault”. I don’t care if the software has some bugs or limitations… but don’t act as if we were not on the same side when I’m pointing it: I’m not judging your work 🙂 I just want to help you make the software run better.

When an applicaition is developed it’s worth spending time making a very detailed documentation so that not only the behaviour is explained but also the reason why. A close and fluid dialog between the original developers of an application and the enginners who have to give support to it is important.

Open and public discussion will give the chance to share points of view. Customer A will know what customer B thinks.