Joel writes about in house software:
That’s the second reason these jobs suck: as soon as your program gets good enough, you have to stop working on it. Once the core functionality is there, the main problem is solved, there is absolutely no return-on-investment, no business reason to make the software any better. So all of these in house programs look like a dog’s breakfast: because it’s just not worth a penny to make them look nice.
which is essentially why most Enterprise software sucks.
Horrible story. And completely true, as anyone who has to use a bespoke application as part of their job can attest.
But I would make the case this is down to poor costing. Having god-awful user interfaces costs time and money in the long run: the company buying the software needs to specify a metric for “ease of use” before the software can be called “done”. Measuring that metric would be difficult – but not impossible.
The worst software I’ve seen recently:
* A Java-based system used in the local Job markets,
* The First Trust’s online banking system (again, a JSP application).
The quality of these applications is amazingly depressing. Clearly no-one considers UI design or usability testing in any way important. What a short-sighted disaster waiting to happen.
I think that’s the final nail driven into the coffin of my career at $BIG_CORP 😉
I’m not 100% sure but that Java system on the local Job Market was built in WebObjects…which goes to show…..
I agree about the First Trust but then I’ve never seen an application made by a bank that wasn’t awful.
I don’t think COSTING is the issue. IF you built a “UI Testing” module into this sort of app development it would just get cut or re-allocated. Sure, awful UI costs in the long run but banks, as an example, thrive on money now not long term savings.
None of the truly awful apps out there are used by their buyers, that’s for sure.