Slashdot Log In
What's So Precious About Bad Software?
Posted by
kdawson
on Sat Sep 29, 2007 12:26 PM
from the ugly-to-boot dept.
from the ugly-to-boot dept.
David Gerard invites to read Carla Schroeder from Enterprise Networking Planet, who gets down to the real reason why companies want to keep their code proprietary, with examples. Quoting: "We are drowned in tides of twaddle about precious IP, Trade Sekkrits, Sooper Original Algorithms that must not be exposed to eyes of mere mortals, and all manner of silly excuses. But what's the real reason for closed, proprietary code? Embarrassment."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
kinda true (Score:5, Insightful)
I remember as an undergraduate suggesting to my advisor that I release my (actually rather pretty) code that I wrote to do general relativistic raytracing around neutron stars. His response? "People will not understand your code, they will misuse it, and then they will blame you when it gets them in trouble." You might expect someone who's doing raytracing around compact objects to not be so silly as to do something like that, but I think you'd be mistaken: I know I treat the few publicly available codes in my field (e.g., camb [camb.info]) with great disrespect, bitch all the time, and generally am part of the large community that makes it far more trouble than it's worth for the poor people who worked so hard on it.
Re:kinda true (Score:5, Insightful)
Heck, I just realized I could recruit people here
Parent
Re: (Score:3, Insightful)
It might be something to do with the bizarre psychological fact that p
Re: (Score:3, Interesting)
Some of the programs are for personal use - such as to automate the creaation of a photoalbum for web publishing.
I just don't see the problem with letting people know that I am not a good programmer. I have
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
I'm not sure what field you're in, but mine is small (at most 10,000 people, but actually much less.) Giving away code -- it carries with it responsibility, in the sense that if you do give away code people think you are saying "I am so cool that what I have done is better than whatever you haven't released." Sort of like, I don't know, the difference between keeping a diary and publishing a diary on livejournal. It generates problems.
I guess it really depends on the nature of the code. My pet open source project (see sig) has gotten hardly any feedback. I have a trickle of downloads, usually 2-8 a day, one anonymous bug report and some feedback from the author of UltraDefrag after I contributed documentation to his project. So the problem I've had with open sourcing my code is that no one cares. This is probably partially due to the fact that no one wants a SQL front end to MS Access databases and there are better frontends to SQLite.
Re: (Score:3, Interesting)
Re:kinda true (Score:5, Insightful)
Oh, please. That's got to be the goofiest premise I've seen in a long time.
Code is kept "secret" because the companies, rightly or wrongly, think it gives them a competitive advantage. Heck, some companies should be embarrassed about the appearance of their product, do you really think some suits care about how it looks on the inside? Does Coke keep its formula secret because it's embarrassed or because it wants to make its product harder to copy? Same goes for software.
Heck, many open source products are no beauty to peer into, either. The code is so nasty that the argument of "If you don't like it, you can fix or modify it yourself" is reduced to a smart-ass comment with no real validity. Modify that code? First you have to be able to understand the mess. Unless you've been responsible for the mess from the beginning, or have a lot of time to invest in figuring out the mess, good luck with that.
Parent
Re:kinda true (Score:5, Insightful)
I think there's a feeling that in order to open-source something, you have to have it all wrapped up in a neat little bundle, that you can't just take last Tuesday's CVS checkout and dump it onto a web server somewhere as a tarball, even if that's what the community really, really wants. (A dirty tarball today being better than a slick project and a wiki and everything in three years.)
I've actually seen this happen; you can get management on board with the OSS concept in the abstract, but when it comes to actually giving out their code, and they start feeling like it might make them look bad
Parent
Re:kinda true (Score:5, Interesting)
Yep, here I am. I'm a CTO of a rapidly-growing software company. Our big money maker is a product initially conceived as a "quick project" of a few months' duration and was given similar consideration on design and construction. But it worked! It solved a need at a level that was unanticipated, and now, 4 years later, is satisfying 20x the dataset and 100x the customers originally envisioned.
And it was not originally designed for this level of scale.
So, going from a single, solo software engineer, to several programmers, (and growing fast) and developing a rapidly growing suite of products in a rapidly growing company, the cash-cow project remains, alas, solely in my hands.
Does the product work well? Yes, at least, reasonably well. Users routinely rave about how much time it saves and how it's improved their professional lives. It works well for the problem it solves and the problem is not met effectively by any competitor.
But, the dirty secret is that it's simply inelegant. It's a bunch of not-well-structured code only organized by a sloppy ad-hoc naming convention and riddled with minor bugs that are fixed quickly and distributed well, but shouldn't exist in a better design in the first place.
And, once saddled with the code, Code Inertia takes place [kimbly.com] and it becomes an exercise in how to move to something more sane while doing the following:
1) Keep the customers happy through multiple upgrades that don't appear any different than original. Introduce features that are obvious just fast enough to make it all seem worthwhile!
2) Keep the additional costs of development inline with "maintenance level". This cuts the rate of improvement, and also increases the amount of inertia accumulated with #1, since #1 is written to the "old way".
3) Improve the codebase enough to provide meaningful results demonstrated to the august powers, (this means ROI) and
4) Clean up the kludge enough to allow for improved pace of future development. You want to get rid of all the uglies, but there are so many since a few of your original, naive assumptions about the problem were simply wrong.
It's a hard row to hoe, and there's a bit of a "loan" being made, where design decisions early on made to shortcut development woes carry a long-term burden, almost like an interest rate. Since the company has passed the million-dollar-a-year stage, arguing about those original decisions is pointless; the only thing to do now is to figure out how to take what you started with and make it do what you need it to do hereafter.
I've been working for over a year on a basic design decision change that will close out lots of badness and produce almost an order of magnitude better data integrity. Since starting the project, we've almost tripled in client base, and yet I won't be done for at least another year, if ever.
I suppose the argument is moot - if I hadn't come up with the original product in time, the whole business would have failed. The company, then on the rocks, would have closed, and it would all be for naught. But, with the compromises made, it can be amazing just how badly inertia sets in.
Moral? Write the best quality code you can within the budget you have. Always. Because you'll live with a significant percentage of whatever you create, and the future costs of change may well be orders of magnitude more than your initial cost of creation. And you'll never quite know what it is that you end up living with.
PS: While it might sound like I'm complaining, I'm not! I'm living the dr
Parent
Re:kinda true (Score:4, Interesting)
Parent
Re: (Score:3, Interesting)
There ought to be an open source project to clean up research code and make it
Re: (Score:3, Interesting)
If there was a place that *expected* shitty research code I wouldn't mind, but I have a current open source project that I wouldn't want tainted with the bad coder rep my research code would likely generate.
I've got a fully working temporal neural network sat in a deep directory that I'm sure someone would like, if I can tidy it up first. I've not fou
Re:kinda true (Score:5, Interesting)
Parent
Re:kinda true (Score:5, Interesting)
I developed a system that decoded phototypsetting codes, and imaged onto a laserprinter.
I wrote the software using Borland Turbo Pascal, 8087, so it required a math coprocessor. One of the sales reps aquired a 286 laptop that didn't have a socket for a coprocessor, and wanted to demo the software.
I used Borland Turbo C to do a quick hack to emulate the 8087. Worked fine, but I didn't want to support it. Still, it was (somewhat) useful, and I released it as a hack (emul87 on simtel).
Fast forward 8 or 9 years... I got a call from someone claiming to be a "consultant", who had a client using emul87. Apparently, it didn't work on a new machine! And if I didn't fix it RIGHT AWAY, I would be SUED!
Of course I told him to take a flying fuck at a rolling doughnut -- and he went away.
So, this stuff happens. Go figure.
Parent
Re: (Score:3, Insightful)
Two reasons... (Score:5, Interesting)
2. If you can't see it, you can't take it. Most companies would like to get paid, and the honor system is short on honor. One thing is corporate software - but are you really going to go into people's houses and see if they have a pirated version of Photoshop? Not going to happen, so they design up all sort of serial numbers and activation and whatnot that's incompatible with showing source - you'd just comment out those bits.
Re:Two reasons... (Score:5, Insightful)
Parent
Coca-Cola's secret recipie (Score:3, Informative)
McDonalds "secret sauce" amount to mixing ketchup with mayonaise.
So, Yes. Part of the reason for these kinds of secrets is that they are "bad" in a sense.
At the very least, it would be embarrassing to the companies in question to have stuff like this spelled out.
Re: (Score:3, Informative)
So are music recordings. And we all know how well that's worked out, right?
As an earlier poster said, with precise insight: "The honor system is short on honor." We know this. There is no possible doubt about it. And with open source, it only takes one person to steal something in literally seconds that took many years to develop and hone. This is the reality that commercial developers have to live with.
Speaking as a closed-source, commercial software vendor, I
Re: (Score:3, Insightful)
So are music recordings. And we all know how well that's worked out, right?
Hmm, how? Have all artists starved to death, production and distribution companies collapsed, and is music no longer being created and played because the economic incentive has disappeared?
Re:Two reasons... (Score:5, Insightful)
More improtantly, what's there to motivate them to do that? It's extra work for development, extra work for support, longer time to market, more risk of malfunction compared to just writing the code naturally. And what's the benefit? If I were managing a programming that wanted to do that, I'd ask him what the benefit is for this extra work and complexity, and if he didn't have an answer, I'd tell him to focus on what's important and get this product out the door without goofing off.
Parent
Re: (Score:3, Insightful)
Technically it's usually a win for complexity alone - two smaller pieces are easier than one large one. But then there's the benefit that once all your heavy-lifting is nicely wrapped up, you can start coding the rest of your app in Python or something much nicer than C/C++.
It goes back too... (Score:5, Informative)
In a nutshell, I think corps think that their software is soooo competitively important, that they don't want to release it - regardless of how bad it is.
Re:It goes back too... (Score:5, Informative)
Another reason for secrecy is that SABRE was used to manipulate rankings to favor American Airlines flights over others. This eventually got outlawed by the federal government as unfair competition.
Parent
Often companies can't release it for legal reasons (Score:5, Informative)
Been there. Seen that. Got the T-shirt. (Score:4, Insightful)
-Held together with duct tape and bondo
-Only works by the hand of God
-Looking at it is an example of several works in progress from several different people
Yes. Companies that do that have a right to be embarrassed.
Then again, I've seen the other side of the spectrum where the proprietary code is "SOOPER" efficient and works better than any out of the box solution. Isn't that why you do things in-house to begin with?
Re:Been there. Seen that. Got the T-shirt. (Score:4, Insightful)
Another application I worked on, had vendors dictate features and managers (without any technical background) gave us encryption routines. Worse than hacks, retarded XOR and shift routines that a 2 year old could crack. These same managers have used really badly coded RadioactiveX components made for browsers as a "high performance" server component. And of course they wonder why their servers can't take any load.
Embarrassment is probably a good reason why companies withhold source code, but I think it's more the fear of losing business over extremely shitty and insecure software is their primary concern.
Parent
"Trade Sekkrits, Sooper Original Algorithms" (Score:3, Insightful)
Re:"Trade Sekkrits, Sooper Original Algorithms" (Score:4, Interesting)
Yes. You can build a successful business with proprietary code and still show it to the world.
Parent
Duh (Score:4, Funny)
(No, really, it was all sarcasm.)
Don't forget NIH syndrome (Score:4, Insightful)
Re:Don't forget NIH syndrome (Score:5, Insightful)
We have our own memory management; we do it because it allows us to ensure that there are no memory leaks, anywhere, ever. We have our own linked list management because it is a fraction of the size of the alternatives and does exactly what we need. We have our own file dialogs (and treeview dialog logic) because the OS offerings were buggy for almost a decade. We have our own JPEG routines because we need to load all manner of proprietary and oddball JPEGs. We have our own tree structure code for our ray tracer, particle systems and so on because we can make really big trees and unless we control the memory allocation, the tree becomes too fragmented in memory for it to be handled efficiently. I could go on like this for quite a while. In short, though, there are some very good reasons to skip over the canned solutions. And that's assuming that the canned solutions work perfectly, as described.
When one of your operating platforms is Windows, you either learn to do for yourself or you end up with a buggy application, because Windows itself is prone to long term unfixed (and sometimes unfixable) problems. Write your own code and you can eliminate the problems. That's a pretty strong motivation.
Code in libc may be hard to beat when it comes to doing what that code does; but who is to say you need exactly what libc offers? Memory management is a good example. We require firewalled memory boundaries, cumulative usage tracking by routines and by blocks of routines, named memory groups, live overrun detection, dead pointer detection, real-time and post-run logging. And the code has to be really, really good... if there's a bug, we can't wait for the libc maintainer(s) to fix it. With these kinds of needs, pretty soon you end up writing code. It's pretty straightforward, really.
There's a competitive advantage, too. If a bug is found, your turnaround time can be measured in hours if it is in your own code. For every bug that turns out to be a consequence of an OS or otherwise "not your code" library, bugfixes are much more likely to take longer or simply be impossible. Example? We can process streams of image frames. MS's file dialog let you select many files at once. Seems like a natural fit, right? Click on one file, shift click on another, you've got a block, we should process them. Winner! Well, yeah. But.
If you selected more than about 100 files, MS's file dialog would fail to properly terminate the returned file names, and cut off the last one arbitrarily. Leading to all manner of things, not the least of which was not the behavior that the user was trying to achieve. But wait, there's more! Unless the customer, completely unintuitively, selected the last file first and the first file last, the files would be provided to us by the OS out of order. So? (I hear you thinking.) Just process them in the other order, right? Well, yeah, but the first file in the list we got would be mangled in the natural order. And besides, it wasn't the first one the user selected, just a mangled file name somewhere around number 100 or so. What a mess.
We complained to MS for years about these things without result, until I had simply had enough and wrote our own file dialog. End of problem. Now it just works. Plus, since I was writing it anyway, I did it so the file dialog offers tree views, thumbnails, properties, regular expressions, file management, clipboard tricks, you name it.
No, it wasn't perfect first time out the door, but within a few weeks of release, the customers had ferreted out the weak points and they were all fixed and the working application was back in the customer's hands. I haven't seen a bug report on the file dialog in years now. But if I do... I'll put that bitch down like a KKK'er at an MLK rally.
It isn't wasn
Parent
Code Paranoia (Score:3, Insightful)
Obvious? (Score:5, Insightful)
If we publish it and another companies takes it and uses it to make a competing product we will make less money.
Do we need another reason?
Intellectual bugs (Score:4, Interesting)
So we basically spent a year fucking up X into a conglomerate X-Y system, and ended up doing all sorts of horrible things to get it done on time ("fooling" old code, etc.) And I found out for myself how disheartening it is to be ordered to do something hopeless that makes no sense. Meanwhile we discovered that the sales guys had been running around for months promising a system that did X and Z, and that it would be ready next month. They called a meeting. (This is one thing they were good at- scheduling meetings.) They said we need to combine X, and this "Z" we've been promising, into one product. (Z would be a missile guidance system.) X was "prestigious", Z was the hot new thing, and Y was going out of style (denoted henceforth as "y", lower case). Only two customers used y, but they were IMPORTANT ACCOUNTS.
So there's a panic where everyone is trying to convert X-Y to X-y-Z (something nobody in their right mind would want), in the absence of any specifications at all. ("You guys are smart! Tell us what we want it to do!") And it's getting nowhere and bugs are starting to appear in X and people are using old versions like with XP and Vista. So much time passes that we could have written Y from scratch and Z from scratch without fucking up X at all. (I'm simplifying things somewhat, because I ran out of letters- there were a few more after Z.)
Right in the middle of it all, they pulled everyone into a meeting with patent lawyers and demanded that each of us produce a list of all the intellectual property in the application. The top 20 most patentable things.
What do you write? "System and method to cope with your incompetence?" I shudder to think that they might have filed a patent that prevented someone from doing something worthwhile, but I doubt they found anything they did that anyone would ever want to repeat.
Look at the losers and you'll see ... losers (Score:5, Informative)
So... we look at five projects that have every right to contain crappy code, and therefore conclude that companies keep code closed to hide crappy code? Pick crap and you will see crap. How about some successful projects: Microsoft Windows (kernel), Adobe Photoshop, VMware?
Different Approaches (Score:5, Insightful)
Soooo True (Score:3, Interesting)
Ridiculous article. (Score:5, Insightful)
Who here thinks upper management knows what code looks like, at all? Not bad code, not good code, but code, period. Does anyone really believe that the executives who make policy decisions about whether to release code are in any way qualified to comment on code aesthetics?
Hell, I think most programmers are unqualified to comment on code aesthetics. For a lot of people, programming is just the daily grind. People who actually put their heart and soul into crafting a piece of mathematical art are very rare. So if management can't recognize good code and an awful lot of the IT department is apathetic to good code, how is it possible that the decisionmakers know enough to be embarrassed by the code?
And if we can realize this in just ten seconds of thinking, why didn't Schroeder think of it herself?
As near as I can tell, the reason why companies like closed source is very simple: it preserves the asymmetry of information necessary for their bottom line. A free market depends on both parties knowing the product being bought and sold. When you buy a new car, you can read Consumer Reports, you can read Car and Driver, you can read any of a dozen specialist automotive rags that will tell you in excruciating detail what a certain car's dual overhead cam configuration means in context of their competitor's choice for a single overhead cam. The buyer has complete access to information, and that puts the buyer in a position of strength.
Asymmetric information, where the seller knows far more than the buyer, puts the buyer in a position of weakness. If the product is a black box, then you can't really get an informed independent critique; you have to instead rely on the claims of the people selling the product. Which is great, as long as you're the seller.
Re: (Score:3, Interesting)
The code has been incrementally worked on for at least fifteen years, so yes it is more or less a jumble of sorts. Efforts have failed to make it cleaner, and have actually made it worse. The solution is obvious, and we're doing it now. My point is although o
I have seen some of this first hand. (Score:3, Interesting)
int wait_x(int milsec)
But, when they didn't want it to wait, they would would call wait_x().
When I wrote a list of bugs, it was 3 pages, single spaced.
When at Microsystems Software, there were functions named, "we_are_fucked" and comments that
said, "I know this is crap, but Dick wanted this now. I'll fix this later."
That was 3 years after that programmer left.
No. (Score:3, Insightful)
No, this isn't the reason things are kept proprietary. Stop and think for half a second:
If something is going to be designed and released Open Source, this is decided up front. It has legal implications, especially when you might be interfacing with external third-party libraries and making platform decisions. Then code is written.
Things are exactly the opposite: closed source leads to poor code. No one's going to see it. The product has to get out of the door fast. You hire crappy budget programmers. You don't enforce disciplines of good design and code. Marketing runs the show. There is no ability for the community to see, contribute, and fix. All of these things about the closed source process make crappy code easy. I've seen them all.
But of all of these, no, crappy code is not the reason people don't release their source. I've seen plenty of craptastic code released by companies, that of all things is hardly going to stop them. Especially when improving the code is one of the benefits of releasing it.
doubt is a barrier to entry into a market (Score:4, Insightful)
I think that an existing codebase may occasionally NOT be a mess or a competitive drag on a company. I'm not claiming this is frequent, but that it is possible.
Now, let's suppose I'm a young, hungry company who wants to eat a big, established company's lunch. If I know his codebase is chock full of "technical debt," I'll know he's at a disadvantage because everything he does to respond to me will have to carry along the burden of that technical debt. This means I have a better chance of beating him than if he's got clean code. BUT if I don't know if his codebase is crufty or not, that'll sew doubt into my analysis. That doubt will give me pause and provide a barrier to entry into that market.
You'll note that I made no mention of IP heretofore.
Thus, the company with a codebase that is ashamed of its codebase will be keep the extent of its cruftiness secret, to discourage competitors. Conversely, if a company knows its codebase rocks may consider IP to keep things mum, but if it buys into the line of thinking above, it may show off its codebase to warn off potential competitors.
Re: (Score:3, Insightful)
(see what happens in google, etc). These people think they have a team of very good programmers but it's a bunch of tired old-timers.
Google old timers are very rich.
Re: (Score:3, Insightful)
I don't need to read any further.
Right. Because, of course, Windows is perfect, so the article must be wrong.
You don't need to be a zealot to realise that Windows is probably pretty close to the classic definition of the codebase that's outgrown its original purpose by an order of magnitude or more and is now getting pretty hard to maintain. Why else did it take MS 6 years to release Vista, which isn't really much more of an upgrade over XP than XP was over 2K (which took them
Re:Can't help but agree (Score:4, Funny)
Parent
Re:Can't help but agree (Score:5, Funny)
I've always wondered how they get the acronym "CPAN" from that.
Parent
Nah (Score:4, Funny)
Parent
Re: (Score:3, Insightful)
BS. Sweetheart, the only time Windows ever booted in 5 seconds for me was when I installed a Linux distribution to dual boot and the installer resized the NTFS partition to something much, much, much smaller. That's the only time that phenomenon has ever happened to me, so no, you are not getting 5 second boot times with Windows.
Indeed. That's probably why the poster actually wrote:
It takes 5 seconds to start booting windows on my notebook, my PC is the same.