4 ms·
I'd like to point out that this article completely ignores most specialty or enterprise markets. As a maker of insurance software, we employ some people who we
by akeefer 18y ago
I'd like to point out that this article completely ignores most specialty or enterprise markets. As a maker of insurance software, we employ some people who were former insurance agents/adjusters, but none of our developers are, and our only real hope for understanding exactly what has to go into something like a policy administration system is to get out there and talk to customers and potential customers. Even within an insurance company, the developers still won't have a clue because it's not a product they themselves would ever use, and they'll have to rely on someone else communicating the requirements to them.
The same is probably true of just about any other business-focused software; most developers aren't hedge-fund traders, auto mechanics, laywers, hotel managers, etc. yet somehow people manage to build specialized software for those fields. You need people in the organization that understand those fields and what's involved, but the motto of "make something you yourself want" just doesn't apply when you're writing software to run an entirely different kind of business. Developers can be mountain bikers on the weekends, but they're generally not insurance agents or doctors in their spare time.
- gcv 18y agoTrue enough. I deal with "enterprise" software all the time, and I found that it is all horrific. Terrible UIs, almost invariably terrible performance, chronic instability. I'm afraid that, if Steve is right and that to build something good it must be built for the builder, there will never be good "enterprise" software. Also: requirement gathering in that market is just as frustrating as Steve says it is in the consumer market. I've dealt with lots of people who ask for features and then change their minds or realize they didn't really know what they wanted.
- mattmcknight 18y ago"most developers aren't hedge-fund traders, auto mechanics, laywers, hotel managers, etc. yet somehow people manage to build specialized software for those fields. " But imagine how much better the software will be when the developers know as much as hedge-fund traders, auto mechanics, etc. If you look at a book like Martin Fowler's Analysis Patterns, you realize that a deep understanding of the domain is crucial to building a good model to support it.