Archive for the 'Past Life of Ben Sanders' Category

Salesfarce.com - The True Salesforce.com

Published
by
Ben Sanders
on October 2, 2008
in Past Life of Ben Sanders and WTF
. 1 Comment

SalesFarce.com - Failure on Demand

Boy do I have stories about this one…

I remember the day that our company chose to use SalesForce.com (SFDC) as our CRM for lead management. Basically they wanted to get rid of our old back-end system and “upgrade” to a web version with a new supplier. After a brief protest from research in a past life around SFDC, I reluctantly accepted the task to work with them.

It started off fantastically. We met with two very promising people. One was an architect and one was a configuration expert. We met with our business users and mapped out how we would exchange XML data. Our task was ridiculously simple - to have a common lead schema for vendors to submit leads to SFDC’s API. Then their API would do its magic to place the lead in the correct place(s). Then, at a later time, when our sales agent wanted to quote a lead on a product, they (SFDC) would submit the selected lead’s data to our web handler that starts the sales process with our transactional system.

Let’s talk about the leads CF: SFDC explained they don’t have a web API for leads. But they didn’t mention it up front. They mentioned it late into the project. Instead they sub-contracted some no-name company by a guy named Server-On (<- that isn’t anonymized, it really sounded like he was Server On) to write a C# web service project that talked to their API, because we wouldn’t be able to comprehend it. Once I learned of this, I laid the rules for 3rd-Party work. This included fixing code analysis warnings (some could be suppressed - we weren’t Nazi’s) and writing unit tests (80% coverage - sorry Phil Haack). Well they had us attend a WebEx conference to see what they had done. I was incognito as Vic Romano and my lead was Kenny Blankenship. There had not been any attempt at checking, let alone fixing, code analysis errors. They did have unit tests! It consisted of one class named {Something}Test that called another class with some made up variables. And it only called one or two methods in total. Nice… So we pulled Presley off of his failling Callidus project to write a web service that validates and transforms (novel ideas right?) our vendors’ submitted lead data and submits them to the SFDC’s 3rd-Party web service. Oh, and at the last minute, I was notified that this 3rd-Party web service will be hosted on our servers.

Now onto the real pain…the web service that passes a product and lead data from SalesForce.com to our transactional system’s handler. They assigned this developer Crumbie. Crumbie was presented to us as a seasoned developer. Oh, and they yanked the architect from us. So Crumbie and my team of three (not counting Presley) were trying to make this work. My lead, Mr. Bitterman was the overseer, R&B was writing the integrations with our transactional system, and Cornhusker was my middle-man, writing all of the integrations between SFDC and us. So it starts off with us having numerous sessions to bring Crumbie up to speed on what we’re trying to accomplish. We find out very quick in the process that SFDC had a terminal flaw in their design. We needed a combo-box that listed our ID-Product name name-value pairs. Easy right? Not so much. SFDC doesn’t support ID fields. All…let me say that again…ALL fields in SFDC are text, not GUID/Int/ID driven. uBersweetness… So then we got past that hurdle somehow, and then Crumbie is pointing his finger at us saying our end-point is giving hard exceptions. Mr. Bitterman quickly gets me and Cornhusker involved, because they can’t recreate the exceptions. Crumbie confirmed that he is sending the XML in the body of his request. I told Cornhusker to introduce logging into his service. I want their XML string logged first thing, then he can do what he wants with it. After doing this, and Crumbie having another exception, we looked at the log. it looked like this:

<html>
    <body>
        <?xml version="1.0"?>
        <QuoteRequest>
        ...
        </QuoteRequest>
    </body>
</html>

So the rockstar developer did as told…he put his XML in the <BODY> of the request (ROFLMAO x 10000). Mr. Bitterman quick shot him a lengthy email with links to w3schools.com and the W3C spec regarding XML. He also included references to XSD’s, as Crumbie was submitted XML that was invalid. The email was a masterpiece - it remained on my cube wall for weeks.

After months of this pain, we got to meet Crumbie face-to-face. I asked the begging question, “So how long have you been with SFDC?” The answer, “Oh, about four months now.” Excellent. Just excellent.

And the last pain that comes to mind is that another area of our company inherited a bunch of Java code for their integrations. They must have forgotten that we told them upfront we’re a .NET shop.

In summary, this is obviously a combination of being a smaller SFDC customer (hence the 4-month old developer), them getting too big, too fast and not being able to have quality architecture (i.e. the lack of ID fields), and terrible project management.

If you ever want other thoughts, check out thoughtsonsalesforce.com.

Good times, good times…

Callous Callidus, unTrueProducer, and our very own SDLC!

Published
by
Ben Sanders
on September 29, 2008
in Past Life of Ben Sanders and WTF
. 0 Comments

For “Presley“…may where he ended have mercy on his tortured soul…

