Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

How can one sell an idea like "we should use jQuery because its highly optimized and cross browser compatible" or "entity framework is cool because its neat and takes care of our model automagically" when the common response is a blanketed statement such as "jquery doesn't perform well" or "entities bring in 12 columns on a table when we only need 10"?

I am a pragmatic guy that tends to trust axioms I've developed through experience (its not a performance problem until there's a visible slowdown). I don't know if there's a specific "category" that the other extreme fits into, whereas everything is a performance problem until proven otherwise...or even where to begin the communication here.

share|improve this question
7  
He is not called Dick is he? Daily WTF 'Java is Slow' –  AlexC Feb 24 '11 at 16:27
    
Just beat the bag out of him. –  Job Feb 24 '11 at 16:30
1  
@AlexC - OMG YES!!!!!!!!!!!! –  P.Brian.Mackey Feb 24 '11 at 16:36
1  
"Show me the data!" which would be the IT version of that Jerry Maguire line about money that Tom Cruise made famous years ago. –  JB King Feb 24 '11 at 16:40
2  
Tell him that he is a performance hit for your project. –  Wyatt Barnett Feb 24 '11 at 19:00
show 3 more comments

10 Answers

up vote 15 down vote accepted

Bring them hard facts!

For example there are performance benchmarks for ORM and JS frameworks. On top of it all framework and ORM have good selling arguments at their homepage.

After reading your comment I believe in your case the problem is not the right technology It’s the people who refuse to learn new technology.

share|improve this answer
3  
+1 - The difficulty here is that I have gone through and created prototypes for various new tools and technologies to show ...yes they perform well. But, I get the feeling that there's a stigma against any and all change or new tools that comes from having past tools fail (and possibly a fear of complexity). So, the safe bet is just to maintain the status-quo. Unfortunetly, I don't know how long our ancient tools will stand up against ever increasing user expectations and requirements. –  P.Brian.Mackey Feb 24 '11 at 16:39
1  
@P.Brian.Mackey - You could always try the sink or swim route. On your next project where you get to lead an implementation, implement your framework. He can either keep up or check out. –  Joel Etherton Feb 24 '11 at 17:29
    
Problem - No JS framework benchmarking is relevant vs. custom JS (tailored solution). –  NickC Feb 24 '11 at 18:31
add comment

I faced this problem before, people wanting to reinvent the wheel. I usually explain to them we can make the product better and more polished if we spend time perfecting whats important, and not what is lying underneath. Plus...I mean frameworks are there for a REASON, and performance really isn't as much of an issue these days. Reliability is more important, and if frameworks have good reviews/ratings then they are probably more reliable than something anyone could make up on the fly.

share|improve this answer
    
+1 for the idea that while there is likely some performance hit, it's commonly a great trade for significantly reduced time-to-ship, improved maintainability, and, with a mature/widely optimized framework, probably more reliable than what you can build yourself. It's rare that wheel re-inventors will argue that using anything but pure assembly it's the only way to achieve real performance, so why is the use of frameworks over the line? (FWIW I'm not in the "performance isn't much of an issue these days" camp, as I still think performance is very important. Just not the only important thing.) –  Matthew Frederick Feb 24 '11 at 16:37
add comment

Everyone seems to disagree with your colleague, but I think you should take his arguments seriously if for no other reason than to understand his point of view. I'm a firm believer in frameworks when you need them or when they actually provide optimization, but I also believe that over-reliance on a framework can lead to weak development in some cases.

I think you should approach the problem less from a stand-point that your co-worker is wrong and more from the standpoint that the usage of the frameworks you're thinking about will improve development time, performance, maintenance, etc.

I always try to keep in mind to use the right tool for the right job. I don't need a 12lb sledge (jQuery) to hammer in a nail to hang a picture (image swap). But if I run into a situation where I am hanging a picture that requires a railroad spike to keep it on the wall, I better have that sledge ready to go.

share|improve this answer
add comment

he's right, there is overhead

but the assumption that the overhead of a framework is more than a hand-coded solution may not be correct, and even if it is correct, the overhead may not be significant.

propose a test:

  • both of you write something realistic but relatively small
  • you use jQuery (or whatever) and he can use nothing
  • measure two things:
    1. how long it takes you both to code the solution (assuming your coding skills are equivalent)
    2. how long it takes to execute (full lifecycle) each solution

chances are, there will be a small overhead with the framework - very small - but a huge difference in how long it takes to code [and debug!] the solution

