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."

Comments

Two reasons...

[Kjella]

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.

Intellectual bugs

[Anonymous Coward]

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.

Re:kinda true

[Maurice]

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.

Re:kinda true

[ratboy666]

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.

Re:kinda true

[DudeTheMath]

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.

Re:kinda true

[mcrbids]

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