How to Deal With Fear of Custom Dev

Question

I'm dealing with an issue with my current employer that has seriously made me consider seeking employment elsewhere. They are under the impression that 100% of custom development should be eliminated and replaced with COTS products, such as SharePoint. While I realize that this is not a realistic expectation, I've found it impossible to argue my points with the people in management that share these views. Their argument usually involves something along the lines of a feature already existing in SharePoint that covers feature X, therefore there is less risk involved and testing doesn't have to be done against it.

Case in point, we have a situation where a SharePoint list is completely incapable of meeting customer expectations and requirements. Saving this data in a SQL database, however, would easily satisfy the requirements. Any time our development team suggests going outside of the boundaries of SharePoint, however, management goes up in flames about how every line of code adds to the complexity of the project and increases risk. While this is certainly true in some situations, it's not always the case. Their argument, however, is that since SharePoint provides a mechanism for storing data, that we should use it 100% of the time. Regardless of if it meets customer requirements, or not.

I've gotten to the point that I hate coming to work because I'm constantly forced into doing things that I know (with 100% certainty) are not right and that could be made right by doing custom development. It's simply what seems to be an impossible argument where I work, however.

Have any of you experienced a similar situation? If so, what have you done to work through these challenges?

Answer 1

If you don't share the vision of the company and if you can't enlighten them then sure, it is a good time to start looking.

Have you pointed out that there is risk in forcing a "solution" on a client that does not help them or is missing functionality or is unusable?

Perhaps come up with plans to address and mitigate their perceived risks.

Answer 2

I am doing the same thing at my current job, there is no easy way to deal with this kind of situation. All I have been able to do is swallow my arguments, cause they have gotten me no where, and do as required by my management. This off course will go against your basic programmer nature of using the best solution for the task at hand, and maybe getting to build something cool in the process, but since they are the boss it is really your only solution. You could try to site cases, with evidence, where it makes more sense to use custom solutions. But if you boss is anything like mine, it won't get very far before the screaming match begins. The only other solution is dusting off that resume and finding a new job.

Answer 3

Does someone in management own stock in SharePoint? Was the system developed by the CEO's younger brother?

If they are that resilient to change, you should find out the real reason before trying to argue with them. They may claim that there is added complexity, difficulty testing, etc, but if you can counter every argument with one that shows their position, with all due respect, to be misinformed, and they still won't discuss, then you may be arguing the wrong point.

If they are locked into the technology because of a non-technical reason, such as someone once read that SharePoint is the ultimate in any technical situation (and, of course, had no clue what the article was talking about other than SharePoint = good) then you shouldn't bother trying to argue and save your energy. For the job hunt.

Answer 4

You document your concerns and let those above you know them, and then you do as they ask. If it doesn't work, you have documentation that you brought the concerns up. But try to make it work their way, so it doesn't look like you're trying to undermine their plans. They're taking the greater risk, and thus they get the greater responsibility. Try your best to make it work their way, and quit worrying about it.

Answer 5

Prove it to them. When the requirements ask for a list that can handle 100,000 items with a multi-column sort - write a script that adds 100,000 test items into a sharepoint list and let them try it, preferrably with the "customer" requesting the list watching. :-)

Ron

Answer 6

I have faced the same kind of challenges right from day one. Management have a natural reluctance to add custom code to the solution. However in most cases it has been posible to explain than the right solution for the customer would include some custom code.

Remember, if you argue that you can include the custom code in the common codebase, then the boss might approve the idea.

Answer 7

I would definitely get my resume out and into the open if I were you. Not only is the experience that you are currently having frustrating, it can really hurt your career development over the long haul. Just think about it. While you are languishing with your current employer in your current position, other developers are adopting new technologies and expanding their experience.

There is such a thing as ideological differences between developers and what a company's idea of a role for a developer is. If open discussion and candor get you nowhere, you will not be faulted for a lack of effort. Loyalty to a company is a good thing, but the relationship needs to be a two-way street.

