Looks Like a Cow,Swims Like a Dolphin,Quacks Like a Duck,It Must Be Enterprise Software(subtraction.com)
subtraction.com
Looks Like a Cow,Swims Like a Dolphin,Quacks Like a Duck,It Must Be Enterprise Software
http://www.subtraction.com/2007/10/19/if-it-looks-
16 comments
The classic saying is if you buy SAP/Oracle, you don't customize the software suite to fit your company, you customize your company to fit the software.
I am not sure why that statement, in itself, is bad. I've been in the enterprise software industry for a while, and I have seen how customers have a tendency to request customizations on top of the base product that are huge in scope and would kill the project. My org always recommends 0 customization (never achieved, but intended) to shorten deployment time and go with codebase that is maintained by the product team and does not need a huge in-house IT staff post-deployment.
Of course, if the software is crap that statement would make sense, but if that is the case, you should throw the tool out rather than try to plug the holes.
Of course, if the software is crap that statement would make sense, but if that is the case, you should throw the tool out rather than try to plug the holes.
I look at the statement as not good or bad, just a statement of truth. There is no such thing as shrink-wrapped enterprise software. I've worked with at enterprise software organizations where the customer does their own custom modifications and tries to politically lobby us to get them baselined (and take ownership).
Modifications form a lucrative and essential part of enterprise software, judging by what my co-workers and friends at other companies were billed out at an hourly basis (the consultant was always paid a mere fraction of the $100-$200/hr). Sometimes I wonder if paying for expensive consultants wasn't just a CYA-move by the client ("look, I hired the company to consult directly")
Modifications form a lucrative and essential part of enterprise software, judging by what my co-workers and friends at other companies were billed out at an hourly basis (the consultant was always paid a mere fraction of the $100-$200/hr). Sometimes I wonder if paying for expensive consultants wasn't just a CYA-move by the client ("look, I hired the company to consult directly")
Then don't you mean that the original statement is false? You always change the software to fit the company, and never change the company to fit the software?
Yes, like motivational quotes, there is always a bit of untruth to a statement like that.
It's bad because if you change your company to fit the enterprise software, then you can be no better (at XYZ) than any other company using the same software. No competetive advantage is possible (at least, in that area).
If you can customize the software, you can try to fit it around your company's strong points. If you can write the software from scratch, you can tailor it for your company. That's the dream, anyway.
If you can customize the software, you can try to fit it around your company's strong points. If you can write the software from scratch, you can tailor it for your company. That's the dream, anyway.
Whilst this may be true, the problem I have with this statement, and ones like it, is that it implies that there is an unavoidable trade-off between development effort and fit with the business. I don't accept that. My previous company had an online expense system from Oracle that was truly one of the worst pieces of SW I have ever used. I find it very hard to believe that the counter-intuitive UI, the tendency for it to lose data, or the appalling up-time were the result of a unavoidable trade-off between development effort and business fit.
I think the author is dead-on right: this is about a lack scrutiny and feedback.
I think the author is dead-on right: this is about a lack scrutiny and feedback.
"...or, heck, if you’ve ever tried to apply for a job at a big company...."
At a hospital near where I live that shall remain unnamed, I found a job that seemed perfect for me on their site.
Except when I went to apply for it -- not joking -- the application was so incomprehensible and novel-long that I just gave up.
I can't imagine they got the best people with such an application process, though perhaps they got the most persistent ones, and the ones with no better prospects.
At a hospital near where I live that shall remain unnamed, I found a job that seemed perfect for me on their site.
Except when I went to apply for it -- not joking -- the application was so incomprehensible and novel-long that I just gave up.
I can't imagine they got the best people with such an application process, though perhaps they got the most persistent ones, and the ones with no better prospects.
Lots of reasons why, but mostly because the buyers aren't the users in most cases. If users got to pick what they could use in a big company it'd be a WAY different story.
Worthy link from the site's comment section:
Zawinski's Law
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. Coined by Jamie Zawinski (who called it the Law of Software Envelopment) to express his belief that all truly useful programs experience pressure to evolve into toolkits and application platforms (the mailer thing, he says, is just a side effect of that). It is commonly cited, though with widely varying degrees of accuracy.
http://catb.org/jargon/html/Z/Zawinskis-Law.html
Zawinski's Law
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. Coined by Jamie Zawinski (who called it the Law of Software Envelopment) to express his belief that all truly useful programs experience pressure to evolve into toolkits and application platforms (the mailer thing, he says, is just a side effect of that). It is commonly cited, though with widely varying degrees of accuracy.
http://catb.org/jargon/html/Z/Zawinskis-Law.html
More goodies from the comments section:
"Enterprise software" is a social, not technical, phenomenon
http://lists.canonical.org/pipermail/kragen-tol/2005-April/0...
"Enterprise software" is a social, not technical, phenomenon
http://lists.canonical.org/pipermail/kragen-tol/2005-April/0...
What a cock and bull story (sic.)
You know how Fred Brooks said to "build one to throw away"? You just can't do that with Enterprise software because the businesses that use it need it to keep living.
You know all those little things you learn as you go along, and you begin to really understand the problem, and how to solve it properly? You can't do that with Enterprise software either, because everything else relies on what you choose already; and even worse, changes in the environment are coming in all the time that you must adapt to first. That's hard enough, even with a stable (if flawed) foundation to work from.
You can iteratively adapt it, but you can't iteratively improve it.
It's a problem of legacy, of network effects, of debugged/tested/working code and of something relied on so strongly that you can't afford to mess with it.
Joel says you can't improve these things. You can - but it's a research problem. "Things You Should Never Do, Part I" (rewrite code from scratch) http://www.joelonsoftware.com/articles/fog0000000069.html
You know how Fred Brooks said to "build one to throw away"? You just can't do that with Enterprise software because the businesses that use it need it to keep living.
You know all those little things you learn as you go along, and you begin to really understand the problem, and how to solve it properly? You can't do that with Enterprise software either, because everything else relies on what you choose already; and even worse, changes in the environment are coming in all the time that you must adapt to first. That's hard enough, even with a stable (if flawed) foundation to work from.
You can iteratively adapt it, but you can't iteratively improve it.
It's a problem of legacy, of network effects, of debugged/tested/working code and of something relied on so strongly that you can't afford to mess with it.
Joel says you can't improve these things. You can - but it's a research problem. "Things You Should Never Do, Part I" (rewrite code from scratch) http://www.joelonsoftware.com/articles/fog0000000069.html
Incidentally, I often get unknown or expired link when I submit comments, which is presumably HackerNews' way of saying that I took too long considering and drafting my comment. This seems to discourage thoughtful replies.
It seems to me that intellectually stimulating discussion would be served better by a longer timeout.
(fortunately, the back-button and cut-and-paste circumvents this problem, but it gave me a start the first time).
It seems to me that intellectually stimulating discussion would be served better by a longer timeout.
(fortunately, the back-button and cut-and-paste circumvents this problem, but it gave me a start the first time).
There's no incentive for enterprise software to be sexy or provide a good user experience. Lotus Notes is the classic example: you connect to archaic server names, the idea of displaying messages as threads will never happen, menus are counter-intuitive, it's absurdly slow.. I could go on. Ok, so I get that once your organization has tied to Lotus Notes, the cost of replacing it is absurd -- especially if you build applications on the platform. What makes no sense to me is that the visual interface has remained virtually unchanged since I started using it (Jan '06), and the new Webmail pilot looks just as bad. There's a lot of things Lotus Notes can't easily improve. But there's just as many they -can- improve that they don't for some reason.
So is the platypus God's version of Enterprise Software?
A big part of it is that once you get to a system for many tens, hundreds or more people, the basic requirements are so big that there are no real choices beyond the main one or two competitors, and one will be ahead for one reason or another.
Users have no voice, but that's only part of the problem - the time it would take to evaluate New Competitor C just to cover all the unspoken requirements is prohibitive. You can be pretty confident that because they claim nice sounding features and a simple interface, that's proof that they haven't been around to gain enough of the unspoken requirements - if they had, they wouldn't have nice sounding features and a simple interface anymore. Bit of a catch 22, really.
Unspoken requirements in the Windows world are things like "... and has a web interface", "... works on a terminal server", "reports integrate into central management program X", "has an Outlook plugin", "tolerable support for user permissions", "incomprehensible massive logfile", and so on. Either things that a program which incorporates all of them will be cumbersomly big by necessity, and/or an established competitor for several years with a few versions under its belt.
Users have no voice, but that's only part of the problem - the time it would take to evaluate New Competitor C just to cover all the unspoken requirements is prohibitive. You can be pretty confident that because they claim nice sounding features and a simple interface, that's proof that they haven't been around to gain enough of the unspoken requirements - if they had, they wouldn't have nice sounding features and a simple interface anymore. Bit of a catch 22, really.
Unspoken requirements in the Windows world are things like "... and has a web interface", "... works on a terminal server", "reports integrate into central management program X", "has an Outlook plugin", "tolerable support for user permissions", "incomprehensible massive logfile", and so on. Either things that a program which incorporates all of them will be cumbersomly big by necessity, and/or an established competitor for several years with a few versions under its belt.