Skip to Content

Reflections from the Developer’s challenge

Wow!   That sums it up in one word.  It was exciting, incredible, and exhausting.   I was looking for a “challenge”.   I found the challenge plus so much more.   The people were amazing.   The food was good. The hours were long.   The end product was worth it.


I’m a SAP customer.  I was lucky enough to be selected for the developers challenge.   Wasn’t I? 


Day One:


They started us out easy.   They are very deceptive that way.  The first day we watched two different and very good presentations.  You can read about the presentationsSAP Developer Challenge Kick-Off and SAP Developer Challenge Theme One: Social Computing.


We met with our teams the first time.   We discussed our name, and what we would like to develop.  Who would have ever thought it would take a while to decide on a name?  We decided since we where originally team six, and had six people in our team that we would be called “Six in the city”.  The naming took some extra time, because we were constantly switching gears and talking about what we wanted to develop.


We went to the computer museum and had a nice dinner.   This was to be our last “free day”.  I believe we got finished early at around 8:00 or 9:00 PM.


Day Two:


Some more very good presentations were given.  Mobile computing and SAP Developer Challenge Theme Two: Sustainability/Green IT were the topics.   Again details on the presentations can be found here.  


Our teams had to present before a board on our idea.   That would have been nice.  But first we had to agree on an idea.


We spent many hours going back and fourth on what we should create.   .   We finally decided on using voice recognition for mobile phone to call in a request for a report.   We were going to use Java, and Business Objects to make it all work.    Or at least that was what we were going to do.


We presented before the board later that day.   It was very interesting.   We found out they required a business reason for our product.  Go figure!   We also found out that we were being too technical in our approach.


So it was back to our den.  Also known as the room we had been assigned for the duration.   We were throwing out and rejecting ideas left and right.   We gave up on compromise and our group split up.  Some of us doing coding for a carbon design.  Some of us sticking with the original idea of voice to reporting.   Probably not one of our better ideas.


Around Midnight we got some help.   We mapped out each of our ideas on the board, and a third party talked through each of them with us.  Success!  We decided to integrate the voice recognition with plant maintenance.   The idea was that when a problem was found a person on the line could pick up the phone and call it in.   The system would determine the location, severity, and who called based upon the phone call.   I’m sorry to say I still can’t tell you exactly how we parsed out the information from the call.   It was based upon fuzzy logic.   We used a third party tool to generate the voice text into an e-mail account.  Once the problem was determined it would be displayed on the blackberry and iphones.  The first technician to accept the work order would own the work order.  After 1 hour if no one accepted a blackberry message would display on the managers blackberry.   The technicians would be able to display their work for the day, along with a list of work orders.


Day three and four:


The days became a blur.   I know we met at 7:30 AM and coded until around 1:00 am the next morning.  Saturday and Sunday – Monday morning.


Our application was working by Monday morning.   We all got goofy and learned a lot about each other.   It was a bonding experience.   I found out just how good all of my team members were at coding.   We laughed a lot.   And it was fun.


Amazingly by Sunday we were not secretive about our idea, and we were receiving and giving help to other teams.  Again the talent here was amazing.


The scope of our project shrunk.     The voice recognition would stay the same.  We were going to send messages to the technicians to accept and confirm the work orders.


We all were drinking plenty of caffeine and Red Bull to stay awake.


There was a camera team running around to take pictures of the teams, and video.   Now I know what the reality TV people feel like.  Eventually we ignored them.  But it took some getting used to.


Day Five:


SAP Developer Challange Demo Jam 2008 Webcast.   Time to get ready for how and what we were presenting.   We got there at 7:30 to get ready.   By the time our time slot for our practice run on the presentation stage came along we were ready.


Our presentation went fine.  There were not any problems.  We made our time.   The problem was our presentation was boring with a lot of power point slides.  So we decided to change it.


That was a good decision.  However we were changing it just prior to all the teams presenting.   We did not practice it.  Not once.  I don’t think I’ve ever done that.   Presented without practicing.


As you can imagine our presentation left out a lot of our actual content.   My suggestion to everyone and anyone who asks is not to change your presentation without at least one dry run.


Most of the presentations went without any hitches.   And then everyone sat nervously while waiting, and waiting for the judge’s decision.   As you have probably guessed or read prior to this, we did not win.


We didn’t win?   I know I walked away a winner.  I learned many new things.  Met wonderful and talented people.   I had a good time.   And most importantly I walked away with an application that I may be able to use pieces from it for my company.  


Would I do it again?  Probably.   I’m still recovering.  I slept all day the first day I got home.   Now I know what to expect, and to quote a team mate it was, “Crazy”.

