Blog Host: Matthew Billingham - Consultant READ ENTIRE BIO

I've been thinking about the shape of SAP development in the future. Let's have a look at the changes since 1997, when I first entered the world of R/3.

• New ABAP editor
• Activation of programs
• New SAPGui
• Smartforms
• EnjoySAP controls
• ABAP Objects
• Long workbench object names
• BAPIs
• BADIs
• Industry Solutions
• Other SAP solutions -- BW, CRM, SRM…
• Web application server
• J2EE
• …

I think the value of ABAP development will decrease. Programming is expensive -- processor power, memory and storage isn't. There's likely to be an increase in modelling over developing. Of course, the complexity of our processes is also increasing, so what is simple modelling now will be very complicated modelling in the future. There seems to be an attitude that it will be the functional analysts who will do this modelling, but currently the capability doesn't generally lie within the functional population. If the developers can gain the functional and business knowledge, it is us who will be best suited to take advantage of this skills gap. We can close it more easily than our functional counterparts. It has always been easier for a techie to go functional than the other way round. Some of the best functional consultants started as developers. (I'm an exception to this -- I started as a PP consultant!).

SAP is pushing hard for Java to be an equal of ABAP in SAP development. It simply isn't there yet. But in the next few years, it will be. ABAP has the power, at the moment. Java has the flexibility. When Java has the power that ABAP has, I think development in ABAP will slow down. However, as long as there are any applications -- like FI/CO! -- written in ABAP, it will never disappear.

This is a very simple, short analysis. But three things are clear to me. To succeed in the new SAP future:

1. We must change our image from "techie" to "business professional."
2. We must position ourselves as those who provide business solutions. We need to be viewed as problem solvers, not programmers.
3. We must learn Java and learn to utilize it well within the plethora of SAP environments.

My stay in Barcelona has two official purposes -- to review the progress technically of our Spanish project and ensure quality -- and to coach, encourage and support my deputy, who is technical lead for the project.

Of course, in these days of communication, I'm still doing stuff for my French project and my global stuff -- and with the remaining time sorting out some problems in the UK. It did occur to me, as I connected to the printer in the Spanish office, that five years ago, you could not have done this. I just plug my laptop into the LAN, and away I go. Enter the network address off the printer, and -- bingo! -- I'm connected.

Not quite as convenient in the hotel. Well, that's not quite accurate. There is a wireless network here, but at €6 for one hour, I think I'll stick to the dialup!

Over the last few days, I've been struck by the differences in the approach to program reviews of the various countries I'm in contact with. The English hate it, but do it well when forced. The French love it. My Indian colleagues view it as a competitive game. The Germans and the Swiss do their best to fulfil the letter, but certainly not the spirit of the procedure. I haven't seen how the Spanish do it. I leave that for tomorrow.
Posted by Matthew Billingham How to improve your programs with a ruler and a pencil
07 SEP 2004 22:00 EDT (02:00, GMT)
I was working on a program today, and, boy, was it complicated!

       FORM ...
       IF cond1.
       .
       IF cond2.
       .
       ELSE.
       IF cond3.
       .
       ELSE.
       .
       ENDIF.
       IF cond4.
       IF cond5.
       IF cond6.
       .
       ENDIF.
       ENDIF.
       ELSE.
       .
       ENDIF.
       ENDIF.
       ENDIF.
       ENDFORM.

       FORM ...
       CHECK cond1.
       .
       IF cond2.
       .
       EXIT.
       ENDIF. 
       IF cond3.
       .
       ELSE.
       .
       ENDIF.

       IF cond4.
       IF cond5 AND cond6.
       .
       ENDIF.
       ELSE.
       .
       ENDIF.
       ENDFORM.

Hey ho. Barcelona tomorrow. It's a tough life.
Posted by Matthew Billingham V-signs
07 SEP 2004 06:00 EDT (10:00, GMT)
When you get a new functional specification, what do you do first? Me, I tend to launch up the logon pad, login and start coding. Then I pause, read the specification and think for a while. Then I write the technical specification. Then I program.