then your friend can argue with the facts, instead of with you

note: be prepared for continued resistance; many times the pushback against frameworks is couched in technical terms, but is actually a smokescreen for "not invented here" or "I don't want to learn another tool"

share|improve this answer
add comment

Remind your wheel-reinventing colleague that what he is doing is a variety of Premature Optimization. How can he know that these frameworks represent an unacceptable performance hit until they have been demonstrated to cause a problem. Meanwhile, your mutual productivity will certainly have gone WAY down with all of the extra work that you've had to do.

share|improve this answer
add comment

How about explaining the performance hit to the project delivery time when you don't use some of these huge time-saving and battle-tested frameworks?

share|improve this answer
    
Not sure the reason for the down-vote, are you saying NOT using jQuery or other established frameworks (as long as there is a definite need for them) is going to shorten a project's delivery time? This is essentially the "don't reinvent the wheel" argument... –  G_P Feb 24 '11 at 16:53
    
I go a cowardly drive-by downvote, too. Someome has a bug up his or her kiester today. –  Adam Crossland Feb 24 '11 at 17:34
1  
I agree with you (and certainly didn't downvote you!), but I have seen development time prolonged due to using a framework for a simple task which could have been done quickly by hand, and then having to deal with the framework not being quite right, not doing quite what you need, not quite being understood, etc. –  Carson63000 Feb 24 '11 at 23:19
    
@Carson63000 - Agree with you 100% - The scope of the task at hand definitely needs to be weighed against the impact of introducing a framework. –  G_P Feb 24 '11 at 23:26
add comment

One option would be to tell him that he gets to be in charge of performance tuning - if it can be shown there's a performance issue! Or, if you have the resources, build two Proof-of-concepts: you build yours with jQuery, and everything else you want. He can build his with his own hand-rolled super-fast system. Don't allow this to go on for more than a couple days (it's a proof-of-concept) and see who's performs better at the end.

And of course as others have mentioned, get some hard numbers and performance profiles for both sides of the argument.

share|improve this answer
add comment

First, he may be right for your specific situation.

Since it seems you're having problems getting him to look at your point of view, you need to do a better job convincing him.

You two are on two different points along the line between "Build" and "Buy". This is a pretty long line. To the left, in "Build" you have SpaceX, that had to build an entire industry. On the right, in the "Buy" you have complete outsourcing of all IT functions to IBM, HP and the like, and the business does no coding at all. In the middle, about 2 mm apart, are the two of you. You both need to convince management that your approoach on "build vs buy" on the framework and orm and such--and by "buy" I mean "not built in-house"--is in the best interest of the company, long-term. Twitter would have died if they had outsourced to IBM. They rolled their own. Think about that.

Either way, management needs to get off the golf course and get in there and do their job.

share|improve this answer
add comment

Well for the ORM one the answer is "Only if you write your query that way, the same of which can be said for SQL". As others have said, hard facts are what you need.

Also, ask specific questions to dig into what he says - "Can you give me an example of JQuery not performing because that is not my experience".

The third option, and a wise old developer suggested this to me, just include the "thing" anyway (assuming it doesn't have bad issues).

Seeking approval only leads to the answer "no". Get it in there, then you can ask them to point to specific areas and ask them to tell you what is the problem.

"Hey, this EF code, brings back only the 2 needed data items from that table, what's the problem" etc.

Obviously, you need to be pretty confident in yourself and the tool you are using before going ahead with this approach! :-)

share|improve this answer
add comment

Well rejecting libraries like that out of hand is stupid and sometimes arrogant. The product hours invested in these and the thought behind them makes rejecting them simply rediculous.

It can be that your co-worker is right though since you need to compare and outweight the demands of the software, which is a part of the design. It can be that an ORM or ActiveRecord solution is just to much of an overkill or on the contrary, that the software needs a really coupled solution for the DB and ORM just won't cut it.

Taking these stuff into consideration are important each time you design a software.

For the client side libraries I would have to say it's plain stupid since you can always find a framework that is suitable for your needs. And as some said before me, What is better than a battle tested framework?

Let him take the crap out of all the cross-browser issues, he will come to you willingly regarding on how to use a framework.

Btw, I had a boss once who didn't account on frameworks. I just showed him how easy it is to make ajax requests instead of copying the functions again and again(which was a dumb Idea in the first place), well he didn't know how to code so..

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.