Why must 3rd party software always be so painful to work with?

posted Tuesday, April 19, 2005 5:23 PM

The project that I'm currently working on is using a 3rd party content management system. It provides all the features you'd expect in a CMS and all the marketing material provided makes everything seem easy enough.  As we get deeper into the implementation more and more of the warts of the CMS are presenting themselves.  The system seems very capable for managing basic websites, however, is lacking in several areas when it comes to managing a large website such as the one we're using it on.

It seems like everytime we use a 3rd party component or software packages to help speed up our development efforts it winds up making everything more painful.  An exorbitant amount of time is spent hacking away with the software trying to get it to work the way we need.  It provides some basic features that are useful, however, is lacking in many very important areas which brings the development to a grinding halt as workarounds, hacks, and pure nastiness is considered so that the solution can be delivered.

These experiences always bring me back to one question.  Is using 3rd party software really worth it?  In the amount of time it takes to learn, customize, and hack away at the 3rd party software we could have built a custom solution to do exactly what we needed.  It would have provided us with all the functionality we needed, would have allowed us to add new features and functionality as needed, and made the experience of working on the project much more pleasant.

Do I just have bad luck with 3rd party software or is this something others are seeing and feeling as well?

10 Comments

# re: Why must 3rd party software always be so painful to work with?

Tuesday, April 19, 2005 8:39 AM by Anonymous coward    
3rd party software is a curse and I strongly suggest you *always* write a custom solution that completely meets all your feature and functionality requirements and that can easily be extended by anyone on any platform.

Also, no cheating by using wussy editors and other 3rd party crap -- you gotta write those too. And the OS's, they're crap, all of them, your better off writing your own since a custom solution would work much better for your application.

After a couple years, let us know how it's going. Better yet, send me a copy so I can whine about it too.


# re: Why must 3rd party software always be so painful to work with?

Tuesday, April 19, 2005 11:31 AM by Steve    
Anonymous Coward,
How well put. I'll let you know how I make out. Perhaps I could sell the fruits of my labor to you when I'm all done?

In all seriousness I think the point you're making is actually somewhat valid, despite you're delivery. There are some very good 3rd party packages out there that I really do love, and that really do work as well as one would hope. Unfortunetly there are just as many poor ones that cause people like me to rant, throwing around all kinds of generalizations that only apply to a subset of of the packages that are available.

Anyway thanks for the comment, feel free to leave you're name next time so I can thank you for the thoughts. :-)

Cheers,
Steve

# RE: Why must 3rd party software always be so painful to work with?

Tuesday, April 19, 2005 12:55 PM by Eric Wise    
I think the main problem is that many 3rd party controls try to be everything to everyone. It makes sense in that they want to hit the maximum amount of market possible so they can turn a nice profit.

However, by spreading themselves thin they lose out on the depth that hurts organizations like yours Steve.

There are good and bad 3rd party tools. I have had pretty good luck with developer express and telerik for example while I have had nothing but suffering from infragistics.

In the end though, I tend to take the path that if I feel the need to seek a 3rd party control then perhaps I'm overcomplicating my UI. Is there an easier, cleaner way? If not then I have to trudge through multiple vendor components and make the dreaded build vs buy decision.

In defense of 3rd party vendors though. Oftentimes individual business processes and expectations are anything but "standard". If you're going out to buy a 3rd party package, particularily you folks in the enterprise market (SAP, etc), you are going to save yourselves a world of pain if you are willing and able to shift your processes and expectations to align with the original intent of the software. Large customizations are risky and expensive.

# re: Why must 3rd party software always be so painful to work with?

Tuesday, April 19, 2005 5:08 PM by Michael D.    
I've used 3rd party frameworks very often and should say that with about 50% of success. Sometimes they work and really save time (like O/R mapping solutuions - NEO, Hibernate and Tangram), sometimes they don't (some of the complex CMS)

Sometimes it is hard to choose right solutions, but development everything from scratch is definitely wrong.

Michael
Agile Blog
<a target="_new" href="http://www.targetprocess.com/blog">http://www.targetprocess.com/blog</a>

# re: Why must 3rd party software always be so painful to work with?

Tuesday, April 19, 2005 5:26 PM by Frans Bouma    
I think you seriously have to evaluate the testing strategy you guys take when you examine the various 3rd party options you have to choose from. Apparently you pick the wrong tools and you find that oud too late.