I worked at one place where we followed this thing called the "V model." You may have heard of it -- it's used in a number of different organizations. This particular client -- I can't say who, let's just leave it as "a government agency" -- had the best implementation of the V model I've seen. Here's how it worked:

Starting at the top of the left side, we have the user requirement (UR). From this the functional analyst writes the functional specification (FS). Now, this FS is peer reviewed for correctness and completeness, with specific attention to whether it meets the UR. Any changes, deficiencies, etc., are noted on the review document (RV). ( I mentioned this before, but not its full scope). Any corrective action is taken, and the FS is reviewed again. When no more issues are found, the FS is released to the developer, who writes the technical specification (TS) and the unit tests (UT). The TS is reviewed against the FS and UR -- any issues noted again on the RV. The FS or even the UR might be changed -- and, if so, reviewed again. When the TS finally makes it through all this reviewing, only then is the programmer given leave to start developing. The actual development is the vertex of the V.

OK, riding up the other side of our V, the developer performs the unit tests. The TS, UT and development are all reviewed, and the results are recorded in the RV. After everything is OK there -- and remember changes can go all the way up to the UR -- the functional analyst writes the integration tests, more reviews and eventually the development goes live -- the top right of the V...Until more functionality is required, when the whole process starts again.

Now, it won't necessarily be possible to apply this where you work, but at least you can do some of it (it is worth it -- rework is soooo reduced). Just as an experiment, the next time you get a functional specification -- write the technical spec before you start coding. It takes discipline, but it might make a difference.
Posted by Matthew Billingham Juju-flop
06 SEP 2004 05:00 EDT (09:00, GMT)

In today's modern Galaxy there is, of course, very little still held to be unspeakable. Many words and expressions, which only a matter of decades ago were considered so distastefully explicit that were they merely to be breathed in public, the perpetrator would be shunned, barred from polite society, and, in extreme cases, shot through the lungs, are now thought to be very healthy and proper, and their use in everyday speech is seen as evidence of a well-adjusted, relaxed, and totally unf [bleep!] ked-up personality. So, for instance, when in a recent national speech, the financial minister of the Royal World Estate of Qualvista actually dared to say that due to one thing and another, and the fact that no one had made any food for awhile [sic] and the king seemed to have died, and that most of the population had been on holiday now for over three years, the economy had now arrived at what he called, "One whole juju-flop situation," everyone was so pleased he felt able to come out and say it, that they quite failed to notice that their five-thousand-year-old civilisation had just collapsed overnight. But though even words like "juju-flop," "swut," and "turlingdrome" are now perfectly acceptable in common usage, there is one word that is still beyond the pale. The concept it embodies is so revolting that the publication or broadcast of the word is utterly forbidden in all parts of the galaxy except one -- where they don't know what it means. That word is "Belgium" and it is only ever used by loose-tongued people like Zaphod Beeblebrox in situations of dire provocation.

-- © The Hitchhiker's Guide to the Galaxy, by Douglas Adams

I was in Belgium on Friday. Left home at 6 a.m., staggered off the plane in Brussels at 8 a.m. Due home by 9:30 p.m. I'm not impressed by Swiss International Airlines. For short haul flights, they charge you for refreshments, unless you are in business class. This from the national carrier. When I flew Cross-Air, before it was taken over by the failed, collapsed Swiss-Air, not only was the refreshment included in the price, but, once, I actually enjoyed the food! A rather nice lamb salad.

The purpose of my visit was to train the developers for our Belgium project, in our procedures and standards. When they started to look bored, I pointed out that this is the tenth time through for me -- imagine how I feel!

We look at Source Code Reviews, which I am convinced are the best method of quality assurance in programs -- when done properly, of course. It is a requirement in my company -- one introduced by yours truly. I hated it the first time I encountered it, but, boy, did it sharpen up my programming style.

