Skip to Content

Just a developer?!

I have heard that we “the technical group” do not need to understand the project from the beginning.  To streamline the process, the “functional team” will be able to write the specifications and hand them to the developer.  Or even better – the functional analyst tells the programmer exactly what needs to be done, and the programmer writes the specifications.  The functional person then reads them and revises them.   Any programmer will work.  Ahhhhhhhhhh!!!!  I’m stomping my feet and jumping up and down.  Maybe even doing a little dance.


<u>In MY perfect world</u>, well there are no customers, no specifications…  OK, that’s not going to happen…   Really what I would like to see is mutual understanding and respect.  The functional person gives me a high level view or detailed view of what the customer wants, and we work together to make it happen.  He/She respects my technical knowledge, and I trust their SAP knowledge.   We worked to decide what technology is appropriate.  If it is a user exit, badi or other…  And they let me do the technical side.  They don’t spoon feed me all the details.  I even get to  help work on the technical specifications.  Not wait for someone to give it to me.  Just because I’m <u>ONLY A DEVELOPER</u>, doesn’t mean that I don’t have ideas on how to provide a solution.  Last I knew, I did understand some of the various technology.  Do I know it all?  Absolutely not.  And I never will.  But I like to weigh in on the technical design.  Oops, my perfect world.  In my perfrect world, I would give my input and work together with the team for a good solid technical design.


<u> OK – Back to the normal world and my rant:</u>

When I develop, I like to know the entire process.  I have to understand how it all works, so I can make sure my code works correctly.   For new development I usually have questions.  Questions like what are you trying to do?  Why new development?  What screens are you basing this on?  These are all normal questions for me to ask.  Then I go on to think about the technology that is being requested.  What language should be used?  Is it a web app.?  Should it really be in BI?   ALV? Object candidate? Web Dynpro? MII?…


A side benefit of the questions is that I can help problem solve when issues arise. I understand where the problems are coming from.   That’s just how I develop something new.   It is second nature to me.  And it makes sense to me…  If the developer doesn’t understand the process (project purpose, purpose of the code they are creating), and blindly codes, there are problems later.   I can almost guarantee it.


If you have read my various titles from above, you may have noticed (or not) that I worked on the functional side of SAP for a couple of years.   The lines between a developer and a functional team member are very grey for me.   Even the lines between technical SDN and business BPX.   I do know different processes / configuration very well.  Depending who I am working with, I use the skills that I learned as a business analyst. 


I made the decision that I would rather work on the technical side of SAP.  I like to be hands on, developing code, and learning about new technology.  However, that doesn’t mean that I don’t like working with the business or that I can’t grasp the process.  It just means I love the technical pieces / parts of SAP.  They are changing all the time. 


So maybe I’m out of my mind, and I shouldn’t be concerned about the process before I code.   Some of my own technical colleagues feel that way.   


**Side note:  It does depend on what I’m doing.  I may not have to have a lot of knowledge about a process.  If it is a quick fix, I don’t worry about the entire process.  I just worry about how my program has to function.  I’m talking new development, here.


I prefer to be in on the project from the point the project team decides that there is custom development required.  “WHY?”  you ask.    Many reasons: It is so much easier to let the project team know how much effort something will take.  I have also heard how easy it is just to “throw that together” in a program.  It will only take a couple of hours.   Development comes with a cost, and there needs to be an understanding of the cost up front.  There should be a high level estimate on how long the development will take.



