Slashdot Mirror
What's So Precious About Bad Software?
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."
Now, the stuff that isn't released to the public? That's 180dB noisy code. I can relate with what's being said here to a degree.
That said, I don't think sloppy code it the real reason source stays closed. Big business just thinks it'll make them more money in the long run.
1. What others don't know, won't hurt you. Any improperties in the code, any patents violated, any sarcastic remarks in the source - if you don't release source, they won't see it.
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.
Live today, because you never know what tomorrow brings
In one company I worked with we were having real performance issues with a billing application. We staged a meeting with the software supplier to try and resolve things. One of the main problems we had tuning the database was the use of obfuscated pl/sql code in the Oracle database. I could see what was executing, but couldn't even add hints to help things along.
I asked them if we could get access to the code to help in tuning efforts.
"That's our Crown Jewels. We can't just let anyone see that" came the reply.
"Well, your Crown Jewels appear to be made of brass" quipped one of our project managers.
It's always been my experience that software companies prefer to hide what's behind the scenes. Having worked in some, I understand why.
Where there's muck there's brass. And vice versa.
I wonder why SAP is still in the business of ERPs then. SAP's R/3 code is open (but not freely distributable). If you are interested in the inner workings of SAP's R/3, log in with developer priviledges (or just SAP*), fire up the R/3 builtin debugger and look how the code is actually working.
Yes. You can build a successful business with proprietary code and still show it to the world.
Having worked for a large stupid company, this really rings true. We were a startup with a product that did X. A big famous large stupid company bought us and said, ok, we want this HUGE thing Y that does this and does this and does this and does this- and it has to be built on X (because it was "prestigious", although it did NOTHING similar) and totally integrated with it and the Y data types have to be completely intermingled with X data types so you can transfer objects from the context of X to the context of Y seamlessly. (I have to change details to protect the guilty, but imagine that X was a raytracer, and Y was a vote counting system.)
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.
At my previous place of employment this reason for keeping software closed was actually named several times by different people.
May Peace Prevail On Earth
I'm in exactly the same position. I'll be obtaining my phd in a few months, and I planned to release the full source code for my work, which amounts to over ten thousand lines of code (machine learning and EA's in my case). It all works, and what it does is pretty cool. However code written over three years, haxxed about, experimented with and cannibalized at times to make utilities does not in fact make a nice release candidate.
There ought to be an open source project to clean up research code and make it easily useable.
As it is I'll probably release the code when I have time to completely re-write all the code, making it intelligible.
intersting thoughts. I am in medicine; however, only a small fraction of the programs are related to medicine. I have in there general utilities that I have used for mass conversion of file formats (usually one text file format to another), or to allow me to get access to datasets others have published.
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 the essential knowledge to program, I just don't care about taking the time to polish off a program - becaue to me they are just tools. I understand why a programmer would be upset about releasing poor code, but for someone who considers programming more of a hobby, I don't see the point.
When all else fails, try.
Back at Aspen Technology, I was working with the IRMA card. They provided source code (In C)for their file transfer code for $100. I tried their code and found really dumbass bugs, such as:
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.
Fight Spammers!
Yes, because that's baloney. The only value your company is selling is the knowledge capital in your engineers, technicians, sales and marketing staff. Other companies pay for your crappy code because its works. But they only know it works because of whatever moderate success they believe your company to have. If some other company stole your code, the market would have no clue whether the code works or not; they'd still buy your services. Nor could that new company wield the code like you code; if they could do it any better then they'd write their own code, because the code is a reflection of the knowledge growth of the company.
Code only ever matters to other engineers. Its not a capital asset in and of itself, regardless of what the lazy, inept investors and bean counters fool themselves into believing.
Years ago I posted the source to a neural net implementation that I did while in school. It was a very simple one with just regular back propagation, and the code was documented with examples. Soon after that I started receiving all kinds of email asking for help with the code from people clearly trying to use it to do their Comp Sci homeworks or projects. I started out with courteous and helpful replies, but at some point people ask questions which really have nothing to do with the software (and more to do with whatever that person is working on) -- to the point where they are wasting your time and you have to cut them off. Then they get annoyed and start insulting you.
the most likely event would be that I release the code, people look at it who are interested in the algorithms, they recoil in horror, and my reputation drops.
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 found any other source code for this type of neural network under an open source license, so I will make it nice at some point.
I would have moderated parent as insightful, but I prefer to comment and elaborate. There may be an advantage to releasing your sloppy code. Someone might come along, clean it up and show you what was wrong with it. Sure, that code isn't going to get you any job offers. The next program you write after learning how to make pretty code might, though.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Way back... way, way back...
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.
Just another "Cubible(sic) Joe" 2 17 3061
Our CEO refers to our code as "spaghetti code". I work for a multinational corporation with an engineering base of a few hundred in the US and a hundred or so in India, as well as a manufacturing base of around a thousand (I believe) in East Asia.
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 our CEO has likely no knowledge of any programming language at all, he knows what our code is like.
In the field my employer works in, namely, financial software, we are mostly competing with our customers. What we do isn't necessarily hard, but is complex. We've put years of experience into the software. Any of our customers is trying to decide whether to do these calculations in-house or farm it out to us. If our source code was readily available, we'd get a lot of "Thanks, but we've got what we need now!" instead of sales. It's not proprietary algorithms, it's not trade secrets, it's simply the thousands of programmer-hours that have made an intricate piece of software what appears obvious in hindsight. We do occasionally release the source under an NDA for a customer with an odd platform we can't provide some kind of object module for, but that's certainly the exception. We aren't embarrassed by the state of our code; we just want to make sure we're paid for the work.
You save only 59 seconds over 8 miles by going 75 instead of 65. Do you really have to pass that guy? Do the Math!
We have a memory allocation library at that we wrote which wraps the standard C memory allocation and freeing functions. One thing it allows you to do is create memory checkpoints. To find memory leaks, you set a checkpoint before the memory for some structure is allocated and another after it should all be freed (ie, anywhere the program terminates, or once a structure should no longer be needed).
The program can then dump a full list of the memory allocated, and where is was allocated from at the checkpoint. Granted it is a fair amount of work to wade through a checkpoint in a large application to see what is and isn't needed, but it can be used to detect and fix memory leaks. I successfully used it to track down a very small memory leak in an application (just a few bytes excess), which weren't being freed in a loop. The program would run okay for a short time, but start eating up significant amounts of memory if run long enough. We put a checkpoint before a loop which caused the problem, let the loop run 1000 or so times and did another checkpoint. Looking at the difference between the checkpoint we had 1000 allocations all done from the same file and line number. Pretty easy to fix after that.
No, not impossible.
Our manager would catch this, or any variation of this, first time it happened. This is because on exit, after legitimate cleanup is done (meaning, we deallocate the things we have been keeping proper track of... memory for windows, palettes, layer lists, that sort of thing), the internal memory pools are all tested for pointers that have not yet been deallocated. Every individual pointer, and the groups they belong to, would be reported along with the name of the pointer(s) and the pool(s) which would generally take you right to the problem area. Then they are automatically cleaned up. It would also catch the list that wasn't destroyed, by the way, because the list resides inside memory allocations we track as well.
So now the questions arise: Why are there pointers remaining allocated? Why is this list still hanging around? What are the names of the pointers? Are they polygons? Image layers? Blocks for list elements? What pool asked for them? Was it a filter? A plug-in (mind you, the plug-ins have their own subversion of all this, they get their memory and other resources from us, not from the OS, but we could have a fault in the plugin handling, for instance) Is it an object we made for the OS, like an icon bitmap? Whatever it is, between the pool ID(s) and the pointer ID(s) we'll be brought close to the source of the error pretty quickly.
Once you know there was a leak, you think about what you did with the software, combine that with the ID's on the pools and pointers so you're looking in the correct area, and the hunt begins. Usually doesn't last too long, either. If it isn't obvious (and it usually is), you just keep reducing user level cases until the problem begins to appear and disappear, and pretty soon you're looking right at the problem.
There's just no substitute for rigid, detailed memory tracking, fire-walling, and monitoring. As a debugging tool, it is a very, very big hammer.
I've fallen off your lawn, and I can't get up.
Why would you say that? I didn't remove the OS file dialogs. I just added some that actually worked the way Microsoft said they were supposed to, and had (a lot) more features in addition to the OS's version. If you really want to use a buggy OS dialog that gives you a list of names instead of a properly functioning one that presents thumbnails and names, why, you certainly still can. You can even block select files in the OS dialog. Maybe they'll even fix it some day, you never know.
But until then, when block selects fail, you can find out why in our docs, and then you can learn how to use the image manger dialog instead. Because it, you know, works. And our tree view works just like Microsoft's. Except ours doesn't leak memory, wasn't designed for a C++ interface (we use C) and is a good deal faster than theirs. Other than that, it's just like Microsoft's. We even used their icons.
I know, I know. IHBT. Still, when a troll gets all up in your face, it's fun to poke 'em in in the eye with a stick from time to time.
I've fallen off your lawn, and I can't get up.
I've known/seen companies who have indicated a willingness to open-source their code -- meaning that they've thought about the competitive aspects and realize that it's not going to hurt, and might help, them -- suddenly drag their feet at the last minute, or spend months or years "preparing" to open-source their code. I think this is directly related to embarrassment over the poor state of their codebase.
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 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
I have no problem with your religion until you decide it's reason to deprive others of the truth.
The problem with this idea is that it is really unlikely you actually have implemented everything that Microsoft did, albeit with bugs.
Does it resize? Does it work on every language and codepage supported by Windows? Does it support the full set of Unicode characters? Can you sort in all the optional ways? Can it view in a detail list as well as thumbnails? Does it support every different font size? All the possible icon formats? Does it monitor the file system for changes and refresh itself? Does it handle right-to-left text? Does it handle all the in-place explorer operations like open, delete, rename? Are the icons it displays matched to the COM objects explorer users so that special objects behave correctly? Does it support all the possible media? Does it handle special cases such a path names longer than the traditional 256char maximum? Does it support all the accessibility addons, key shortcuts, etc? Does it work on every version of Windows? Does it support screen-readers?
In my experience, people can do exceptionally great jobs of some ASPECT or aspects of what Windows does, but they won't implement 90% of the background features, mostly because they don't even know they are there. Microsoft have been building these features in for decades (of course, somewhat to their cost in maintenance) and it is a huge hurdle to match them all.
For every expert, there is an equal and opposite expert. - Arthur C. Clarke
I wrote you a nicely detailed answer using quoting and so forth, but slashdot won't let me post it; claims there are too few characters per line. Very irritating. The general answer is that we support what we need to support; some of what you are asking about isn't relevant for a special purpose dialog that displays thumbnails (detail listings... we do show image properties which are far more extensive and appropriate... screen readers... you can't screen read an image); some of it isn't relevant for a dialog that isn't shared with other developers. We do handle Unicode and left to right languages such as Arabic. In addition to the general functionality, we provide a lot of features that aren't otherwise available, and of course there is the "feature" that our dialog actually works for its intended purpose.
The key thing here is that the dialog meets the needs of our customers; and that, it does very well.
Finally, as I mentioned earlier, we didn't get rid of the OS dialogs. We just added another. So should the day come where a user needs a feature only available in the OS dialog, it'll be right there for them.
I've fallen off your lawn, and I can't get up.