For those who've not encountered it, what we do is go through the program -- ensure it conforms to published standards, but, and probably more importantly, also ensure that the program is well written, modularised and commented. The program is compared with the Technical Specification and with the Functional Specification to ensure that all requirements are met.

This introduces a healthy element of competition between programmers, as we strive to reduce the number of issues on the one hand, and go through our colleagues programs with a fine-toothed comb on the other!

And you know, in the end, the overall development time is reduced. An immediate benefit, even for time-critical projects. Oh, and when the developments get into production -- they often work!

...

By the way, if you've got kids, remember to give them an extra hug sometime soon. Some parents today can't anymore...
Posted by Matthew Billingham A good programmer
03 SEP 2004 05:00 EDT (09:00, GMT)
{RANT MODE}

I'm NOT happy. I want to make that perfectly clear. Seriously dischuffed. My normal happy go-lucky, relaxed, easy-going attitude is undergoing destruct testing. And the reason: an example of the worst kind of programming, which has wasted an entire half day. A half day that I simply do not have. The program deals with objects that have eight associated long texts. To control the maintenance of these there are six variables/tables/fields per text. So, what naming convention did the original programmer choose? That's right, nothing meaningful like qa_txt, qc_txt or hdr_text. No, that would have required a modicum of thought. No, instead I have to contend with txt1, txt2, txt3.

It get worse. The long texts are associated with some screen fields. And the names of the fields? Kztxt, kztxt2...-- the latter defined in a Z structure! Oh, and the identifiers of the long texts -- VERN, Z0C1, Z0C2...

