For a few years I had the distinct impression that nothing I wrote would ever see the light of day. I went from project to project working on code that eventually got scrapped because of a change in corporate direction or because the client changed their mind about something. In once case I was hired into a large computer company that rhymes with Hell where on my first day I was informed that the large project I was hired to work on had been canceled, so find something to do while we figure out what we're going to do next. After bouncing around for awhile I took a job with a smaller company but within two weeks of being there I started producing applications that were used on a daily basis by about fifty people in the company and got continual feedback. It was one of the best feelings in the world, having people come by and say "This is great! Now if only it would also do this..."

Same thing happened to me, except I didn't leave (ok, I admit - paycheck was too good to pass up)... I almost went nuts trying to invent things to do. Doing nothing is MAJORLY overrated... Finally I broke free and although getting back in the world of deadlines and things that were supposed to work yesterday wasn't easy - I'm back where I belong - writing things that actually get used somewhere and where I get yelled at if they don't work...

Funny, I just jumped projects for this very reason. Well, that and I thought the end result of no one using our product was the Miltonization of the project. I didn't want to wait around until the "glitch" was fixed.

Sounds like yet more people who have had experiences straight out of Cube Farm. I've always wondered why this seems to be the norm instead of the exception.

You'd think that, even with all of the political in-fighting, at least *something* useful would get done, but somehow it just doesn't seem to happen...

its been a good 3 years since ive made something usefull. When I try and code something, I scrap it because 1. There is already a program out there that does the exact same thing or 2. No one will ever use it. Like everyone else mentioned, it seems you get more responses when you develop something for a small company; and it feels great.

> you'll find people working on stuff that isn't going to ship.
> Or that if it does ship, it won't be noticed, or won't move
> the needle. That's tragic.

agreed.

I see a compelling argument hidden in there for open source.. if the work you have done is in a proprietary code base, it dies with the company that owns the copyright. with open source it can live on.. fork.. be used in many ways by many folks and can be adapted infinitely.

Perhaps this isn't possible in most situations... perhaps it would be used less or fail.. but it is certainly something I would consider if using the metric "stuff that people would actually use".

great post.

Seems like you are pushing the idea that the value of software is in direct proportion to how many people use it. This is a very narrow definition.

Many people eat at Denny's, drink Coors Lite, eat McDonalds, etc. In that sense you have appealed to the masses and/or have shaped them by there not being any alternative (I will drive 5 miles to find a good micro-brew rather than drink Coors Lite). But these products are hardly the 'best'.

Some people want to write the best software in terms of size, speed, elegance, etc. Does that mean it will be used by many? No, and that's where marketing comes in. For the most part is a developer's ego stroked when they write a 'hit' they everyone uses? Sure. But that should not be the only criterion, and it's far from the 'ultimate metric'. That's rather shallow.

>Seems like you are pushing the idea that the value of software is in direct proportion to how many people use it. This is a very narrow definition.

All art is pop art. No matter how beautiful something you make might be, if no one ever sees it or wants it, does it really exist?

Interesting post, I guess on the other extreme you've got "Shut Up and Ship", where you might spend so long adding cool features that, individually, people will love, but they combine into some sort of monogoloid hybrid of every geeks wet dream application.

Shut up and Ship...
http://destraynor.com/serendipity/index.php?/archives/122-Ship-or-Shut-Up.html

I would propose a slight modification to the statement, "their job is to build software that people will actually use" and add this:

"their job is to build software that people will actually want to use."

Our entire company uses Lotus Notes as its e-mail client and I have yet to meet a single person outside of IT that wants to continue using it.

On the other hand, we get daily requests from new prospects for our products who were recommended to us by other customers. Now, that's a great feeling!

Steve, great point. I'll accept that change.

Also, for the other Steve: I'd argue that the vast majority of software that's written is either never used, or used only grudgingly by people who are required to use it. Size of the audience isn't really the point here; I'd rather have 10 happy users than 1,000 users, 900 of which are unhappy.

I am constantly looking at my code these days and asking myself, before I write new stuff, "If I write this, is it actually going to be used?"

