Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
How Much Software Is Actually Used?

By svillee in Culture
Thu Jan 24, 2002 at 12:09:56 AM EST
Tags: Software (all tags)
Software

2000-present: Shelfware Associates, Inc.
Develop and maintain software product. Conduct system test to ensure product does not fall off shelf.

If I put this on my resume, I don't think I'd get very many job offers. But some days, it seems like this just about covers what I do. I'm on a team that recently wrapped up nearly two years of hardware and software development for a single customer. Yesterday I heard a rumor that the customer may just scrap the whole thing and build their own system, even though they have already paid us pretty much in full. This prompted me to revisit a favorite old question of mine: how much of the software we write is ever actually used?


I'm interested in polling K5 readers that are programmers. Think back over all the software you have written during your career. Ignore software you wrote for fun. Include only software developed for your employer, or if you are self-employed, at the request of a customer. Approximately what percentage of this software has ever actually been used in a production environment?

A demo for a customer does not count, nor does a "trial". In order for it to count, some actual end user must have voluntarily used the software for its intended purpose.

If you developed a particular feature for a product, then the question becomes, has anyone in the field voluntarily used that feature for its intended purpose?

My own career spans a little over 20 years, and I have worked at six different companies. I estimate that about 10% to 15% of my software has ever actually been used in a production environment. Am I just unlucky? A colleague of mine estimates the percentage in his case at about 25%.

Don't get me wrong. In today's economy, it's a blessing to have a job at all, and my salary is not directly affected by whether anyone uses the software. But still, as a professional, I'd rather be writing software that gets used.

What causes "shelfware"? Why would a customer pay good money for software and then not use it? A reasonable inference might be that the customer was not satisfied with the product for some reason, but didn't want to go through the hassle of trying to get their money back.

On the other hand, I had an experience about 10 years ago that suggests at least in some cases, the problem is more fundamental. At the time, I was a programmer for a vendor of IBM mainframe software. In this world, a software package would often be priced in six figures, and this in itself was a new phenomenon for me. Previously I had written software for PCs, where a product might sell for a few thousand dollars.

When we were doing a beta at a customer site for one of our products, it was normal practice for us to send a developer to do the installation. On one occasion I volunteered to be that developer for a beta installation at a bank on the west coast. I won't mention any names, but it was a large well known bank.

This was to be the second of our products they were purchasing. The first had already been installed about a year earlier. When I got to the customer's office, I went to the manager of the group that was going to be using the software. I expected to get right to work on the beta installation.

But the manager said, "We're not quite ready yet. It's a nice day. Why don't you leave the tape with me and just head down to the beach? I'll cover for you if your boss calls." So I went to the beach for a few hours.

Later, they were finally ready for me. I went through the installation procedure, and then looked around for someone in the group to give it a try. But no one seemed interested. They all had other things to do.

I thought, okay, maybe people are busy now, and they'll get to it later. But I was only going to be at the site for a limited time, and one of my responsibilities was to get first-hand feedback from users.

Then someone came up to me and said, "as long as you're here, could you take a look at the older product? It doesn't seem to be working too well." The older product had been installed a year earlier, and now they wanted me to get it working. At least they were showing some interest. So I tracked down and resolved the problem with the older product. It was a configuration issue.

I went back to the guy and said, "I fixed the problem with the older product. So, you have a fairly immediate need for it?" He replied, "yes, we are demoing it for upper management tomorrow." That's great, I thought. They care about our products when it's demo time.

I couldn't help noticing that our sales rep for this customer was quite an attractive woman. The cynical part of my mind started spinning. I thought, for over $100k? Nah...it can't be...or could it? But I could only speculate.

Occasionally, customers would ask us for a feature that would keep track of usage statistics for our products, so they could get an idea of how often people used the software. We would always reply that we had no plans to develop such a feature.

Anyway, that was 10 years ago. But the issue of shelfware keeps resurfacing.

There's a lot of talk in software methodology circles about reusing code. Maybe instead we should be focusing on actually using code for the first time.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
programmers: about what percent of your software has ever actually been used in a production environment?
o less than 15% 17%
o at least 15%, less than 30% 4%
o at least 30%, less than 45% 9%
o at least 45%, less than 60% 9%
o at least 60%, less than 70% 6%
o at least 70%, less than 80% 16%
o at least 80%, less than 90% 8%
o at least 90% 27%