Long text	Variable naming convention	Screen field	Long text ID
QA text	Txt1	Kztxt	VERN (OK, SAP standard can't do anything about that)
QC text	Txt2	Kztxt2	Z0C1
Header Text	Txt3	Kztxt3	Z0C2
Initial QA text	Txt4	Kztxt5	Z0C3
Additional text	Txt5	Kztxt6	Z0C4
Etc.	Etc.	Etc.	Etc.

AAAAAGGGGGGGGHHHHHHHHHHH!!!!!!

Not only did the programmer not take the opportunity to use meaningful names, he didn't even keep to the same naming convention!

We discovered that one of these long texts wasn't being saved under certain circumstances. I started digging around and found the aforementioned DOG'S DINNER of a naming convention. And not only is the logic around the maintenance of them convoluted, it's been cut and pasted for each different object type. I've spend the whole afternoon modularizing and renaming and getting some sense into the development, so that NOW it can be maintained. Now that the structure is clear, the omissions are glaring and the program can, finally, be fixed.

I just want to make one thing clear. Quickly writing programs that work doesn't make you a good developer. If it can't be maintained and supported, then don't bother. Do something more productive with MY time. Put those blasted comments in. Explain what each section is for. Don't use global variables when you can use local ones. Break the program into logical modular units. Does it look pretty? Or is it a mess! Look up in your dictionary words like "Encapsulation", "Meaningful" and "Invariance". THINK! Will I be able to fix this program at 3am on a Sunday, with a hangover, in two years time. If the answer is no – go and rewrite.

{/RANT MODE}

P.S. A few years ago, there was a program that had been in production for a while and that stopped working. It calculated commission payments to salesmen; when a new document type came along it stopped working. No problem -- log into production and debug it. Except that its runtime was four hours. OK, there are things we can do about that. Only it was full of SELECT...ENDSELECT. And as all ABAP developers should know, this construct often can't be debugged -- it causes the debugger to dump.

Next step, then, is to see if we can figure out the flow by looking at the code. Except there are few comments, and there are four driving internal tables called ITAB1, ITAB2, ITAB3 and ITAB4.

We had to rewrite the program, using SELECT INTO TABLE and meaningful names; try to figure out what the program did, directly from the code; and put our own comments in. Did I mention that there wasn't any offline documentation either? No functional specification, no user requirement. Having rewritten, we had to run the program in parallel with the old one, in production, to ensure we got the same results. Then we could start debugging -- three weeks after the problem was first noticed.

It took us another week to identify and fix the problem.

During this time, the salesmen were not receiving their commission payments, which they were rather annoyed about. We had to make payments to them, at a rate far higher than what was achievable through the normal calculations. The total cost to the company of this badly written program (including development time, the extra payments, the time to negotiate the extra payments and all other associated activities) was in the region of $500,000.
Posted by Matthew Billingham I've just encountered an insurmountable opportunity.
02 SEP 2004 06:00 EDT (10:00, GMT)
Just been downloading some Martyn Joseph music videos. I'm so pleased with broadband. I've "only" got a 700K line, but it's so nice to look at a 40MB file and know it will be saved in just a few minutes. Video used to be impossible, but now the quality is great. I hooked my laptop to our TV through an SVHS cable, and it's nearly broadcast quality. If you like satire, there's some great video to watch here. There's even live streaming TV. Most of it, of course, is subscription only, but there's free stuff, too. I can sit here in Switzerland and watch Brooklyn PSB. Shame it's so dull. And if you are in Brooklyn, you can watch my local TV. Not only dull, but also incomprehensible. (In fact, they do have a live show from the local comedy store, which frequently is in English and can be very funny ).

OK, OK. I'm in Europe. This is new to us. I've only been online since 1996. 28kbs dial-up. In the countries I've lived in it's only recently that dial-up has been free.

Now, there's been some dispute about the official start of the various seasons. Apparently there are the official astronomical seasons, which run from the Summer Solstice to the Autumnal (Fall) Equinox to the Winter Solstice to the Vernal (Spring) Equinox. But I don't buy this. It would mean that Midsummer's Day is the first day of summer. NO! It's "mid-," it can't be the start. It doesn't make sense. The UK Met-Office uses June - Aug. = summer, Sept. - Nov. = autumn, Dec. - Feb. = winter and March - May = spring. Going back a bit further, the change of season was traditionally celebrated at the cross-quarter days -- halfway between the solstice/equinox -- Imbolc, Beltaine, Lughnasadh, Samhaine. These are closer to the Scottish quarter days and would put Midsummer day at the middle of summer but would also put August in autumn, so that's not most people's understanding of the seasons. Take your pick. For me, autumn started today. Hey, I had to light the fire this morning, it was so cold.

Had an interesting little problem today. We have some standard program templates we use for our application-to-application connections, all controlled and monitored by an interface management program. Part of the standard is the use of GUI_UPLOAD. Now, we switched to this when we went to 4.6C, since SAP has labeled WS_UPLOAD as "obsolete." But it doesn't work for certain Unix files. So, we put the question to Waldorf, who told us to go back to the obsolete WS_UPLOAD. Apparently, though GUI_UPLOAD is released in 46C, it doesn't have its complete (i.e. working) functionality until 6.20. We found a better solution. We told the site with the problem to put the correct conversion switch on their FTP command. Problem solved.

Sometimes you have to back off from the problem that is in your face, and look at what you are actually trying to achieve. For example, we were writing a userexit for process orders, where when the PO is released, the shipping long text from the associated sales order gets copied into the header long text of the PO. However, SAP, in their ineffable wisdom, have decided that rather than check for a long text, they'll put a check field into the database table. So, although we could use READ_TEXT and the SAVE_TEXT to transfer the long texts, we couldn't set the long text check field on the table. (We're not permitted to update standard SAP tables directly, without signatures -- in blood -- from some very senior managers. Even more senior than me, if you can imagine that. So high, that the air is thin, with all the problems that brings...but I digress...)

I asked the functional analyst why they were wanting to transfer the texts. It's so when the process order is printed, the text from the sales order is also printed, and the people with access to the process order haven't access to the sales order. Erm..."Why not just grab the text from the sales order when you run the print program?" says I. "Oh, that's a good idea," says the functional analyst. :-) Often, the technical issues you encounter are in fact due to wrong specifications -- so don't be afraid to challenge the analysts. Sometimes they make mistakes -- after all, it's not as though they are developers, like us.
Posted by Matthew Billingham Summertime, and the living is easy
01 SEP 2004 05:00 EDT (09:00, GMT)
Heck, I just realized -- autumn starts tomorrow here in Switzerland. Mind you, the nights have been drawing in for 10 weeks. The skiing season will soon be upon us. Before then, the development phase of my France project will end -- just five weeks away. The way we do projects is in phases.

First we do blueprinting. Fit gap analysis, concept papers, activity descriptions, functional specifications. Well, I say Functional Specifications (FSs). On my project, thankfully, all the go-live critical FSs were ready at the end of this phase. I've heard of some projects, whose names I shan't mention, to protect the innocent guilty, where the list of desired FSs wasn't ready until well into the next phase, which is the...

Realization phase. The fun factor of the project ramps up a gear as the developers join. Hooray! Shouts of jubilation! The boys (and gals) are back in town. Party on, Dude! Programming -- yeah! And documentation -- boo! And source code reviews (oh, the horror!). I've heard there are other activities, too -- configuration, test spec writing, data migration (OK, often a development team job, but I teflonned that away; nowadays it rests easier with some functional analysts), identifying more gaps, and writing more Functional Specifications. This is where we are now, and forever more will be, worlds without end, amen -- erm, until end of September anyway. Oh, dear. I had two two-hour meetings today, and one of those took two and a half hours. My brain has gone all mushy. I had to inform the project manager (who is a really good guy -- hi Gilles, can I have that bonus now?) that we need to keep the whole development team until end of November, rather than losing half of them first week of October. It's all these extra developments identified during this phase that's done it.

Testing/Training/Getting everything ready to go live phase. For developers, we just keep on going. We've finished all our go-live critical developments, and so hit our targets. Hooray! Bonuses and treble whiskies all round (with apologies to Ian Hislop). Can do on all the non-critical stuff. That still has to be done by go-live? Strange world, isn't it. During this phase, our developments are shipped to some foreign country, known as QA. It's weird there. They can't change anything. I've visited a few times, but wouldn't like to live there. Occasionally our expat developments come home on furlough for R&R (repair and rewriting), but many we never see again. Ungrateful lot. You sweat over these little programs, you surround them with love and care and documentation, you expend days of your life over them, fixing their little bugs, adding new bits of functionality. And then they leave you. Without so much as a sy-subrc = 4.

Go-live. Alledgedly, after the QA the developments go into this mythical kingdom called "Production" -- personally though, I don't believe a word of it. Sometimes our programs undergo some kind of reincarnation and reappear in the development box. Oh, Frabjuous joy! It's nice having the kids back. But they don't hang around for long. Why do they always fly the nest? I don't think I'll ever know the answer to that question. Anybody got any I can answer?
Posted by Matthew Billingham Grinding to a halt
31 AUG 2004 05:00 EDT (09:00, GMT)
Watching Eastenders (very depressing, makes me feel much happier) on BBC Prime. One of the few English language TV channels we get here. We get Albanian, Turkish, Kosovan as well. Quite a diverse community. Spent the first of two days this week in France -- 15 minutes to the border, then two minutes on the other side. Morning mainly taken up with planning. The developers tell me what they did last week, what they're planning to do this week, then I play with the figures -- we're in pretty good shape for the testing phase beginning in October.

Here's a good question: How do you estimate how long it will take to develop something? If you've got a hundred developments what do you do? How long does an average ABAP development take? For some applications, I've written the solution in about five seconds flat -- but it took me two weeks to figure it out!

I think SAP brings particular peculiarities into the estimation challenge. Unlike other development environments, we are often enhancing what's already been written by another programmer -- probably a German, for the older SAP stuff. Our applications have to integrate nicely into what's already existing.

Oh, and by the way -- this is how I estimate development time -- this includes the time to write the functional spec, the technical spec, write the program and fix the bugs. Figures in Man Days.

	Simple	More complicated	Complex
SAPScript	7	10	15
Interface	5	10	15
Dialogue transaction	7	14	20
Smartform	3	5	7
Everything else!	4	9	14

Feel free to use these, but do remember: With programming, it always costs more and takes longer.

But why should this be? Why does it take so long to develop software and even longer to get it working? Perhaps it's because programming is an as much an art as a science, according to this in silicon.com. I hypothesize that this is because of the uncertainty produced by the halting problem. It is a fact of computer science that there are two types of programs: those that can be shown to have no bugs (proved), and those that can't be shown to have no bugs -- can't be proved. It is a fact that it is impossible to write a program (or develop an algorithm) that can decide whether a given program can be proved or not (corollary of the halting problem).

Somehow, our brains manage to overcome these limitations and "know" that the software is right (or not), which seems to imply that our brains do not run on algorithmic lines). For me, this is why software design can never be a science. You can bring scientific principles into play, but it will remain an art.