So I was working as the EBusiness Development Manager at this medium-sized insurance place in Des Moines. We had several projects failing in other areas, and we were affected by some of their pain. But one, in particular, stuck out. We were partners with Callidus to use their agent commissions/compensation system called TrueProducer. My team’s part on the project was very small - we essentially needed to hook our E-Contracting up to Callidus’ web service layer (or so we thought). So I grab my team lead “Joe”, and my analyst “Jane”, and we sit with the Callidus team and our agency group in a meeting about this very subject. After a demo of some poorly written software, we grilled them on capabilities for E-Contracting. Since their head engineer on this project answered our questions correctly, we were relieved and headed back to await the green light.

Weeks later, we get the green light. So we ask where their API/WSDLs are, just like any normal development group would. The response from Callidus’ point person was “Um…web services? We’ll have to get back to you.” So they get back to us and now we’re talking flat files since they won’t have the web services they said they had until 2009 (or later). Oh yeah, and we found out that the legal contract they signed that stated SQL Server 2005 and it was hosted in our shop, basically meant to say Oracle and Callidus’ll host it.

So after hours and hours of meeting with out Agency Support team, I assign my Contract-To-Hire, “Presley”, to this initiative. I figured that the agreed-upon solution just needed to modify existing E-Contracting screens to render a PDF file that could be entered by hand into Callidus. Not the most automated or efficient, but it would do.

So throughout the duration of this seemingly neverending project, “Presley” grew more and more frustrated. Finally I inquired into why. Now, understand that “Presley” and I share a similar sense of humor and I had been his beating post for his frustrations, but rather than share the individual experiences, he concocted the Software Development Life Cycle (SDLC) pretty accurately for having only been with us for 4 months. I wanted to share it with you:

  • Gather requirements
  • Gather more requirements
  • Assign Project
  • Begin coding
  • Change requirements before any useful code has been written and do not tell the developer
  • Keep coding with a confused but happy look on your face
  • Change requirements again, this time eliminating an entire requirement that has already been coded
  • Keep coding with a straight face
  • Change requirements and also add some new requirements
  • Keep coding still with nobody having seen the code
  • Create a new task with other additions to the same code that has not yet been seen or approved.
  • Keep coding, but much slower and in disbelief that a place functions like this
  • Add more items to a task and say it’s the final list of items to work on.
  • Keep coding but do a lot more internet surfing since you realize this crap isn’t going to end well
  • Add more items to the list which you just said was final for the second time but mark it as TBD
  • Stop coding because you’re just pissed off
  • BA Asks developer how progress is coming on the task where half of the original items are crossed out and some items still are marked TBD
  • Testers ask the developer how testing is going.
  • Developer is so confused he looks for a new job and give up working on the project.
  • BA thinks project is still coming along nicely even though no coding has been done for the task as it is listed now.
  • Developer’s supervisor quits in disgust  nobody cares but his team
  • Developers leave one by one
  • Company keeps running with idiots at the wheel
  • Life goes on

So Long…And Thanks For All The Fish

Published
by
Ben Sanders
on September 28, 2008
in Past Life of Ben Sanders and WTF
. 1 Comment

I was just talking with a former employee of mine. He worked for me while I was at an insurance company in Des Moines, Iowa. He is based in Cleveland, OH. So it got me thinking that I really leaned a lot while I was there (all 1 year and 1 day of my employment!). If you’re in IT - you should heed my thoughts carefully:

  • I learned that you cannot hire a CTO just because he worked for Google.
  • You also should not hire a CTO because he was your neighbor.
  • Project.Deadlines != Management.GetRandomNumberBasedOnWind();
  • It’s funny to see the head of the architecture group not understand what an Astronaut Architect is.
  • CIO’s that say “That’s the problem I have with this place” repeatedly should either do something about those problems or be sacked. I prefer the latter.
  • Hiring Business Analysts at the last minute to meet a milestone is generally a bad idea. Keeping them after several failures is also just as much of a bad idea.
  • If you love your sales organization, or just love sales, for the love of all that is technically holy, do not use SalesForce.com as a partner. Unless, of course, you really don’t care to have primary keys, you want tons of batch jobs on your own servers, and you just love having tons of code without Unit Tests or with Code Analysis warnings. For inquiring minds - I’ll blog about this one later.
  • Giving your developers one holiday (Christmas) but taking away their entire month of March is extremely hazardous to your code base. Also expect an exodus soon afterwards.
  • If you ever work for a company that has an EBusiness Operational Committee (EBOC) that meets for 1 hours every Monday and accomplishes nothing but causes more chaos - run like Hell!

So to kick my blog off right, I was reminiscing about some memories from the last year. I really think anyone wanting to leave that IT Third Reich is really going to be better off. The grass may be just as brown where you are going, but you will at least get your weekends and evening back!