Slashdot Mirror
Business Software Needs A Revolution
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."
it's no accident that Sales and Marketing is S&M.
They just chose who is in the bondage.
Dacels Jewelers can't be trusted.
There are some good points made in this article. Working at a
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.
Doug Tolton
"The destruction of a value which is, will not bring value to that which isn't." -John Galt
Marketing speak does not translate to real world performance.
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...
So rise up, all ye lost ones, as one, we'll claw the clouds.
they're not working out the way the sales guys told them they would
What?!, a dishonest sales person? Never!
I have often regretted my speech, never my silence.
-Xenocrates
Film at 11.
They lie to their developers when they say 'All we need is this one feature to make customer 'X' happy'.
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.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
I'd love to see a survey of how many people use the huge number of convoluted and complex review and version features provided by Microsoft Word. The addition of these feature seems to represent the only major change from one version to the next of this microsoft suite, nowadays...
You mean the Sales and Marketing department oversold the capabilities? Say it isn't so. On a former project, we needed to emulate a remote system for some testing. We wrote some code that responded for that system, as it was expected to, so that you always got the answer you wanted from it. It was affectionately called the Marketing Server.
I've wondered for a while what the point was. For the price of some of these packages, you can hire 2 developers (or more!) for a year and get them to code an application that does EXACTLY what you want. As long as you stick with a fairly standard architecture and document it well it should be just as effective. Using components that have already been developed (such as various jakarta subprojects) can really speed projects like these and make them worthwhile. Most importantly, it is custom tailored for your business.
Where's my lobbyist? Right here.
is bloated, buggy, and too expensive
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.
One of the key problems is that software vendors think that they should continue to add more and more features. Each time a software vendor solves some little bullshit problem for one customer, they decide to throw it into the next version resulting is feature creep. This might be kind of cool for the geeks but it sucks for most users, especially the typical users of the software. As most of us know, as you increase the number of features, you increase the complexity. As you increase the complexity, you decrease the usabilty. Thus, paradoxically, as you help some people you hurt a lot of other people. Stated another way, the harder these vendors try to help users the more they hurt them. Usability just keeps dropping.
How to Download YouTube Videos
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.
> finding that they're not working out the way the sales guys told them they would.
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.
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.
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.
no need to do any research ...
A bit off topic, but related. I got tired of trying to find a really decent store suite for e-commerce. Most of the ones which did what I needed cost hundreds to thousands of dollars, and would require additional licenses as more features or bugs got fixed and made a new version release. Going from version 3 to version 4 would be a $200 upgrade, or buying the package to include coupons would be $150.
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?
Human nature is the same everywhere; the modes only are different. -- Earl of Chesterfield
Analysts estimate business-software customers spend $5 installing and fixing their software for every $1 they spend on software.
.75 FTE for a Unix Admin for on-going support. This is about 5 times the need of any of our other Unix servers, and makes me wonder how much care & feeding the system will require just because of the buggy application. From my observations, the numbers quoted in the article for fixing software don't look high at all, and may in fact be too low.
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
To be honest, at least 50-90% of the cost of big software packages goes into maintaining another company, paying that company's CEOs and sales staff, paying for first level support people to misdirect your call and other things that are, to a great degree, unrelated to the quality of the software you're getting.
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.
Hey freaks: now you're ju
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 :-(
Paul "Say no to feeping creaturism"
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.
You see, one of the major problems is the cost of software. The more it costs, the more the suits want it. It's like having that uber-car with redicules horsepower that you will never be able to use because you live in the heart Chicago.
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.
Go here for teh [sic] funny.
Marketing people overstate the usefulness of their products in order to sell them.
Wow.
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.
you should read everything on the internet as if it had "but I'm probably talking out of my ass" appended to it.
The big business app vendors have mastered the buzzwords to impress the CxO's and boardrooms into believing they solve the problems. After all, if FORTUNE 100 software company whose software is used by everyone doesn't fix the problem, who can? The evaluators are shut off because the sale is predestined by the owner.
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...
There's enough blame to go around to everyone in the enterprise software rip-off game:
* 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.
-- $G
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!
Fight Spammers!
Does anyone believe that C#/Java will improve the overall quality, standardization and total cost of ownership of enterprise software? Or is the improvement only incremental? My theory has two parts: 1. Strongly typed, managed code environments will eliminate many of the problems created under older C++/VB/COBOL programs. 2. The scope of the runtime environment, which now includes XML "web-services" and other high-level constructs will help to eliminate integration problems that called for customization in the past. I've always felt that enterprise software vendors could make their biggest improvement in sales by reducing the overall implementation costs and leaving the core features alone.
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...
Paul "Say no to feeping creaturism"
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.
It's that same question ALL OVER AGAIN.
o r comparable methods)
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.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
I've been a software Product Manager at some of the biggest software producing companies in the world since 1995. I'm the guy an awful lot of you coders seem to dislike so much. You know, the one always asking for just one more feature to be squeezed into the release, and, oh, can we get it two months early?
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.
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, Validator, JUnit, 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.
Feature-creep is often caused by "the customer is always right" syndrome. The benefits of adding the feature are considered, but not the total cost it. It is sort of like cocaine, or a greasy burger: it might not kill you today, but eventually it will, or at least make you disfunctional in the longer run. But people ignore the downsides because they grow subtley.
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.
Table-ized A.I.
Lock the sales people in a room with a computer and a development system. When they have coded all the features they sold, they can come out...
...and spend the next few months taking tech support calls.
"I'm not impatient. I just hate waiting." - My Dad
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.
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 developer time. That is by far the most expensive part in software development, and you want them churning out new features, not dealing with optimizing stuff unless it's critical.
Even Linux and KDE/Gnome is doing that. The reason is that there seems to be an neverending well of computing power to take from, and judging by the "Who needs more than X GHz posts" it has surpassed what some people need. If computing power started to flatline, I think we'd see concern for making things faster. But why bother to put in the effort for the last 10% getting 110% * 2 = 220% in 18 months when it'll go to 100% * 2 = 200% all by itself, just by new computers?
Besides, bad UI design really can't be helped in software. Creating a good UI requires understanding the program (those buttons belong together, that belongs there, this is an either/or situation and not both etc., which an IDE just won't know. And understanding human UI perception, also a hard one. A good IDE is no replacement for a good programmer, but of course it helps.
Kjella
Live today, because you never know what tomorrow brings
Now I also have no love of MSWord, but FUD must be combatted:
"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 the "actors" directory and clippy will be gone.
I don't like Word either!! But I have to use it at the office and frankly I don't think that OpenOffice is mature enough yet, so I make sure I learn ways to make Word less annoying.
for salesforce.com courtesy of BusinessWeek.
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.
Here's a revelation:
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 hard on this topic, and this is the only way I can think of to try to reverse the trend. Small, moral, computing businesses.
Time to take a business course, people! Know your enemy!
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" (which might be a fair point, especially if they picked a system that did the job).
Paul "Say no to feeping creaturism"
Exactly what Jakarta subprojects would you suggest for building an ERP system? Or CRM? Compiere? Please.
:)
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 *enterprise* choice, we're stuck with the crap from the vendors.
One IT manager told me "All ERP solutions suck. And whichever one you choose sucks worst."
[IMHO] It's an unfortunate reality within most enterprise settings that large scale software demos are *almost* impossible.
Take for example any system which requires your company to move to a new database to actually use the software. Most vendors would scoff (unfortunately) at loaning you adequate equipment to even run the database, let alone the staff to migrate even a trivial sample of your current data to their system. Additionally, real testing would require a mock production roll out and user training as well. Most IT departments can barely keep their heads above water with upgrades on production enviroment systems (patching, client upgrades, database upgrades, etc.) let alone running one production system and another full evaluation system. Not to even consider that most user populations would not support the testing phase. 'I don't have time to do all my work/data entry on both systems!'
I think the general problem is long term vision over short term vision. Companies want a faster buck and vendors promise a faster buck (for a bucket of bucks). In business utopia, software would be fully evaluated (hell it might work too) to ensure that the shoe fit. Unfortunately we find that everyone is either wearing shoes that are too small (you need an upgrade!) or shoes that are too big (it's scaleable...). Gotta love those software/show salesmen/women.
It's egregiously pathetic.
Bloated code isn't just the fault of the sales & marketing people, or the engineers (if you are looking from the POV of sales & marketing). The customers choose their products by comparing features that they will never use. Unless you have no competition, the bells & whistles are what sells, even though (or, maybe, especially because) the customers don't know how to use them, wouldn't know what to do with them if they ever did, and don't need to do it anyway.
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).
While I totally agree with your point above, it will (probably) never happen. Here's why.
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 abstract concept, it is virtually impossible to sell quality to someone who has no idea what quality even means with respect to software.
Until businesses realize this and employ the right kind of decision makers, this will not change. And for the record, there are absolutely no signs that is happening.....unless you work at NASA or some other mission critical organization where software quality is recognized. To the Fortune 500's, software quality is just another buzzword to throw on top of the pile.
note: I speak from experience - 10 painful years as an implementation senior manager
The article focuses on a move towards hosted services served over the Internet. This is good, for some things, like ecards, and bad, for most things, like business critical software. It's one thing to have hired stupidity cause a network failure which loses an hour or day of work, it's another to have external companies you can't fire or even recoup losses from cause unknown downtime due to a lost connection, bad cable, squirrel, or backhoe cutting your upstream.
/. community feel for managed services? I get shivers down my spine. What if they get hacked? what if they change their licensing/cost? you're stuck, and they have your data in their format.
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
Returned Peace Corps IT Volunteer
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
Documentation is essential for maintaining good systems. This includes documentation internal to the source code and written documentation about what the system does and why. However, The way my previous company implemented CMM was a waste of time. It literally turned a job that would have taken 32 hours (including some good documentation) into an estimate of 240 hours. My theory is that if it takes longer to document than it does to code something isn't right. After all, when something breaks it makes it quicker just to rewrite everything than to read all the documentation.
Here is how to fix the problem:
Get rid of the idiot programmers. Anyone that has worked on a development team in a corporate environment has met them. (I know, this is easier said than done.) At the top of this list are the ones that copy code from a similar function and leave in all of the code that is not relevant to the current function because they don't understand exactly what the code does.
Don't have separate New Development and Maintenance groups. Require that people that build a system maintain it for a period of time. This forces the people with the most knowledge of the system to provide support. Also, as they work maintenance they learn the coding practices that allow this and future systems to be easier to maintain.
Don't overwork the developers or set unrealistic development schedules. As was mentioned in the article: "Don't rush bad software out the door." If someone has not had enough sleep because he just pulled 5 or 6 - 12 hour days he is not going to be very good at programming. People need some mental relaxation. Also, if you force them to work horrid schedules (weekends, holidays) to keep up with an unrealistic release date they are not going to be happy campers and this will also affect the code quality.
When a user asks for some useless feature, instead of adding it explain to them why it won't do anything or how they can accomplish the same thing in the system a different way. This will either A) Keep a useless feature out of the code which will keep the complexity lower, or, B) Lead the user to better explain what he wants to you allowing you to have a greater understanding of what he wants and it gives the programmer a better insight of what needs to be done.
Last, Remember the KISS principle. Keep It Simple Stupid. A programmer's code should be clear and simple. He should realize that someone will have to maintain the code(maybe even himself) and that he should use good programming practices and documentation and not to use some obscure procedure call that no one has ever heard of in order to show off.
Looking for a job?
Want your resume written professionally?
DON'T USE TUNAREZ!!!
Iâ(TM)m currently working for a Fortune 500 company in the IT department, and the pendulum is swinging from custom development to off-the-shelf packages (including PeopleSoft and a few others that are smaller in scale). Iâ(TM)m a developer, so I have a bit of a biased opinion. That said, there are a few reasons that Iâ(TM)ve seen for the desire for IT middle-management to go for off-the-shelf tech. And, of course, the first reason is because it is seen as easier than custom, in house, dev work. Face it, if youâ(TM)re a middle manager and you have a project that is over schedule and budget, with an internal dev team the blame is with the manager in the team. With an outside vendor, you have many more excuses. Other reasons include lack of knowledge of software dev practices (which leads to the perception that software dev is just too difficult), the preference to deal with a vendor rather than manage a large number of people, and so on.
Iâ(TM)ve certainly seen internal software dev spin out of control here, but Iâ(TM)ve seen the same kind mess with the off-the-shelf software. You pay the base price, then for the consultants to come in and configure it (for weeks or months on end), then you pay for support and upgrades. And you train the users to use a product that often has a difficult to use UI. And retrain them again each upgrade cycle. And, as has been posted already, the users are sometimes forced to adapt the business process to the software, rather than the other way around.
I donâ(TM)t think that everything should always be done in-house. Itâ(TM)s not always advantageous for a company to have to create its own dev and QA team, as well as get good managers who can oversee the project cycle. Especially for software to suite the companyâ(TM)s basic needs, which may not change very quickly. There just needs to be an alternative to these massive enterprise software/consulting companies, many of which seem to center their business model on keeping consultants on the tab for as long as possible.
"The" business application is a do-it-all monster, like MS Office; and since it must not only do everything but do everything INSIDE everything (like actively linking spreadsheets inside word processing documents, and insane tasks like that), trimming it down is an enormous task.
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.
It goes back to the old adage that in theory there is no difference between theory and practice, but in practice there is.
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.
I don't want to seem mean but:
:-)
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.)
Some solutions are easier to use. For example, building a GUI from a standard set of widgets is dirt simple using Visual Studio. But good design is still hard, and good analysis is even harder. Even assuming that your app doesn't have bugs that crash it, many naive algorithms that work just fine with your sample data don't scale to huge databases or high transaction rates or huge numbers of users.
That doesn't make ease of use bad in itself. However, there is also a very real danger that bosses, customers and users will perceive the project as being done because the GUI looks complete and polished. Joel on Software has a good article on this very problem entitled "The Iceberg Secret, Revealed"
The net will not be what we demand, but what we make it. Build it well.
For years I have been wondering why business software hasn't evolved into a set of common building blocks. Business and accounting functions are so standard. Business software packages all do the same basic things: payroll, billing, accounts payable, inventory, order processing, etc. Why isn't there an ANSI standard for doing all these things? Why isn't there a universally used set of business objects by now? Back in the eighties I sort of had hopes that the ISO9000 people might push along these lines, but all they did was insist that every process be documented.
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."
Some years ago, I heard a story about a Siebel Systems account that ended up costing $100 million before it stalled because nobody had any more money to budget for training the end users after the crap was installed.
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...
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
People seem to think that bigger, faster, more configurable, more features are what quality is about.
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.
Government of the people, by corporate executives, for corporate profits.