I suppose you could construct an algorithm that would design bridges that won't fall down, but you definitely couldn't construct an algorithm that will generate programs that won't fail.

Last of the summer wine has started now, so I'll stop my blurbling along. Keep those questions coming!
Posted by Matthew Billingham Don't panic!
30 AUG 2004 05:00 EDT (09:00, GMT)
Sunday afternoon in sunny Switzerland -- well, sunny now; it was chucking it down a few minutes ago, probably the remains of a Floridian hurricane -- thinking about blogging for the next couple of weeks about ABAP, SAP, about life, the universe and everything. As any fule kno', the answer to life, the universe and everything is 42. But what's the answer to ABAP and SAP? Even Deep Thought would have had trouble with that.

SAP seems to think the answer is Java and Netweaver. And judging from the number of articles in the SAP Professional Journal, this does seem to be the weight of opinion -- though the latest edition does have a rather good article about debugging ABAP, amidst all the stuff about Java. (If debugging is the art of removing errors from programs, is developing the art of putting them in?) However, one evaluation report that passed my desk regarding SAP J2EE indicates that the tools are lacking behind the concepts.

What do you think? Have you got experience with any of these tools? Should all of us ABAP developers go out and retrain as Java programmers? Will that old joke we used to say about COBOL come back to haunt us? (What did the ABAP developer say to the Java programmer? "Would you like fries with that?")

