Have Software Developers Given Up?(blog.dantup.com)
blog.dantup.com
Have Software Developers Given Up?
http://blog.dantup.com/2016/04/have-software-developers-given-up/
309 comments
We haven't given up, there is simply not enough financial incentive to make the software any better. See 'We Could Write Nearly Perfect Software but We Choose Not to' https://blog.inf.ed.ac.uk/sapm/2014/03/14/we-could-write-nea... "The simple truth is that bug–free on-time software is just more expensive than we (or our clients) are prepared to pay."
I see what you mean and am often equally frustrated, but you know what this reminds me of? The state of infrastructure in a booming underdeveloped country, which is a good thing. Let me explain it a bit further.
Have you tried hiring a programmer lately? It is very hard, there is a huge demand and most programmers I know receive several offers a month. The demand for software is CRAZY. So we all do what we can: quick and dirty when it is good enough. Just like in a country with no roads, any dirt road and crappy pavement is better than nothing if you have hundreds of trucks that need to go through RIGHT NOW.
So here it is, websites are made hastily, tech half work, but are better than nothing. How much of the things you screencaped have more than 5 years of existence? Like you said, we are software developers. We write software and we write bugs. Right now, there is far more need to implement new features than to correct bugs. Hopefully it will change at one point but right now this is the crazy race forward, and that is a good thing!
Have you tried hiring a programmer lately? It is very hard, there is a huge demand and most programmers I know receive several offers a month. The demand for software is CRAZY. So we all do what we can: quick and dirty when it is good enough. Just like in a country with no roads, any dirt road and crappy pavement is better than nothing if you have hundreds of trucks that need to go through RIGHT NOW.
So here it is, websites are made hastily, tech half work, but are better than nothing. How much of the things you screencaped have more than 5 years of existence? Like you said, we are software developers. We write software and we write bugs. Right now, there is far more need to implement new features than to correct bugs. Hopefully it will change at one point but right now this is the crazy race forward, and that is a good thing!
I remember what software, and the internet, used to be like 20 years ago. My user-experience, and expectations, has increased in almost every way imaginable during this time. From a 10,000 foot view, I'm extremely pleased with the way things have changed in the past 2 decades.
To answer your question with a question of my own: If you think that software/service X sucks, why not see this as an opportunity to do something about it? If X really does suck, and if the reason X sucks is because it's being designed/managed all wrong, you could make a ton of money for yourself by building a company around building a better X which doesn't suck. Build an alternative that prioritizes reliability over agile/fast-releases/new-feature-rollout, or whatever you think the problem is.
If you're right, if users genuinely care so much about reliability, if reliability is important enough to sacrifice feature-experimentation, time-to-market and development-costs, then you should be able to achieve great market success and win over the current unreliable dinosaurs. More generally, some other company/startup that espouses the above reliability-centered philosophy should be able to enter the market and start dominating it.
The fact that neither you, nor anyone else, has killed off the companies/services/products that you're complaining about, leads me to suspect that users in general are willing to give up some reliability, in exchange for other benefits like low price and novel features. I know I certainly do.
To answer your question with a question of my own: If you think that software/service X sucks, why not see this as an opportunity to do something about it? If X really does suck, and if the reason X sucks is because it's being designed/managed all wrong, you could make a ton of money for yourself by building a company around building a better X which doesn't suck. Build an alternative that prioritizes reliability over agile/fast-releases/new-feature-rollout, or whatever you think the problem is.
If you're right, if users genuinely care so much about reliability, if reliability is important enough to sacrifice feature-experimentation, time-to-market and development-costs, then you should be able to achieve great market success and win over the current unreliable dinosaurs. More generally, some other company/startup that espouses the above reliability-centered philosophy should be able to enter the market and start dominating it.
The fact that neither you, nor anyone else, has killed off the companies/services/products that you're complaining about, leads me to suspect that users in general are willing to give up some reliability, in exchange for other benefits like low price and novel features. I know I certainly do.
What I do in this "war" is constantly reminding and educating my coworkers that they should care more and also teaching them HOW they can do that.
I had already several very hard and harsh fights with my bosses, even with the CEO telling them "everyone is not very good at this company" because I care about quality very much and rather fight over it than sit quietly and just produce shit.
I gave "talks" about specific topics, constantly grab the opportunity when I can tell them about a new concept, Clean Code, better tools, whatever. I introduced TDD, CI, automatic deployments, will introduce CD next month over a year I have been working at my current company.
If you are one of the better developers you can and should fight against lazyness and low quality, even teach the ones who cares/know less.
Also it's very comfortable to blame your boss, but you can do very much about this. I introduced automated testing not because they asked me for it, but because I thought is important. I educated them that this way, development will take a bit longer, but will be higher quality. You can even do things which improves quality and they don't even know about. My next step is to introduce third party services (which they never used before and always went with the open source or cheap solutions) which makes our work easier, so we can focus on what's important, and make it better.
I had already several very hard and harsh fights with my bosses, even with the CEO telling them "everyone is not very good at this company" because I care about quality very much and rather fight over it than sit quietly and just produce shit.
I gave "talks" about specific topics, constantly grab the opportunity when I can tell them about a new concept, Clean Code, better tools, whatever. I introduced TDD, CI, automatic deployments, will introduce CD next month over a year I have been working at my current company.
If you are one of the better developers you can and should fight against lazyness and low quality, even teach the ones who cares/know less.
Also it's very comfortable to blame your boss, but you can do very much about this. I introduced automated testing not because they asked me for it, but because I thought is important. I educated them that this way, development will take a bit longer, but will be higher quality. You can even do things which improves quality and they don't even know about. My next step is to introduce third party services (which they never used before and always went with the open source or cheap solutions) which makes our work easier, so we can focus on what's important, and make it better.
I just spent half a week with the following... I re-joined as a contractor in a new role at (big corporation), I arrived my first day (only gone a couple weeks), was able to pick up my security badge (no problem), issued laptop, bag an accessories, no problem..
AD login was written down, missing the last character that was there before, tried as it was, finally tried with the missing character, still no go... three calls to cusomer support later, disconnect ethernet, and able to login with secure wifi.
Able to login, setup a couple things... hmmm, no access... Told my email address was now a different one, ask about original email address. No bueno... wait a day, call back (still waiting on response from original issue), decide I can't wait, needed to get in. No email access, no lync.
Finally get a call from email support the next day (weds), but it's 7:30pm and I'm out to dinner, didn't recognize the number, sent to vmail... the issue was that I had no email, the message on the voicemail said "email me", no callback number, no email address, how the hell was I supposed to email them.
Two days later, I come in, I'm able to send mail, but not receive... there were somehow two email addresses configured. After the weekend, I'm finally able to send and receive, but now have a 3rd email address, and have to manually fix my profile in a bunch of internal services that were auto-populated at first login. Not to mention a VP in another division (with the same name) getting a bunch of email meant for me, because my email was fubar'd.
It isn't just software, it's entire processes. I basically sat for a week, twiddling my thumbs (mostly), because I couldn't communicate... still waiting on access to our ticket tracking system (was told to wait until I had email and lync).
I'd cry if it weren't so funny.
AD login was written down, missing the last character that was there before, tried as it was, finally tried with the missing character, still no go... three calls to cusomer support later, disconnect ethernet, and able to login with secure wifi.
Able to login, setup a couple things... hmmm, no access... Told my email address was now a different one, ask about original email address. No bueno... wait a day, call back (still waiting on response from original issue), decide I can't wait, needed to get in. No email access, no lync.
Finally get a call from email support the next day (weds), but it's 7:30pm and I'm out to dinner, didn't recognize the number, sent to vmail... the issue was that I had no email, the message on the voicemail said "email me", no callback number, no email address, how the hell was I supposed to email them.
Two days later, I come in, I'm able to send mail, but not receive... there were somehow two email addresses configured. After the weekend, I'm finally able to send and receive, but now have a 3rd email address, and have to manually fix my profile in a bunch of internal services that were auto-populated at first login. Not to mention a VP in another division (with the same name) getting a bunch of email meant for me, because my email was fubar'd.
It isn't just software, it's entire processes. I basically sat for a week, twiddling my thumbs (mostly), because I couldn't communicate... still waiting on access to our ticket tracking system (was told to wait until I had email and lync).
I'd cry if it weren't so funny.
Coder are soldiers paid to do a job. If the army fails, blame the generals that totally do not care about quality and will prefer to pay dozens of obedient coders lower and lower that do not care than be eventually facing opposition based on concern in quality.
Most over heard arguments before standing up: hey, we don't have a choice, there are all these companies competing with us doing the same. The other arguments for not caring about quality is : not having customers because you are a startup and that well, we will all be wealthy after we will have sold our shares and you will be able to care with the next management.
Bosses get what they ask and pay for.
Most over heard arguments before standing up: hey, we don't have a choice, there are all these companies competing with us doing the same. The other arguments for not caring about quality is : not having customers because you are a startup and that well, we will all be wealthy after we will have sold our shares and you will be able to care with the next management.
Bosses get what they ask and pay for.
Oh, thats nothing. Just today Firefox managed to freeze up the entire X server with some WebGL content. Gedit become unresponsive several times, also had rendering faults (just 640kb file with autogenerated html and js).
SublimeText2 crashes daily. (it's faulty plugin)
Office outlook for Web is a general usability horror and has many features that do not work. Win10 has number of bugs that I encounter almost daily, Edge is generally very buggy.
I think generally all these problems are indicative of several factors combined. Laziness, general lack of attention to detail and pure developer incompetence, general need to push out stuff too fast (marketing decisions policies) and then finally complexities in the software systems itself. Today any given software system is enormously complicated to a degree that nobody really understands the systems completely. In fact it's a more or less a miracle that things work as much as they do considering all the billions of bits that need to be just right for me to even write this comment. That being said, I don't think there are shortcuts here. Better quality can be achieved but it requires the mindset for doing things that way. And it's going to require testing. And a lot of it, unit tests, regression tests, automated test suites.
Personally I find that when I write code I often need more unit testing code than the actual code to cover the system under test functionality properly. I'm talking about a ratio of up to 5 lines of testing code to a 1 line of real code. Sometimes I can get close to 2:1 or 3:1 if the function/class/method is not very complicated. Anyway even if you now take that conservative ratio of 2:1 and go look at any random open source project I'd be surprised if you would actually find that much testing code there. Good luck.
I think generally all these problems are indicative of several factors combined. Laziness, general lack of attention to detail and pure developer incompetence, general need to push out stuff too fast (marketing decisions policies) and then finally complexities in the software systems itself. Today any given software system is enormously complicated to a degree that nobody really understands the systems completely. In fact it's a more or less a miracle that things work as much as they do considering all the billions of bits that need to be just right for me to even write this comment. That being said, I don't think there are shortcuts here. Better quality can be achieved but it requires the mindset for doing things that way. And it's going to require testing. And a lot of it, unit tests, regression tests, automated test suites.
Personally I find that when I write code I often need more unit testing code than the actual code to cover the system under test functionality properly. I'm talking about a ratio of up to 5 lines of testing code to a 1 line of real code. Sometimes I can get close to 2:1 or 3:1 if the function/class/method is not very complicated. Anyway even if you now take that conservative ratio of 2:1 and go look at any random open source project I'd be surprised if you would actually find that much testing code there. Good luck.
I hear a lot of complaints from non-programmers about the software they use and they always try to make sure I'm not offended. I can't even begin to explain how I'm not only not offended, I hate these lazy problems even more than they do.
Some of those are clearly complicated issues but there's so many cases of just plain laziness it's infuriating. However, I don't blame the developers entirely. There's so much pressure from management, product managers, etc. and so much cost cutting it's ridiculous. It doesn't directly affect the bottom-line though so I'm not sure we can do much except expect more from ourselves and get used to it.
Some of those are clearly complicated issues but there's so many cases of just plain laziness it's infuriating. However, I don't blame the developers entirely. There's so much pressure from management, product managers, etc. and so much cost cutting it's ridiculous. It doesn't directly affect the bottom-line though so I'm not sure we can do much except expect more from ourselves and get used to it.
Ultimately it's not really about software developers, is it?
Most of these issues seem to be management decisions.
Like giving a car mechanic a few cheesegraters and a dog, sticking him in an open field in a thunderstorm, and asking him to rebuild your engine.
He could be a prodigy. But there's water in it, man. There's bloody water in it.
Half of the stuff on that page should not involve any programming at all. The nPower one, for example. Yeah, it's broken, but that's not the actual problem. The problem is that it would take about 5 years to report the issue, so no-one knows it's broken. Just give an email address or a telephone number, and actually employ customer support instead of paying yourself $50M/second. Done.
Most of these issues seem to be management decisions.
Like giving a car mechanic a few cheesegraters and a dog, sticking him in an open field in a thunderstorm, and asking him to rebuild your engine.
He could be a prodigy. But there's water in it, man. There's bloody water in it.
Half of the stuff on that page should not involve any programming at all. The nPower one, for example. Yeah, it's broken, but that's not the actual problem. The problem is that it would take about 5 years to report the issue, so no-one knows it's broken. Just give an email address or a telephone number, and actually employ customer support instead of paying yourself $50M/second. Done.
As software evolves and gets more complicated it only makes sense that bugs will become more obscure and tougher to chase down in projects that are reaching sizes we've never seen before. Most developers have a bug list longer than they can handle. It's not about 'giving up' it's about prioritizing. It's not about being lazy it's about only having so much time in a day.
What's most interesting to me is that people choose to blame developers for their observations of quality or content of software, games, etc. Completely ignoring the organizational or institutional structure involved, as if we all have complete autonomy over the products we work on.
I've seen people blame developers for, like, female characters in games being oversexed. Newsflash- that's a business, product, and design decision. People even tried to blame engineers for the VW emissions scandal! Companies nowadays set ridiculous release schedules, overwork their developers, and release crap. But sure, blame the devs, that will probably help.
The author here is a dev so there's really no excuse.
I've seen people blame developers for, like, female characters in games being oversexed. Newsflash- that's a business, product, and design decision. People even tried to blame engineers for the VW emissions scandal! Companies nowadays set ridiculous release schedules, overwork their developers, and release crap. But sure, blame the devs, that will probably help.
The author here is a dev so there's really no excuse.
I've never written unit tests in my life, and my code works most of the time. There used to be times where I'd write code for an entire week in Java without compiling (because it was taking forever) and back then we used pretty basic IDEs that didn't help as much as they to today to help you prevent stupid errors. And, usually, my code compiled just fine and worked. Today's developer is a trial-and-error one, tweaking a few lines of code, refreshing the browser, and seeing if stuff works or not. Today's developer spends disproportional amounts of time writing unit tests and, yet, producing buggy code.
Software development is still young. 30 years ago it really wasn't an industry and 50 it was pretty much an academic venture.
We have better procedures and tools. The groups not using version control, unit tests, peer reviews and other common means to increase quality will be out-competed by those who do.
Just write the best software you can, with the best group you can in the mean time and in the long run this will sort itself. Of if you think you can sort it out, try to.
I don't know what "sorted out" looks like but I would not be surprised to see apprenticeships like plumbing and HVAC or certifications like medicine and law. Sorted out could look like just about anything, perhaps we will be drenched in shitty software until unit testing is taught to second graders along-side basic arithmetic.
We have better procedures and tools. The groups not using version control, unit tests, peer reviews and other common means to increase quality will be out-competed by those who do.
Just write the best software you can, with the best group you can in the mean time and in the long run this will sort itself. Of if you think you can sort it out, try to.
I don't know what "sorted out" looks like but I would not be surprised to see apprenticeships like plumbing and HVAC or certifications like medicine and law. Sorted out could look like just about anything, perhaps we will be drenched in shitty software until unit testing is taught to second graders along-side basic arithmetic.
You can really tell when web developers don't actually use the website they're building (especially contractors). Same for applications and for overly complex software where developers only use few features themselves (hence web browser bugs).
Only very talented or disciplined people manage to write flawless code without stumbling over their own bugs first. A good, opinionated, statically typed language helps, IMHO (scripting languages are one of the reasons for crappy web pages).
Only very talented or disciplined people manage to write flawless code without stumbling over their own bugs first. A good, opinionated, statically typed language helps, IMHO (scripting languages are one of the reasons for crappy web pages).
"Write Failed: Success" is my new favorite error message.
As a software developer, there is always an infinite list of stuff to do, things to build, issues to fix, etc. Why do we spend time doing other things rather than fix these annoying quirks?
In my experience, it's usually because there was something more important to do.
I don't think it's fair to criticize these decisions unless you know what was done instead.
In my experience, it's usually because there was something more important to do.
I don't think it's fair to criticize these decisions unless you know what was done instead.
Developers want to build quality stuff that they can be proud of. Time, budgets, marketing promises, and reality have a way of interfering with that. Rare is the job where you can tell your boss "We could release this now, and I could start on the next thing, but I'm not happy with the quality and would rather rework it." and they will just say "Ok, do that. Make it good. We'll tell all of our clients that they'll just have to wait for what we promised would be ready this month. They'll just have to deal with however that impacts them and their business."
More layers = more bugs, both at the software level and the business level. And there are a lot more layers now. We're not just compiling raw ASM or C and handing it to the end-user anymore. Every couple of years we add more layers to both.
More layers = more bugs, both at the software level and the business level. And there are a lot more layers now. We're not just compiling raw ASM or C and handing it to the end-user anymore. Every couple of years we add more layers to both.
I got a bad one. I tried a few years back to log into flickr with my yahoo account. No matter what I tried, I kept getting this error:
"Hello- new account signups are temporarily unavailable from this network address space used by your Internet Service Provider.'
Flash forward 2 or 3 years. They've gotta have it fixed by now, right?
Nope.
"Hello- new account signups are temporarily unavailable from this network address space used by your Internet Service Provider.'
Flash forward 2 or 3 years. They've gotta have it fixed by now, right?
Nope.
Nah, they just get bored easily.
Writing new stuff is like building model airplanes, fun.
Bug fixing is like chores, unless someone gives you some kind of "incentive" to do them you don't.
Writing new stuff is like building model airplanes, fun.
Bug fixing is like chores, unless someone gives you some kind of "incentive" to do them you don't.
The "Pro_Hacking" story made me laugh. In that case, I think the support person is just providing the body of a response template, where "Hello Pro_Hacking," is fixed (i.e., not something the support person can easily change).
Hi! I work on an incredibly relevant project called Product Pains. https://productpains.com
Products aren't perfect. Whether they have frustrating bugs or are missing a useful feature, there's always room for improvement. The best way to help them improve is to give them feedback.
Unfortunately most companies aren't the best at taking feedback. They either don't provide a way to give feedback or don't prioritize it enough in their roadmap.
Which is why we created Product Pains, a new feedback channel for every mobile app and website. It works like so:
- People can post feedback about any product.
- People can also vote and comment on feedback.
- Teams can subscribe to feedback about their products and mark feedback as "In Progress" or "Fixed".
Voting is critical because teams get a clean, prioritized list of the issues that are most important to their users. Rather than having to manually aggregate individual app store reviews, emails, tweets, etc, they do virtually no work.
It's so satisfying to see a Product Rep mark your feedback as "fixed" and know you had an impact on their product and everyone who uses it. I'd love to see your feedback on Product Pains.
Products aren't perfect. Whether they have frustrating bugs or are missing a useful feature, there's always room for improvement. The best way to help them improve is to give them feedback.
Unfortunately most companies aren't the best at taking feedback. They either don't provide a way to give feedback or don't prioritize it enough in their roadmap.
Which is why we created Product Pains, a new feedback channel for every mobile app and website. It works like so:
- People can post feedback about any product.
- People can also vote and comment on feedback.
- Teams can subscribe to feedback about their products and mark feedback as "In Progress" or "Fixed".
Voting is critical because teams get a clean, prioritized list of the issues that are most important to their users. Rather than having to manually aggregate individual app store reviews, emails, tweets, etc, they do virtually no work.
It's so satisfying to see a Product Rep mark your feedback as "fixed" and know you had an impact on their product and everyone who uses it. I'd love to see your feedback on Product Pains.
My guess is that it's always been this bad and often worse. But maybe we are more adventurous and use a wider variety of software these days, so there are more chances to see something go wrong.
Software updates alone will expose you to more versions, so you'll have more chances to see different bugs (rather than the same ones that you learn to adjust to or ignore).
Software updates alone will expose you to more versions, so you'll have more chances to see different bugs (rather than the same ones that you learn to adjust to or ignore).
It has not been mentioned that software engineering differs from other types of engineering (like civil engineering) in that it builds abstract objects (software) that are then expected to function in a number of differing material contexts (hardware). Think about how strange that is. Engineers building a bridge for example translate their ideas into specific arrangements of carefully chosen material. The software engineer builds for a limited number of reasonable architectures and for a virtually unlimited number of hardware in various states of disrepair. It is a testament to human ingenuity that software works at all as well as it does.
For this reason, the example Shuttle's software misses the mark. Writing code for a single known device is by orders of magnitude a simpler problem than writing code for numerous permutations of hardware.
For this reason, the example Shuttle's software misses the mark. Writing code for a single known device is by orders of magnitude a simpler problem than writing code for numerous permutations of hardware.
I think the "go fast and break things" mantra is causing programmers to doubt that stable, bug-free software can be built at all.
At my last company i was an older developer in a mostly younger team.
We were working on a full rewrite of our product. Version 2 was going to address all the hastily patched together misfeatures of version 1.
Even with this admission that we had a quality problem, I could barely convince them to let me take time to design the new version.
I was supposed to be the architect in charge of designing the new system, and I was constantly being rushed. I would tell them that if we think this through, we'll have a more coherent and stable product.
It was like I was talking Swahili to them.
On the few parts of the system where I was given enough time, I got very few bug reports. As for the rest, well I did what I could. It's no use being a martyr.
At my last company i was an older developer in a mostly younger team.
We were working on a full rewrite of our product. Version 2 was going to address all the hastily patched together misfeatures of version 1.
Even with this admission that we had a quality problem, I could barely convince them to let me take time to design the new version.
I was supposed to be the architect in charge of designing the new system, and I was constantly being rushed. I would tell them that if we think this through, we'll have a more coherent and stable product.
It was like I was talking Swahili to them.
On the few parts of the system where I was given enough time, I got very few bug reports. As for the rest, well I did what I could. It's no use being a martyr.
The real question is why a missing final newline should cause an abort on an install and this was not detected on package creation
Expect this to get much worse as the profession is stripped of its remaining threads of prestige by the explosion of bootcamps and the supplanting of the terms "software developer/enginer/programmer" with "coder," one that equally well describes medical data entry clerks (no doubt the way many managers and spiteful journalists actually view us), if Google search results are an accurate representation.
Why expect professionalism from people who aren't treated like professionals and shown the respect that would normally be their due?
Why expect professionalism from people who aren't treated like professionals and shown the respect that would normally be their due?
A lot of the decisions made behind software products depend on management's decision as to what is 'good enough' and when to release a first version to iterate upon.
Every day, I encounter parts of the codebase that could be refactored or sections of a page that probably do not make sense to half of the user base, but in the eyes of management, this is not a problem as customers will learn. If I were to spend all day polishing aspects of the site, that would not be as preferable as working on a major feature release.
Every day, I encounter parts of the codebase that could be refactored or sections of a page that probably do not make sense to half of the user base, but in the eyes of management, this is not a problem as customers will learn. If I were to spend all day polishing aspects of the site, that would not be as preferable as working on a major feature release.
That guy keeps finding an awful lot of errors, is what I thought while reading this article.
It seems many users like myself don't even notice errors any more or have developed an instinct what software or services to stay away from, have low expectations from support (read a logfile?) and a general disdain for a lot of what is going on by using adblocker or avoiding switching services unless really necessary.
So yea, we've given up mostly :)
It seems many users like myself don't even notice errors any more or have developed an instinct what software or services to stay away from, have low expectations from support (read a logfile?) and a general disdain for a lot of what is going on by using adblocker or avoiding switching services unless really necessary.
So yea, we've given up mostly :)
It's always been really, really bad once you try to take the experience into your own hands. The path of least resistance with technology is to stay well behind the curve, choose the popular brand, avoid niche use cases, use the minimum amount of features, and modify nothing - in effect, to use everything as if it were an Apple device in stock configuration. However, sometimes more effort is worthwhile because the unmodded experience is so poor or ill-fitted.
Yesterday I finally got fed up with my cheap Android phone and flashed it with a modded rom. It took probably 8 hours of reading and downloading and testing and waiting to get it into a working state, because there are so many points along the chain where a little misconfiguration breaks the process, and the people making mods often have working software with poor documentation and inadequate testing.
In the end, there just is never enough time to go around to make it perfect for everyone in every use case. You have to choose carefully when you want to fight the battle - and you can expect to lose, a lot of the time.
Yesterday I finally got fed up with my cheap Android phone and flashed it with a modded rom. It took probably 8 hours of reading and downloading and testing and waiting to get it into a working state, because there are so many points along the chain where a little misconfiguration breaks the process, and the people making mods often have working software with poor documentation and inadequate testing.
In the end, there just is never enough time to go around to make it perfect for everyone in every use case. You have to choose carefully when you want to fight the battle - and you can expect to lose, a lot of the time.