matthew.billingham

    November 2008 Previous month Next month

    Introduction 

    Before Community Day began in Berlin, I'd seen that the topic "working as an independent consultant" had been proposed for the agenda.  The proposer had had to withdraw, so Mike Prokraka volunteered to take over.  I met with Mike, and suggested that we do it together.  But the agenda was set, so we didn't have the opportunity.  I've just checked Mike's blogs, and he hasn't written about this already, so I thought I'd give it a go.  In the following I use the terms Freelance/Independent/Contractor interchangeably,  so lets go...

    The Good

    Freedom!

    For me, the biggest plus of working independently is freedom.  Theoretically, at least, I get to choose where and when to work.  Part of that is that you're outside of office politics, though some of the work you do may have political consequences, you, as an external have (or should have) no vested interest.

    Money!

    Externals, on the face of it, are paid considerably more than internals.  However, the money that they actually receive may well be nothing close to what the company is paying.  Most independent consultants work through agencies.  It is not unknown for a consultant to be paid 2/3 of what the agency gets.  The client most often doesn't know what cut the consultant gets, and the consultant usually doesn't know how much the agency is charging the client. 

    So, why do clients use independents at all?  Well, the cost of an internal isn't just their salary.  You may not be aware of it, but in most European countries, for every €1 you earn, your company pays a percentage of social security on that.  In the UK, it's around 12%.  Further, if an internal is ill, the company may be obliged to keep paying full salary.  In Switzerland, some companies do this for up to two years.  There are insurances for the company against this, but of course, there are the premiums to pay.  Externals don't get paid during public (or voluntary) holidays, usually don't have training paid for, or the costs of conferences, like Teched!

    Also, with freelancers, there's more flexibility.  The contract between client and contractor is not subject to employment law.  That means they can, if they both chose, have varying and unequal notice periods.  Perhaps call-off contracts.  Or fixed price contracts.  

    HR - Personnel

    Imagine.  No appraisals!  If you work as an independent contractor,  your work is judged mostly by results.  If you're not up to scratch, you'll be disposed of.  If you're good, you'll get renewed.  In many  companies, the hiring and firing of independents is outside of the responsibility of personnel.  We're NOT staff.  We're NOT employees.  We are simply an item on the purchase order.  The  British government have recognised the difference.  If you work throught a limited company in the UK, but behave and are treated as an employee, you don't get any of the tax benefits that true independents are entitled to - in recognition of them really being in business on their own account.

    New people, new environments

    One of the biggest attractions for many people is the opportunity is to meet new people and work in new environments.   Whether you travel internationally, or remain in your country, or even your local area, every time you start work with a new client, you encounter different working practices, procedures, mindsets and attitudes.  Often you are able to bring different ideas and suggestions, as you've worked in so many different ways.

    The Not So Good

    By now, you may be wondering why anyone would want to work as in internal!  Well, it isn't all wonderful.  There are aspects that should make any sane person think twice - or even three times.

    Security

    Forget job security.  Your security is to the end of you current contract.  And rest assured, if the client doesn't need you any more, you'll be gone.  Currently, I'm working on a call-off contract - the client budgets for, say, 90 days over a 6 month period.  They're under no obligation to use all those days.  From one week to another, I may not know if I'll be working in the following week!  (Though to be honest, I kind of like this - I certainly don't get bored!)

    You're also on your own - there's no-one looking after your interests. There are various contracting groups established, for example the PCG in the UK.  You'd be well advised to join such a group, if one exists in the country your working in.  Often there isn't, as getting contractors to work together in such a way is not unlike herding cats.

    Training

    Training is your responsibility.  Not only do you have to pay for your own training, usually you won't be billing while you are training.  And you have to pay all the associated expenses.  Though I've found all training to be beneficial in some way, there have been courses where the investment really hasn't paid off.  Pre-2000 it was difficult for independents to get onto SAP training courses - they simply weren't set up for it.  Thank goodness that has changed.

    While we're on the subject of training, there's the related issue of breaking into new technology areas.  Most often, clients want someone who can hit the ground running.  They're not interested in someone who's done the training course, but has no practical experience.  So, if you're an ECC (R/3) ABAP programmer, and you want to do BI, it is very difficult to make the switch - even though you may be brilliant at it.  It can be done, but you need to have built up a relationship with your client, and perhaps offer to work at reduced rate for a while.

    New people, new environments

    Again!  When you start a contract with a new client, the chances are you won't know anyone there.  They don't know your reputation.  You have to prove yourself every time.  Initially, this can be frustrating.  You get treated, for example, as "just another developer", when in fact, you could be a Thomas Jung or Rich Heilman-in-waiting! 

    Away from home

    Especially in SAP, it is unusual to be working in your home town, even if there are several large SAP customers near where you live.  You have to be prepared to weekly commute.  When I started contracting, I was living in the West of England, and working in Calais, France.  So every Monday, I'd get up at 4:15 am, and drive three hours, so as to get to the tunnel by 7:30am, and be at my desk sometime after 9 - the French being one hour ahead of the UK.  Then on Friday, I'd leave at 5pm, and get home at 8 or 9. I then moved house, to East of London, and lo and behold, got a contract in the West Country.  So I ended up doing nearly the same commute, but in the other direction!

    Agencies

    Viewed by some as a necessary evil, if you're a freelancer, then the chances are you'll have to work through a recruitment consultancy/agency.  To be honest, it is very difficult to get contracts without agents, and, having one done a stint as an agent, I can tell you it's pretty horrible job!  Agencies charge the client more than they pay you - well, they have to make a living, they don't do it for free.  Usually, that markup is in the region of 15-20%.  It does happen, though, that it can be 33% or even 50%.  If you're getting your rate, then you may not care.  The difficulty is, you could actually be costing the client more than the chap sitting next to you.  Guess who'll be first out of the door when budgets are cut?

    Agencies will usually factor your invoices.  This means that they pay your invoice, before the client pays them.  This gives you added security.  Agents are also useful if you want to negotiate with the client.  First, they're very good at negotiation - probably better than you - second, they're removed from the coal-face of the job, so they have a more neutral position than you. 

    Conclusion

    So, there we have it.  A few pros and cons of the freelancing life.  I love it, and wouldn't really want to be an internal employee again.  But it isn't all roses.  There is a price to pay, and not everyone thinks it is worth, or is suited to the uncertainty.  If you're thinking about going freelance, consider long and hard on the effects on your family.  What will you do if you're out of work for 3 months?  What will you do if there's serious illness, or you have an accident?  Can you handle having to prove yourself in each new place?  Can you handle not being part and parcel of the client's organisation - perhaps not being included in briefing meetings, or the Christmas party.  Many people go back to the security of a permanent job after only one or two contracts.  If you're going to take the plunge - make sure you count the cost.

    Consider the following fragment of coding.

    DATA: v_matnr TYPE matnr,
          v_ekgrp TYPE ekgrp,
          v_count TYPE i,
          v_value TYPE p LENGTH 8 DECIMALS 2.

    ...
    PERFORM myform USING v_matnr v_ekgrp v_count v_value.
    ...

    FORM myforum USING i_matnr
                       i_ekgrp
                       i_count
                       i_value.
      DATA: l_result TYPE p LENGTH 12 DECIMALS 2.
      l_result = i_count * i_value.
    ...
    ENDFORM.
    If I run the Extended Syntax Checker, I get the following message:
    Program:  ZMZPROG_STATUS  Row:   57 Parameter "I_MATNR" is untyped. 
    Static type checks and optimizations,
     therefore, cannot take place. 
    If a type cannot be declared, use the type ANY.
     ANY. use the type ANY. use the type ANY. 
    use the type ANY.
    Internal Message Code: MESSAGE GUX
    (The message can be hidden with "#EC *)

    Usually, it's a good idea, and probably part of your development procedures, to eliminate any such messages.  So, what should we do for this one?  One obvious action would be to make them all TYPE ANY.  The message itself tells us that this will make the message go away.  ( Using the comment "#EC * is definitely not the right way to proceed, and will probably get you into trouble with your quality team.  Only suppress Extended Checker messages, when you can justify it from a programming point of view. )

    You most definitely should not use TYPE ANY for typing your parameters. The reason why you should use specific types, is something called "type safety" - you ensure that the type of your calling parameter matches the called parameter at syntax check time. Errors picked up by the syntax checker are much more easily picked up than runtime errors.

    Let's say I do use TYPE ANY, but make a mistake in my PERFORM statement, by getting some of the parameters the wrong way round.  Like this:

    DATA: v_matnr TYPE matnr,
          v_ekgrp TYPE ekgrp,
          v_count TYPE i,
          v_value TYPE p LENGTH 8 DECIMALS 2.

    ...
    PERFORM myform USING v_matnr v_count v_ekgrp v_value. " parms in wrong order
    ...

    FORM myforum USING i_matnr TYPE ANY
                       i_ekgrp TYPE ANY
                       i_count TYPE ANY
                       i_value TYPE ANY.
      DATA: l_result TYPE p LENGTH 12 DECIMALS 2.
      l_result = i_count * i_value.
    ...
    ENDFORM.

    This will syntax check fine.  But if you tried to run it, you'd probably get a dump about arithmetic conversion.  Or worse, you wouldn't get a dump, but you'd get strange results - perhaps once the program is productive - that requires analysis and debugging to track down! If, on the other hand, I'd been more specific in my parameter types, like this:

    DATA: v_matnr TYPE matnr,
          v_ekgrp TYPE ekgrp,
          v_count TYPE i,
          v_value TYPE p LENGTH 8 DECIMALS 2.

    ...
    PERFORM myform USING v_matnr v_count v_ekgrp v_value. " Parms in wrong order
    ...

    FORM myforum USING i_matnr TYPE matnr
                       i_ekgrp TYPE ekgrp
                       i_count TYPE i
                       i_value TYPE numeric.
      DATA: l_result TYPE p LENGTH 12 DECIMALS 2.
      l_result = i_count * i_value.
    ...
    ENDFORM.

    Then a syntax check (just an ordinary one, not the Extended) would have picked up the error.  An error picked up at syntax check time is much easier, and therefore cheaper, to fix than one picked up at runtime... when the program fails in production!  An artificial example, sure.  But if the FORM has a long list of parameters, you can see that it could easily happen!  ( This is one reason why I much prefer programming in ABAP Objects - in that context, in most cases, the names of the parameters are visible in the CALLING code ).

    So, when should you use TYPE ANY?   Well, you'll notice in the definition of i_value, I could have TYPE p; or been even more specific and used a predefined type of p LENGTH 8 DECIMALS 2.  But by defining them as NUMERIC the form can be used a v_value of any numeric type. That is, I, F or any form of P.  This is design decision, according to the requirements of your program.  Use type ANY when you really mean that the parameter could have any type.  Also, have a look at the generic types - like NUMERIC, DATA, CLIKE

    The general principle is to use as specific a type as possible in all your parameters.  In this way, you'll have introduced type safety into your program, and you're programs are less likely to have runtime errors.