You must be Logged on to comment or reply to a post.
  • In my experience, there are 2 kinds of developers.  Those who just like doing what they are asked to do and those that like to get involved and understand what the development is for.  I agree that the latter makes a better developer.  Your right, the program will need reworked if the developer is just doing what the specification says to do.

    By the way, since you are quoting the Borg(I think that's right), they just do what they are told without thinking about it.  Sorry!

    • Thank you Brian! 

      You are right.  I am quoting the Borg.   I sometimes feel like I should just do what I'm told without thinking.  Very rarely, but sometimes I feel like that.  And sometimes, I have to just program without thinking. 

  • Michelle, I hear where you’re coming from but I think it really depends on the type of developer you are. As an in-house developer what youa re saying makes sense. Why? because this is an application and process that you will be working on in the future, modifying, supporting etc. But looking at it from a management standpoint as a developer I would need you to focus on being the best technical developer there is, and I would want our functional people to be the best process experts, as this serves the company best. Is there overlap? Certainly, I think as you said it's important for there to be collaboration, a functional expert develops a functional spec comes to you explains the process and then allows you to make the technical decisions, technology to use, language, algorithms to design etc. and I think also provides constructive feedback,  this model works because both your strengths are utilized. Remember not all developers had a functional background previously, so your situation is different for that reason as well.

    We deal with this in our own work as I am regularly asked when managing projects for clients why the client in-house developers are present during blueprinting but not our consultant developers, this is because the in-house developers are really different they do serve multiple roles. As consultants our developers are used to coming in when the spec is done and after formal handoff, working out a technical design and coding. As a project manager this means I only engage our developers when they are needed, they are not needed for process design, they are not the experts (now in some cases I know of developers who might qualify as better experts then the functional person but that is an exception), of course they would love to sit and learn but that is not the best way to use these resources and also keeps project costs lower and also means more overall work can be completed.

    My 2 cents.

    • Hi Phillip,

      Now you are sounding like an SAP person.  It depends.  🙂

      I do see your points as valid.  Our consultant developers do not need to know the process.

      I'm not agreeing that I don't need to understand what I am developing.  I agree to disagree.

      I love to hear from the "other side".  (Of course you are on the dark side.)    It makes for an interesting debate.

      Thank you for your two cents,


  • Dear Michelle

    Do not let them grind you down!
    I get in trouble all the time for rising above my station as a developer. I too was on the functional side and have a very good knowledge of the business, as I have worked for my company for 19 years, and not even in IT for the first seven of those.
    Several times I have become aware of a business problem that needed resolving but no-one was looking at, so I wrote a program to fix it - in my spare time - and then presented the solution to the business analayst as a fait accompli. The trick is to do it when there are several users who will benefit from it in the room, as then it cannot be swept under the carpet.
    However on paper I should not really be doing this. Luckily the CIO has always seen the benefit, and we are fairly laid back in Australia. If someone works in a very red tape organisation they could get into trouble over showing initiative. I had a colleague join us straight from working in the government and he almost fell over dead with shock when he heard a business analyst say "well, that requirement came straight from the business, and it's in the technical specification, but it's nonsense, so don't do it". It was nonsense by the way.
    Clearly I see the line between developer and business analayst as very blurry indeed, but that is just because of my background.
    I bet hardly any companies let their developers do this, but I love going out to the plants and seeing people use software the development team has written, often that is the only way you become aware there are problems with it, and also you can see first hand when people are doing complicated workarounds e.g. copying down a number from one SAP screen and then typing it into another SAP screen ten seconds later. Once again we are lucky our CIO sees the benefit.

    Cheersy Cheers


    • Thank you Paul!

      What a great response.   (Of course, I would say that, as you are giving a good example to support my blog.)

      I'm glad I'm not the only one around that likes to see the process along with the technical side of things.

      I'll try to stay positive, and keep educating people.  Good idea on the way to cut red tape.  I like it.  (And may use it.)


  • Was wondering when the first business process expert/ buisness process analyst was going to counter you and say "in my perfect world, there would Some would continue the debate by asking: "is it easier to train a developer to understand the business needs than it is to train a biz person to code?".  Thanks for stimulating a lively conversation here.  We were having an internal conversation today about the concept of having team members work to their strengths and allowing for those that have strong skill sets to focus on using them.  Interesting that it is more often developers who feel they can live without business analysts or rather they can easily fill the role.  I hear less of the inverse.  That's to say business folks who deem technical folks unnecessary.

    • 🙂  I love it!  Great response. 

      I've been hearing for years that we are not going to have to do any custom development.  I haven't seen anything without some enhancements that needed to be completed.

      Great idea about having team members work to their strengths.   However, I would argue that part of the developer's strength is the ablity to drive the technology, and understand how the program/enhancement fits into the larger process.  At that point they can suggest different techniques for making the custom change.  The developer does NOT develop the process. But they do estimate hours, and think about what technologies make sense with the process that is mapped out.

      I really don't want to fill the BPX/business role.  I HATED going to all those meetings.  I didn't like playing the go between between not doing customization and keeping our internal customers happy.  People who can do that are amazing.  I can and do work on configuration when needed.  I just don't like the part where nothing gets done except for meetings for months, years, decades...

      In my company we try to keep the customization down.  Customization = more support dollars.  Harder to upgrade....  So their is a big push back on the internal customers to avoid customization.  It was hard for me to say "no" when I knew it could be done with customization.  Even harder to have days where I felt I didn't get anything done.  (All meetings.)  It takes a certain kind of person to like doing that.  Some one into self inflicted pain, I think.  🙂

      Sorry guys - I didn't mean we didn't need you.

      Clarification:  My perfect world would be me creating programs without any INTERNAL customers.  And that means free of specifications.  MMMMmmm no internal customers, no need for process, no need for BPX people.  Maybe I am saying in my perfect world, no BPX people.  But I wouldn't get paid in my perfect world.  That would be a problem.

      I think you haven't heard the inverse that the BPX can do the programmer role, because you are a BPXer.  I hear it all the time.  Not really that the BPX person could do the programming, but that the programming is easy to do after the specifications are written VERY detailed.  (Detailing the exact user exit, BADI, and/or the BAPI, that it should be done in basic ABAP, not anything web based..  etc.)  On the other side, I haven't heard the inverse that we don't need BPXers, because I moved back to development a couple of years ago. 

      Personally I would think the BPX strength would be the larger picture.  Where I would see a fix to a problem, I may fix the small problem.  The BPXer would take it a step further, and look at the big picture.  What is causing the problem?  Is it a problem with pushing many buttons because earlier in the process something wasn't done?

      Again to me it depends.  Do you want/need a big project?  Or can a quick fix work every now and then.  There is a time and a place for both.  But if I don't know the process, I can't understand when to make that small change, and keep making small changes, and when to not make the change.   By not making the change it could bring to light the need for looking at the bigger picture.  I don't need to understand it all.  Just how my piece fits in. 

      Wow!  Long response, you have me thinking again.   I may not be making sense either.  I kind of talk around and around on this one.  I'm reading some great responses.

      I would LOVE to hear any comments on either side.  I of course reserve the right to disagree.  🙂

      Thank you Marilyn!  I'm re-thinking the issue again.

    • Marilyn, we have been talking about eliminating the need for developers forever, back in the 80's it was CASE tools (I had one) interestingly they look similar to all the BPM tools available now. The vision was you designed your process using a flow chart and code came out the other end and no need for a developer. ƒº IMHO A developer will always be needed.
      I also believe we will never eliminate the BP Analyst, I have the reverse experience as Michelle, I was a cracker in school before joining the working world (developed some nice shareware), I was not looking for a job in IT but kept developing in my spare time at home.  But since I am now more focused on the analyst end let me say that as an analyst I would be focusing my education on research in operations, supply chain etc. accounting so this would differ from a developer. An analyst needs to be an internal process expert with the big picture. The analyst probably is an experienced individual plucked from the operational end of the business and can relate to what happens on the shop floor etc.
      A developer on the other hand is going to focus his/her attention on technology, optimization of algorithms, language enhancements, SQL optimization etc., The developer is the internal technology expert on the technologies used by the company. The developer is usually not someone pulled from the operational end, of course there are always exceptions.
      What I agree with Michelle on is that development is a collaborative effort, yes a spec is needed but then when handoff occurs I think a developer like Michelle has a lot to add because of her experience and this experience is something to be taken advantage of, in our practice our senior developer sits in on spec handoffs and we have always updated specs based on his comments or things he sees were missed by the analyst so it¡¦s not as cut and dry as here¡¦s a spec, get coding.
      These lines are going to be fuzzy depending on the company and management. In small to mid-size companies it is very common that a person wears both hats whereas at larger companies I would expect or have seen in my experience that these are two separate roles.  My only thought since I lean towards these being separate is that combining the roles means the person is trying to handle two disciplines and the old saying ¡¨Jack of all trades master of none¡¨ comes to mind.
      Great conversation.
      • Some more good comments!

        Thank you Phillip. 

        By the way my title is really Programmer / Analyst.  The other title that overlaps is business / Analyst and then there is a Business Process Architect.  Our lines are very grey.  At least I think so.

      • Philip,
        I guess we go round and round ourselves trying to determine if there need to be real demarcation lines drawn in the community spaces or whether it best not to isolate the so-called BPX content from the SDN content because there are enough folks doing both roles who need access to both kinds of information.  And we've had complaints from both sides (functional and technical) that complain of too much deeply technical stuff mixed with business process conversations, or too much theoretical, methodological content where practical application and development knowledge is wanted.
        That leads me to think that the best solution for how to organize content, discussions, and collaboration activities should be based on some kind of personalization and filtering ability that each member can employ based on the use of tagging, feeds and establishing connections with one space or another or even multiple ones and creating community with their own respective "peeps" or colleagues as a matter of individual choice.  There will always be some neighborhoods that are more comfortable for some to live in here than others.  But there are also a couple of "jack of all trades" members who I see as being the resurrection of renaissance types: good at most everything they do and highly capable of moving between worlds. Yep great conversation with no definitive conclusions because there are very mixed opinions on this topic.
    • "is it easier to train a developer to understand the business needs than it is to train a biz person to code" - yes.  Usually.  If the developer as interpersonal skills! 

      As far as the abolition of development goes - as soon as you allow a conditional (If ... Then ... Otherwise ), or a loop ( Do ... for a while ) - you've got development.  And you've got the potential to do it well, or badly.  The same generic programming skills apply to ABAP as to, e.g. a moderately complex Visual Composer scenario.  It's all to do with computablity, I believe - centred around the concepts of Gödel's "Halting problem".  Some compare development to engineering.  The main difference is, you can't take a bridge, and then use it as a component in another bridge.  So long as you can introduce another level of complexity, you need developer skills.

      What I want to know is: what did all these skillful developers do before Ada and Charly came along? 

      • You mean all those "lazy" human beings who invented ways of automating and easing their lives who thought wheels a better type of encoding than dragging stuff?  Or do you mean those hapless folks who invented by error and thought they were creating celebratory fireworks but instead changed the course of warfare?
        Or I further wonder if this takes us all the way back to the hunters and gatherers discussion.  The original geek vs. suit interchange as Cain and Abel 🙂
        • I've often felt that if it wasn't for us lazy people, no labour saving devices would ever be invented.

          In my first job - system programmer on VM - I spent a lot of time writing little routines to save me the bother of manually administrating user accounts.

          I will work my socks off to avoid work. 😉

  • For me this is an interesting topic as I personally sit on both sides of the fence on regular basis.  What I have found from a developer point of view though is the following:

    - The Business Analyst side fails to prepare the necessary process flows and documentation that allow a developer to understand the process.  In other words that fail to explain to a developer how they expect the business user to use the system.
    - Functional/Process specs should not include information about BADI's/tables or anything custom in detail.  The moment the spec starts listing tables or psuedo code it is a technical spec and not a functional specification
    - Detailed Functional and Technical Specifications need to be written together and not apart.  In my ideal world there is a process specialist working with a technical specialist who bridge the gap together on the solution.  Combining these two roles elminates the ability to have two different thought processes review something similar.  I'm not saying you can't have a BPX, but you still need that pure tech person to challenge the approach.

    - Modeling/Coding tools only work well if you don't want custom processes at this point, in the future this may change.

    On any project the developer should be able to understand the high level process by reviewing the process flows and the documentation being made available.  It is important that people understand how their puzzle piece fits in, or otherwise you run the risk of integration errors due to no one looking at the "big picture" from a technical perspective.

    Take care,


  • Hi Michelle,
    I agree with you a lot.
    I also sit on both sides of the fence but in my case, I did the other way around, I started as a functional getting into technical later. So I see this from a perspective of the functional guy.

    I strongly believe there is this huge communication gap between functional and technical teams. This is costly for the corporation since it leads to longer and more error prone solutions.

    I believe that one way to address that is to stablish a ground level for communication between these teams. And that is one of the things I propose in my SAPTechEd session below:
    CD201 - Best Practices in Development of Business Classes Using Object-Oriented ABAP in SAP NetWeaver 7.0

    By using Business classes, a level of abstraction is built and programs become more "tangible" for all.

    I really recommend everyone to take a look at my session. I welcome you all.

    And you Michelle, hopefully we'll get a chance to chat on site, like we did last year. 😉

    Thanks for your post

    Leonardo De Araujo

    • Thank you! 

      I can't wait for TechEd.  The count down has started.  I actually already have your session on my agenda.  Even before your nice comment.  It's the first one I'm going to!  (After the keynote)

      I would love to talk with you again in person.  I'm sure I'll see you there!


  • The relationship between the functional and the technical is difficult to break.  The concept of BPX is great for management cost savings but its only going to work in a few cases for a short time frame.  If you can find such a person which can do the job of two then they will surely start charging you double before long.  That has been my experience over more than 20 years of IT work.  Ask yourself how well did Java and WebDynpro work with ABAP developers?  Its been several years and its maybe starting to take off now.  I love new technology and I'm always the sucker that wants to try it out.  My first experience was a gui based code generator Oracle developed in the late 80's.  I though by around 1993 the term developer would hold a different meaning. I have to agree and don't believe you will replace the functional and technical team.  But, I do support and encourage the usage of tools.  I think BPX, Visual Composer, web dynpro all are money saving tools but you have to find the balance. 
    • Hi Eric,

      I found your comments very interesting.

      Balance between the fun new technology and the business reasons always seem to come into play.  I like the newest, latest, etc.  You are right!  There is a balance.

      "Know both the functional and technical side charge double".  Hmmm...  I guess that means I get to charge double.  I understand technical, and functional.  I think every developer should start to learn and understand an area of SAP. 

      There have been a lot of comments in this blog about developers who do understand both.  HOWEVER, working together blends the two areas together nicely.  It makes it easier to deep dive into all the new technology for me.  And deep dive into the functional side for them.  I think combining the 2 skill sets makes for a better solution.

      I used to work with RPG.  (Not role playing games by the way.)  COBOL too.   We did it all! Functional and technical.  They went hand and hand. 

      So now things have changed.  I think our focus continues to grow and expand.  We now focus on a lot more than just reports or small systems.  Now the basic functionality is built.  We are enhancing it or adding to it. 

      For the better or worse?   I know people who programmed via punch cards.  I can't imagine the time that would take. 

      So I think the term developer has changed.  By the way my High school BASIC programming teacher told me not to go into programming - everything would be programmed by the time I got out of college 🙂 


  • In my "former life" I was on the functional side of projects and had a strong technical background.  I worked with developers who also had strong functional and technical backgrounds.  In other words we could have switched places if needed, and we were able to discuss both the business side and technical side to come up with solutions.  Now, I teach Computer Information Systems (CIS) courses to college students and I continue to explain to them that they have to understand the business side in order to develop applications that can properly support the business needs.  Some of them would rather just work with technology and not discuss business processes, etc.  Thank you for this posting - I'll show this to my students in hopes that they can see the value from a developer's perspective!
    • I completely agree!  To program a "business application", you should understand your business needs.  Go figure.

      CIS courses.  Wow!  That must be a challenge.

      I think that to learn to program, you have to be given all the information on a problem.  That way you can come up with an answer that is graded. 

      Then you go out into the big wide world, and have an AHA! moment.  All the information for a project/program is NEVER given to you.  Once they learn that, it makes it easier to understand why they have to know the business or process side of things.

      So - it may be a bit hard to get them to understand.  Those that do are going to have an easier time of it when they hit the "real world".

      As for my blog.  I'm not sure it will help them.  But it never hurts to try.

      Thank you for the comments!


  • I always felt and thought exactly the same things, reading your blog was almost like talking to myself.
    I did my best jobs when the functional person briefed me on the general picture and the fundamental needs and motivations for the development in question.
    Thanks for raising this issue, I hope it changes the way those "strong personalities" think 😉
    • Thank you for the nice comment.  It's been a rough week, and it is great to hear I'm not alone!!!!  I'll keep working on changing perceptions about developers.
  • This is funny.  About 10 years ago at Louisiana we implemeted SAP's 4.6 HR and payroll. This was brand new and no other state had done this.  We had no one who knew SAP and many of hte business processes were changed because of implemetation.  So all of the new programmers (one day COBOL, next day ABAP LOL!) went to the functional payroll adn HR master data classes.  We ended up knowing as much or more about time, payroll, and FI than the functionals - so we could identify the problems and write the specs.  Now we have functionals who became business process owners, but still the techs do the research.