I have this knee-jerk tendency to want to write a function or a class that takes into account every possible need that I *might* have in the future. It takes a lot of discipline and self-control to make sure that I only write code that will actually be used by the product and its users, not what I think *might* be used, or what *might* be useful to the end-users. I have to work really hard to restrain myself and wait until they ask for it before I provide it.

In short, yes, code and software in general should focus on what th users will use, not what I *think* they might use. The vast majority of what *I* think they'll use ends up never getting hit by the code profiler.

In another vein, as Corey pointed out, there's a compelling argument here for open-source code. I was wondering again, just today, if there wasn't some sort of site out there where developers could submit source and algorithms to the general public, so that developers could then go there and search for existing code that solved their problem. It would be nice if I could go to a centralized source code repository on the Web, and search it for something like "quicksort c#" and have it produce a list of available code submissions that various authors had submitted, and download them, so I didn't have to rewrite it. A facility like this would go a long way to helping us to avoid reinventing the wheel, especially if it provided tools to foster collaboration. Something with user-based ratings, critiques, etc.

Just a thought.

FYI Mike, Slashdot discusses "building a programmers rosetta stone" here:
http://developers.slashdot.org/article.pl?sid=07/01/21/1410208

Often when I am checking with my users, I find they would have worked out their own shortcuts and neat little tricks on my software. These could be some thing I designed or a surprising new use for different functionality. This is one of the best parts of my job.

Since I have a Commerce degree, creating a product that people will use is paramount. My two partners and I always have this conversation:

"Someone asked for feature X"

"Are they going to pay for it?"

"No."

"Tell them if they want, they have to pay for it."

"What if they don't want to pay for it?"

"Then find someone else that's interested and will pay for it. Then get the original company to also pay for it."

It's interesting. Our application is so client-focused, it's almost ridiculous. Such is the poor state of IT apps that our clients are actually surprised, no, shocked, that when they ask for something, we put it in. Apparently such treatment is non-existent when dealing with most IT companies. And we don't even whine about it.

Now maybe if that raging egomaniac Joel Spolsky would listen to his customers and allow deletion of case relations in the most overrated product in the world - FogBugz, I would also believe that maybe there's someone else in the world that works like we do.

I agree that if you're being paid exclusively to produce something that people will want to buy, then you should be a responsible employee.

However, I disagree with the implication that it is *always* a waste of time to write code unless other people will (want to) use it. To my mind, there is nothing wrong with putting effort into something purely for one's own satisfaction, whether it is a chunk of code, a hunk of prose, a math puzzle, or a painting. Fiddling around with anything for intellectual amusement makes one's mind sharper, or more relaxed, and there are always new things to be learned by playing.

There is also a lot to be said for working on something that has no immediate market or application, because so often, it turns out that someone will indeed find a way to put it to use. Think of Faraday's (perhaps apocryphal) response to the government official who asked him, "Of what use is this electricity?" Faraday answered, "I do not know, but I suspect that one day you will tax it."

To that end, I am always happy to see companies that pay people to do undirected research, and I wish that both the private and public sectors would spend more money in this fashion. It seems to me that we are lately obsessed with immediate applications for everything, and I worry that we are coming up with only incremental improvements, and overlooking the next big thing.

Plus, it's okay just to have fun, as long as it's not on someone else's dime.

I'm young and not yet at the employable stage. It scares me that I might end up having to write pointless code until I think that's what I'm doing at the moment.

And Mike, Google Code Search can be used something to that effect, I've pouched and adapted a lot of code I've found there. It's also very useful as extra documentation if you don't know how to use a library.

I think you are all missing the fact that you don't know beforehand what will be successfull and not, that's the reason why large companies have hords of people that seem to do nothing or working on projects that may seem useless. Who knows ?

Also, as long as you are coding you are learning, it's careless to say the only thing that matters is to ship, Rich Skrenta seem to go as far as to say that work on standards is useless, thats pretty important work in a long perspective.

I feel that as long as somebody uses the app then the programmer is fufilled even if it is only one person.

Two or so years ago, while discussing a late-‘90s start-up I used to code for, a new co-worker asked me if my application was still in use. It was food for thought then…and now a defining metric along this thread for me includes “How long is my application in use?” I am very please that two of the applications I devoted years of my working life to are still in production. (Eight years and four years, respectively.) Sure, some (much?) of the code has been refactored out of existance, but data structures and business object taxonomy has most definitely endured.

