I had one of those once so I winced when I saw it. I was printing 'Error: ' with the message that came back from the server and in one case saw 'Error: Success'.
I see similar messages fairly often. I believe "Success" is what you get when you use strerror() to translate an errno of 0 (success) on a Linux/UNIX machine with English localization. So this contradictory message is what happens when the programmer uses an errno-printing function (perror() or something custom) to indicate an error that wasn't actually due to a failure that sets errno.
I'm pretty sure that was his SSH connection dying after he killed the remote server. But yeah, it's hilariously/depressingly contradictory. Worse than useless, since you don't know if something went right, or something went wrong, or both, or neither!
Yeah, could've been something like that. It doesn't normally do that it was just a one-off, so I figured it was just something weird up (like maybe I'd already told it to reboot and it didn't seem to work, so I sent it again but it was just starting).
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.
Even if it's just plain laziness-- how do we get to the point where a developer is being just plain lazy? People naturally want to do good work and want to be proud of what they do. So if people appear like they're being lazy-- they're probably really demoralized, or overworked, and they just haven't heard a nice thing about their work in weeks. We're social animals, and engineers need appreciation too.
In a well-functioning industry, shipping broken items would just create a money-sink at the support end. One of the reasons this doesn't happen is that many software is unique (effectively, every vendor has a monopoly on their program), so software vendors can get away with ignoring most of their users. Even if there's multiple programs the user can choose from, switching costs are high (they usually require expertise).
This is not just a failure of the software industry, you see this in every field where there's hardly any feedback from end-users to the vendor.
Look at the first example. An escaping bug. When did you last see an escaping bug in a desktop app? The shift from Visual Basic/Delphi/C++ Win32 apps in the 1990's to the web introduced this category of bug that was previously rather rare.
That sort of thing isn't really caused by lazyness. It's caused by our tools creating holes for us to fall in to, and then developers falling into them.
Apparently this person was not using technology any time before the iPhone?
Quirks, useless error messages, website rendering problems... they've been around forever. Has this person even tried to install software packages on Linux 10-15+ years ago?
Have software developers given up?
I'd argue the vast majority never cared.
And really, why bother caring so much that you take to the web glorifying others glitches?
We hear about data theft stories, companies shutting down due to data loss fuckups... life goes on. It's shit that many people are burned because of these things, but really our society does not care. The loss is absorbed for the most part and we move on.
Stop being so dismayed with the world, or how other people aren't as good at things as you are. Move along.
The thesis is that because this person ran across a few glitches in a small subset of systems "programmers" have all given up. It continues to then re-count some bad interactions with customer service types and an anonymous Twitter user.
Seriously? That's it?
And this leads him to believe programmers everywhere have quit caring?
How does this even hold up? You realize it's not necessarily a programmer at many a institution prioritizing work. You realize that the power company customer service person probably will have zero clue what the issue is?
This is poorly thought out blog spam.
I expect the other 95% of the time, shit works just fine. But blog posts about everything working just fine don't generate hits.
I did use technology before the iPhone, but I don't remember being as frustrated by it as I am now.
The most frustrating thing is that we seem to be getting worse, not better. We're not learning from mistakes, we're too busy churning out the next buggy release to review the mistakes in the last one :(
When huge software companies like Google and Microsoft are churning out buggy crap, it's easy to see why others assume they can't do any better.
Maybe a recency bias. I have used computers since I was a kid, my earliest memories are Windows 95 but I am sure there was some before then too. I remember constant BSOD, constant application-crashing bugs with vague error messages, no ability to Google the solution to the problems you do have. Sometimes a game wouldn't work and there was really nothing you could do to even troubleshoot.
I doubt we're getting worse. At worst, we're staying even as complexity grows tremendously. I would guess we're probably improving slightly despite insane growth in complexity.
I would say that with great size, like Google and Microsoft, comes a greater difficulty in making bug-free products. Too small and you don't have the funding, but the sweet size is probably somewhere between a "small business" and "Google". Companies the size of Google have a lot of bureaucracy. They have a million products. They have thousands of developers. And in the end, the majority of the business doesn't even come from these glitchy products. It's understandable that noone is really up in arms over these bugs because upper management doesn't give a shit, and the developers only give a shit in so far that they aren't fired. Sometimes you'll have developers who care because of pride in their work, but they're the minority.
In the good old days, you'd just turn it off then on again.
The reason management doesn't care is that it isn't important. If a bug eventuates on a web page, the impact is minimal usually.
There are contingencies if a FAQ page is blank like in the article example. The user can visit the contacts page and email their question. Crisis averted.
Most of this web stuff is relatively trivial in terms of impact.
I used to work in ASIC development where the impact of a bug is massive. Hence the verification effort and rigor should be much higher.
When my friend was talking about buying a Prius, he saw Priuses everywhere for a few weeks. It's not that the Priuses weren't there before: it's just that he didn't notice them as much before.
Only graphic card issue if 10 years ago. not much.Currently i still confuse why apple don't follow update like linux.Just to download XCODE 5GB every update is very annoyance.
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.
gedit has to be the slowest piece of software on Linux, which is insane since it's supposed to be gnome's notepad counterpart. Starting up geany it's way faster and geany it's basically an IDE. Ridiculous.
Overhead of unit testing is why I'm not a fan of it for personal projects. Testing even the simplest 400 lines of code needed more than 1000 lines of testcode and I'm doing as little as possible.
99% is a way high over-estimate. Yes, strongly statically typed languages eliminate a LOT of potential bugs and I always try to use them. But it's not like they eliminate 99% of all bugs.
> Yes, strongly statically typed languages eliminate a LOT of potential bugs
They don't. AFAIK, lines of code is the only known metric with significant correlation with bugs so far. And if you ever wrote anything in a good dynamically typed language, like Perl, you know that its type system never causes any problems.
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.
30 years ago it was definitely an industry. The commercial games market exploded with the arrival of cheap 8-bit micros in the early 80s. Mini and mainframe application development has been around for a lot longer.
Commercial software development has been happening since the 1950s.
"Sorted out" means that software doesn't fail in stupid, avoidable ways.
The current state of the industry is shockingly bad. But users have been trained to expect broken software, developers rarely have enough of quality ethic to care about those boring bug fixes, and management just wants more money.
So here we are.
Personally I blame Microsoft for gifting the industry with a tradition of bullshit EULAs that more or less said "We can ship any old bug-ridden crap we feel like, and we're not responsible if it blows up in your face and takes your business down. Besides, if something goes wrong it's clearly your fault for being too stupid and ignorant to use the software properly. Whatever - definitely not our fault, so don't even think about suing."
After the Pavlovian conditioning and Stockholm syndrome set in, it became impossible to expect consumer pushback.
30 years ago, when I started working as a professional software developer, I encountered people in their 40's who had been professional software developers for 20 years. So no, software development is NOT young. FORTRAN was released almost 60 years ago, in 1957. Cobol was released 55 years ago in 1960. It's been half a century since thousands of people have been programming professionally.
How old is a 60 year old industry? It's the time it took to go from the first Write brothers airplane to jet airliners and rockets into orbit. It's less than the time from the discovery of DNA to full sequencing of the human genome. Between 1850 and 1910, steamships went from barely worthwhile to gigantic ocean-going liners (RMS Olympic) and battleships (HMS Dreadnought).
The software industry is not young. The third generation of developers are entering the workforce. Some of them have grandparents who were professional software developers. The industry has completed (or failed at) 100's of thousands (if not millions) of major projects.
IMO, far far too many people working in the industry simply refuse to learn from the past. But that's a rant for another 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.
My post was actually aimed at the industry more than specifically developers. The headline was a bit bad (it was written before the post) but I didn't expect to get 30k visitors overnight so I probably didn't proof-read/tweak as much as I could've done :D
nice article. I use OVO Energy they have a nice user interface for managing gas and electric. Although I did just check it and it's down for maintenance.
I did wonder why he would voluntarily move TO Npower. Even if you're saving money, it's not worth it. A single 'live chat' with them was more than enough to convince me of that.
I haven't had a gas bill from them in 5 months because their system wouldn't let me put in my gas readings. I had to go through a painful 40 day complaints process to get anyone to put them on the account. Never heard back from anyone. Eventually someone on their twitter feed was able to fix it over the course of a day, but of course it will be 3 months before their system generates a bill from the new figures. I've had plenty of ASP.NET "error occurred in the application" pages too so clearly they aren't building their site in Release mode. Overall, best described as a clusterfuck.
Yeah; lots of people told me I shouldn't go there. Iwas lucky it didn't work out and I had to move away, but SWALEC so far hasn't been much better. We still can't login!
nice a downvote for recommending a utility company with a decent control panel. real smart. Reminds me of the arrogance I faced when trying to get my first programming jobs.
Ahhh... spoken like a true developer. Blame the QA department.
The problem with having a QA department is by definition, if they are a "department", they are not part of the development team. The only way testing is ever taken seriously is if the top architect spends his coding time writing test cases, instead implementing features, after all the architecture documents are put under ECO control. And let's hope the same architect believes in closed-loop validation (that is, instrument and measure your test coverage) instead of open-loop validation (write tests without actually measuring what code gets tested by it.)
Software is always bad at the top of the market, when hype and get-it-out wins over quality and measured improvements. Javascript is also always hugely popular at the top of the market. (2000-DHTML, 2008-Web2.0, Now-Node/Ang/React.)
Eventually, the Developer Gods of the Copybook Headings with terror and slaughter return.
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.
> 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.
"But I was just following orders" isn't an acceptable excuse in any situation. You are inextricably tied to a set of moral obligations by your decision to build things that affect other human beings, and you cannot shirk them or push them upward. They are yours, they remain yours, and attempts to rationalize the abrogation thereof are at best gross.
Own your shit. If you cannot do good and do well, then quit. (I have done this; it is not that hard.)
Then own it, and fix it, and be with a clear conscience. I couldn't, at that particular job, and I could do good elsewhere. So I made the decision to do that.
"We're just coders, it's not our fault" is not an excuse. Either own your shit (and, implicitly, fix it) or refuse to participate. There is no middle ground.
Trying to change job here to avoid taking part in this buffoonery.
I can't. Nowadays so much jobs are regulated per diploma/certifications that it is hard beginning again and regain while "older" the momentum for credibility.
The funny part I see breadmakers, cooks, construction is also suffering the same problem. I am currently in France, restaurants for average people are so bad, they do stuff that intoxicate people. I can do bread, cooking, fixing bikes and I do better than "pro" nowadays" without a diploma in their field.
Something systemic seems to be going on. Like people are just taught to execute and required to obey, and bosses don't know the craft of the people they should lead.
Basically being a boss boils down to the capital you can have, and competition seems rigged in favour of people being born wealthy.
I don't think that birth merit outweight a sane competition.
I find the Figaro monolog that inspired French and US revolution about the old monarchic regimes to be very actual.
Weirdly enough author's right says it should be in public domain, but it is impossible to find a link to this essay that is very actual.
The systemic thing is called "professional managers". In the past, only people "from the trenches" were promoted to manage and lead others. Nowadays, we have managers who studied nothing but management. And it shows.
Karl Marx analysis was that through education you can capture the praxis (savoir faire) and transform it into both stealing it from the craftsman and also making expert in doxein (savoir faire) that knows nothing (Donning Kruger effect).
I think that it has always fueled my intuition that a profession should be defined by the craftsmanship and not he education.
And I found asking questions a better way to make people aware.
People will first deny we all have shit in the eyes. And say you are exaggerating.
But, ask them about their experience in IT, but also every days inconvenience because of loss of quality in product. There is a pattern. People feels like industry don't care anymore about consumers. And let them tell their part.
It makes people realize they miss the simple boring life that works.
And maybe they saw something you don't see and they can help you and you can help them.
My first way to improve this is to help people be better consumer by sharing simple way to spend less and get better products by focusing on rational choices. I also sometimes learn. I also sometime am bullshited.
> "But I was just following orders" isn't an acceptable excuse in any situation.
On the contrary, it's an acceptable excuse in lots of situations. The finding at Nuremberg was that there is a line beyond which it stops being acceptable, and murder is on the far side of that line. But most things in commerce are on the near side of it.
In other words, a moral obligation to give up your job rather than tolerate sloppiness, applies when you're dealing with safety-critical stuff such that sloppiness could get someone killed. It doesn't apply when the sloppiness will cause minor inconvenience.
> 11) Actions at the sharp end resolve all ambiguity.
> Organizations are ambiguous, often intentionally, about the relationship between
> production targets, efficient use of resources, economy and costs of operations, and
> acceptable risks of low and high consequence accidents. All ambiguity is resolved by
> actions of practitioners at the sharp end of the system. After an accident, practitioner
> actions may be regarded as ‘errors’ or ‘violations’ but these evaluations are heavily
> biased by hindsight and ignore the other driving forces, especially production pressure.
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.
I disagree. While there are management/process/whatever issues, there's also a lot that could be improved by the devs.
For example, take the podomatic example - that's just a sloppy function written by a dev. The NPower thing is just sloppy setup of the website and bad links in email templates. The MS thing, well why did the devs add jQuery to a site that is so incredibly static?
Devs make a lot of decisions that influence the quality of software and I think we need to start taking more responsibility for that.
That and allowing anyone access to your computer's graphical interface as if they were at your computer, even yourself over a web connection, is a bad idea.
I think the 8 character limitation is helpful. Because if you need to protect yourself against it, you can ask "but wtf do I really want to do? Probably not a VNC server..."
I reported a software bug in a commercial package (Allegorithmic Substance Designe) a few months ago. The support guy told me that, to help me, he wanted me to install a VNC server, send him my id and password, and let him have access to my machine so he could debug the problem.
When I balked he acted all offended and told me they work with some of the biggest companies in the industry, they see lots of stuff on customer's machines, and are totally trustworthy.
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.
That's true; and the post wasn't aimed specifically at devs, but more of the software dev industry as a whole (I know the title is pretty badly worded).
I think companies should start caring more about their quality and users should stop giving money to those that don't. Some of these silly bugs are pretty ridiculous and should never have happened.
I think it's entirely fair if there is no proper feedback method indicated on the erroneous page. How else am I going to do anything about it? See also the "dear-github" letter.
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.
Start with very small, modular code... avoid spaghetti coupling (that is removed by multiple laters)... organize structure by feature, not type/class, and accept that all features don't look the same... Some features may only be data structures, service libraries and/or ui.
Separate event chains from your UI so much as practical, and avoid classes that look like Car, Wheel, etc that are too smart for their own good.
Actual code reviews, experienced architect(s) that actually understand the whole project, and paired development. Not being afraid to refactor... creating componentized pieces that can live in separate codebases if possible.
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.
Yeah, that's basically it: software sucks for economic reasons. It's insanely expensive to create good software, and even if you spend a lot of money, you're not guaranteed to get it.
I think there are some tragedy of the commons situations though, where everybody is relying on extremely underfunded common infrastructure. It was only after a bunch of expensive security holes that the users of this software started to pay more attention:
Blaming users is part of the problem. Yes, they vote with their wallet, but their vote is usually made in ignorance and is often mislead by companies that are so used to dissembling and exaggerating they call such antisocial behavior "best practice".
That said, it is true that this is largely a problem with the economic incentives. Capitalism optimizes for businesses that are financially efficient, so the business that sells the lowest quality product they can get away with is "successful". This becomes even worse in software, where quality is harder to see directly. Even the people that write software can have a hard time evaluating "quality".
The solution for this situation is simple, but it's basically taboo to talk about it: liability. If you sell software, you need to be liable for any damage it causes when "used normally". For a decent sketch of how this might look, see Dan Geer's explanation[1]. There may be other ways to implement liability. I suggest that the software industry should find a way to implement this as soon as possible, if they want any say in what "liability" means.
Yes, this will raise development costs; spending more for better development practices was the goal.
While custom software typically comes with guarantees (if it doesn't work, the provider is generally liable to fix it for free. If it's not "finished" on time, it may even pay damages —determined by contract); shrink-wrap software (free or proprietary) generally comes with a nice piece of text saying that if it shreds your hard drive, or lag so much it makes you mad enough to throw yourself out the window, it's not their fault.
Liability towards one customer is also not the same as liability towards thousands, or even millions of users.
"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."
I have to agree wholeheartedly with this statement. I'm relying on software to basically help me run my life. Thanks to software, I can accomplish more than I would otherwise. (OTOH, I also take on more, which is a whole other post on making ourselves crazy by trying to do too much.)
Still, there is room for improvement. The problem is that no single point of failure exists. It's a layered problem involving economic incentive, unskilled people jumping into development to shore up the shortage of labor, an immature consumer base, a dizzying array of tools, methodologies, and standards for developing software, etc.
At present, I don't see any way out of the dilemma.
> If you think that software/service X sucks, why not see this as an opportunity to do something about it?
I try very much. I try to report any issues I find like this (I spoke to 5 different people at NPower trying to explain their issue, and nobody cared or understood).
I have a job/family/life. There's only so much time I'm prepared to put into trying to make silly things like these better, and I'm certainly doing far more than most! :)
If you think that software/service X sucks, why not see this as an opportunity to do something about it?
A lot of the examples in the blog post are about sucky corporate websites. You aren't going to set up a competitor to IKEA, let alone an electricity company, because the quality of their IT is poor. That argument works in only one case:
• The product is pure software
• It doesn't have any barriers to entry
• The quality of the incumbent is so dire, and the chances of improvement so low, that it makes sense to replicate their entire product investment just to "do it right this time"
The frustration was that support kept greeting with the random name despite being asked not to. I'm sure that's just a "Hello $NAME" template, but it's still lazy.
But yeah, they're included here because of the repeated greetings like that. I suspect it was a template, though it only started after I told them that wasn't my name; first few emails (not shown) were "Hi Danny"!
My concern was that the name entered was "Pro_Hacking". I was worried that maybe someone had found an exploited in their system and may have been able to activate the account anyway.
I was asking them to confirm it had not been activated, but the chat didn't go so well!
I was refactoring some legacy academic code recently. It came with a GUI which, if the user did something wrong, fail with the message "Error N" (N being some number) without any further information or logging. The only way to figure out what happened was to grep the source code to see precisely what triggered the alert box.
There's also the bizarre policy university has about passwords. Your password is reset every six months (fine), it can't be similar to your old one (fine) and it's truncated to 8 characters (what?).
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."
Is there some reason to believe that with enough money software could be bug-free? Developers are often guilty of just refactoring for no particularly good reason other than their personal sense of aesthetic, which can lead to endless (and destructive) refactoring. More money also makes people design lazy, so that instead of finding clever ways to reduce effort and improve uniformity, you just have everyone make their own forms.
In case of NASA, it's not only because of money though. It's because of a very rigorous process of designing and testing their software, sufficient time to follow this process, as well as writing a single product for a single customer. Of course money enables such process, but alone it is not sufficient.
It probably could and in testing it could, they just decided not to find out whether it would really work properly when seven people's lives depended on it working. If you can practically avoid an edge-case you haven't ever relied on in decades before when people's lives depend on it, not risking it doesn't seem that crazy.
Actually, they could but given the fact that the shuttle is not much different to strapping equipment and people to a gigantic bomb they seem to have decided that even though exhaustive testing found no issues a small change in the schedule was less risky.
It isn't a practical solution for the majority of software out there. I also think that while their method works, it is pretty archaic. Looking to the future I hope we can find a way to achieve the level of results they do, without the ridiculous effort and cost.
> Looking to the future I hope we can find a way to achieve the level of results they do, without the ridiculous effort and cost.
That is unlikely. For computational complexity theory reasons, writing correct software is extremely computationally expensive (regardless of whether or not the language is Turing complete). In fact, it is "the hardest problem in computer science", in the sense that any problem with bounded complexity can be efficiently reduced to software verification. Even verifying finite-state-machines (the simplest computational model) is PSPACE-hard.
What we can do is find many ad hoc ways, each helping to some extent with some kinds of correctness properties.
Most software problems I encounter in the real world ARE of bounded complexity, and they can be reduced to software verification. But this is still a very tedious process and there are significant gains to be had by making this more accessible without having to solve the hardest problem in computer science.
Certainly. It's just that there cannot be one (or a few) advances that would make writing correct programs generally easy. We can concentrate on domains (in the safety-critical embedded world this is almost a solved problem for some kinds of applications thanks to the invention of synchronous languages in the '80s, that make formal verification relatively efficient). We can also address some "internal" properties, like memory safety and transactions, that on the whole might make writing correct programs easier (though not provably correct).
I work on safety critical systems. At least 80% of the work for building such a system is not critical for the actual quality of the product, but is necessary to satisfy compliance rules. Documentation of the development process is really extensive.
Enough money and the goal of making software bug free can make it bug free.
But enough money and the goal of making it infinitely flexible, having all the possible features, or the most perfect UX that a team can not decide on what it is will only make the software more bloated than it's reasonable, and fill it with bugs.
I think "bug-free" software is a distraction. It's fine to make the occasional mistake. The real problem here is that nobody seems to take these mistakes seriously. Everyone seems to expect software to be occasionally broken, including the people writing it.
Aren't your second and last sentences in conflict? How could we not expect software to be "occasionally" broken, if it's "fine" to make the "occasional" mistake?
Of course, making mistakes is only human, but mistakes should never get past the build process (compilation, automated testing). Any mistake that does reflects an error in your design (not making your code amenable to verification) and/or your process (not capturing requirements in tests).
Yeah, using "occasionally" in both places drew a parallel that I didn't intend. We can expect people to make mistakes without accepting broken software. As you say, there are processes that can reduce the impact of mistakes on the final product. I think a culture of taking issues seriously is also important. Small mistakes are easy to make, but they're easy to fix if the organization has a good way for them to be reported and allows people to spend time fixing them.
> Developers are often guilty of just refactoring for no particularly good reason other than their personal sense of aesthetic, which can lead to endless (and destructive) refactoring.
There are lots of good reasons to refactor - if indeed frivolous refactoring is more prevalent I would think this kind of opinion should be supported by a source/reference.
> that with enough money software could be bug-free?
According to empirical studies, practicing TDD leads to a 90% (yes, that number is correct) post-ship bug reduction at an upfront cost of 15-35% more development time.
Which seems like a pretty good tradeoff, to me. (And I've experienced it firsthand.)
Some of the above is empirical (read: scientific, no-bullshit) data.
My opinion on it has grown to the point that I think TDD should literally be inseparable from programming, and the two together should simply be called, "programming." Lacking any unit tests whatsoever (TDD or otherwise) should be called, "taking stupid, extremely hazardous risks to save a little time, like reading your phone while driving"
I've not found a programming task in at least 5 years that wasn't waaaay better-written when done via TDD. Some things, like IO, can be a challenge to unit-test, but that's why we have great ideas to solve that like Gary Bernhardt's awesome "Boundaries" talk https://www.youtube.com/watch?v=yTkzNHF6rMs
> Is there some reason to believe that with enough money software could be bug-free?
Yes. It's pretty easy to write provably correct software, just expensive.
> Developers are often guilty of just refactoring for no particularly good reason other than their personal sense of aesthetic, which can lead to endless (and destructive) refactoring
Not my experience, but even if so, if you require your software to be proven correct then it won't matter - any refactor that breaks it simply won't be accepted.
> More money also makes people design lazy, so that instead of finding clever ways to reduce effort and improve uniformity, you just have everyone make their own forms.
Shrug. We have provably validated diodes AIUI. If you can get provably correct basic components you can build up complex components using the same techniques as in software.
Good point. But choose the wrong hardware and you can never have provably correct software. E.g., the Intel x86 ISA makes all x86 processors impossible to prove correct. (there are 2^120 possible instruction encodings - the universe will die heat death before anyone could verify all of them in an implementation http://www.emulators.com/docs/nx06_rmw.htm )
The problem lies with the amount of financial resources available to software users. Users can afford buggy software. They can't afford non-buggy software except for a very small number of uses.
The high cost of bug-free FOSS is the time the developers can volunteer to develop it, which takes away from time spent on additional features. The developer's time is a limited resource that has to be spent where it is best utilized, and making the software bug-free might not be the right place.
Yes, good point. In both cases the limit is time. How do you think one should decide on what qualifies as best utilized? What would count as additional features? Does documentation count as a feature in software?
Often the buggy software turns out more expensive. It can be a false economy not putting that extra time in to ship stable software.
If you ship something that loses data and you have to start restoring backups and patching data, it probably would've been cheaper to do a little extra testing.
Like everything; it's a tradeoff. I think we're universally bad at playing the game!
The sad part is the authors example is easily avoidable and does not cost more to avoid. The fact that a developer was making manual changes in a production environment points to bad process and lack of knowledge of a better way. In every environment I have been in since 2000 production is locked down it is modified by scripts that are tested in several environments before the script even gets to production. With virtualization and continuous integration the cost of doing it correctly is marginal and the savings in avoiding crisis and recovery is substantial. There in lies the core issue, it seems more and more developers are loosing focus of the process of managing change across environments and are resorting to manual processes that are not reproducibly. Simple point is, if you are making manual changes in any environment other than a local dev environment you are doing it wrong.
Source control should be your single source of change, and check-ins should cause a chain of events via continuous integration and issue tracking. A checkin should cause a build to kick off if it is successful it should deploy to an integration environment where tests should smoke test it. If it smoke tests it continuous integration should up merge to a test branch, deploy to test and then update the ticket system to update all associated tickets to ready for test. When the tester verify the tickets automation should again up merge to release and automation should release to production on a release schedule. This is a solved problem.
> The sad part is the authors example is easily avoidable and does not cost more to avoid.
Except for all the costs of maintenance. It always costs more, generally in the way of time.
> With virtualization and continuous integration the cost of doing it correctly is marginal
Until you have to debug while the integration fails.
> This is a solved problem.
Even with unlimited funds, you get a cost of time and communication. There are tickets and tickets and a queue and a release schedule. The optimal path is not as simplistic as you would fantasize.
> The fact that a developer was making manual changes in a production environment points to bad process and lack of knowledge of a better way.
I'm guessing this is relating to my SQL mishap in the opening lines? You're making assumptions that I was doing something manually in production here, and not that I was executing a script that was buggy or against the wrong machine.
Sure, we could build safeguards against this, but it wasn't something we really considered would happen. Needless to say, we've learned from that one!
Great link and article. I've always thought the NASA story is truly fascinating. Knowing that your bug could kill the person sitting across the conference table certainly changes the attitude towards being careful with software :-)
As others have said, software is a young field, and in many ways we're still pushing and exploring the boundaries of what's possible with software. All of us are still very much "early adopters" in this nascent technology experiment / revolution. The nature of demand and untapped potential for software systems creates a financial incentive for high-stakes rapid experimentation at the expense of sloppiness (in attitude and in software quality) we've seen for as long as there's been software.
I do think investing a little bit more time up front and using TDD combined with good leadership / experience is ultimately healthy for your product and team, if you can manage it. However, we shouldn't forget that being "cowboys" got us to where we are today, and continue to break open exciting new opportunities for software.
This is misleading. Most of us couldn't possibly write significantly better software, even without time and money constraints. Money can buy existing talent, but it can't create talent where there is none.
Nonsense. We're in the software industry. We can use tools, and if the tools aren't good enough we can make our own. Writing correct software isn't a matter of talent, it's a matter of process.
Writing correct software isn't just a matter of having the right tools and processes, even if those can help. It's primarily a know-how issue. No amount of process can fix using the wrong algorithms or coming up with the wrong designs.
Suboptimal algorithms may lead to poor performance but you can enforce correctness. If you let the requirements drive the design rather than trying to design up-front (i.e. good process) you end up with good design. Asking the right questions to gather the correct requirements is arguably in-score or not, but again it's primarily a process issue.
I meant more that you need to let the things you encounter during implementation drive the design. This is particularly relevant when requirements change (as they often do), but even if you can nail down the spec perfectly up-front, trying to design at that stage is still a mistake.
You can't always enforce correctness. Consider the case of a typical web dev shop that hires a developer who thinks escaping is a good solution to SQL injection. It might get snuck past code review if you're unlucky.
There are static analysis tools that can identify such problems ... sometimes ... maybe ... depending on the language and frameworks in use. But to deploy such tools you have to know about them to begin with. And most devs can't simply produce such a tool if there isn't one on the market because that's not what they're being paid to do.
Unfortunately, knowhow can't be automated away entirely just yet.
> Consider the case of a typical web dev shop that hires a developer who thinks escaping is a good solution to SQL injection. It might get snuck past code review if you're unlucky.
> There are static analysis tools that can identify such problems ... sometimes ... maybe ... depending on the language and frameworks in use.
Analysis tools are the wrong approach - that code should be simply impossible if you're typing things correctly, and inadequately typed code should be very obvious in code review.
> And most devs can't simply produce such a tool if there isn't one on the market because that's not what they're being paid to do.
Most devs could write such a thing if the company told them to. The reason "that's not what they're being paid to do" comes down to process.
> Most devs could write such a thing if the company told them to. The reason "that's not what they're being paid to do" comes down to process.
Most organizations barely have enough of a budget to implement the applications they actually need using already existing infrastructure (frameworks, tools, etc.). Asking these organizations to roll their own infrastructure is like asking ordinary people to run their own water or power utility.
Economics is only a part of it. Often, poorly built software increases costs for the company that built the software, like when customers call the helpline to get an agent to do what they could have done on the website. Or, when I call the helpline and the agent asks me to call again because their software isn't working today.
As another example, when I was logged in to my mutual fund web site, I found a button that says Get Statement. Since I wanted to download one, I clicked it, and it said, "Your statement will arrive in the post soon." They sent a paper statement without confirming me what I wanted. When it arrived, I threw it away, of course.
In many cases, poorly built software increases costs for the company as well, so financial incentives are only part of the story. Incompetence is another part, maybe a bigger one.
Considering the upfront cost has just as much to do with economics as considering the overall cost of high quality software. Economics is a description of human behaviour and all the irrationality and incompetence that comprises it so decisions of short-term gain vs long-term gain are very much included in the study of software from an economic point of view.
Dropbox has same sign up non-validation mentioned in the article. I mentioned it to them when I got a phantom sign-up notice. Reset password and found an account with my email and uploaded content! You can fully use DB w/o validating your email. Hello anonymous dead-drops!
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.
317 comments
[ 4.9 ms ] story [ 302 ms ] thread[1] http://hallofshame.gp.co.at/stupid.htm
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.
I think in general though, we would be better moving slightly towards the "spend a little bit longer" end of the spectrum.
This is not just a failure of the software industry, you see this in every field where there's hardly any feedback from end-users to the vendor.
Look at the first example. An escaping bug. When did you last see an escaping bug in a desktop app? The shift from Visual Basic/Delphi/C++ Win32 apps in the 1990's to the web introduced this category of bug that was previously rather rare.
That sort of thing isn't really caused by lazyness. It's caused by our tools creating holes for us to fall in to, and then developers falling into them.
Quirks, useless error messages, website rendering problems... they've been around forever. Has this person even tried to install software packages on Linux 10-15+ years ago?
Have software developers given up?
I'd argue the vast majority never cared.
And really, why bother caring so much that you take to the web glorifying others glitches?
We hear about data theft stories, companies shutting down due to data loss fuckups... life goes on. It's shit that many people are burned because of these things, but really our society does not care. The loss is absorbed for the most part and we move on.
Stop being so dismayed with the world, or how other people aren't as good at things as you are. Move along.
You know what at least one problem is, I bet you have ideas about how to fix it too.
Seriously? That's it?
And this leads him to believe programmers everywhere have quit caring?
How does this even hold up? You realize it's not necessarily a programmer at many a institution prioritizing work. You realize that the power company customer service person probably will have zero clue what the issue is?
This is poorly thought out blog spam.
I expect the other 95% of the time, shit works just fine. But blog posts about everything working just fine don't generate hits.
The most frustrating thing is that we seem to be getting worse, not better. We're not learning from mistakes, we're too busy churning out the next buggy release to review the mistakes in the last one :(
When huge software companies like Google and Microsoft are churning out buggy crap, it's easy to see why others assume they can't do any better.
I doubt we're getting worse. At worst, we're staying even as complexity grows tremendously. I would guess we're probably improving slightly despite insane growth in complexity.
I would say that with great size, like Google and Microsoft, comes a greater difficulty in making bug-free products. Too small and you don't have the funding, but the sweet size is probably somewhere between a "small business" and "Google". Companies the size of Google have a lot of bureaucracy. They have a million products. They have thousands of developers. And in the end, the majority of the business doesn't even come from these glitchy products. It's understandable that noone is really up in arms over these bugs because upper management doesn't give a shit, and the developers only give a shit in so far that they aren't fired. Sometimes you'll have developers who care because of pride in their work, but they're the minority.
The reason management doesn't care is that it isn't important. If a bug eventuates on a web page, the impact is minimal usually.
There are contingencies if a FAQ page is blank like in the article example. The user can visit the contacts page and email their question. Crisis averted.
Most of this web stuff is relatively trivial in terms of impact.
I used to work in ASIC development where the impact of a bug is massive. Hence the verification effort and rigor should be much higher.
When my friend was talking about buying a Prius, he saw Priuses everywhere for a few weeks. It's not that the Priuses weren't there before: it's just that he didn't notice them as much before.
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.
That developers insist on using unsafe languages like Javascript speaks volumes.
They don't. AFAIK, lines of code is the only known metric with significant correlation with bugs so far. And if you ever wrote anything in a good dynamically typed language, like Perl, you know that its type system never causes any problems.
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.
Pretty much that. We are still at paleolithic levels, even if progress has been fast.
30 years ago it was definitely an industry. The commercial games market exploded with the arrival of cheap 8-bit micros in the early 80s. Mini and mainframe application development has been around for a lot longer.
Commercial software development has been happening since the 1950s.
https://en.wikipedia.org/wiki/LEO_(computer)
"Sorted out" means that software doesn't fail in stupid, avoidable ways.
The current state of the industry is shockingly bad. But users have been trained to expect broken software, developers rarely have enough of quality ethic to care about those boring bug fixes, and management just wants more money.
So here we are.
Personally I blame Microsoft for gifting the industry with a tradition of bullshit EULAs that more or less said "We can ship any old bug-ridden crap we feel like, and we're not responsible if it blows up in your face and takes your business down. Besides, if something goes wrong it's clearly your fault for being too stupid and ignorant to use the software properly. Whatever - definitely not our fault, so don't even think about suing."
After the Pavlovian conditioning and Stockholm syndrome set in, it became impossible to expect consumer pushback.
How old is a 60 year old industry? It's the time it took to go from the first Write brothers airplane to jet airliners and rockets into orbit. It's less than the time from the discovery of DNA to full sequencing of the human genome. Between 1850 and 1910, steamships went from barely worthwhile to gigantic ocean-going liners (RMS Olympic) and battleships (HMS Dreadnought).
The software industry is not young. The third generation of developers are entering the workforce. Some of them have grandparents who were professional software developers. The industry has completed (or failed at) 100's of thousands (if not millions) of major projects.
IMO, far far too many people working in the industry simply refuse to learn from the past. But that's a rant for another day :-)
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.
The problem with having a QA department is by definition, if they are a "department", they are not part of the development team. The only way testing is ever taken seriously is if the top architect spends his coding time writing test cases, instead implementing features, after all the architecture documents are put under ECO control. And let's hope the same architect believes in closed-loop validation (that is, instrument and measure your test coverage) instead of open-loop validation (write tests without actually measuring what code gets tested by it.)
Eventually, the Developer Gods of the Copybook Headings with terror and slaughter return.
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.
"But I was just following orders" isn't an acceptable excuse in any situation. You are inextricably tied to a set of moral obligations by your decision to build things that affect other human beings, and you cannot shirk them or push them upward. They are yours, they remain yours, and attempts to rationalize the abrogation thereof are at best gross.
Own your shit. If you cannot do good and do well, then quit. (I have done this; it is not that hard.)
"We're just coders, it's not our fault" is not an excuse. Either own your shit (and, implicitly, fix it) or refuse to participate. There is no middle ground.
I can't. Nowadays so much jobs are regulated per diploma/certifications that it is hard beginning again and regain while "older" the momentum for credibility.
The funny part I see breadmakers, cooks, construction is also suffering the same problem. I am currently in France, restaurants for average people are so bad, they do stuff that intoxicate people. I can do bread, cooking, fixing bikes and I do better than "pro" nowadays" without a diploma in their field.
Something systemic seems to be going on. Like people are just taught to execute and required to obey, and bosses don't know the craft of the people they should lead.
Basically being a boss boils down to the capital you can have, and competition seems rigged in favour of people being born wealthy.
I don't think that birth merit outweight a sane competition.
I find the Figaro monolog that inspired French and US revolution about the old monarchic regimes to be very actual.
Weirdly enough author's right says it should be in public domain, but it is impossible to find a link to this essay that is very actual.
I think that it has always fueled my intuition that a profession should be defined by the craftsmanship and not he education.
But my "clear conscience" doesn't help the overall situation.
How can we make the industry as a whole less bullshit? That's the question that I want answered.
And I found asking questions a better way to make people aware.
People will first deny we all have shit in the eyes. And say you are exaggerating.
But, ask them about their experience in IT, but also every days inconvenience because of loss of quality in product. There is a pattern. People feels like industry don't care anymore about consumers. And let them tell their part.
It makes people realize they miss the simple boring life that works.
And maybe they saw something you don't see and they can help you and you can help them.
My first way to improve this is to help people be better consumer by sharing simple way to spend less and get better products by focusing on rational choices. I also sometimes learn. I also sometime am bullshited.
But, you know: trust but check.
On the contrary, it's an acceptable excuse in lots of situations. The finding at Nuremberg was that there is a line beyond which it stops being acceptable, and murder is on the far side of that line. But most things in commerce are on the near side of it.
In other words, a moral obligation to give up your job rather than tolerate sloppiness, applies when you're dealing with safety-critical stuff such that sloppiness could get someone killed. It doesn't apply when the sloppiness will cause minor inconvenience.
> Organizations are ambiguous, often intentionally, about the relationship between > production targets, efficient use of resources, economy and costs of operations, and > acceptable risks of low and high consequence accidents. All ambiguity is resolved by > actions of practitioners at the sharp end of the system. After an accident, practitioner > actions may be regarded as ‘errors’ or ‘violations’ but these evaluations are heavily > biased by hindsight and ignore the other driving forces, especially production pressure.
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.
For example, take the podomatic example - that's just a sloppy function written by a dev. The NPower thing is just sloppy setup of the website and bad links in email templates. The MS thing, well why did the devs add jQuery to a site that is so incredibly static?
Devs make a lot of decisions that influence the quality of software and I think we need to start taking more responsibility for that.
From https://tools.ietf.org/rfc/rfc6143.txt:
> To form the key, the password is truncated to eight characters
I think the 8 character limitation is helpful. Because if you need to protect yourself against it, you can ask "but wtf do I really want to do? Probably not a VNC server..."
When I balked he acted all offended and told me they work with some of the biggest companies in the industry, they see lots of stuff on customer's machines, and are totally trustworthy.
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.
I think companies should start caring more about their quality and users should stop giving money to those that don't. Some of these silly bugs are pretty ridiculous and should never have happened.
Separate event chains from your UI so much as practical, and avoid classes that look like Car, Wheel, etc that are too smart for their own good.
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.
I think there are some tragedy of the commons situations though, where everybody is relying on extremely underfunded common infrastructure. It was only after a bunch of expensive security holes that the users of this software started to pay more attention:
https://www.coreinfrastructure.org/
But there is plenty of other stuff that needs to be done, that would benefit everybody, and doesn't involve security holes.
Blaming users is part of the problem. Yes, they vote with their wallet, but their vote is usually made in ignorance and is often mislead by companies that are so used to dissembling and exaggerating they call such antisocial behavior "best practice".
That said, it is true that this is largely a problem with the economic incentives. Capitalism optimizes for businesses that are financially efficient, so the business that sells the lowest quality product they can get away with is "successful". This becomes even worse in software, where quality is harder to see directly. Even the people that write software can have a hard time evaluating "quality".
The solution for this situation is simple, but it's basically taboo to talk about it: liability. If you sell software, you need to be liable for any damage it causes when "used normally". For a decent sketch of how this might look, see Dan Geer's explanation[1]. There may be other ways to implement liability. I suggest that the software industry should find a way to implement this as soon as possible, if they want any say in what "liability" means.
Yes, this will raise development costs; spending more for better development practices was the goal.
[1] https://www.youtube.com/watch?v=nT-TGvYOBpI#t=1531
Even sites who clearly deliver malware through their ad network don't get sued.
Liability towards one customer is also not the same as liability towards thousands, or even millions of users.
I have to agree wholeheartedly with this statement. I'm relying on software to basically help me run my life. Thanks to software, I can accomplish more than I would otherwise. (OTOH, I also take on more, which is a whole other post on making ourselves crazy by trying to do too much.)
Still, there is room for improvement. The problem is that no single point of failure exists. It's a layered problem involving economic incentive, unskilled people jumping into development to shore up the shortage of labor, an immature consumer base, a dizzying array of tools, methodologies, and standards for developing software, etc.
At present, I don't see any way out of the dilemma.
I try very much. I try to report any issues I find like this (I spoke to 5 different people at NPower trying to explain their issue, and nobody cared or understood).
I have a job/family/life. There's only so much time I'm prepared to put into trying to make silly things like these better, and I'm certainly doing far more than most! :)
A lot of the examples in the blog post are about sucky corporate websites. You aren't going to set up a competitor to IKEA, let alone an electricity company, because the quality of their IT is poor. That argument works in only one case:
• The product is pure software
• It doesn't have any barriers to entry
• The quality of the incumbent is so dire, and the chances of improvement so low, that it makes sense to replicate their entire product investment just to "do it right this time"
Unfortunately such opportunities are rare.
But yeah, they're included here because of the repeated greetings like that. I suspect it was a template, though it only started after I told them that wasn't my name; first few emails (not shown) were "Hi Danny"!
I was asking them to confirm it had not been activated, but the chat didn't go so well!
There's also the bizarre policy university has about passwords. Your password is reset every six months (fine), it can't be similar to your old one (fine) and it's truncated to 8 characters (what?).
What did work was to prepend "A+" instead of appending it. So apparently they silently truncate long passwords somewhere before the 64th character.
NASA with the Space Shuttle software came pretty close. http://history.nasa.gov/computers/Ch4-5.html
http://www.fastcompany.com/28121/they-write-right-stuff
That is unlikely. For computational complexity theory reasons, writing correct software is extremely computationally expensive (regardless of whether or not the language is Turing complete). In fact, it is "the hardest problem in computer science", in the sense that any problem with bounded complexity can be efficiently reduced to software verification. Even verifying finite-state-machines (the simplest computational model) is PSPACE-hard.
What we can do is find many ad hoc ways, each helping to some extent with some kinds of correctness properties.
But enough money and the goal of making it infinitely flexible, having all the possible features, or the most perfect UX that a team can not decide on what it is will only make the software more bloated than it's reasonable, and fill it with bugs.
Of course, making mistakes is only human, but mistakes should never get past the build process (compilation, automated testing). Any mistake that does reflects an error in your design (not making your code amenable to verification) and/or your process (not capturing requirements in tests).
There are lots of good reasons to refactor - if indeed frivolous refactoring is more prevalent I would think this kind of opinion should be supported by a source/reference.
According to empirical studies, practicing TDD leads to a 90% (yes, that number is correct) post-ship bug reduction at an upfront cost of 15-35% more development time.
Which seems like a pretty good tradeoff, to me. (And I've experienced it firsthand.)
http://research.microsoft.com/en-us/groups/ese/nagappan_tdd....
Also discussed in this infoq article
http://www.infoq.com/news/2009/03/TDD-Improves-Quality
Here's someone's thesis paper on it, with data:
http://www.nomachetejuggling.com/files/tdd_thesis.pdf
There's also interesting discussions like this
http://programmers.stackexchange.com/questions/206355/the-re...
"it is my experience that the value proposition for TDD grows exponentially as the time and resources involved in a project grows linearly."
This has also been my own experience.
This person's comment also is interesting and has data
http://programmers.stackexchange.com/a/210756
Some of the above is empirical (read: scientific, no-bullshit) data.
My opinion on it has grown to the point that I think TDD should literally be inseparable from programming, and the two together should simply be called, "programming." Lacking any unit tests whatsoever (TDD or otherwise) should be called, "taking stupid, extremely hazardous risks to save a little time, like reading your phone while driving"
I've not found a programming task in at least 5 years that wasn't waaaay better-written when done via TDD. Some things, like IO, can be a challenge to unit-test, but that's why we have great ideas to solve that like Gary Bernhardt's awesome "Boundaries" talk https://www.youtube.com/watch?v=yTkzNHF6rMs
Yes. It's pretty easy to write provably correct software, just expensive.
> Developers are often guilty of just refactoring for no particularly good reason other than their personal sense of aesthetic, which can lead to endless (and destructive) refactoring
Not my experience, but even if so, if you require your software to be proven correct then it won't matter - any refactor that breaks it simply won't be accepted.
> More money also makes people design lazy, so that instead of finding clever ways to reduce effort and improve uniformity, you just have everyone make their own forms.
Um what? What does this have to do with anything?
It may sound silly to some but I'm really interested in what people think about this.
If you ship something that loses data and you have to start restoring backups and patching data, it probably would've been cheaper to do a little extra testing.
Like everything; it's a tradeoff. I think we're universally bad at playing the game!
Source control should be your single source of change, and check-ins should cause a chain of events via continuous integration and issue tracking. A checkin should cause a build to kick off if it is successful it should deploy to an integration environment where tests should smoke test it. If it smoke tests it continuous integration should up merge to a test branch, deploy to test and then update the ticket system to update all associated tickets to ready for test. When the tester verify the tickets automation should again up merge to release and automation should release to production on a release schedule. This is a solved problem.
Except for all the costs of maintenance. It always costs more, generally in the way of time.
> With virtualization and continuous integration the cost of doing it correctly is marginal
Until you have to debug while the integration fails.
> This is a solved problem.
Even with unlimited funds, you get a cost of time and communication. There are tickets and tickets and a queue and a release schedule. The optimal path is not as simplistic as you would fantasize.
I'm guessing this is relating to my SQL mishap in the opening lines? You're making assumptions that I was doing something manually in production here, and not that I was executing a script that was buggy or against the wrong machine.
Sure, we could build safeguards against this, but it wasn't something we really considered would happen. Needless to say, we've learned from that one!
As others have said, software is a young field, and in many ways we're still pushing and exploring the boundaries of what's possible with software. All of us are still very much "early adopters" in this nascent technology experiment / revolution. The nature of demand and untapped potential for software systems creates a financial incentive for high-stakes rapid experimentation at the expense of sloppiness (in attitude and in software quality) we've seen for as long as there's been software.
I do think investing a little bit more time up front and using TDD combined with good leadership / experience is ultimately healthy for your product and team, if you can manage it. However, we shouldn't forget that being "cowboys" got us to where we are today, and continue to break open exciting new opportunities for software.
I don't understand this dichotomy. What kind of engineer designs anything for a third party without gathering their requirements?
There are static analysis tools that can identify such problems ... sometimes ... maybe ... depending on the language and frameworks in use. But to deploy such tools you have to know about them to begin with. And most devs can't simply produce such a tool if there isn't one on the market because that's not what they're being paid to do.
Unfortunately, knowhow can't be automated away entirely just yet.
Analysis tools are the wrong approach - that code should be simply impossible if you're typing things correctly, and inadequately typed code should be very obvious in code review.
> And most devs can't simply produce such a tool if there isn't one on the market because that's not what they're being paid to do.
Most devs could write such a thing if the company told them to. The reason "that's not what they're being paid to do" comes down to process.
Most organizations barely have enough of a budget to implement the applications they actually need using already existing infrastructure (frameworks, tools, etc.). Asking these organizations to roll their own infrastructure is like asking ordinary people to run their own water or power utility.
As another example, when I was logged in to my mutual fund web site, I found a button that says Get Statement. Since I wanted to download one, I clicked it, and it said, "Your statement will arrive in the post soon." They sent a paper statement without confirming me what I wanted. When it arrived, I threw it away, of course.
In many cases, poorly built software increases costs for the company as well, so financial incentives are only part of the story. Incompetence is another part, maybe a bigger one.
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.