Sadly, the will eventually probably come to realize that they are wrong in their assumptions - but you can not wait for that day to come. Sometimes it never comes. In particular (and don't get me wrong, I love SharePoint when it is used for what it is intended for), SharePoint is become the next Access, in that people who read management magazines see enough of it thrown around to call it the messiah.

Answer 8

I really feel your pain.

If it was me I would use my spare time to collect information that proves my point and document it in a easy to understand way.

If they only understand money, talk money, if they only understand fear (doing "this" because they are scared of "that"), use the fear, finding scary thing for them in "their" solution.

Document every new implementation, the time, money and problem that arises. And document what your solution would be instead.

They probably doesn't see the problem in their solution, because they focus on not having problems in "your" solution.

Answer 9

This may sound bad and may not be the answer you want. There is a little known division in my office called "The Skunk Works." People, on their own accord (usually during lunch breaks or compile time) decide to write little programs that help the company. The fun things about this is the result doesn't "cost" the company anything.

The conversation usually goes like this:

"We need to buy this software" -Boss

"But, we have had that thing for months. John, wrote that back in the day" -Programmer

"?" -Boss

A lot of times the developers see a decision as being bad and just create a parallel process that happens automatically. Then, when the stuff hits the fan and the customers are frustrated, the alternate solution is ALREADY in place.

I have an example of an auto release machine. Developers used to create these custom reports. As our customers increased, the developer's workload increased. The problem was "In order for the customer to get the custom report developer had to be involved." So, while the company was looking into hiring someone to do reports full time or to find ways to have the customers do them, I wrote an auto release machine that looks for report changes and releases them directly to the customer. I also wrote a utility that allows anybody to make changes to the reports that was easier to use than what the developer has. When the Boss made the announcement of trying to find a solution, I told him that it was already in place and that even he could make changes to reports and get them released. Now, everybody can change reports, usually it is management and customer support who make these changes. The fun side is that developers arn't involved anymore.

Just do it. If you're going to quit anyways, might as well try.

Answer 10

I have worked in a place where management were not constructive in their approach, not quite as bad as you describe, but bad enough.

There are a couple of options. One is to go ahead and do what needs to be done for the client with the best "value for money" option you can. You will probably have to get the developers together as a team to make this "civil disobedience" work.

A more forceful approach that will really make the shit hit the fan is to go to the client (don't do this if it is an external client or if you wish to keep your job) and lay out what is going to happen to this project if X and Y. This is pretty much telling tales out of school and is going to be bad, but entertaining.

A slightly better way is to go up the chain and get a sponsor who can make shit happen for you. Essentially go behind your boss(es) back. This may work, but it is going to have predictable results for your relationship with your management.

Last and hardest is to identify the person who holds the view that any custom code is bad and engage them in conversation to find out where they got the belief and counter that with examples. Emphasis on conversation as you will have to listen to and understand their underlying concerns (which won't be about custom code per se) and only address them after you gain that persons trust.

I cannot tell you which way of doing things is going to work best because it depends so much on the individuals involved. All I do know is that you cannot change people and in my experience the best way to solve the problem so far has been to leave and work with people who are not so...

Answer 11

I find that there is typically no way of 'winning' these debates through talk alone. Many managers form an opinion of a product or solution through reading management oriented articles. See if you can find some counter-articles.

If you can cite examples of things which SharePoint is incapable of doing, and show examples of how you can cost effectively solve these problems through custom development then you are well on your way.

The mistake is to try and make this a conversation about technology, it's not, its about efficiency, cost effectiveness and maintainability - those are the mantras and metrics which will sway non-technical managers into considering alternatives.

If you can put together a proof of concept for some of these issues so much the better, eye candy really helps to sell outside of technical teams.

Finally, good luck :)

Answer 12

how about not calling it custom code. If instead you call it 'anticipated SharePoint user extensions' or something it may soften the misconception surrounding a specific term.

also, as has been said, there may be other hidden from you reasons that management is pushing this agenda. It is probably best to not second guess these too quickly, as many would be valid.

Finally, there are alot of places that need development. it doesnt hurt to look for a better match.

good luck.