If you're trying to write software for others, it's going to end up as mediocre and probably not entirely what they wanted.
Stop for a minute and notice how absurd this statement is.
99.9% of all software ever written was for others. Was it all mediocre and "not entirely what they wanted"?
This is the entire reason for systems analysis and requirements specification. You don't need to do any of this for the software you're writing for yourself. You must do all of it and do it well when writing software for others; that's how you insure that it's exactly what they want.
99.9% of all software ever written was for others. Was it all mediocre and "not entirely what they wanted"?
Having lived and breathed (and somehow survived) in the enterprise environment that employs the vast majority of the programmers out there, I can agree with that proposition whole-heartedly.
Yes, 99.9% of the software that gets written is mediocre at best. A shockingly large proportion of it is downright abysmal, but most of it is mediocre. Thankfully, we don't get to see most of that software since it is safely locked away inside the mega-corporations that pay hordes of programmers to write it.
99.9%? That's just insane. You're saying that all the games developers never play their own games?
How about people writing languages, compilers etc. You don't think they use them??
I'd say the majority of open source software is written for yourself rather than others. People contribute the most when they are using that software.
You don't have to be the only customer/user of your software, but it helps to be a customer/user of your own software. That's what I mean by writing for yourself.
I'm saying that the ERP, accounting, banking, claims processing, ecommerce, order entry, scientific, etc., etc., etc. software they work on is for someone else. They dwarf those working on games, compilers, and open source.
I think there's a difference between an engineer working for someone, and the person making the product decision. If you're a developer for a software company building accounting software, and you don't have much use for accounting software personally, you're probably fine. But if you're defining the product, you're much better off if you've been a user of accounting software in the past.
I interpret the post as just a long rantish way of saying: "If you want to write good software, you've also got to use it."
In my experience, there is a lot of software out there that is deemed valuable by management, produces good ROI, but is despised in some way by its users. I'd say the majority of it. (And I've been in many dozens of shops as a consultant.) That will fly for internal software for a big company, but not for a web startup.
Another way of saying it: really doing "systems analysis and requirements" right puts you in the user's shoes. That's the part that matters, not the artifacts produced by the process. (I'm preaching to the choir here, I know.) In fact, the "systems analysis and requirements" process matters not a bit, only the result, which should be getting the real user experience into the heads of development.
Stop for a minute and notice how absurd this statement is.
99.9% of all software ever written was for others. Was it all mediocre and "not entirely what they wanted"?
This is the entire reason for systems analysis and requirements specification. You don't need to do any of this for the software you're writing for yourself. You must do all of it and do it well when writing software for others; that's how you insure that it's exactly what they want.