January 24, 2006
Have you ever worked with developers that were charter members of the third-party-control-of-the-month club? You know the kind-- they never met a third party control they didn't like. They spend all day trolling downloads and experimenting with every tool listed on The Daily Grind. Which means deploying your solution is now a tricky balancing act of obtaining and installing the proper license files from a half-dozen different control vendors. Who all do things slightly differently. Oh, and don't forget to make sure the versions of all your controls are all up to date with the latest bugfixes, too.
These are also the kind of developers who are prone to adopt giant, complex frameworks just to get tiny additional bits of functionality. If you're not careful, your entire project is liable to come down with a severe case of frameworkitis.
I, on the other hand, think anything outside the base framework is guilty until proven innocent. I'll adopt third-party code, but as little as I can get away with, and only if it offers significant, proven benefit to the problem I'm working on. I've been burned too many times. My code may suck, but it's a constant level of sucking that I can plan around.
That's why I was heartened to read Joel's account of how the Excel team
aggressively avoids dependencies:
When I was the program manager in charge of the first implementation of Visual Basic for Applications, I put together a careful coalition of four, count them, four different teams at Microsoft to get custom dialog boxes in Excel VBA. The idea was complicated and fraught with interdependencies. There was a team called AFX that was working on some kind of dialog editor. Then we would use this brand new code from the OLE group which let you embed one app inside another. And the Visual Basic team would provide the programming language behind it. After a week of negotiation I got the AFX, OLE, and VB teams to agree to this in principle.
I stopped by Andrew Kwatinetz's office. He was my manager at the time and taught me everything I know. "The Excel development team will never accept it," he said. "You know their motto? 'Find the dependencies -- and eliminate them.' They'll never go for something with so many dependencies."
In-ter-est-ing. I hadn't known that. I guess that explained why Excel had its own C compiler.
By now I'm sure many of my readers are rolling on the floor laughing. "Isn't Microsoft stupid," you're thinking, "they refused to use other people's code and they even had their own compiler just for one product."
Not so fast, big boy! The Excel team's ruggedly independent mentality also meant that they always shipped on time, their code was of uniformly high quality, and they had a compiler which, back in the 1980s, generated pcode and could therefore run unmodified on Macintosh's 68000 chip as well as Intel PCs. The pcode also made the executable file about half the size that Intel binaries would have been, which loaded faster from floppy disks and required less RAM.
"Find the dependencies -- and eliminate them." When you're working on a really, really good team with great programmers, everybody else's code, frankly, is bug-infested garbage, and nobody else knows how to ship on time. When you're a cordon bleu chef and you need fresh lavender, you grow it yourself instead of buying it in the farmers' market, because sometimes they don't have fresh lavender or they have old lavender which they pass off as fresh.
The .NET Framework was intended to be the dependency to end all dependencies. It's huge. It's also comprehensive and generally well-written. Any time you're reaching outside the framework for a giant swath of functionality, pause first and think about what you're trying to accomplish. Before you start stacking dependencies on top of the mother of all dependencies itself, make sure what you're getting justifies that risk.
Is it possible to take dependency avoidance too far? Of course. The flip side of reducing dependencies too aggressively is the Lava Flow anti-pattern:
As we delved into it, we interviewed many of the developers concerning certain components of the massive pages of code printed out for us. Over and over again we got the same answer, "I don't know what that class is for, it was written before I got here." We gradually realized that between 30 and 50%
of the actual code comprising this complex system was not understood or documented by any one currently working on it. Furthermore, as we analyzed it, we learned that the questionable code really served no purpose in the current system, rather it was mostly there from previous attempts or approached by long-gone developers. The current staff, while very bright, was loath to modify or delete code that they didn't write or didn't know what it did for fear of breaking something and not knowing why or how to fix it.
I've never had a problem with lava flow because I am pathologically addicted to deleting code. I'm not afraid to get all Strunk and White on that codebase. I don't care if it woulda, coulda, shoulda been used-- is it being used right now? No? Then it's gone. Period. If you need it back, well, that's why God invented source control systems.
I'm not against dependencies. Everything software developers do is one giant string of dependencies. I'm a pragmatist. Strive to make your dependency stack as small as you possibly can.
Posted by Jeff Atwood
Interesting you link to MS Patterns and Practices. We use the Updater Application Block 1.0. We looked at 2.0 but decided against simply due to the complexity overhead of understanding all the other stuff it depends on. UAB 1.0 is standalone and simple.
Yup. That's why I ripped out a ton of third-party stuff when I moved our application to ASP.NET v2. I hate, hate using third party stuff unless it's so necessary and so vital and it's so useful _and_ I can't afford to build it myself.
And only if it comes with source code. The amount of bugs I usually have to fix depresses me.
Hear! Hear! Totally agree with you Jeff.
It's another reason i've gone back to Win32 from .NET. And dissed the registry.
Ahh I thought I was the only one feeling like this.
Anyway, I s#ck at english. But a stupid question, why the name 3rd party ? Who is having the 1st and 2nd party ?
1st party -- microsoft
2nd party -- you
3rd party -- control vendor
I suppose we could reverse position 1 and 2, but I don't think it matters. The original purchase is from Microsoft (#1) to you (#2), so any additional purchases come from party #3.
I agree with you for the most part Jeff. I would absolutely rather use the intrinsic .NET code, but the fact of the matter is, the standard controls that ship with .NET are for all intents and purposes, pretty lackluster IMHO.
Compare the DataGridView, for instance, with a one of the heavy duty 3rd party grids from like Infragistics, or DevExpress. The functionality totally exceeds the standard grid's limited capabilities, and that's just one example.
I do try to avoid 3rd party controls and code as much as possible, but sometimes to produce a polished application that most users have come to expect is ultra hard with the given controls in the System.Windows.Forms namespace.
Compare the DataGridView, for instance, with a one of the heavy duty 3rd party grids from like Infragistics, or DevExpress.
Yes. But the point is that some people will replace _all_ their DataGrids with the Infragistics grid (Yes, I've seen it happen), even if they don't use any of that functionality, rather than reducing their dependencies and using the 3-rd party grid only when necessary.
I agree with you entirely. We were just talking today about the perils of black boxes and I think that that's what you're getting at. If you've got code that you didn't create, then it's pretty likely that you're going to get burned at some point when something in there goes wrong.
Jeff, thanx I thought it was something like that. :)
Anyway there is alot of good reasons to use 3rd party software, but on the other hand alot of reasons not to use it.
My experience with 3rd party software when it comes to userinterface like custom controls, is that I just dont use it. Often I tend to use too much time looking into how the control works, instead of the time used writing my own. Often they do 123 billion things, but just cant do what I want. Often the effort used to styling the control is insane, compared to .. "it is actually only html, not assembly it generates". Maybe it is because I still use vs2003, but the webform designer is just dosent work for me ( does it work at all?). I dont want to customize every control on every page if only 2-3 properties are changed. Not everything can be done in a stylesheet and not every 3rd party control is styled.
On the other hand, I use some 3rd party software to create things like PDF reports and stuff. And in that case it works fine, because I can just call a method on a wrapper class that does something like PDFGenerate.CreatePdf(template, output, etc ) and nothing else is touched by that.
Maybe it is just me, but I think the problem is that I dont like the way the asp.net or windows forms architecture is build. I love the .net framwork, love C# and VB.Net. But with asp.net I dont think that the controls make everything better. Maby your problem is not if you remembered to close your bold tag, but instead some validation, event handling, binding, viewstate, etc problem.
I am a pathological code deleter also. It just makes things so much easier and cleaner to work with.
And your right... if you want it back, go get it from the source control system.
I used to use SqlHelper. I ended up writing my own wrapper classes - there was a memory leak in one of the releases and I couldn't wait for MS to fix it.
I used to use Peter Blum's controls, but when ASP.NET v2 came out I ripped it all out, since ASP.NET v2 had all the features I needed.
I used to use Nullables - very briefly, if I think I'm thinking what you're referring to. When I found out that .NET v2 was going to have them, I ripped them all out.
Thing is though, you've picked some somewhat decent, robust additions. And you probably didn't pick them lightly - you put some though into them.
Your LavaFlow Anti-Pattern reminds me of a joke. The part about I don’t know what that class is for, it was written before I got here." :
Scientists set up an experiment where they put 5 monkeys in a cage.
In this cage, a bunch of bananas is hung from the ceiling, out of reach of a monkey standing on the ground.
Also in the cage is a a small chair, large enough to enable a monkey to reach the cage.
Each monkey has an electric-charge device attached to it.
Each time the monkey tries to get up on the chair, ALL of the monkeys are shocked.
Pretty soon this leads to the behavior of all of the monkeys beating up any monkey who dares climb the chair.
Now, the scientists take one monkey out and put a new one in, but this one does not have an electrical device attached. Sure enough, it tries to climb the chair to get the bananas and gets beat up. Soon, it follows this behavior too.
Next, take a second monkey out and put another one in without a sensor. The pattern repeats.
Finally, the cage has all 5 monkeys in it with no electrical devices, but any time a monkey climbs the chair, they get beaten up by the others. Why? "I don't know, but that's the way it's always been done around here".
Sorry for the long road to such a lame joke!
Disagree - I'm a third party whore. Almost all my ASP.NET apps reference these libraries.
Sometimes i run into dependency hell, especially with log4net. But for the most part i'm a heck of a lot better off than rolling my own functionality for any above. I do agree with you about _SOME_ ISV's though. Infragistics sucks, its soo bloated, and upgrading is a nightmare.
As for deleting code, i agree with you 99.9%, the only thing i would change is that if the code was commented then deleted and you still needed it. I would tell them to re-implement it. You usually get it done cleaner the second time around.
I wouldn't call myself a third party whore but for complex controls if I can find a vendor who does it well, I won't hestitate to try it. Especially, if it will save my weeks of development time.
Infragistics however has left a particularly bad taste in my mouth.
I chose infragistics asp.net tools based on my past experience with their windows controls which in the past had worked well for me.
What a mistake to think they would do as well with their aps.net controls. I don't recommend this product to anyone! I open support issues about their HTML editor and I get responses like, "you have not deployed correctly" This just infurates me. I put in one request about the HTML editor not able to load an html doc. Their response: "We did not design this for large HTML docs". Excuse me? Define "large". No where in their documentation can find a document size limit.
Their update panel does not work when the server is taxed. After five seconds or so, the connection appears to timeout and no response is ever received. Even when it is received, it is way to slow.
The update panel has forced us to rewrie several pages using JSON and client side script.
I think they've outsource their development and/or support based on the names of the people I've had contacts with. This alone explains the drop in quality of their product.
I just wrote a small post about how dependencies are also the source of many security issues.
I like your writing style, and was wondering if you had time to look the small entry I wrote and tell me what you think. I've read your advice to bloggers, and I'm working on implementing it.
First/second/third parties is terminology that comes from the law. If there is a contract, then it's between the First Party and the Second Party. If anyone else interferes, they are Third Parties.
Yeah. I'm going to have to go ahead and disagre with you on this one... a href="http://weblogs.asp.net/jgalloway/archive/2006/01/25/436377.aspx"http://weblogs.asp.net/jgalloway/archive/2006/01/25/436377.aspx/a
I don't think you should totally avoid it, some third party tools are useful and allow the developer not to spend time developing functionality that already exists. I think someone mentioned a PDF generator.
The more dependencies the more potential problems with upgrades, migrations, etc. Maybe the server goes to 2003 and the third party component doesn't work anymore. Now you wait for them to fix it.
Also, the more controls, the more libraries are loaded, more memory usage etc. It becomes a big headache, and you have to learn everyone's API to use the control (some good some bad).
Here's a good example of not using a library: Client wants reports in Excel format. Instead of using Excel libraries to create the worksheet and reports, we decide to create a CSV file that contains the data. Now, they might not get all the bells and whistles of Excel formatting, but *any* Excel client version will be able to use the data. If you use Excel API, you have to install Excel on the server to get the libraries, etc. Just simpler all around in IMO.