But make no mistake that 'the wrong tools' is a subjective term. Perhaps you all are too stubborn to change the way you work to adapt the 3rd party software so the productivity can really be increased. A good example you also have experience with is a 3rd party O/R mapper. If the user is too stubborn to change the way he works with data in his application, the O/R mapper logic will only be in his way and will not bring any advantage. Is that the O/R mapper's fault? Definitely not.

I also agree with Michael: developing everything yourself is DEFINITELY not the way to go, there is already enough NIH in the software business.

# re: Why must 3rd party software always be so painful to work with?

Tuesday, April 19, 2005 10:51 PM by Steve    
Despite my post I'm very much in agreement with you guys as well that developing everything yourself is &quot;DEFINITELY&quot; not the way to go. The post was more of a rant on how *some* 3rd party software isn't very good. Frans, you're point regarding needing a better evaluation and testing strategy for the products is certainly valid, however, we often times find ourselves in a situation where our client has already decided on a package. We can, and sometimes do, push back if the package doesn't fit, however, often times the investment has already been made so the package has to &quot;work&quot;.

One other clarifying point, the packages that I'm talking about aren't things like O/R Mappers, UI Controls, or etc, they're bigger CMS packages, e-Commerce packages and the like.

Anyway as I said this was more of a rant then anything else, I'm certainly not advocating we start writing all our O/R Mappers, UI Controls, and etc from scratch. There are plenty of very good 3rd party packages out there for that sort of thing, which I'm all for using whenever it makes sense.

Cheers,
Steve

# Re: Why must 3rd party software always be so painful to work with?

Wednesday, April 20, 2005 2:41 AM by Eric Wise    
&quot;One other clarifying point, the packages that I'm talking about aren't things like O/R Mappers, UI Controls, or etc, they're bigger CMS packages, e-Commerce packages and the like. &quot;

This is why my ISV product, Easy Assets .NET, will have a standard version and a source included version. For people that want my product to do things that are outside the &quot;norm&quot; they are welcome to build their own extensions (or contract with my ISV to have the extensions built for them, the advantage being that extensions built by use are covered by use ala warranty).

# re: Why must 3rd party software always be so painful to work with?

Friday, April 22, 2005 10:34 AM by John Rusk    
In a way, it's harder to be agile when heavily reliant on a 3rd party product. Why? Because the product constrains your freedom to make changes.

Also, I saw a post recently, on Jeff Atwood's blog, that was very critical of &quot;enterprise&quot; packages. In my opinion (based on particular products which I won't name) too much &quot;enterprise&quot; software is the result of teams that weren't smart enough to implement the functionality simply. Instead, they build an over complicated solution and, having invested so much time in it, have to sell it for an &quot;enterprise&quot; price to recoup their investment.

Configuration is another issue. These big be-all-and-end-all products are typically hard to configure. All too often their goal is that customers should be able to configure them without writing any code. So they invent their own limited, frustrating config scheme. We don't need those schemes. We already have two great ways to communicate precise instructions to computers. They are the latest results of decades of on-going evolution and research; they're called C# and Java ;-)

# re: Why must 3rd party software always be so painful to work with?

Tuesday, April 26, 2005 1:28 AM by Geoff Webb    
I often find myself in the same situation, where others have already purchased a third party system that I have to work with. My team and I document the extra time (read money)that it takes to overcome the problems in the app. Sometime our management even looks at our figures.
In the end, I get paid the same.

# re: Why must 3rd party software always be so painful to work with?

Tuesday, May 17, 2005 10:04 PM by Larry Aultman    
I share the frustrations of many programmers in terms of 3rd party conrols. These extend beyond the actual implementation of controls to the long term customer support, particularly in the area of deployment (licensing issues) and updates. We buy third party controls for specific tasks that would cost us a huge amount to duplicate. It usually isn't the control's capability that is lacking in my judgement, but rather the scant documentation that is provided to allow our developers to utilize the control as intended by its designer.
I am not one to curse or swear, but sometimes I would like to have the guy who wrote the thing here for a consult.
Control writers write controls not documentation. Someone mentioned Infragistics earlier, who have great products but their docs really stink. And it is mostly true of the others as well. Docs cost as much to produce as the controls themselves and they are NOT fun to write so they go lacking. The bigger guys usually do better because they have the resources. The notable exceptions are the ones who produce only one product like TxTextControl, who have good docs and a responsive staff.
So for our company, a &quot;one off&quot; development will get the outside controls so that we can be competitive and for our in-house and long-term projects we usually use 3rd party stuff initially and phase them out over time as the cost of support dictates.
Parting shot... I hate learning a new control.

Post a Comment

 
 
Prove you're not a spammer: 
9 + 8 =