So, I’ve been wrestling with this third party app that’s been acting up for a few days now. It has been really frustrating. Enough for me to ask several times why it didn’t get completely developed in-house. Looking at it there is no reason for it not to have been done by one developer. It is some linkbuttons and some pretty colors and borders that are dynamically created by metadata. Its been really annoying blindly trying to get past some of these bugs. This isn’t the first time this has happened to me when using payware OR freeware. In the future, I plan on staying as far away as possible. Here are the reasons why.I think you should too:
You didn’t make it – Duh. I mean, you think its not that big of a deal, that code is code (or apps are apps) but think of how you feel when you’re sitting in front of a brand new application. The learning curve that is behind debugging something you didn’t build with your own fingers is a chore. When you understand an application you may not know exactly what’s causing the bug, but you know generally where to look and have a much better idea why it may be happening.
Email support packages – Nothing is worse than an email support package (except for maybe a smoke signal support package) ESPECIALLY when you are dead in the water either in production or development. Waiting that “1-3 business days” between questions and answers is torture. Especially when they don’t get your question the first time, or when their answer isn’t the solution…. It can go on for weeks and its extremely tedious. Phone support packages can be dreadfully expensive, upwards of $1000. It’s a tough call to make not knowing just how much you will be using this package. Of course as developers (personally, I like “web-hero”) we say things like “no, don’t buy the package. Its too much to pay, this is open source so if it blows up I can fix it.”
Sales people – Listen, I don’t hate sales people. Some of my best friends are in sales (seriously, if you need a Pitbull Tire Lock let me know. They are great security for your vehicle, and the bonus is they have the hottest sales girl…..pretty much ever). That in mind, we all know they make LOTS of promises. Can your application be used with 1.1? Sure! Can I integrate this while keeping my high security model? Definitely! Will your program make my code infallible? Of course! I have been mislead several times only to get an email support message that says something like “Oh, we apologize for the confusion, that’s not supported in this version. However, it is in development and will be made available with our next release.”
We don’t support that application anymore – You want to think that your application is so cutting edge that it would only incorporate the latest and greatest but you have to admit these little companies that produce integratable applications are popping up in alarming rates. Just as scary, they are disappearing just as fast. Do you want to pay $3000 for a feature that breaks in a year and there is no one to email about it? (You can email me, but I will only say “Told you.”)
Ugly Code – I was taught to take pride in things I create, to make sure everything matches and has similar structure. To pay attention to patterns and conventions in order to make a smooth and agile application. To produce a product in which any decent developer can sit down and say “Wow, this is very self explanatory.” Now you’re taking someone else’s stuff and just slapping it in there. Not only that but a lot of times companies don’t care what the code looks like, just that it works. Today I got to edit things like “LinkButton8” and “Label29”. If Project Awesome was something I created myself it would make me physically ill to see these things polluting up my legacy. Like putting dirty clothes on your children, it may make them look better than nothing, but it’s still pretty bad.
There are some really awesome products out there that can make your web app shiny and flashy, and believe me I like these things. You have to think, though, if someone else did it, so can you. I think 90% of the time it's a better investment of your time to do-it-yourself, you just may learn something. Sometimes, like in the case of PA (Project Awesome) there may be one developer working alone and it’s just not realistic time wise to do all these things on your own. I guess my only advice (if you must) is to thoroughly research each tool before you buy it utilize free trials, and speak to the developers before giving them company money. After all, it’s only your code and schedule that will suffer if you choose unwisely.
Outside of maybe point one and five, I fail to see how this relates to open source software in any meaningful way. The title feels a little misleading.
ReplyDeletePoint one is easily addressed: spend some time with the code you're going to use for your application. It's something that open source gives you for free that your vendor will most likely slap a price tag on. With open source software, you can inspect and interrogate and fiddle to your heart's content and -- even if the software isn't right for you in the end -- you will have a much more thorough understanding of what lies under the hood than with a closed voodoo system.
Ugly code may be a more legitimate concern, but it can be true of any project -- even your own. Hell, that code is ugly is often a subjective debate in itself. There's so much ego in this industry that people often get blinded by that which is merely different and that which is truly detrimental to the maintenance of a software product.
Of course, this is assuming the third party software in question is non-trivial. If the third party code gives you that little and is costing you that much, by all means start looking for an alternative -- whether that means finding another product or writing your own.
But if you are dealing with something non-trivial -- something that you couldn't write yourself in a day or so -- then you might very well be better off sticking with a tried-and-tested solution. Otherwise, expect a lot of pain along the maintenance trail. Perhaps more than if you had just bitten the bullet in the first place.
In my (uninformed, scattered) opinion, some of this is dangerous advice -- advice that needs more context than you're giving here. Scope is very important: is the application or system you're using third party software for a domain in which you're an expert?
If not, why are you trying to write the code?
Tom,
ReplyDeleteThose are all great points and I appreciate them, I will answer them below.
Paragraph 1: I see what you are saying, and that is very realistic if you are adding a widget or something small. Like JS text editors. I should have clarified that small things like that, as long as they are reccomended and tested (preferably by someone I know) are fine by me and make life easier. What I am speaking of is larger more involved apps that may add classes and controls and all kinds of foreign things to your app.
P 2: There is a healthy balance when it comes to code, however, I think you will agree the the control + number naming convention is the lowest of the low and I'm sure you wouldn't want to be dealing with that either.
Lastly, I agree, scope is an important thing to discuss. I maybe should have been more clear. I am learning as I go!
Thank you so much for your feedback, it is greatly appreciated.
Sara
I couldn't agree more. So for the past 30 years I have been holed up in my garage writing a new operating system. I would have been done much quicker, however I got sick of writing in assembler, so I had to write a compiler. Once I was done writing the compiler the first time, intel changed and expanded from the 8086 (16 bit) to 386 (32 bit) and I had to rewrite big chunks of it. I really set out to create an accounting package for a friends business (who subsequently went out of business), however, I just didn't want to use anybody else's code. I am nearly done with the operating system, and all I have to do is write a device driver for the video card I developed. My accounting system might be finished in 2023.
ReplyDeleteIn all seriousness, using other peoples software is a fact of life -- from the operating system, to compilers, to small little libraries, to your coworkers shitty code. Your job as a developer or a member of a development team, is to select the best available third party code, refactor (if time money permits) your coworkers crap, and live with the junk you can't. A developer whose first instinct is to write their own [insert random thing here, let's say dependency injection framework] isn't being paid for it, is doing something truly unique that no other framework will solve, is fresh out of school, or has never worked at a software company (i.e. you are screwing the person signing your check simply because he/she doesn't know any better).
ac, I completely disagree. I admit there are tools out there. However, if it's something simple and you can do it in house you should. I never said it should be your first instinct, I said if you can do it in a reasonable time you may save resources in the long run.
ReplyDeleteIf you were looking at what I am looking at you would understand my frustration with a developer who was too fast to slap in whatever he thought would work.
As always, I appreciate the feedback and gross generalizations. :)
I would have to say that I think 'ac' went a little beyond the perview here. An operating system is not a 3rd party application. Neither are drivers, or for that matter hardware.
ReplyDeleteThat being said, crappy little 3rd party applications or control libraries (read things to simplify your job as a developer) really shouldn't exist. They exist because of lazy or uneducated developers.
As far as the advice given I would say that it primarily falls under most development best practices. Comment your code, provide good support, use standard naming structures. All valid points.
After my first enterprise level project I decided that I had a deep hatred for 3rd party applications. They barely get the job done, and most of the time overcomplicate my job.
It's a personal opinion, but the last time I checked, this was a personal blog, so really the only person who should be knocking entries here is the person who wrote them. I follow a personal policy with peoples blogs; If I don't like them, I stop reading them ;)
Cheers
Thanks for the plug Sara......it's awesome to get me sales but if you can get me hot nerd dates that would be awesome too!
ReplyDeleteThanks, Ixdatul, the whole point of my blog if to learn. So if people feel I am horribly wrong I welcome their opinion, esp if they have been in the field longer than I have. I can only share my experience, and for the past week or so my experience has been full of angst. This is NOT me back pedaling. I still feel very stringly that people are WAY too fast tossing this stuff into their work without a bit of thought. This comes not just from this experience, but many in the past.
ReplyDeleteI can take critisim of my opinion like a man. I'm just a bigger fan of caring guidence and direction. I guess then you have to get people to care.
Coming soon: Pictures of me and orphans eating pie! Kissing kittens! Saving people from fires!
I think 90% of the time it's a better investment of your time to do-it-yourself, you just may learn something.
ReplyDeleteYes, exactly. There've been a few times when I've succumbed to the lure of third-party apps on big projects, but not without at least taking a crack at writing my own.
It's worth putting up with the eye rolls and the but why don't you just use Wordpress (or phpBB, or Drupal, etc.). I always learn something.
One other plus side to rolling your own - you only get the features you need, not a lot of extra modules (and extra crap code to wade through).
Five good reasons to stay away from third party applications (even open source ones)
ReplyDeleteSays the programmer who's using prototype (a third party open source javascript framework) for this website. I can see you're using Graffiti CMS. At least that's closed source. ;)
Sara, I guess that the problem lies in generalizations. Yes, there are crappy 3rd party apps out there, but there are also good ones that can make your life much easier.
ReplyDeleteThe title of the article is somewhat a bit too strong, and, in my opinion false. You shouldn't stay away from 3rd party apps. Otherwise, any piece of code would take ages to be implemented. And, unless you're a true expert in the area, it may be actually a better piece of code than anything you could write. Nevertheless, it is true that you should check that using any external piece of softare is really going to help you. And that includes:
- That the app actually does what you require. In a Java desktop app, we've have been using a docking library, and it worked well. Until someone asked for a docking context to be inserted inside a docked window. The library allowed that, but we had many problems and we finally had to remove that functionality, because it was not the way usually docking managers work.
- That you have enough and updated documentation about how to use it. Typically a weak point of open source projects, although some have excellent documentation.
- That you're going to have the support that you require. Open source apps have an advantage in this respect to closed source. You DO are able to look at the code and figure out what the bug is, or which flag you forgot to activate, or whatever. This can be quite time consuming, but if it is too complex that you can't figure it out, then probably it is also too complex for you to implement it by yourself in a short period of time. Of course, unless it is REALLY a bunch of spaguetti code packed together. My experience is that open source projects tend to have cleaner code than closed source ones, since no one is actually going to have a look at it outside the development team.
I have to disagree with Ixdatul in one point: for any developer, O.S. and drivers ARE 3rd party apps. Just like the standard libraries of Java, .NET or whichever is your favourite language. It's just that, since they are used by an awful lot of people, they are considered to be stable, tested and documented. Or at least quite so. Once I spent a full week trying to make work an SQL query until I found out that the error was an undocumented bug in Oracle 9i. But that wasn't a reason for me to try to write my own database system ;D
Overall I find the last piece of advice at the end of the original post quite sensible: use trials, have a look at the code if you can, and make sure it is what you need before commiting any more resources (time and/or money) to an external app. But likewise, before starting bravely to code a component, do a quick search at Google and find out whether someone has already done it for you.
Barbra - great to see the opinion of another GirlDeveloper. Please keep checking in for new things. I really want to get together a support system for female programmers, and young women who want to be programmers. Something a little less formal than what's out there. Thanks for stopping by.
ReplyDeletehaaaaaaa I just got totally PW3ND by Brian.
Enrique, thanks for your response. You made some great points and opened my mind a little.
Have a good holiday, everyone.
Do not use the magic word opensource =)
ReplyDeleteI feel your pain, 3rd party tools never just work. They all seem to have a hard time with just looking at what's in the Framework; they need to rebuild it all in their own way. There is no need to use an existing .net interface, they just copy, paste, and rename everything to their own 'world'. There is some unwritten rule that reading books like the Framework Design Guidelines is probably something that should not be done by 3rd party developers. And do they even try to talk to Microsoft?
Making the buy decision instead of spending time to build it yourself is one of the most overlooked decisions out there. Even if you decide to go with an open source solution, sure you can edit the code to extend of fix it. But you don't get the knowledge of the product by just saying we're going to use that. Getting that knowledge (from a possible badly documented product) costs a lot of resources. It gives a limitation, because you don't have unlimited resources available. The same limitation you get from saying I buy this product to solve issue y. There probably are some limits to the product, because mostly the authors of the product target a wider range of issues. In some cases it might be useful if a products can also solve issue x and z, but will it solve them deeply enough, who knows.
I currently think the issue is more about asking the correct questions to yourself. Is the issue we need to solve core to our product? Than building something yourself seems to make the most sense. You build up knowledge of the sub product and are probably more flexible to the long list of change requirements. Don�t forget that there is a limitation there also, because resources aren�t free and you can still make the wrong decisions, but at least you can blame yourself now =). Good thing is that you and your company build up more and more knowledge about the knowledge domain.
Is this issue we need to solve something that is not a core issue we try to solve for our customers? Let�s say I build a visitor stats product, the graphs I see are probably pretty core to my product. The make or break the success of my application. Just as gathering the statistics. But the login system that gives me access to the statics is that core to the product? I don�t think so! The end users want their problem solved, statistical information about visitors in the most productive way. Buy a 3rd party solution for this otherwise you are wasting resources you could have spent on extending the graph functionality or any other core issue. (I know login functionality is a bad example, can't think of a better one right now) Most of the times it might also be no real problem if the required solution is not possible because of limitations in a 3rd party tool. It get's accepted, but it needs clear communication. People understand decisions and there consequences.
But keep in mind; the most important rule: you are not the end user! They don�t care about flashy buttons that fly over the screen with 50 functions; they have an issue/problem they want to get solved. They are not the geek that likes computers, they use their pc just like a car, to get from point a to point b as fast and easy as possible. Is it really needed to let your application look like a flashy space station? Or can you also not use the flashy space station 3rd party tools and still make the end user happy. A hard question, but if you think like a programmer the answers is always yes, while that might not be the right answer.
Like others here, I think you're over generalizing. There are lot of crappy 3rd party tools and libraries, open or closed source. On the other hand, there are plenty great ones. You just have to weed them out.
ReplyDeleteWhenever I need a new feature that I think could be handled by a 3rd party I go shopping. By shopping I mean look around, not get out the wallet. I rarely break my I must have the source rule, whether it's open source or closed; yes closed source doesn't mean you don't get the source, it usually means you have to pay more to get it. The few times I broke this rule I made sure the library was very stable, i.e. has been around for a long time and used a lot, in other words: mature.
When you decide to rely on a 3rd party tool or library you have to be very careful. It's like inviting a stranger to live in your house. You would make sure they're OK, right? :) And one more thing: be very very picky. If it doesn't work perfectly in your tests dump it fast.
Come to think of it, it's like dating; you should be good at this :-)
Pete
For everyone the pro's and con's between open source versus commercial is obvious. Yet a majority of developers in the world totally approach both routes incorrectly in my humble opinion.
ReplyDeleteOne lacking understanding i have found in plenty developers i have worked with is what i call Logic Dependency Management. There are libraries a plenty in the world, question is how you should go about to use it. You got a critical piece of logic, would you rather code 20% and depend 80% on a third party component. Or maybe reduce your dependency on a single component and only let it handle 20% of your logic and you design/code the rest. Then again you can also build a collection of working 20% components and together it can handle 80% of you logic.... Its how the dependencies between the component are implemented which will usually spell success or disaster.
Developers usually shoot for the silver bullet component to handle as a high percentage of their coding logic as possible, and when it does not work as expected the component is seen as a failure (not matter if its open source or not). I had to resolve such an issues today with using Apache IBatis.
So to sum up, always keep inconsideration how any third party component will function with all your other components/code. It will help you picking a working solution from the start and avoid trial-and-error scenarios.
If I may make a suggestion... incidentally... i agree with you. If we're going to use an application that is actually intended to function with our systems then yes, build it ourselves, because the cost ceiling on reverse-engineering, bug tracking and hacking to get it to integrate is going to be higher in the long run, then an in-house created solution.
ReplyDeleteHowever, if the (relentlessly annoying) time constraints consistently require a solution (created by some sales and marketing team for some wanker idea that they've just sold and we didn't have, in order to pat themselves on the back while doing shots later that night cuz well... they're hero's), well then i go one place and one place only....
http://sourceforge.net/
1: All of it is in-progress and most of it is incomplete, and as a result, you can dust it to it's bare bones and yank out what you need from it, instead of writing the code yourself, for a temporary solution while the in-house product is created - of course... this requires someone in the IT department to actually sell the idea, to the point of realizing that yes, we will have this, no this isn't permanent, and yes, we are going to produce a better mouse trap ourselves. Yes yes, i know how difficult that can be but well... the trick is simple... word it and present it in such a way that it because their idea ;) get it?
It is for that reason, and that reason only that I recommend to all IT personnel to take 2 things...
1: a public speaking course
2: A marketing/sales course
why? well duh... it's basic programmatic reality... if you want to know how something works... take it apart... that applies to departments, and related inclusions... such as marketing, sales and administration. If you know what they're going to do and why they're going to do it, then you can either a: beat them to the punch with an answer before they propose the solution (which I promise you, they'll have already sold, implemented, promised and or paid for long before IT gets their hands on it), or b: present to them an interim solution that still satisfies their instant gratification needs while allowing the in-house development team to work through a proper solution, using the free code that they've just pilfered from umpteen different projects from the sourceforge.net database of unfinished solutions...
and you know what? there are perks. You get to broaden your mind! Learn no ways to do the same thing! Discover the magic of cross blended language compatibilities and cross platform solution resolution. And hell you learn stuff!
I have never yet ever in my career ever at all in anyway shape or form ever said, no that can't be done because of ... insert the i don't know how to do that reason here... bs that a lot of developers like to say to avoid the actual learning of new technologies... of course you're obviously the exception.
Everything is possible, nothing is impossible, no we don't know how to always do it, but well... that's why we're IT. We're suppose to figure out how to do it, and if that means that dammit, now i have to learn 5 new languages, and 7 new integration technologies, then fine... tonight i get drunk and tomorrow, i start reading, learning and getting on getting on :)
cheers!
Being a new grad, in the city where I live in all they have is opensource jobs with a few companies trying to mix .Net with php programmers - lame. After working with Ruby on Rails for 6 months and doing mvc programming, and trying to follow their convention paradigm, my confidence in microsoft technologies gained new heights.
ReplyDelete+1 to apps developed in house and microsoft technologies in general.
Third party applications are programs written to work within operating systems, but are written by individuals or companies other than the provider of the operating system.
ReplyDeletethree fields to cross till a farm appears
ReplyDelete