This “how long in production” metric is personally rewarding, I recognize this and the viability of my new employer’s application played a significant role in my decision to join the team last summer.

This highlights the difference between "programmer" and "developer". To write code is to program, but to take some requirements, design a solution, make decisions on what is useful/will be actually used and weigh against what you'd like to do if you have the time - that's Software Development.

Personally, I enjoy working for a company who is also my customer. It means that I only get asked to do things that will be used. I try to make a good job of it, so it looks nice and is easy to use, but ultimately I'll get direct feedback from the people I already know will be using it in anger. It's a good feeling.

I guess I am fortunate that I develop for both internal and external customers. At the company I'm at, I'm pretty much the sole developer and *all* the software I write gets used--I don't have time to write anything that won't get used. That's another important question I get to ask myself when I set out to write the software. "Do I have *time* write this if it doesn't fit into the schedule, or am I just goldplating the system?"

I'll have to check out Google Code Search, and the rosetta stone idea. They both sound promising.

Add me to the list of people who skipped projects because the work that was being done was never gonna be noticed by anyone

My directly-written software gets used every day by hundreds of thousands of people. You can kick that up into the millions if you count code based on mine or derived from mine over the course of the last decade. Prior to this particular job my code was in limited venues, and now it's literally world-wide.

Fun stuff, but a big responsibility, too. The next release must live up to the quality of the prior releases, and now needs to incorporate ideas about software design we didn't have 10 years ago. I don't just write new code for new releases, I have to revise existing code to match the new code (and keep an eye out for future maintenance coders).

The good news is, it never gets dull. I'm starting a major new release today, and I've got about three weeks to finish it. Hey! What the heck am I wasting time here for?

maybe, programmers should just code, and the rest should be done by other people

just wondering

I don't think number of users matters. I would rather write something that the top 10 brain surgeons in the world rely on to do their jobs than write several lines of trivial code in Microsoft's TCP/IP implementation that get used by 100,000,000 people a day.

I'll be honest, the little bit of code I've released outside of my own computer (most of my code was for myself) received a small amount of use. But 450 people using my program as opposed to just me is still a heady thing. I once uploaded an app to AOL in the mid 90's. In the early 00's I went back in and checked on it, and it had gotten over 10,000 downloads. There's still one of my apps floating around out there that some use, even though I haven't supported it in years and years. That's an interesting experience.

What was sad, though, was that I had a computer that had three full-fledged applications ready to ship when my company folded and took the software. I wasn't even writing the software for them, it was my own private effort on the company computer. I learned, then, to never put anything on my work computer. A simple lesson, now, but one hard learned when I was a teenager. I'll never rewrite those apps again.

Anyhow, writing code SHOULD be fun... but most often, it simply isn't.

The greatest thing about being a professional programmer is getting a paycheck.

Yes, it is truly great if hundreds/thousands/millions of users use/love your app. But, to be quite honest, I don't really care from a standpoint of personal satisfaction. I want the users to use and or love my app but that's only because I want to stay employed. Do I take pride in my code, my UI design? Of course I do. But I won't lose too much sleep if my boss says the powers that be have killed the project I've been working on for months.

As long as I'm treated with respect, given a proper working environment and collect a decent check on Friday then all is golden.

If you want to feel true personal acheivement from coding then code something you want to code in your spare time. Make certain it is something you can put your heart into and nurture and develop using your standards and your guidelines. Then when it's ready toss it out there into the big wide open and see if people like it (and more importantly will pay to use it).

Thank you! This is inspiration. I write lots of fun throwaway scripts for the purpose of learning this-or-that esoteric language. I have lots of ideas, but nothing ever gets done. I have now cleaned out my "~/Dev/Projects" folder and permanently trashed most of the half-finished messes that did nothing in order to focus on only two real usable projects.

Some of my best software is used by (a) me only or (b) one or two people. I don't feel unfulfilled because I don't release it into the wild. More often than not, I can take a class or a module from these and use it in something else that's actually going out to all our clients.