So, I'm British, and I live and work in Switzerland, which isn't as idyllic as it might seem, but the taxes are low. I've been programming since 1981, in various languages: Basic, Z80, C, Modula 2, RPF, SAS, DCL, Rexx, Java and VBA to name a few; and, of course, ABAP (since 1997). All of this despite my MBTI score showing I'm firmly INFP! I look at programming as an art form -- I think developers should aspire to be architects rather than bricklayers, and I think it a shame that many companies view programming as a semi-skilled job, at best. To learn what is required from a really good developer, I recommend The Pragmatic Programmer by Andrew Hunt and David Thomas.

Currently I'm leading the developers on an R/3 46C implementation in France, developing some nasty complicated batch management stuff under a tight deadline for our global stuff (characteristics and classifications, dontcha' love 'em?), training our methodology and standards to our Belgium project (on Friday) and reviewing our Spanish project's developments, hopefully next week. That's something to look forward to, as I have my trusted deputy and his sidekick leading that implementation.

For my time here, you can contact me via Yahoo instant messaging using "matt_the_abapper@yahoo.com" or via AIM with "Matt The Abapper" if your timing is right. I'm fairly busy this fortnight and have a family that occasionally likes to interact with me, so you will have to be lucky -- but it is possible! Bear in mind that I'm on Central European Time. I can't promise to respond to anyone who attempts contact me this way, but I appreciate you trying. I'm happy to discuss anything, but if you really want to get some useful information out of me, stick to ABAP-type questions and classic R/3 infrastructure. And remember, there's no such thing as a stupid question!
Posted by Matthew Billingham