Business Software Needs A Revolution 399
An anonymous reader writes "According to a Businessweek Online article, today's high-end business software is bloated, buggy, and too expensive - no surprise to those of us who have paid our bills by adding pointless features to some piece of software arbitrarily priced at $100k. Evidently, firms are now re-evaluating their software purchases, and finding that they're not working out the way the sales guys told them they would."
Just goes to show... (Score:4, Funny)
They just chose who is in the bondage.
Market forces control software quality (Score:5, Insightful)
software company, there is quite frequently an incredible amount
of pressure to get new features in as quickly as possible.
However I don't think that phenomenon is ever going to go away.
To a certain extent there is market pressure to add new features
to your product, people always want the new bells and whistles.
There has been a tremendous market pressure over the last decade
to add bells and whisltes over bullet proofing your code.
Perhaps there will be some pressure now towards bullet proofing
your code, but until customers stop demanding more features and
start demanding quality code, software won't change.
There are some companies out there (M$ being the prime example)
that don't add much in the way of new functionality, but rather
repackage things, move buttons and menus around and make the new
incompatible with the old. At the same time they only fix
certain bugs, but leave others alone. Yet people buy their crap
at record rates.
I think most developers would love to see a move towards
software quality rather than software features, but until the
market dictates that as a priority it just won't happen.
Re:Market forces control software quality (Score:5, Insightful)
PHB's love to buy "all-in-one" and "easy-to-use" solutions that can be used by morons, instead of hiring people who know what they're doing to assemble a solution out of reliable, well-tested components (which often are used from that scaaary command line.) Often they're seduced by the idea that such products will keep them from having to hire those weird, long-haired, jeans-and-t-shirts people to administer everything, because companies make absurd promises about how easy the products are to use. In the end, of course, these products end up costing more, because things fall apart at the worst possible time and someone (or a bunch of someones) has to be brought in now to fix things. But the PHB's never learn.
Re:Market forces control software quality (Score:5, Insightful)
To be more precise, that's what Sales and Marketing says sells. I think if you ask most customers, they'ld prefer software that works and solves their problem. Generally, Sales blames any lost sale on the feature that the other guy has and you don't. Thats why the emphasis is on adding features over quality, its to take away the sales excuse, not to satisfy customer demand.
Re:Market forces control software quality (Score:5, Insightful)
And herein lies a significant portion of the problem. Customers frequently don't really know what they want or need. Before software gets leaner and better, there's a number of things that need to happen.
Re:Market forces control software quality (Score:3, Informative)
Re:Market forces control software quality (Score:5, Insightful)
Customers frequently don't really know what they want or need.
Customers know exactly what they want even if it may not be exactly what we think they need, and that's a big difference. Software types are far too willing to let their assumptions and preferences produce a solution that is what the customer "needs".
Corporate Complexity needs to be eliminated. Many corporations have built an incredibly complex structure over the years and are unwilling to redesign their business processes to make the best use of software products. I'm sorry, but you'll never convince me that the processes that have slowly built up (layer upon layer) over the last 100 years are anywhere close to optimal in today's market.
It is the individual business rules that make each company different, give each an identity, and give each a possible niche. Why should we have cookie-cutter companies just so we can install cookie-cutter software? I write software, and I believe it is the software that needs to adapt to individual companies, not the other way around. And any company that has been around for 100 years probably has some real business acumen, even if it doesn't fit well with your favorite COTS.
Re:Market forces control software quality (Score:4, Interesting)
You may have said "500" as hyperbole, but when we were trying to help on one Fortune 500 company (which shall remain nameless, and I can't name their product because you'll know who they are...) replace a legacy ERP system, I was shocked to find that the database record for each customer had over 300 data fields, slowly accumulated over a period of 30 years. Some of them no one knew what they were for anymore, but the majority actually had some obscure purpose in some dusty corner of their bloated bureaucracy. Each department predicted dire consequences if they lost their data fields, so the majority ended up being retained, with several hundred thousand lines of new code written on top of the modern system to effectively emulate their old one. It cost $millions to do this. This company was hurting badly because their profits were being eaten up by bureaucratic overhead as their market share migrated to the cheaper products of lean, efficient Asian companies. They're still hurting today, and I don't think they'll be Fortune 500 much longer.
Re:Market forces control software quality (Score:4, Insightful)
The ease-of-use illusion (Score:3, Insightful)
That doesn't make ease of use bad in itself. However, there is also a very real danger that bosses, custome
Re:Market forces control software quality (Score:5, Insightful)
Market forces are definately part of the big picture, but companies are self-preserving entities. The goal of any business is to make money and that does not translate into quality software. I found this interesting:
It amazes me when I work with software 'solutions' that have cost millions of dollars that have no interface in or out of them other than the specific stuff provided by the vendor. I'd kill for direct access to the underlying DB or a nice clear way of moving data in and out, or a great way to make custom GUI... but the company is more concerned with ensuring that we are locked in FOREVER than with providing the tools we could use to make their software more friendly to our over all IT enviroment.
I think we will see the service model slay many of these large monolithic enviroments, but the transition is going to be very painful... the infrastructure and data investment is going to be a large, expensive hurdle to overcome.
Re:Market forces control software quality (Score:3, Interesting)
It amazes me when I work with software 'solutions' that have cost millions of dollars that have no interface in
Re:Market forces control software quality (Score:4, Informative)
J.D. Edwards has a design that accommodates things like a custom GUI. In JDE, the business logic of the "system" is implemented in a layer of "business functions". These are API function calls that perform the usual create, update, delete operations, but at the level of business abstractions, such as documents (orders, customers, etc.) All of the necessary validation is performed in these functions. The APIs are documented and there are several thousand of them. The APIs are then exposed through multiple mechanisms to the developer (C libraries, Java objects, XML, proprietary forms/report methods, etc.) This design provides the developer with a means to wrap the full functionality of the system in a custom interface, with the same validation as the vendor provided interface.
The only problem with the JDE system is a lack of solid documentation on the interaction of all of the functions. A single business "document", such as an invoice, may involve a minimum of 6 business function calls. Exactly what calls are necessary, and in what order, is not public knowledge, as far as I know. You can discover it by examining system source code or doing debug traces, but that's a major roadblock in some cases.
Re:Market forces control software quality (Score:3, Interesting)
I have a
Re:Market forces control software quality (Score:3, Interesting)
I'm the parent post you responded to, and I want to respond: actually, yes, one of the key features of the 'service model' internet based software that I develope is the guarantee that my clients can, at any time, through several different very well document interfaces (SOAP, html tables, CVS, custom SQL read-only queries) pull their data out of my application.
I felt it was a gamble, and it has been. Very public API allow competition to easy write routines to suck your data out and steal customers. But
Re:Market forces control software quality (Score:2, Insightful)
However, I think companies will be changing their minds about this when their admins explain how much money bad code is costing them.
One problem is that it is difficult to tell before purchase which commercial software products will be more reliable. Unlike open-source software, most companies don't publicize the bugs in their software. Thus, when making
Re:Market forces control software quality (Score:3, Interesting)
The problems lie with the specialized applications. They might be built upon OSS tools (a lot of the apps I work with/on are), but the system itself is proprietary, complex (models a specific business process), has rather few users compared to other apps (like MS Word, Mozilla etc), and offer no "hobbyist value" (you won't be
Re:Market forces control software quality (Score:5, Informative)
To be fair, Microsoft do add functionality and bug fixes to new releases. Few would argue that driver handling in Win XP (to name just one thing) is not a huge improvement over the way driverws were handled in Win 98. Despite the Fisher-Price GUI (which one can change back to the old Windows look, thank God), I'd say that XP is a pretty decent OS for home use. But would people upgrade to this new OS purely to get rid of some bugs and problems?
The market is demanding new bells and whistles. How many people would purchase a new version of MS Office, if it would look exactly the same as the previous one, and didn't add any new features? I've been to Microsoft sales presentations. All the people there, like me, were there to make a decision for their company to purchase the latest & greatest to come out of Redmond. You should have heard the Ooohs and Aaahs as each new (and completely pointless) feature was presented.
In fact, I firmly believe that new features and a new look and feel go a long way toward convincing potential buyers that all your old bugs and issues have been fixed. You'd expect the opposite... new features mean new bugs, but no. If you're in the software business, you might want to try the following experiment when you roll out a new version of your product: give half your customers the new version, but with the same splash screen and GUI as the previous version, and give the other half exactly the same new version, but with a different splash screen and with a new look-and-feel. (Redesigning the button icons will be sufficient). Then ask all the users to fill in a short customer satisfaction questionnaire, asking how this new version performs compared to the old one. Does it perform better, meet their needs better, has less bugs, etc. You might be surprised by the outcome...
Re:Market forces control software quality (Score:3, Interesting)
The market is demanding new bells and whistles. How many people would purchase a new version of MS Office, if it would look exactly the same as the previous one, and didn't add any new features? I've been to Microsoft sales presentations. All the people there, like me, were there to make a decision for their company to purchase the latest & greatest to come out of Redmond. You should have heard the Ooohs and Aaahs as each new (and completely pointless) feature was presented.
Well, from your descriptio
Re:Market forces control software quality (Score:5, Insightful)
This just in- (Score:5, Insightful)
Seems to me that if I was spending 100K plus on a software package (or system) I would test it first to make sure it fit my needs, as opposed to listening to a marketing drone...
Re:This just in- (Score:5, Insightful)
It's very easy to run your demo and say - lookit the pretty colours! This is what our software does that our competitors doesn't! It's much harder to wow your audience with "This demo machine has been running for two weeks without a single crash!" The uptime statistics for these large corporate packages often end up as a dry piece of paper which ends up landing on a SysAdmin's desk and causing him to cry.
Remember that Chicago song "Give 'em the old Razzle Dazzle!"
Re:This just in- (Score:2)
Re:This just in- (Score:5, Interesting)
sPh
maybe you and i would check, but unfortunately.... (Score:5, Insightful)
I'm sure you would, and I certainly would. Unfortunately in the corporate world these decisions are too often made, for "non-technical reasons" [1] by people who lack this apparently simple insight. I've seen too many inappropriate purchases made, of over-priced, under-functional software and systems that looked like it did what the purchaser thought he wanted, but in real life failed to do what the company acutally needed. Or had prohibitive costs. Or...
And I don't believe that my experience is particularly unusual.
[1] don't ask :-(
Re:This just in- (Score:2, Informative)
Re:This just in- (Score:4, Informative)
sales people (Score:4, Funny)
What?!, a dishonest sales person? Never!
Easy to fix. (Score:3, Funny)
...and spend the next few months taking tech support calls.
Salesmen lie... (Score:3, Funny)
Salesmen Lie (Score:5, Insightful)
They lie to their customers when they say 'And this feature our developers just put in will make your life easier'.
The hell of it is that when developers put in 60-80 hour weeks coding bloat features, the salesmen are the ones who get bonuses for making a big sale.
The problem here is not so hard to see.
Re:Salesmen Lie (Score:2)
Most Customers Don't Know What They Want
Outside of vague notions about improved efficiency, push-button convenience, and some hot industry jargon, most users fail to properly and clearly define exactly what they're looking for out of a piece of software. The result is a never-ending stream of "and another thing..." requests that stray far from the initial scope of an implementation.
The problem is (and has always been) that too often, the business user
Re:Salesmen Lie (Score:5, Insightful)
You are right, that some salespersons (it's not just the male kind) lie. On the other hand, there are many salespersons who pride themselves for their integrity - and are painfully honest at all times. The problem is that buyers lie, too and developers? Let's just say that honesty is a human problem, not a "salesperson" problem.
The real problem is what your salesperson has to do to keep the lights on at your firm: he or she has to find someone who needs what you do, then create a deal that is profitable for you and is good for the customer. Now imagine what happens when the customer does not disclose information or misleads the salesperson? What about managers who insulate salespeople from developers and engineers? The hell of it really is that doing good business is hard: everyone has to do their part, sales, marketing, finance, production, accounting and operations with integrity and accuracy or there is a liar or two created and possibly a bad deal done.
So far as bonus goes, I can assure you for every 60-80 week you put in coding, there is a salesperson who puts in 80-100 hours on the road, away from family presenting your software, writing proposals and getting completely and utterly rejected by 200 people to find one that wants whatever your company makes. At the end of the day, you make the product. Your salesperson finds a buyer and pays your paycheck. The dotcom folks learned the hard way: you go out of business if you don't sell anything or if you don't have anything to sell.
$G
Useless features... (Score:4, Interesting)
not necessarily useless to everyone (Score:4, Insightful)
I suspect there is a small core of functionality that we all use in any given package. After that, different kinds of users use different sets of extra functionality. Just because most people use less than 25% of a program's functionality doesn't mean they are all using the same 25%.
You mentioned version control in Word as a useless example. I know people who need and use version control, and for whom the enhanced "differences" display is a great advantage.
One man's bload is another man's vital feature. Which makes my ID more ironic than usual, I suppose...
Sales and Marketing (Score:5, Funny)
I've always wondered (Score:5, Insightful)
Re:I've always wondered (Score:2)
Re:I've always wondered (Score:2)
Re:I've always wondered (Score:3, Interesting)
I've got this kind of situation at work. The department I work in is replacing the system I've written and am now maintaining, with a different system that's less suitable for the job and costs 4 (yes, FOUR) times my salary, per year.
Isn't bureaucracy great...
Re:I've always wondered (Score:3, Insightful)
But Mr. non-programming, Clippy using management will ooo and ah at the latest salesmen pitch/demo/crab leggs and beer, order the expensive software package because we need it and give it to younger and much more tech savy programmers to work thier magic.
The tech savy programmers were also not invited to the sales meetings (which just happened to be "off-site" and personal invite by sales
if they aren't smart enough to buy the right one.. (Score:3, Insightful)
If they aren't even smart enough to choose software that does what they need (or at least to reject stuff that doesn't) you should probably be grateful they aren't running a project to create software that does all those things they don't quite understand! Or writing the specs for such a project. Or deciding which features to drop as the deadlines whoosh by.
Besides, they'll tell you they "need it now, not in a year"
Open-source is NOT a cureall (Score:3, Interesting)
I just spent 7 months with Epicor (ERP and CRM), which is one amazingly crappy piece of software. But where's the open source choice? I mean there's not even a viable OSS replacement for Quicken let alone a ERP, CRM, or real accounting system.
If you want tons of consulting bucks, write a *good* open source ERP or CRM platform and sell the consulting/support/training. But until there's a decent *enterpri
Re:I've always wondered (Score:3, Insightful)
Because both levels
Re:I've always wondered (Score:3, Insightful)
(*) Yes, Seven Million US Dollars: that's how much Albuquerque Public Schools paid for their accounting package. You know, the one that has been featured on the front page of the local newspapers
Re:I've always wondered (Score:5, Insightful)
Enterprise products are purchased because:
1) It takes man years just to produce requirements for complex applications that developers can use.
2) It can take 2 FTEs just to do the DBA work on a relatively complex enteprise app, let alone all the developers, testers, documentation people, and trainers it takes for the rest of the app.
3) Most companies are not in the business of producing software and can't manage projects like this. They are in some other business and need to focus their energies in those directions.
4) With enterprise apps you pay for things other than the app. You pay for the time of not having to develop, of course. You also pay for something that is secure, audits its transactions, allows flexible reporting, maybe works across multiple time zones, maybe with multiple languages, maybe allows different database technology, and maybe integrates with other stuff you have. You want training. You want support. You want the ability to upgrade into new versions or onto new OS/HW platforms. And you want to yell at something when your expensive app doesn't work, as opposed to someone yelling at you for all the money they've sunk into their home-grown solution.
I think your point is valid for a lot of projects. And I think a lot of companies overspend on solutions because they don't understand their needs or overinflate their risk. But there are a lot of complicated systems that 2 people could never pull off without so much time that the technology moves before you get the app out the door.
So what's new? (Score:5, Insightful)
Software has been following this general trend for years now (except the too expensive part). I know this is like the "when I was your age I had to walk 50 miles in the snow up hill to school at 4am" kinda whining, but I'm going to do it anyway.
Fact is, other than watching video files and ripping cd's, why is it that you need an OS that requires more RAM than you had HD space years ago for. If you map computing oomph (mips, ram, hd, video speed/resolutions) and software functionality (say on the y axis), you'd end up with an incredibly dissapointingly near flat line. With as much horse power that we have today, we should be able to create nearly bug free software because of all the majorly powerful development tools that put all this power to good use. Instead, we have majorly bloated development tools (Rational Rose et al) and environments that focus on letting people make pretty but ill conceived ui's and make a half hearted stab at helping to improve code.
Bah, humbug.
Re:So what's new? (Score:3, Insightful)
I don't see a correlation between speed and stability. More processing power doesn't mean you have less bugs. The amount of time it takes to code a quality program, takes the same amount of time with more power. That is, unless you're opinion of less-buggy software is just using an obnoxious level of try-catch statem
Re:So what's new? (Score:2)
Not too far off. Just better coding techniques as well as better tools. Back in the days we'd say that checking parameters and return codes was just too expensive performance wise. Yet today we have such massive horsepower, but yet we do the same things. We sti
Re:So what's new? (Score:3, Interesting)
Offset by Moore's law (Score:3, Insightful)
Hang on, let me try to play UT2k3 and DivX on my P100, the oldest one still around. You can measure it in spf (seconds per frame). But not only that, but we are optimizing for develo
Usability and Feature Creep (Score:5, Interesting)
Re:Usability and Feature Creep (Score:4, Interesting)
It's not complexity that makes software suck.
It's the inability of a given development team to handle the complexity they created.
Complexity can be managed - if done properly. But nobody cares about doing it properly when there's a quick buck to be made.
Re:Usability and Feature Creep (Score:2)
Re:Usability and Feature Creep (Score:2)
Part of the problem that led to these areas are the bloatedness of t
Start with a market consolidation (Score:3, Insightful)
Once the market cleans out the Boom chaff, look for more interesting apps to come out of the consolidation. This is a market issue, not a technology issue.
Re:Start with a market consolidation (Score:4, Insightful)
No it won't! That's a non sequitor. Using your logic, the consolidation in the 1920s and 1930s of the 20 or so automobile manufacturors and their suppliers into 3 uber-companies (Chrysler, Ford and GM) made the quality and innovativeness of the cars go up!? By the 1950s, the Big 3 had begun their long, slow, painful ride into mediocrity.
An active free-market in fungible [reference.com] goods with lots of healthy competition is what improves things. Not an oligopoly.
This is the big reason proprietary software is so afraid of OSS. With OSS and the GPL, all software offerings become fungible. You don't like your MRP package? If it's based on an open source project, and the package is popular enough that their competitors created "conversion kits", you can just swap it out. Don't like your e-mail server? If its using a standards-based protocol, you can swap out the server or clients as you see fit.
Blaming the woes of Business Software on too much competition is not only without basis, it flies in the face of the experience of 200+ years of free market capitalism.
ok, (Score:4, Funny)
ok 2 old jokes:
Q: what's the difference between a used car salesman and a software salesman?
A: the used car salesman knows when he's lieing.
Q: how can you tell if a software salesman is telling a lie?
A: his lips are moving.
Revolution? (Score:3, Interesting)
re-evaluation doesn't mean refund. It means lets spend more money and hope it works this time! (or maybe the existing vendor has an upgrade solution! we can use our relationship to get a great discount!)
The revolution has to come from the businesses who buy the software. And the sound of that revolution would be "I know what I want, I want a,b and c". Venders would be in utter shock, many will fail because they are not used to actually making what is demanded only what they think/know it should be.
one can learn this fact from Dilbert cartoons (Score:4, Funny)
Little off topic... (Score:5, Insightful)
The free or low-cost solutions did little, were hard to use, and were buggy as well.
So people really had two options. Pay plenty for good software that they would have to continue paying if they wanted to keep up to date in modules and features, or pay little or nothing and get software they would have to invest additional money into making work how they need.
So, like those before me in the free software world, it made me start my own software suite for e-commerce, to be released free under the GNU GPL license, because I would already need it for my site, so why not give it to those already in my position.
I think this is where business software will be going. A small company or a programmer will find that there is a need for a software package or suite. There will be two options, expensive lock-in software or cheap hobbling software. They will probably decide in this economy it will be easier to either build off FSF-approved-licensed software to make it work how they need, or just build their own.
I'd love to see this option work out well. An alternative to Peachtree/QuickBooks for all platforms that is XML based. Linux-based POS software for stores. Inventory management and shipping database applications.
Why spend $100,000 on such a suite when you can just build off a free project, or start your own using the knowledge you already have with the suite you couldn't get working how you wanted, open it up and reap benefits from servicing contracts and support to other companies in similar situations.
Or am I just dreaming?
Re:Little off topic... (Score:2, Insightful)
Thats assuming your project doesn't become a deathmarch like 4 out of 5 other projects like this.
p.s. Why hire an $80,000 programmer when you can hire 3 $20,00
When will management get it? (Score:5, Insightful)
The management mindset of "do it right now", as opposed to "do it right" is costing them more in both the short- and long-term. Until prevailing attitudes are changed on the part of those making the purchasing decisions, software makers will still have little motivation to change.
My employer is looking at a $1 million+ project for HR automation. $40k of that is for the unix server, the rest for software and "services". And this was, supposedly, the best software available. The vendor also recommended a
Good news for independent developers & small c (Score:5, Interesting)
Think about it: for $100k, you can get package X, which does half of what you need it to do in some areas and twice what you want it to do in others. Or, you can hire me & my buddy Josh for a year. We'll write you a custom piece of software integrating open source tools, work right along with your employees and give you all the code and a support contract for XxX hours over the next YyY years.
If there's an OSS package that already does most of what you need, you can probably hire their developers to customize it for you quickly and at a very minimum expense. You don't even have to tell anybody about your custom code, unless you intend to release the binaries outside your company.
And of course, if you can get three companies that need a similar piece of software, you can invest in a small business that does exactly what you want and split the cost. That's how my friend's firm works...the bills are paid for by the big guys, and anything they sell on top of it is a bonus. As a result, their rates are 1/2 to 1/10th those of their pay-for-our-big-name-CEO competitors.
That's your software revolution: customization, adaptation and competent small businessmen. And it's already happening.
Word is the worst thing that has ever been written (Score:5, Funny)
It has imprecise layout options.
It second guesses your decisions.
It is ginormous for what it does.
It has encouraged use of Bold, Italics, and MS Comic Sans
It sucks CPU cycles like a 40-dollar whore.
It indexes every last damn file on your PC.
It saves information that you really don't want distributed in every file.
It has an annoying mascot.
It has been ported to mac.
It is used by mac users.
It gives you hell whenever you don't want to save as a
It is far too expensive.
It has too many features.
It encourages use of MS Comic Sans
and...
It encourages use of MS Comic Sans.
Thanks.
Re:Word is the worst thing that has ever been writ (Score:3, Informative)
"It indexes every last damn file on your PC."
So you forgot to turn off FindFast.
"It saves information that you really don't want distributed in every file."
So you forgot to install the GUID patch that causes it to not add your MAC address to all the files you save.
"It has an annoying mascot."
So you forgot to unclick the checkbox for the "office assistant" during the MSOffice installation. Even if you didn't install office, just rename
A problem (Score:4, Insightful)
You wouldn't believe the number of times I've seen MySQL passed over for Oracle when none of the Oracle features will benefit the project.
And if you wanna argue about support, I think it's a non-issue. If you need help with Oracle, do you really think you're gonna get more help calling their customer support than you would doing a little google for info on MySQL? I think not.
Another problem is with sales of software. It's like for each new version, it is number one priority to have more bullet-points on the back of the box pointing out new features. How about one bullet point that just says "faster" and another that says "more stable." That'd tickle me just right. But I don't see it happening anytime soon.
Solution? It seems like marketing needs to change more than the actual software development. If the marketing groups were able to market stability/speed instead of the beaten-horse of new features, then we'd start to see a change in software quality.
Re:A problem (Score:2)
Uh, have you not been reading Microsoft's marketing literature? Every new release of Windows (for example) has always had these bullet points as their continuing promise. It doesn't mean they're a reality, but the
Re:A problem (Score:2)
Actually most Microsoft products I have seen say faster, more stable, and more secure then the previous version. What that means to me is that they admit the prior versions are slow and buggy when they want you to pay big money to buy a new version.
Shocking revelations (Score:5, Funny)
Marketing people overstate the usefulness of their products in order to sell them.
Wow.
Simpler Business Software? (Score:5, Insightful)
It is because software is supposed to bend to the will of the user, not the other way around. And that is why software is so feature-laden, so mandatorilly configurable.
If you wrote yourself a business app without configuration, you are dictating to your customers exactly how they will do the business they intend to use your software to do. That's great if your customer either does not do business in this area yet, or if they already do business the same way you expect them to.
But guess what! 99% of the target customers out there do or will want to do business differently!
For example? Let's pick something we can all agree on: source code management. Now how are we going to do business? Every shop will have a subtly different answer.
And that's the problem. Customers frequently don't know how they do business, and forcing them to articulate their current processes leads to them facing this unpleasant truth. Sometimes they tell you the wrong thing. Sometimes they deliberately tell you the wrong thing.
Sometimes management gets wind of all these neat metrics that the new system will be able to measure, and those get tacked on to the requirements sheet.
Sometimes there comes a requirement to seamlessly interface will all these legacy systems. Oh, and seamlessly sort, classify, access, and audit all the legacy data too.
You get the point.
The comparison with the auto industry is similarly bogus. The auto industry has a sharply restricted list of top level suppliers (Ford, GM, BMW), has the infrastructure to provide all routine supplies (like computer units, replacement hoods, etc), has a universal interoperability standard (the road), and a standardized operator interface.
Until the requirements for Business Software becomes simple and universal, the software fulfilling those requirements will never be either simple or universal.
Too Expensive to Admit it Failed... (Score:5, Interesting)
I saw this happen when my company evaluated a $2 million package by Big Software Company X and went away saying no way in hell. Then it came down from above to look into it, and $4 million and 2 years later it's still not done. The problem is, any project with that much money, and the big names on it can't (by definition) fail. So more money, more time, more frustration.
Of course, it's easy for someone so close to the implementor level to see it as management's fault. They turn around and see it as the implementors' fault for not doing it properly, since it works everywhere else so well.
They overruled the mechanics and bought the Jaguar, and don't want to look foolish and admit to the neighbors it's always in the shop. Articles like this are a positive sign though...
Enterprise Software, Sales and Marketing Hype (Score:5, Insightful)
* Buyers for not even applying common sense to outrageous claims
* Software companies for overselling and underdelivering
* The press for pandering to the software companies for ad $$$ a the risk of their readers
* Consultants and IT managers for using buggy implementations as job security
Shame on all of us.
What to they expect? (Score:2)
The basic problem was, most of the people there were idiots. Can't really beat around the bush, the people were morons. Now I'm sure that at some corporations it's different, if the CIO or high-ups really know their stuff, but from what I've
Because of tolerance (Score:5, Insightful)
The Sprint PCS Vission support person told me to powercycle my phone when I was having connection problems. This was to flush the buffers and cache. They said that this is a common problem with all software and said that even Microsoft Servers have to be rebooted every few days.
If we hold companies' feet to the fire and and be demanding, they may change when we start demanding refunds for buggy software.
No bugs is good bugs!
Will .NET and Java have a positive effect? (Score:2, Interesting)
LEARN TO LOVE SOFTWARE DELIVERED AS A SERVICE. (Score:2)
Unfortunately, so much of the software must be located locally: the OS, the authentication scheme, the network administration, email, etc.
The reason, I believe, companies are taking stock is the simple fact we keep buying software to solve the problems of the previous versions of sof
If You Have To Ask How Much... it ain't worth it. (Score:4, Insightful)
There's an old saying in the automobile and housing markets - if you have to ask how much it costs, you probably can't afford it.
I think the same applies to software - if you can't find out, on the website, how much it costs - that is, if you have to deal with a salesweasel, not just to buy the damn thing, but just to find out how much it's gonna cost to buy the damn thing, you can't afford it.
Honestly, how many of you would buy a game for your PC if the price was listed as "Contact Your MegaGalacticGames Sales Rep for pricing." (Whereupon your MGGSR will promptly ask you what kind of car you drive, and charge you $49.99 plus $10/month if you drive a Ford, and $69.99 plus $12.99 a month if you drive a Boxster.) And in either case, you're going to be calling him back next week to find out how much the map editor and the multiplayer option costs. (The answer, of course, is that the add-on cost depends on whether you use a Bic pen or a Montblanc when you signed the check for the initial purchase.)
If you make purchasing decisions for your own company, don't you have an ethical obligation to handle your employer's money with the same sort of care you would your own? If you wouldn't trust a company like MGGSR with your $49.99 gaming dollar, why should you trust them with $499,999 of your boss' money?
Personally, I take the old rule one step further.
If I have to ask how much a piece of software costs (because the vendor gives me no other way to find out, short of calling his salesweasels) not only can I probably not afford it, but odds are pretty good the software isn't worth it, even if I could afford it.
Why does software sucK? (Score:5, Insightful)
Software sucks because there is no demand for quality software - hence software vendors do not need to implement internal engineering processes which could ensure that the software is good (to a degree).
The problem happens when you get into the Enterprise "space", where companies are accustomed to spending huge amounts of money for products that are engineered to be bulletproof.
Then they settle for products which were coded the same way consumer companies coded their freeware.
Here's how to solve this problem:
Company X claims they sell "unbreakable" software.
Their software breaks.
They get their asses sued off, or handed to them by their competitors. **IF** their competitors use an engineering process to write their software, and IF they can show that process, and prove it to their customers that they use it, and show, with numbers, how it helps.
In other words, act like a REAL software company, instead of just another dotcom trying to make a quick buck before another dotcom is tricked into buying them.
What do I mean by "engineering process?"
http://www.sei.cmu.edu/cmm/cmm.html
(
Yes, it costs a LOT more to do these things. But they work, and should be a great selling point for people buying software. Unfortunately, the main reason we had a "computer revolution" in the 80's and 90's is because software was so cheap to produce - because it was being written, compiled and shipped. Not engineered.
If there was a demand for quality software, then it would be worth it for a software vendor to use these processes to ensure quality. And it would be profitable, because they could charge a lot more. Some vendors DO this, and get their asses handed to them by other vendors who do not. Which brings me back to the original problem. STUPID CUSTOMERS.
So, stop whining about sucky software.
Stop spending money on software in the "Enterprise" price range, without knowing that it is, in fact, Enterprise quality.
Stop listening to Gartner Group and other ANALists. Stop reading lame trade rags. Their corruption is what allowed this market to degenerate and devolve to the state it's in today. Their job was to educate responsibly, and they failed miserably. But they did make a lot of money from SUCKERS along the way.
Never gonna happen (Score:3)
Software Engineering is very similar to other kinds of engineering (civil, mech, chem, etc) - however, since software is abstract to 95% of the people making the decisions, it's much easier to make a decision NOT to pay for that engineering. With physical engineering, its easy to point out and sell the "quality" feature. ie: if there is bad civil engineering, the bridge falls down. However, since software is an
Software Quality (Score:3, Insightful)
Documentation is essential for maintaining good
Software as a Service (Score:2)
I live in software development. I've written software packages designed to be delivered as a service. But if I owned a company, I would have serious doubts about using a service-based product for any of my core business processes.
Why? What happens to your precious historical accounti
Been there, done that (Score:5, Insightful)
There is great truth in this article, and a great lie. Software companies publish buggy, bloated product all the time, but not because it's fun and not because we marketing weenies think it's such a good idea. It's because that's what the market wants. The idea that customers are asking us to stop is a load of crap created by journalists looking to write about the latest backlash.
Sure, as the article points out, Oracle 11i was bug-ridden, but how many millions did Oracle make off it? Claiming a 11% drop in revenue in 2002 is just a tad misleading--who *didn't* see a drop in revenue in 2002? Didn't some bubble burst or something? Bottom line, customer's bought the software, bugs and all. And you can bet an awful lot of them were screaming at Oracle to get the software out as soon as possible. So where's the motivation to do it any different?
Every customer will tell you he wants just one more feature, or just one critical (to him!) bug fixed, and then he'll be happy. Bunk. Fix the bug, add the feature, and get ready for the next demand. And since what Customer A wants isn't always what Customer B wants, we get lots and lots of features, many of them aimed at a very small subset of users. Add to that all the customers screaming since the customers want it *right* *now*, and we ship software with way too many bugs, and lots of silly features. Which customer pay for.
Re:Been there, done that (Score:3, Informative)
Lets start with some figures...
In the quarter to May '00, Oracle sold $250m of new application licenses in the Americas. (A pretty solid number all round.)
Three years later it sold half that number.
SAP, PeopleSoft both did better. (And in SAP's case, they did it despite some really horrible currency disadvantages.)
In Europe, the numbers are even more frightening.
Oracle's share of the enterprise applications market on a rolling 12-month view - and I'm happy to
War story (Score:5, Interesting)
I work at a pretty large .com, one who actually survived the bust and maintains a profit, and has a pretty significant amount of traffic. We have used ATG Dynamo for our application server for several years, partially based upon the built-in ability it has to do an MVC architecture, personalization, pools, and so forth.
However, we just completed a web application that was built using many open source components, including Struts [apache.org], Validator [apache.org], JUnit [junit.org], and others. By using open source components we have completely divorced ourselves from using the proprietary technologies used by Dynamo, and have opened ourselves up to the possibility of using a different, and of course cheaper, application server. This would not have been possible were it not for stable, performant open soruce initiatives.
Not only is management happy because we have (potentially) saved a bunch of money, but the developers are happy because they are much more friendly towards open source than closed technologies; it is far easier to get an answer to a question via Google than it is to pay for and go through the hassle of using a support contract of some kind.
I do not mean to denegrate Dynamo at all, because it is actually a fairly good application server. The licensing costs, however, just cannot be justified when so much of the functionality provided by it is already available elsewhere, for free.
Self-created problem (Score:4, Insightful)
Further, a lot of the tweaking is for vanity purposes IMO. I could build a system that could generate complex business applications mostly just by filling in values in a "data dictionary" set of tables that describe fields and relationships between them, plus a few event handlers. However, the interface would be so boring and predictable that it would be ignored. It would lack a WoW factor that people seem to want. Managers like to stand out from the crowd. They *do* pick a system simply because it looks cool.
Finally, too many places fail to design their databases well. They let slop creap in over time, resulting in bad, poorly normalized tables. Don't let your schemas slide. Don't duplicate columns and data if you don't need to, and don't make a bunch of tiny one-to-zero-or-one tables.
outsourced cheap labor abroad (Score:2)
Congratulations - you've been duped by an ad (Score:3, Interesting)
Don't read into what BusinessWeek "predicts" too much. They are almost always wrong. As an example, they were cheering on Enron's business plan as being brilliant and unstoppable when they should have been questioning their numbers and trying to uncover their pyramid scheme. As I recall, BusinessWeek had pictures of the Enron execs jumping on trampolines and laughing in the article - business journalism at its finest!
I think traditional software still has some legs yet.
What about immature tech management teams (Score:2)
In such cases, the people in the trenches know what is possible, what is not, and what needs minor tweaking, and what is incompatible with the architecture. However, if the tech manager is a dipshit all the feedback goes to waste.
In such cases, it is a dishonest engineer (or h
Revolution? (Score:2)
"bloated, buggy, and too expensive"
just like most western governments.
make world a better place, don't profit maximize (Score:2, Insightful)
Why not think of how the world can be made a better place using computers. Then if you sell support for it, people will notice and appreciate that you have morals to go along with your ideas. Then good karma will eventually come your way and you'll be able to make a decent living on it.
Yes, It's a leap of faith, I know. But the geek world is quickly becoming the toothless bitch of the business world, and all this intrinsically useless bloatware is the result. I've thought long and
Where does this software come from? (Score:3, Funny)
I've seen it first-hand in the aviation industry. I worked for a small aviation company that sold fractional ownership of airplanes, as well as provided executive jet services and medical flights. Aviation-related data was all entered into an ancient DOS program that stored data in a single .dbf file on a central server. The DOS program cost $125,000 and $15,000 a year for maintenance. This was in 2000! The company that made the software was shocked that we were able to share the application on a Citrix server (and they threatened to sue).
"Web Services" (Score:3, Insightful)
I think web services will be popular in the future, and will drive down the cost of packages wares, but will not replace them entirely, just because large companies and intelligent IT departments with sufficient budgets would prefer having the software locally, I'd think (again, emphasis on sufficient budgets). YMMV, if you're part of the backbone, multiple connections, etc.
I dunno, what's the
The PC Industry has blown it. (Score:3, Interesting)
It is actually a chicken-and-egg problem to see who is at fault, the buyers or the vendors.
Let's start with the buyers, and their proxies, the press. What is the easy way to evaluate software to purchase? Surely not to take the time understand its architecture, algorithms, efficiency of code, etc. and to fully test whether it works in the environment for the intended purpose. No, it is to compare features. So, we got the "Feature List from Hell" and the trade press replete with exhaustive feature comparisons. As if they meant something.
So, as a vendor, to what are you going to build and sell? Of course, you want to be the first to be out there with just enough of each and every feature have the most filled column in the reviews (it barely matters that the features actually work). Sure, you'll also make noise about the rest, but we know it is all Marketicture. E.g., Microsoft has been talking about the benefits of code reuse since the 1980s and implying that Office was more efficient because of common elements, yet StarOffice is about the only suite that actually implements an OO component model.
The article makes an example of Oracle's bad release of 11a, because it was rushed to market. They overlook that this is repeating history -- Oracle almost went out of business in the early 90s because their software was so fundamentally rotten that they had major lawsuits from both customers and shareholders. Obviously, even the industry leaders don't learn. Or maybe they do -- Oracle did it to gain market share, and it worked; at the end of that period, the competitors with better products were fatally wounded, but Oracle "fixed it all" and came back. The lesson is obviously: "it pays screw your customers".
Then, after years of vendors rushing to market and bloating their products with useless bells and whistles that one in 10K people might ever use, and IT managers buying it all uncritically, we then get a new phenomenon.
Consolidation happens, and a few vendors gain market hegemony. Some exploit this by starting to create deliberate incompatibilities. Now, the purchasing decisions get taken out of the IT managers' hands by the business managers. Their primary concern is compatibility -- "I tried to send a critical file over to Bob Jones at our biggest customer and he couldn't open it -- I've had enough of this import/export nonsense, so, damnit, we're standardizing on Microsoft Office for everyone!". In the mid 90s, the major sales forces sold directly to top management; the goal was to go around IT, and it worked.
By not being critical and business-focused in the first place, IT management lost what little power it had. They had become plumbers. Then, they got outsourced to India.
Add to that a collection of bad or self-serving decisions on industry standards, and the mess is compounded. We now have TrueType fonts used broadly, but the more sophisticated Adobe fonts used by the serious graphics experts because John Warnock would not agree to Bill Gate's demand for zero royalties on the fonts shipped with Windows. Or, did you ever have to contend with all the incompatible International character sets and code pages on a variety of browsers and email clients? Everyone talks a good game of international standards, but when it comes right down to it, there is no one standard that is actually used everywhere -- local code is still needed for every locale. And, there are dozens of examples like this.
And, of course, this is all happening in an environment where there the vendors bear no responsibility for their product working. Marketed under "licenses" that would make a pirate blush, they can peddle crap that would generate FTC prosecution for fraud if it wasn't laughed off the shelves first. Do you know anybody that wants any kind of serious device, like a car or a plane, running a PC O
Back to basics (Score:3, Interesting)
Maybe the answer is to re-examine software inter-operation and see if these things can be moved further apart. I forget which open-source app was moving towards XMLizing all the data formats, but that's a step in the right direction. Next, in my opinion, will be XMLizing user output formats.
The end result? Application A, instead of having its code intermixed with application B, instead sends the embedded information to it, receives bitmap or vector data as an output, and places it in the user's view. Yes, it's a hell of a lot of added overhead; but the amount added would be worth it, in order to have nice, discrete, stable applications.
If only it was simple to fix. (Score:5, Insightful)
I donâ(TM)t think it is simple to fix. Business processes tend to get complicated. Companies must try to meet the needs of many different customers. The end result never looks like something that was designed by one person but rather a conglomeration of the attempts of many people to make everyone happy. You canâ(TM)t just tell your customers to deal with it this way because the programmer doesnâ(TM)t want to spoil the elegance of his system.
You also have to take into account that you rarely if ever get to start from scratch and make everything simple, homogeneous, and elegant. You always end up having to get this file from the old Unisys machine, access this database on the AS/400, ftp this file from another old system, etc. Deal with this Perl script, that COBOL code, that piece of JAVA.
These âoepackagesâ that you implement end up being about 75% code from the vendor and about 25% glue and hacks implemented on-site to meet requirements. So the complexity arises from having to meet all of these needs when a software system is implemented. Each new project adds a few more goofy requirements.
When you start integrating with legacy systems and code from all of the place it is very difficult to adequately test. If you sit down and look at everything it is impossible to develop enough test cases to cover the full range of possibilities. They are practically infinite. Every machine, OS, OS patch level, language, library, communication protocol, file format, database, etc. throws another opportunity for a failure.
You also never have a stable target. Businesses merge, spinoff, develop new products and services, move, layoff, downsize, rightsize⦠At the drop of a hat. When you think about it, we are kicking butt to have anything working.
Why isn't there a standard? (Score:4, Insightful)
Every company seems to think their situation is unique; off-the-shelf software just doesn't fit the way they do business. But with the high cost of customization and one-off coding, it would really make sense to let software standardization drive business standardization. Maybe it's the same problem that doomed the big push to imitate Japanese business techniques in America. American managers were happy to show a few videos, hand out some pamphlets and say to their employees, "Okay now, go act Japanese." The thing they were reluctant to do was give mere workers the control necessary to accomplish that.
I have a feeling that if somebody wrote a complete, concise standard for business software, managers would hand it to their in-house developers and say, "Go code this, but make sure it lets us keep doing everything the way we do it now."
My Response: Well, DUH! (Score:3, Interesting)
My immediate reaction was:
1) If Siebel is this incompetent, he should be out of business.
2) If his client was that stupid, they should be out of business.
3) Who authorized $100 million for a software project without budgeting for training end users?
4) I should go to the client and tell them, "Hey! For a fixed fee of $10 million to me personally, I'll solve ALL your software problems!"
It also reminds me of the story in (IIRC ComputerWorld years ago) that Travelers Insurance was suing the Cobol standards people for coming out with a new standard when the company had yet to finish converting from the OLD standard to the LAST standard. This was a company that had a TWO HUNDRED FIFTY MAN COMPUTER SCIENCE DEPARTMENT WITHIN their IT organization and they couldn't convert their millions and millions of lines of COBOL from one COBOL standard to another in less than something like ten years... My immediate reaction was, "Who is the moron running their IT department - and why isn't it me?"
Management morons...'nuff said...
Quality is misunderstood. (Score:3, Insightful)
It isn't, and it's a cultural problem rather than a technical one.
Fitness for purpose is what quality is about but vendors and purchasers both get this wrong. Zen And The Art Of Motorcycle Maintenance is an interesting read on the subject.
Ironically, one of the reason Unix is still around after 30 years despite everything the Digitals, IBMs and Microsofts of the world have tried is that it is a high quality system. The, do one thing well, mantra is almost the definition of quality.
Re:Better to buy or bring in house. (Score:4, Insightful)
You admit that you lack accounting knowledge, but you wanted to code an accounts payable application yourself? Using open source software won't magically give you accounting domain knowledge. At least GreatPlains offered a framework for setting up an accounting system, even if your management mishandled the implementation.
As you now hack up some PHP+mysql app, you've hit the core problem mentioned by many, many others: users don't know what they want. ("The department that need(s) automation dont know what to automate and cannot come to conclusions.") But accounts payable is a *standard business function*. It's been implemented thousands of times before by companies like yours. Your staff don't need to know what to automate; in this task, they're hamstrung by 1) being accountants, not software or process designers, and 2) being used to the manual way they do their jobs.
So call up your suppliers, your trade association, the other companies in your building, whatever...someone who's done A.P. before. Ask who they used for implementation. Then call up vendors and ask how they handle the key requirements and pitfalls that you've heard. Stand on the shoulders of giants
(Or, if you insist on coding something yourself, consider this: if you're automating a department that is 100% manual today, there is bound to be some very simple feature (in your eyes) that absolutely blows the staff away. "You mean we can list all the accounts 30 days past due in Chicago? With one click? Wow, that used to take Marge half a day to work out.")
(Oh, and your management needs to take charge and decide if they're going with an external vendor or an in-house solution. With the best will in the world, it sounds like you're torn between two completely incompatible implementations right now.)