I have found that even in writing code that never sees the light of day, there is something positive that can gleaned from the experience.

How else do you learn what not to do? Which is just as important as learning what to do.

also, I've had the experience of coding features that the user didn't know the needed until they started using them. Then you get e-mails like "you have cut my administration time by 20 hours". When I wrote the feature, I "Assumed" that the user would use it. but we do that for all features.

My question is what is the best way of identifying which features have the highest probability of being useful?

Jeff, you make an excellent point but sometimes it's completely out of a programmer's control to ship a usable product. What do you say to programmers who have to deal with unrealistic deadlines, ridiculous requirements and a producer that thinks having the site done in all Adobe Flash is the way to go?

I can write code. No I can write good code...but without everybody on the same page it's hard to make something that really gets used by the end user. The fact is Chuck Jazdzewski's quote is still dead accurate: If a measure of success is if I ship a product I believe as a programmer I have succeeded. But on that same token shipping software doesn't necessarily mean you shipped usable software and you can't expect the failure of people not using the program is the software developers fault.

P.S. Love your site.

one of those cosmic collisions:

<a href="http://www.jnd.org/dn.mss/human-centered.html">http://www.jnd.org/dn.mss/human-centered.html</a>;

I agree with him more than Our Host. Here's why. There are two broad classes of coders; coders for hire and developers. I've worked for both kinds of organizations and been the customer of both kinds. The latter is preferred over the former. Being a coder for hire is awful, as the article demonstrates; not much different from bricklaying. Being a developer working for (or being The Smart Guy) is better by any measure. The Vision Thing does matter. It is the reason that software development really exists: to implement a Better Way to do something. A Better Way To Do Something *almost* always comes from a subject expert who: does know a Better Way, knows this strongly enough to tell the client to Stuff It when called for, and does want to get the code right (it expresses His Vision).

Oddly enough (superficially, odd) the client gets a better system through the application of Tough Love: "you're a freaking fool, just shut up and do what you're told". Clients who think they're in control because they've got some coders on billable almost always end up with drek. They get what they deserve. If you've spent any time in the financial industry you've seen lots of 1960s software running around in Pixel Dust. Amen.

> sometimes it's completely out of a programmer's control to ship a usable product

Is it truly out of a programmer's control to ship a usable product? If so, then that's a type of programming I would choose not to participate in. You can change your organization, or you can change your organization.

http://www.codinghorror.com/blog/archives/000689.html

> I agree with him more than Our Host.

Well, I would sincerely hope so, since he's Don frickin' Norman, and I'm just a random guy on the internet.

Ever try to use an API with no documentation? Frustrating experience.

Comments are useful, if you comment

Use Built In VS stuff (Allied Comment) or NDOC. VBers don't worry, I think there is VBDOCMAN or similiar.

Here's a link on C#

http://www.codeproject.com/csharp/csharpcommentinganddocs.asp

"Some people want to write the best software in terms of size, speed, elegance, etc."

Sorry, elegance counts for squat. An elegant solution may satisfy intellectually, and just as several have mentioned, there is value in this. However, relative to success in software development (the main point of the post), it matters not.

I just finished a (beta) sub-system that I'm convinced would greatly simplify our process and increase productivity. As I was working on it, I tried to imagine the reasons (perhaps good reasons) that it would not be adopted at this change resistant organization.
In the end, nobody even looked at the camtasia demo I recorded. Worst outcome ever - I picture myself explaining this in some future interview, "it really was a good idea and would've been useful." Yeah, right - prove it. Worse than failure.

>that's a type of programming I would choose not to participate in

Good point but if I changed my job everytime I was unhappy with the direction of the application I'd probably have a resume 20 pages long. I think it's a fine line just like anything else in life.

But I agree with you...everytime I find someone complaining I just tell them....DO SOMETHING THEN! ;)

>How many users actually use your application? Now that's the ultimate metric of success.

I would rather my programs be very useful to a few dozen people than to be only slightly useful to thousands. Mind you, all my applications apply to a very narrow field of users so this might not apply to all types of programs.

In the long run I would like to lead the function of a large organization.
In the short term I would like to build up myself as an efficient employee through knowledge, skill, responsibility and honesty.