You must be Logged on to comment or reply to a post.
  • Really appreciate your reflections here. Some of us (myself included) attended the event remotely by way of ustream.  Many here read the blogs.  Interesting to have a behind the scenes look.  It would be even more interesting for you to flesh out how you actually mapped out your development, how you moved from technical to giving a business plan. (that’s bridging the geek gap, I guess 🙂 )
    You’ve answered a lot of my questions about how it felt to be a participant. I’d love to understand the  specifics of your entry even better from a technical way especially.
    • Thank you for the comments.

      Once presenting to the panel.   It was apparent that we needed to have a business reason for the voice recognition.  Voice recognition was an idea that Yonel had thought about in some depth.   He even knew of a third party that translated voice to text with a good deal of accuracy.   He had worked with metadata, and had a plan on how that could be used with “fuzzy logic”.

      Of course as per my blog we needed a business problem that we could solve.  We went back to the drawing board. We looked at some of our other ideas. We were thinking about: Carbon tracking, Carbon accounting, hazardous material tracking, and predication sales.

      We talked about realtors needing to get information quickly while on the road.  We talked about executives needing information while in meetings.   Each of these business reasons seemed king of weak.  Then we came up with carbon tracking and over our carbon limit then sending a message to the blackberry.  The executive could then get reports via the blackberry. 

      Then we looked at what would it take to design them.   What technology would we need? Did we have it available?   Did SAP already offer a similar solution?     How long would it take to build?  We went through each suggestion answering those questions.  In predication sales, it seemed like SAP had already done something similar.  Carbon tracking – we watched a presentation on carbon accounting, and the whole concept was too large to work on a two day solution.   Hazardous material was not well thought out.   I’m not sure why we discarded the realtor suggestion.

      So – we decided to think about the projects we were each working on.   I have a project for next fiscal year regarding plant maintenance and MII.  The project is to put the plant maintenance information on an MII screen for ease of use.   Eventually in the future we were going to move it to a mobile device.  Aha!  We now had something we could easily link to voice recognition.   We pulled voice recognition easily into the plan: it seemed to fit.

      We then mapped out who was doing what.   Assigned each of the team members to a task.   We had to know where the points were where we integrated.   We set up a frame work for those points.   Daniel created a “test” data base to work from on his server while Baski and I developed in SAP.   Baski also spent some time learning about how to code on the Blackberry.  Michel worked on the web applications.  Yonel converting voice to text, and getting it into Daniel’s server.   Fletcher was our presentation and documentation guy.  He and Michel kept us on task.  (Sorry guys if I missed something each of you did.  Some of the days became a blur.)  We had to divide and conquer because of the time limit.

      As far as architecture on what we did – you know the technical side –  I can give you very little at this point.   I’ll try to follow up later.   We split the work, so I have very little information on what the others worked on.   I however, have all the code.  I plan on pulling it apart and looking at it after I get caught up at work.

      As for my piece – I used function modules and BAPIs to accomplish creating and updating the plant maintenance order. 
      Hope that answers some of your question.   I’ll try to follow up on the technology that we used.

      • Also –

        Our business problem:

        It takes days or hours to complete a plant maintenance order.   The line person may call to the dispatcher.  The dispatcher enters and then prints the work order.  The technician goes to the plant maintenance building to collect the print out.  They go fix the line.   Then they take a signed copy of the paperwork back to the maintenance building.   With people on the move, this could take hours just to get in the technicians hands.   Then the confirmation may not get the maintenance building for a while.

        The solution:

        A line person calls in a problem.   The third party software converts the message to text.   This includes using “fuzzy data”.   If the word is jump, and the text ends up lump, then the fuzzy logic can convert the word from lump to jump.   The only thing the line person has to know is the asset tag.   The asset tag will be converted to the location in SAP.  A work order is automatically generated.  That work order is sent to all the technicians blackberries or iphones.  Once someone accepts no one else can accept.   The work order status is released.  When the work is done, the technician confirms the work order.  The work order operation is confirmed.

        If the line person says something like “never mind”.  The software does not create a work order.

        Ideas for future development:

        Very interesting solution.   We can use it to develop even more remote applications for plant maintenance such as order and looking up parts.

        • You Rock!
          Just was thinking that collaborating further with the community (in the wiki?) might be a direction.  It would be good to have some continued looks at this from a community perspective.  Maybe you will pick up the challenge and make this into a new community project to be developed further by your cohorts here.
          • Thank you!   It sounds like a great idea to me.  As soon as the dust settles, I’ll try to figure out how to make it a community project.  (I’m still catching up on my “real” work at Perrigo.)
  • Hi Michelle, thanks for sharing your experience at the Developer Challenge.  We all had a lot of fun and I really enjoyed watching the creative / development process and seeing the amazing solutions everyone came up with in the end.  I was blown away by the creativity, technical skills, teamwork, and quality solutions everyone showed.  Great job!


  • thanks for your perspectives on this event!  great to hear from the customer’s perspective on the SAP Developer’s Challenge! 


  • That sounds incredibly intense!  My SAP competition experience was completely different.  We were able to get feedback on our initial idea, and then have another month to plan what we were going to say to the judges.

    However, I think this would be fun.  I feel like I can perform well under pressure, mostly because I have done school projects under crunch time.

    Fun read