I Hate Mr. There Is A SharePoint Product For Everything
I hate you! You know who you are. You are the guy that no matter what comes up, there is your stupid third party solution that although you think will work, it never does and I get blamed for you being inept. You mainly suggest your stupid little solution during project conversation because you know god damn well that the company has already spent an obscene amount of money on it and you really, really are looking for any justification to use it because you brought the solution to the company! Sometimes I wonder whether you just troll the net looking for SharePoint products just so that you have something to suggest and say at meetings.
Let’s take an example conversation of why I hate these types of people.
[Management]: Well Adam, we need to rollup a subset of data across our instance. It’s a one stop shop, where need it done fast, and not very generic in terms of data aggregation. This is a very specific goal folks and has high visibility on this project!
[Mr. There Is A SharePoint Product For Everything]: Corasworks will work great for this! They have some super awesome rollup! Because it has the name Wizard in it! It has to be great!
[Adam]: No, no, no. Don’t you dare suggest that. Mr. Management man, Corasworks software (I choose Corasworks in this example because what I am about to say about them as a SharePoint product vendor is accurate IMHO. And everyone knows I think Corasworks is a stupid purchase decision), under the hood, is absolutely terribly written, mostly consisting of hackneyed inefficient code. I have seen several instances where the product itself was the cause of several acute server issues pegging processes due to poor programming design decisions. They fail drastically in handling basic environmental respect issues, making the product an even poorer decision for use, an example of which is not handling relative URL’s in their WebParts (IMHO, if you are asking for a site reference you should always be offered the option to tokenize this). This is a bad idea, and I would encourage you to disregard that suggestion. In order to develop this will take pretty much as much time as this meeting is going to take, this is not a very intensive task.
[Mr. There Is A SharePoint Product For Everything]: This isn’t a bad idea! It’s called the Data Rollup Wizard! Why wouldn’t it work, it has a cool name! And we already own it!
[Adam]: Which is why you are suggesting it, that’s all this is about. In the time that you are able to get this “amazing” data rollup whatever to work, it easily could have been hand coded to the specifications that management is handing down. Seriously, I don’t think it’s a good idea. I really think that the benefits of doing custom development will far outweigh those of staying within the defined limitations of a company that knows nothing about our business or practices, and I think its wise all in all to follow the concept of “Do not use a cannon to kill a mosquito”, principally when that cannon hardly works and has all sorts of internal design problems. There are several intrinsic benefits to the in-house development decision as well, such as being able to extend the source code to OUR needs, and being able to recycle methods that we write in future development efforts.
[Mr. There Is A SharePoint Product For Everything]: Ok! Well don’t you worry Adam. I have 50 other products in mind that will do this. I encourage us to go buy more crap to make Adam’s life miserable!
Seriously, I am sure if you are a SharePoint developer than you have had some variation of this conversation. There is always that one guy on the team, that no matter what the problem is, he always has a company that offers a product that solves it, even if its not an entire solution, surely it is better than spending in-house development time on it. I really hate that guy, because a lot of the time the products that he recommends don’t get used, and it gives an awful ding on project reports because there is an obscene amount of money spent on his meaningless suggestions, both consisting of obviously the product cost itself, but there is also a huge time investment as they product has to be explored, questioned, tested, implemented, and configured. Then you don’t even know that you did it right because you are relying on a guide that some intern wrote.
Look, I am all for buying something that helps the project along. There are some things that are so generic in purpose that it truly does not make sense to develop them in-house, like interface controls provided through companies like Telerik or Infragistics. Honestly, there isn’t a ton of purpose in writing that yourself. But taking a piece of software and trying to wrap your business goal around it, instead of programming TOWARDS a business goal, is arbitrary, and well, just plain stupid. That is trying to fit a square peg in a round hole, and generally I see costing entirely more much time and money than just sitting done and hashing it out with custom work.