Votes: 81
Results | Other Polls

Related Links
o Also by svillee


Display: Sort:
How Much Software Is Actually Used? | 26 comments (25 topical, 1 editorial, 0 hidden)
ignoring fun (4.66 / 3) (#1)
by jh on Wed Jan 23, 2002 at 09:39:02 PM EST

> Ignore software you wrote for fun.

Whatever for? Or, how do you define "fun"?

Of the commercial software I've written that wasn't for fun, perhaps 50% saw production, or maybe it was closer to the 30% or so you cite.
I have indeed ran into the shelfware problem there. And I hope 0% is still in use, though the number is probably closer to 5%. That software, in total, never ran on more than maybe 500 systems.

Of the software I wrote for fun, which includes plenty of software I was paid for BTW, probably 75% was released, of which 75% is still in use (with a good 10 to 20% of the stuff that's not in use being software that was used in production but which I purposfully killed off), and I hope that at least 50% of it remains in use for a good long time. A lot of it is known to be in use on between 1 thousand and 100 thousand+ systems.

To me, this implies that perhaps the software I write for fun is better, or more accessible (it's generally released for free after all), and that it seems to have a longer lifespan. Ignoring it would be a good way to skew the numbers.

Percentages (none / 0) (#3)
by vambo rool on Thu Jan 24, 2002 at 12:05:53 AM EST

Back when I worked for other people, I'd say maybe 30 to 50% of my stuff went into a final product. Maybe less. Much of it died because the company died and took everything down with it. Part of it died because PCs were invented and replaced Minicomputers for which I had written much of my code.

When I first started working as a contractor, it was about the same 30-50%. This was for two (possibly three) reasons.

First, some companies don't bring in the "big gun" contractors until it's already too late and there's nothing that can be done to save the project. But still they try by throwing more and more bodies at it.

Second, the market changes, the company [goes under|gets bought out|changes focus] or the manager gets out of favor.

A good example of both of these is all those companies that swallowed one of the first Microsoft lines that claimed OS/2 would be TNBT* and put all their development efforts into that only to be abandoned after millions in R&D costs had already been spent. I'm not sure Lotus Development (for one) ever fully recovered from that.

Third, frankly, is piss poor management. You can can have an absolutely stunning project/product and if management can't understand what it is or what it does and salesmen can't be made to understand why they should cream over this, it will wither on the vine.

Now nearly 100% of what I write reaches final product stage. I haven't "coded" as in C++ in several years, I now do DB & application development with ColdFusion and/or PHP with MS SQL Server, Oracle or MySQL, but in any case, almost all of it reaches final cut. The contracts now are much more result oriented with a known, well articulated goal quite unlike before.

* The Next Big Thing



Noticed this myself (4.50 / 2) (#4)
by rusty on Thu Jan 24, 2002 at 12:12:37 AM EST

In about four years programming, if I went by your standards (Include only software developed for your employer, or if you are self-employed, at the request of a customer.) I'd have to say maybe 10% of the code I've written has been used. Some of it I'm not really sure about, which is the only reason I'm willing to go as high as ten percent.

On the other hand, I wrote some code for fun that now has several other developers, and something like 30,000 regular users from all over the world.

I don't know whether that changes your conclusions at all. But it may be worth looking at this kind of thing when you consider the shelfware issue...

____
Not the real rusty

Myself (4.00 / 2) (#5)
by scanman on Thu Jan 24, 2002 at 01:02:09 AM EST

I've just started, and I've only made one product, with another in progress. The first one was never used (as far as I am aware) because at the last minute one of the big boss's friends apparently told her that you should only ever use Windows NT servers, even though the whole project was designed for Linux, and everyone else was well aware of this. (It was a really tiny business, where a copy of NT server was a fairly major expense). I was paid in full, however, so I can't say I really care.

"[You are] a narrow-minded moron [and] a complete loser." - David Quartz
"scanman: The moron." - ucblockhead
"I prefer the term 'lifeskills impaired'" - Inoshiro

A reasonable figure (4.00 / 2) (#6)
by arheal on Thu Jan 24, 2002 at 02:02:59 AM EST

That figure (circa 15%) is about average for the medium term (up to 5 years). After that the figure drops because of dying products/companies/industries. I have been programming full time for around 18 years, so by this time probably 95+% of all the code I have ever written now resides on the big hard disk in the sky.
There can be only one!
Shelfware? (3.00 / 2) (#7)
by Talez on Thu Jan 24, 2002 at 02:45:31 AM EST

While IANAC and IANAM (Contractor and Manager respectively), I believe this problem originates from 2 things...

1) Managers specifying software requirements

2) "This thing is crap" doesn't seem to be a valid reason to return software

I was going to write a big speil about it... but I don't think I really need to...

Tal



Si in Googlis non est, ergo non est
target selling (4.00 / 1) (#8)
by adiffer on Thu Jan 24, 2002 at 03:49:51 AM EST

My code reached production about 70-80% of the time. I generally rode in a different boat from all the other developers around me though. My product range was specialized and I could do some of my own selling. During company reorganizations, my product came more into demand and I was free to pounce upon internal opportunities. The fact that my boss let me operate my area as a small business made most of the difference.

The reason my percentages weren't higher was my tendancy to write small bait applications. If I had a chance of winning a new process from some manager I had not previously supported, I would write them something quick to try out. Those apps were not quite production level. I would keep a few around and reuse/refurbish the code most of the time. I usually lost half of those battles, but it was well worth the time spent doing it.

Let's see... (none / 0) (#9)
by shadur on Thu Jan 24, 2002 at 06:19:49 AM EST

... The first "real" program I worked on was an in-house project I'd been hired to finish after the original author ran off. (In retrospect, I should have smelled the rodent then and there. Ah well. Hindsight's 20/20). After a year or so I was fired on grounds of "uncompatible personalities" between me and the company boss. The project never finished. The second project was (again) in-house, for another company, as a major component to a long-term strategy plan they'd made. Unfortunately, when the short-term cash flow is experiencing troubles, long-term projects get downsized. Haven't heard from them ever again other than a short side note in the paper about a local company being investigated for less-than-ethical sales practices. Sigh. Third, and only actually finished, software project was something I started on because none of the traffic accounting packages I could find were doing exactly what I wanted done, and at the time it looked easier to just write my own. It works, it performs its job pretty well, and I received permission to GPL it. It's in debian's testing tree and I've received and fixed various bug reports. So I guess it is being used. This of course isn't counting the dozens of shell/perl/php scripts I've bashed out to automate one job or another...

The only times (4.00 / 2) (#10)
by porkchop_d_clown on Thu Jan 24, 2002 at 09:56:42 AM EST

The only times I've been sure that my stuff was being used was when I posted freeware to palmgear.com - then I'd get bug reports.

More seriously, I'd say about half of my professional projects were cancelled or went live without being used much. I don't mind this too much except when you can see the problems coming, harp about them for a year, then get to the end of the project and people say "this doesn't work!"



People who think "clown" is an insult have never met any.
Strange but true... (4.50 / 2) (#11)
by RareHeintz on Thu Jan 24, 2002 at 10:23:09 AM EST

I've been writing software for my own amusement for over 20 years, and doing it professinally for about 10. I'd estimate that about 80% of the software I've made professionally is still in production use, and most of the dead stuff was made early in my career.

Now, I'll admit that part of that high number is because I wrote some software for large companies that fear change, and they will use a thing for as long as it works. However, part of that is due to a practice I learned early on that, while risky, has probably saved my job more than once: I will refuse to write even a line of code until everyone involved - the customer, management, and techies on the job - buy into the requirements, technical implementation, and schedule. I find that project success rates are far higher when that one criterion is met than when it is not.

Of course, that's not easy. Customers apply deadline pressure, managers have their own agendas, and coders in the trenches generally don't give a damn as long as they're employed - all of these factors (and more) work against having a well-specified, reasonable project plan before coding starts. Also, there's the problem that you can never completely specify any relatively complex system in advance and expect it to come out the way you specified it - but you can completely specify the business requirements in advance and make your changes with those in mind.

Anyway, that's my $2e-02. If it makes anyone feel better, my 80% number will probably drop now that my last employer looks to be tanking.

OK,
- B
--
http://www.bradheintz.com/ - updated kind of daily

Get a better customer :-) (5.00 / 1) (#12)
by Maniac on Thu Jan 24, 2002 at 10:36:54 AM EST

Hmm. Most of the code I've written over the years went into systems that basically ran until the hardware died. Mostly DoD sales, now doing work for NASA. The current system is in operations 5 x 16 with development and support the rest of the week. I'm in the middle of replacing almost all the hardware to give the system another 5 years of life.

I look at it this way, the customer has to have a REAL need to satisfy. The tools that you give them have to be effective. You have to meet the cost and schedule targets. You miss any of these and the product will end up as shelfware.

Of course, with government contracts, you have to get past a pretty serious competition to get the work to begin with. Our win percentage is OK and our performance is good, so we have stayed in business. But the market in government contracts is far smaller than it used to be. Tough times ahead for all of us.

Balance after 4 years (4.00 / 1) (#13)
by ggeens on Thu Jan 24, 2002 at 11:25:42 AM EST

I have been working as a consultant for about 4 years now. Most of the code I wrote on the job has been used.

My first project was cancelled before it went to the production stage (it had some major architectural flaws).

At another project, I started working on a certain change request before it was completely approved. (I had to: it was deemed "highest priority" by the client.) As the work progressed, the new functionality was first postponed, and the canceled.

Then, there were a few demo's we talked about, but they never got beyond the architecture phase.


L'enfer, c'est les huîtres.


Well, (4.66 / 3) (#14)
by trhurler on Thu Jan 24, 2002 at 12:30:16 PM EST

Every line of code I've ever written that was intended for production has gotten there. Now, there are two caveats here. First, I've only been at this professionally for a little over 2 1/2 years. Second, I'm working for one of the fastest growing companies in St. Louis; it is over twice the size in employees that it was when I started, probably has ten times the revenues, and for all that, has been profitable the entire time. As a result, the sample size for me is somewhat smaller and also the urgency of things around here is somewhat higher; if we wasted several man-years of development even just once, we'd be overtaken by competitors.

In that time, I've written(in no particular order) an authentication mechanism, a library for making shell scripts easier to write, a whole lot of shell scripts for automating drudgework(makes it accountable, uniform, and easy,) heavily modified an ftp daemon, partially completed some distributed computing support libraries(they'll eventually get finished, but I don't have time right now,) ported our whole system to a new platform, produced three different releases of the software, written a good deal of the present installation mechanism, and some other stuff I can't remember in addition to lots of system admin work, bug fixes, and a bit of customer support. With the exception of a few scripts written to automate build chores and so on, every bit of the code has already seen production use in multiple environments, save one little set of two C programs. They were my very first task when I showed up here, and both I and my boss have been forgetting to actually put them into place since about three days after I started. Go figure.

--
'God dammit, your posts make me hard.' --LilDebbie

one of the fastest growing companies in St. Louis (4.00 / 1) (#22)
by phobia on Fri Jan 25, 2002 at 05:31:01 AM EST

who is it? com'on, you can tell us.

[ "never talk to strangers" - RFC 1855, 2.1.2 ]

[ Parent ]
At least half (3.50 / 2) (#15)
by scorbett on Thu Jan 24, 2002 at 12:59:25 PM EST

I've been developing professionally for five years, and in an amateur capacity for about nine years. In my first job, almost all of the code I wrote for my employer was used by customers (except, of course, for the few internal products I worked on). By contrast, in my second job, almost none of the code I wrote ended up in the hands of customers, mostly because almost every project I worked on was scrapped or delayed indefinitely. My third and current job seems more in line with my first job, so I guess it depends on the company.

My own personal opinion as to what causes shelfware is that if no one is using a certain product, then the product was not thoroughly thought through in the first place. I can easily see this happening in the amateur/free time world, where people write code just for the hell of it, but in the professional world, a little market research would probably prevent shelfware in many cases. Find out what the customer wants, and THEN write the software. I've seen too many companies get this backwards.



"free time" software actually has better (none / 0) (#19)
by svillee on Thu Jan 24, 2002 at 07:33:33 PM EST

...not thoroughly thought through in the first place. I can easily see this happening in the amateur/free time world...

The really interesting sentiment I am getting from comments by other people here is that just the opposite is true. It's the software commissioned by employers that tends to become shelfware, and the software written for fun that actually gets used.

[ Parent ]

Very little! (none / 0) (#16)
by spcmanspiff on Thu Jan 24, 2002 at 01:52:34 PM EST

Most of my code saw production briefly, then died along with the dot-bomb client :)

I think that right now, between 0% to 5% is being used.

The only work I did that was intended for production but never ever saw it, even for a day, was a few months of intensive architecture work desiging the internals of a new, super-flexible financial transaction engine. This was going to be used by a dot-bomb alternative currency company that was mainly in the business of gift certificates and micropayments, but wanted the ability to expand into fund management, invenstments, multiple currencies/countries, etc etc etc. (Rhymes with 'lose'!)

They went out of business a bit too quick, *sigh*. Also, I was exclusively doing architecture and no implementation, so I don't even know if this counts as 'code not used.'

I'm a little iffy on whether my current project (struck out on my own as an independent contractor, yay!) will really see the light of day. No big deal, though, as this is kind of a 'get-my-foot-in-the-door' thing.


Contract projects are generally used (5.00 / 1) (#17)
by HagakureGuy on Thu Jan 24, 2002 at 03:14:34 PM EST

As someone who has spent most of my time as a contractor (8-9 years) vs. a full-time employee (2 years), most of what I have written has been used. I would say at least 80%. I usually get called only when someone is serious about getting an application written, since my time costs them money. I have noticed more 'wasted' work lately, for demos and proof-of-concepts that never get approved, mostly due to lack of further money.

Of course, the most annoying abandoned projects are the ones I would write for altruistic purposes, yet no one ever used. Seeing the [non]usage reports on the code repository I wrote at my last employer was really sad.

Some days I need to remind myself that it's only a job.

And it seems like such wasted productivity... (4.00 / 2) (#18)
by treat on Thu Jan 24, 2002 at 04:42:01 PM EST

I have a lot of code that saw production, but ultimately for no reason. It was for a dot-bomb, and we developed the most advanced software in our space. (in fact, too advanced, driving costs up so high that customers could not afford our fees in a rational economy).

I have a copy of the entire codebase, but it is useless. Developed too hastily for the code to be modular enough that any pieces are useful on their own. It took multiple teams of people to maintain this software on a daily basis, and it would be a substantial effort for anyone else to understand how it works well enough to maintain and extend it. (It was never stable, and there is no documentation whatsoever). Substantial pieces (user interface and database backend) require expensive pieces of proprietary software.

I can not think of any use for this software. All the work that was put into it is wasted. The only people that profited are the employees of the company while it lasted (i.e. from payroll). The customers paid more for the service than the value they could possibly have been received. Investors, of course, got screwed.

Even if the software had any conceivable use, the issues of licensing and who owns the software might be impossible to solve. The license under which I have the software is simply a verbal agreement that it is for my own personal use - I can not distribute it, use any part of it for any business purpose, etc. If I desperately felt it should be released under a free license, I would not know where to begin, and would probably find it impossible.


What a good question! (none / 0) (#20)
by SIGFPE on Thu Jan 24, 2002 at 10:13:52 PM EST

I had pondered the same. When I was developing software as part of a games company very little was used. We were devloping a 3D API that got killed when Direct3D appeared so that code died. Lots of people around me worked on games that were frequently canned. I also worked on hardware design that went nowhere and on a software collaboration with SGI that died (Firewalker anyone?) This was a fairly successful games company so it's not a bad reflection on the company - it's just the normal way things work.

However I now work in movie post-production. Now when I write software it's not meant to become a product - it's meant to build tools that we use right now to get a movie out the door. So I'm happy to say that I've touched many pixels in a handful of movies.
SIGFPE

Really? (4.00 / 1) (#21)
by phliar on Thu Jan 24, 2002 at 11:10:57 PM EST

I'm surprised... this is not a question I'd have even thought about.

Where does software written for money, but a research grant (not a commercial company), fall? I did that for about ten years (and other people in my research group used my code). Does that count? It's not "written for fun" (actually it is -- all the code I've ever written has been great fun, and I still have every line of code I've ever written), but the idea is not to satisfy some customer's need but to answer some question.

But ignoring that, and concentrating purely on the commercial side: I've been doing that for about seven years, spread over three companies. In one of them I wrote a prototype (in Unicon) to demonstrate an idea I had; that project was approved and I wrote it "for real" in C++. Real customers are using that (and I wrote a paper on the idea which got accepted at a conference in Italy, and the company paid for my trip to present it -- all expense paid vacation in Europe!) On all the other projects I worked on, all the code was used by honest to god paying customers; this continues in my current job. So not counting the code I wrote in Unicon, 100% of my code was used. And I'd argue that even the Unicon code was actually used since it served its purpose completely.

Could this be a cultural thing, the old IBM mainframe culture (with ties and white shirts)? I have only worked for Unix companies; and grad school was all Unix too. The hacker culture, the "coolness of code" has been very strong in those groups. We didn't have a clear separation between work and home, the people I went drinking with were the people I worked with, and we'd often still be talking about code and Unix six beers into the night.

It's a good feeling, the knowledge that other people are using stuff that you wrote.


Faster, faster, until the thrill of...

At the other end of the scale (none / 0) (#23)
by hansel on Fri Jan 25, 2002 at 07:59:32 AM EST

A lot of the development at my workplace is simple reports and tracking systems using Access/Excel as a frontend to SQL Server. It's easy for a manager or the president or whatnot to imagine some relatively complex feature they want (like automatic calculation of raw materials from the production plant), and for me to get the go-ahead. These turn into 40-50 hour projects.

At this point, perhaps 50% of what we write is actually incorporated into the normal workday and gets the use intended. It's a problem that's well-recognized at the company, but is difficult to root out, because few managers are able to clearly and completely change the behaviour the department completely, meaning a new report that's supposed to significantly alter the workflow is met with resistance and quietly dropped, if possible. Often, the manager isn't even in favor of the report--the president told him to have me make the report, and then to incorporate it into the management of the department, but the manager disagrees, and does the quiet dropping himself.



Not much, sadly... (none / 0) (#24)
by wintermute204 on Fri Jan 25, 2002 at 01:16:50 PM EST

When I first took a job with the company I'm presently at my fist real task was to go to a customer site and install the software we wrote for them. That was in 2000. Three months ago, they called and wanted some answers about using our product with SSL, so I got that toghether for them. A couple days ago I heard from them, still not using it, about getting a version for Win2k. I couldn't beleive that they had it all this time and were still not using it.

The worst case for me was when I wrote an interface between SAP and our product. It was really slick and alot of work, but the company just dropped it. Three weeks of effort and thousands of dollars spent on me traveling to there site a bunch of times and it was just gone.

If I didn't really enjoy the stuff I'm doing it would be really discoraging.

btw We have a site going into production next week (supposedly) so I'll have to see how that works out. Really good question though...

Funny how it works (none / 0) (#25)
by skim123 on Sun Jan 27, 2002 at 08:45:15 PM EST

I've not worked on too many software projects, only being 23 and all, and being self-employed, but back when I was working as a consultant for a consulting company (as an intern, in fact), I was being billed out at $120/hour for four months, 40 hours a week (so we're talking a ~$75,000 job), and the intranet application I developed for them got used for about two months. They wanted a big replacement for their old system, but everyone knew the old system so well, no one really took to the new one. The one guy who was really interested in the project had a lot of say when it came to the budget, I guess; every day he'd get excited to work with me in designing the application, and it was built to his specs, to the T. He was very pleased with the product, but I guess the rest of the company wasn't.

At the other end of the spectrum, I wrote some software for my dad's company when I was a junior in high school (so, what, 7.5 years ago?) (programmed in TurboPascal, if you're interested). Charged him $50 for it. :-) He and his secretary still use it daily. (The program was a relatively simple database system: allows them to insert information, update it, delete it, etc., and run queries on it. Uses a simple text-file database scheme, but is very easy to use. Prior to the software approach, they were actually using index cards to maintain this store of data. :-)

Money is in some respects like fire; it is a very excellent servant but a terrible master.
PT Barnum


The shorter the code, the more it gets used (none / 0) (#26)
by NoNeckJoe on Tue Jan 29, 2002 at 12:02:58 PM EST

What I've found in the last few years of my programming career is that the shorter the program is, the more likely it is to be used. At my last job I wrote several small scripts that performed routine data conversions, computed starting points for simulations, and various other small tasks. I still hear from people who use those scripts on an almost daily basis, and they are grateful for them.

The two huge simulations I worked on still haven't seen the light of day.

At my curent job, I spent six months on a project before we scrapped the entire thing. Ironically, it was the first complete software product that we could have sold. I've spent the rest of my time developing libraries and maintaining a huge code base, but it sees very little use. The most valuable tools for me, and the others in development, have been the quick and dirty tools that manipulate data.



How Much Software Is Actually Used? | 26 comments (25 topical, 1 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!