I think it's people deciding that "good enough" is good enough. In any case, with today's rapid development and update cycles, it's easy to fix mistakes.
Fast, good, cheap; pick any two.
80% of the people only use 20% of the features anyway. And they never see the bugs that drives the remaining 20% of the people nuts.
Very much relate to this. Some days, especially in the corporate environment where I work, I genuinely wonder if we are missing the point completely with all the innovation and advancements in OS' and software instead of focussing on cleaning up what is already there. It always feels like there's more time spent developing all of this than there is dogfooding it.
One thing to add to the gripes re iOS - I've found that it works beautifully when it does, and horribly when it doesn't. His point on notification clearing reminded me of the Mail app when you have connection failures: I had 5 accounts tied into it, and when the networking failed it would throw 2 modal dialogues for each account. The amount of time I spent glued on the spot hammering away at notifications so I could move on felt staggering after a while.
I had a glut of other misc. quirks and persistent crashes that cut through the gloss on the device, this in combination with a string of Windows 7 bad behaviour (started python development, started hating python development) led me to switch onto linux (started loving python development) and a droid handset. Guaranteed they will have just as many warts and bad behaviours, but it feels more reasonable because I'm expecting them, and on linux, have an opportunity to fix them.
There's two aspects to being a "power user" (not entirely but I try) that I could never take for granted - this capacity to fix things that don't work, but also the opportunity to work with the more atomic tools. There's nothing more soothing than stringing commands together, writing a script, or organising things in a text file or database: mostly because if something breaks, I broke it, I can see the breakage, I can fix the breakage. Minor bliss!
Addendum / edit to this to provide context - I think coming from a control systems background has coloured a lot of my opinions in regards to innovation. I've seen fistfuls more value delivered (in this field, potentially applicable to others), by creating small, clean, highly polished, iterative and well integrated systems as opposed to large, sprawling and constantly evolving...messes. The sometimes popular fail first / fail fast / iterate like crazy mantra makes me itch. I've seen successful lean / agile approaches executed that focus on quick delivery without being so flippant about quality.
"Guaranteed they will have just as many warts and bad behaviours"
Absolutely!
But you are not alone on Linux, and in the 'everyone sees this' scenario, be assured someone will be working on it somewhere, or something slightly similar...
Ubuntu actually run a 'papercuts' bug fixing programme designed to get new people interested in developing...
It's been an interesting switch, I've found that in terms of what "I do" on a laptop or device, that hasn't been impacted very much nor inherited a lot of new papercuts. I have however discovered a bunch of additional functionality that has been really productive.
A lot of this is spoken as a total newbie to both platforms and someone who didn't look into them seriously before changing (coming from a long term Windows 8 / Windows Phone / iPhone background).
Androids intents make it feel much closer to a real operating system in the way it allows applications to interact with each other (compare chrome browser integration on android vs iOS). Linux (Mint in this case) feels incredibly low friction when getting started thanks to apt-get, and a lot of the screw ups that I lived with in Windows seem to fail more spectacularly on Linux, with the caveat they can be fixed to the point of being quite polished by digging into configuration or updating libraries.
Under Windows and iOS it feels like you start at 80% working and finish at 80% working. With linux and derivatives it feels more like starting at 65% and being able to tune your way up to 90%. Prefer the latter at the moment.
Things get even worse when you know something is broken but nobody else seems to care.
At the cafetaria here I pay with my bankcard, if I put the card in too soon, the payment never works. I know that the payment device software is clearly broken.
The solution: The clerk stops the payment and restarts it if you put it in too soon, or yanks out your card and puts it back in himself.
This is one of the things that really upsets me. I hate how nothing ever works. We spend our money on things that don't do as they say, or companies that don't do as they should. I guess it's inherit a problem with a profit driven world where more features will always trump actually working.
I'm an end user of IT at work. We have managed Windows 7 desktops and a curated range of software. It all sort of works most of the time. My use cases are relatively simple.
>This is one of the things that really upsets me. I hate how nothing ever works.
And somehow you left a comment, using an OS and a browser, on a international network, that put it up so everybody in the world can read it, and I read it in a totally different country.
All totally unimaginable for the common folk just 20 years ago.
And all that with huge color flat monitors, optical mice, mp3s playing in the background, wireless networking, and tons of other stuff going on at the same time. Heck, you might just left the comment from your mobile phone, or I might just read it in mine.
I'm leaving this comment from a computer that might crash on me sometime today. Or could decide to reboot to install its updates when I'm looking somewhere else. I'm leaving this comment on a site which technically could have existed 10 years ago.
Wireless is working right now, that's great. It might stop working sometime today. Things like that tend to happen, on every network more complicated than "I'm sitting two meters away from my home router".
That might have been unimaginable 20 years ago, but somehow, things are about as unreliable as they were 10 years ago.
(I have to admit, optical mice and huge screens are nice, though. But expensive hardware with a single precise objective tends to be reliable, compared to software).
>That might have been unimaginable 20 years ago, but somehow, things are about as unreliable as they were 10 years ago.
10-12 years ago:
1) Windows was Windows ME (not even in the same league as Windows 7)
2) OS X was 10.1 (or before that). Most people still used OS 9.
3) Linux was not quite ready for heavy enterprise use or home use, had worse memory management, filesystem, window managers, desktop environments, drivers and userland.
Everything too complicated to fit into any one single person's head is going to have problems. That's how it works. There is a tradeoff of functionality vs expense-of-time for any given task, and if you polish the functionality to a mirror-shine but don't receive any economic benefit for doing so, then your software won't make much money.
Honestly, there'S just too many things to fix. It's easy to believe with just a little better management or a little more attention to detail or more XP or whatever all these problems would go way but the truth is it's just too damn complicated.
Each of the products mentioned are huge HUGE projects layered on top of hundreds of other projects. A browser has a various networking stacks themselves built on OS stacks themselves built on device drivers etc etc. Pick any part and it's literally counting on millions of lines of code to be flawless. Interact across the net and now you need the software on all parts of that network to be flawless as well
Can you name anything with so many parts that just works?
It's possible it could get better but it seems unlikely. Each year the new stuff is built on top of the old stuff making the hole deeper and deeper as we go. That's why a 1.6ghz atom with a gig of ram sometimes feels slower than my Atari 800
But his point is that we're spending too much time creating new features, and adding to the pile of broken layers, rather than focusing on getting each layer as close to perfect as possible.
This is a trade off I guess. The issue is that "the market" is wowed by new features more than they are by rock solid software. This is because you don't tend to notice these niggles until you have been using it for a while.
A brand new smartphone or a fresh install of Windows always feels like a well oiled machine for the first day or so.
Would you rather be using a modern OS like OS X , Win 8 , Ubuntu 12.04 or would you rather have a rock solid version of Win 95?
I did kind of hoped that when we got an open source Linux desktop, back in the 1990s, that these things might improve. But they did not make it debuggable, even for an advanced user. I can debug hard server stuff, but I have no idea where to start with most desktop software. It didn't help that its all compiled, would be much easier to add sane debug hooks in say Python than in C++ for this type of software. The web at least has got that right, with far better debug tooling than any desktop environment.
The big lie is we as humans have it all together. That we are the superior species on the planet and we can do what the hell we want.
Global warming, destruction of nature, loss of liberty because governments we elect betray us - don't worry, somebody else will fix that, probably some Y Combinator startup. No wait, driverless cars are the answer.
Us humans hallucinate in our own private world more than we interface with the actual world. We can and will rationalize anything. Nobody is upset because we aren't really there, or even here. We are off somewhere else, thinking we are smarter than we are and that everything will be okay.
With the terrifying state the planet is in, we should all be upset.
>With the terrifying state the planet is in, we should all be upset.
Eh, really?
What I find so amusing about people like you and me (and OP) whining about how imperfect the world is that the world has gotten so much better, even in our lifetimes. And yeah, if you are a white American-born male, it might not seem that way- in fact, the world might not have gotten better for you. If you aren't skilled, it almost certainly has gotten worse for you; you've got to compete against a huge pool of people that were simply not in the running before. But for the masses of humanity that weren't lucky enough to be born an American white guy? eh, I think things are better than they were. And really, things aren't so bad for us, either. Maybe not quite as cushy as they were; but eh, I'm still a long ways from pretending to be Chinese, or even wanting to learn a language other than American English for business reasons. Things aren't so bad, at least from where I sit.
But yeah. Getting upset, first, takes a lot of personal energy; and quite often is dangerous.
more to the point, quite often, it's counterproductive. The food riots all over the middle east? (I'm sorry. Look at food prices[1] Then tell me, with a straight face, that poor people are okay with the cost of living going up 4x, but have a problem with a high-school talent-show quality video. I mean, I guess it's possible that it really is the video? but it sure seems unlikely, compared to the much more reasonable explanation that people get unhappy and violent when they can't get enough to eat.)
I mean, sure, they are upset, it's difficult to afford food. A perfectly understandable thing to be upset about. But, is this going to help them? probably not. I mean, it's going to be bad for us, too... but for us? bad means paying a little bit more in taxes, maybe, or dealing with fewer public services. Worst case, we experience more inflation than we'd like. For them? I suspect it will be much worse. Yeah, getting upset isn't helping them. (One could argue that it's actively hurting them even if we don't retaliate. We are a major exporter of grain and soy. By destabilizing us, they are destabilizing one source of food, and thus driving global prices up further. Of course, especially in the case of Egypt, well, there's something else going on; Throughout history, Egypt has been a major exporter of grain. I don't know what happened to cause that to change, or if our presence in the area has anything to do with it, but it certainly is... an odd situation that Egypt can't even feed itself. It's possible that if they could get us to leave, they would be better off. I'm certainly not in any position to weigh in either way on that one.)
I mean, I'm not saying you should never work to change anything, but quite often? pretending that there is not a problem does less damage than getting upset and 'taking action' without really understanding the situation or the consequences of those actions.
But yeah; all I'm trying to say is that before you "take action" on a global issue where you don't have all the facts (and that is any global issue; none of us have all the facts. On most issues, even if you combined all human knowledge, we'd still have missing pieces.) you should step back, and make sure you aren't firebombing an American embassy, if you know what I mean.
For example, some suggest that part of why agricultural commodity prices are through the roof is demand for biofuel. Sure, biofuel is a great thing- the people working on that are trying to solve important problems that are real problems. But... as an unintended consequence, they are driving up the price of food.
Go look at graph 1 again. god damn. The thing is, for me? And probably for you, grains are so cheap that they could go up 10x without really altering what I pay for my prepared food. I mean, even now, you can get a bushel of soy for $17. A bushel is a lot. like 35 litres. 150 cups. A metric fuck-tonne of tofu. Man, that sounds so cheap to me....
>I'm talking about the BIG things: our planet and ecosystem, clean water, liberty and human rights, they are all becoming irrepairably broken.
food prices aren't BIG? I mean, they aren't big for you and I, sure, but for most of the rest of the world, there is nothing bigger.
And really? you are seriously saying that the average person's level of personal liberty and human rights is lower now than it was 30 years ago?
Like I said, that might be true if you are white and male and born in the US... or if you are anything and live in the parts of the middle east we are at war with, but for the vast masses of humanity, the world has gotten rather more free. /they/ now can compete with /us/ for jobs, which is an incredible improvement. (well, it's an incredible improvement for them. For the least skilled of us, well, it kinda stinks. Me? I think it makes things a lot more interesting, and it vastly increases my potential customer base.)
The Earth has been around for 4.5 billion years. Nothing is irreparable. It may mean humanity shrinks quite a lot for several thousand years out of its own folly. The Earth will endure.
As for liberty and human rights, I concur with my sibling poster - the world has been getting BETTER with regards to those things the last 30 years, Americans are the ones that have been escalating the crazy lately.
Everything is broken, and it sucks and it's kind of our fault. Sort of.
It's a kind of, sort of our fault situation because as time has gone on we've stopped caring too much about companies sitting down and just going "Lets get this stuff sorted out and fixed, and improved and more awesome", but started caring about "How many features does it have? Can it do X in Y and Z situations?" which is great, it pushes the state of the art forward. I think companies are spending too much time trying to get stuff out the door, instead of spending the time improving what they've got.
But we end up in a weird situation where we actively want companies to stop adding new features, but a lot of us are like magpies drawn to the new and shiny. It sucks, it's their fault for not getting stuff done properly the first time, and it's our fault for expecting a new shiny thing every few months. And "move fast and break things" needs to stop being a thing.
There was a time when a computer and the software that ran on it cost millions. That was a time when a bug would cost millions and sink a company or two.
I've been thinking for some years now, I wish everyone would stop implementing features and perfect the ones that are already there.
Optimise. Improve.
This is why I was so upset at Sparrow throwing in the towel - they concentrated on one thing, email, and did it better than I'd seen it done before. By specialising they were able to spend the time to get it right.
I've been thinking for some years now, I wish everyone would stop implementing features and perfect the ones that are already there.
Look at the iPhone 5 discussions taking place. The most common topic you'll see is: it doesn't have enough new features. That kind of thinking is one of the reasons that refinement doesn't take place as often as you and I would like.
Crux of the discussion? It's become a market norm to have more, new, novelty. If the only selling point of an iPhone iteration was bugfixes, stability and refinement of the workflows it would just be interpreted as a list of things that were wrong with the previous product.
I think from one perspective advertising refinement is perceived as perpetual incompetence with respect to your capability to deliver a quality product. Horrible inversion of logic.
This is me being subjective and not having much marketing education so someone may want to correct the idea:
From a literal perspective, not much, but in terms of perception and marketing I'd estimate a whole lot. Each product is still representing your brand and a potential option for buyers. You want to encourage someone to be excited about moving to your new product or platform without presenting the case that the old one is inferior or somehow deficient.
Consider if they iPhone was released with a strong focus on the improvements and bugfixes on the existing features without many new additions. Personally this is amazing, I'd be excited about that, but for many (average joe consumer) people I'd estimate it raises some key questions - why was there so much wrong? What will be wrong with the new one? Why do these products have so many issues?
Consider if iPhone was listing fixes and corrections and phone x was advertising all of their new features and updates with no mention of any rectification - personally, I'd be tempted just to pursue the one that was "best". Especially in a flooded market where it's hard to make a legitimate choice, it's much easier if one thing looks broken and one thing looks wonderful.
Most companies are really just going through the process of iterative refinement but I think you need the feature icing to sell them to people, or really: to take the focus off of the fact the product needed rework, and on to the fact there's super super shiny new things! You quickly forget to engage your critical thinking when being dazzled with this kind of thing.
To be hyperbolic with the example - consider cars. When a manufacturer releases a new model and advertises the safety and performance enhancements, it may be likely that they were addressing issues with the previous model, but presenting them as new functionality. This is much more appropriate for a brand than saying "we've addressed the issue with our brake and suspension package that was contributing to people losing control of the car" or "we've redesigned the porting of the heads on the engine so it's not running as inefficiency". If you have the choice between the perceived perfection of one brand versus the other admitting a few people wound up wrapped around trees and they needed to iterate their design (even if both companies are following exactly the same process), it becomes a pretty easy choice, right or wrong.
Since this is HN, what do you think about the business impact of it?
I know "make something small but better" is a nice motto, but will it work for Apple, Microsoft? Heck, even for a proven startup's product, is it a good long term strategy, or a long term gamble?
There aren't much examples of 37Signal's model of "don't implement features but keep polishing" approach.
Even 37Signals has added new features; they just make them a new product instead. The large advantage of this approach is that the complexity is minimized. As long as your customers are OK with this (37Signals trained their customers early and well), it's a good way to go.
I completely agree. I'm sick of feature bloat, especially when it's taking away from perfecting stuff that's useful but not 100% there. Not every application needs to solve every problem - but it would be really nice if they did actually solve one, rather than prod at a dozen. I'm sure it's part of the reason we get attached to early-stage startups so often: they're hyper focused on scratching their own itch and haven't yet been massively distracted by all of those nuisances that come with growth (like needing to make money)
Having said that, I'll point out that Sparrow (like every other non-webmail client I've used) seems to fall over when dealing with massive volumes of email. I'll get into the office with 500 new emails, skim and archive 490 of them over five or ten minutes or so, and then a few minutes later half of them will just show back up. Overall still a very solid product, so I too was disappointed to see it eaten up and killed off by Google.
Companies like Nokia made some great phone products that did the one thing (well, two if you include SMS) remarkably well in small packages, that had fantastic battery life.
But then the iPhone, and Android, came out and virtually no-one was interested in the old, reliable phones anymore. They wanted the latest, shiniest gadget that they could get their hands on, regardless of how good/poor it was at doing the basic job of making calls.
Of course, plenty of people still do use 'dumb' phones, myself included. Worldwide, we're probably still in a majority. But smartphones are gradually taking over, and it would be a brave company now that decided to put their focus on making a simple, flawless phone, rather than competing for the top end of the market.
If you're after something that does one job and does it well, is there a reason why you've chosen those phones over a very basic Nokia model (or something similar)?
But aren't these exactly the sorts of new features that you're complaining companies are putting into their products rather than perfecting their core capabilities (i.e. making phone calls and sending SMS)?
The way I read it, you did seem to draw a line in the sand - that people should have stopped implementing new features a few years back.
My point isn't an attempt at a gotcha - it's a comment that if this is how you really feel, then the only way that companies are going to take any notice is by putting your money where your mouth is and buying the more robust and optimised versions of those things that do the basics well rather than buying the models with the advanced features.
And it's not an attack on you specifically - it's something I see time and time again. My parents complain that the new TV they've bought, which is internet-ready, has apps etc, is too compicated for them to use. Meanwhile the old TV that did nothing more than show TV programs got thrown out a couple of years ago, despite still working fine, because they wanted the new model. They complain that the new version of Office that they use is too complex, but they've still got the Word 95 discs sat around somewhere (and they've rarely got any need to share documents with anyone else). And they are far from an isolated example.
Some people want the shiny new stuff - I know I do - but I accept that if I'm going to be on the bleeding edge of tech, I'm probably going to have bits of it that simply don't work properly. And as long as both you and I are out buying these things, rather than the boring but stable stuff, then this is what the market is going to build for.
Don't get hung up on "years". I didn't mean that I wish all feature advance had stopped years ago, I meant that for several years now I have been thinking about perfecting one thing before moving on to the next.
Every company is different, every product is different, every user is different. Attempting to speak in absolutes like you are simply doesn't work.
As for your suggestion I forgoe a decade of advance in phones... uhh no. A moderately buggy phone from 2012 is still a thousand times better than your puritan "calls and texts only" ideal phone.
The thing is, it could be much better with a little attention to detail.
I spoke in absolutes because I was replying to the absolute of "I've been thinking for some years now, I wish everyone would stop implementing features and perfect the ones that are already there.".
If that's not what you meant, and instead you were trying to say "I've been thinking for some years now, that a little bit more time was spent on fixing existing features rather than always focusing on new features", then I'd probably agree. Although I would say that most companies are, in reality, already doing this and their doing it to the level that they believe the market is really prepared to pay for.
> A moderately buggy phone from 2012 is still a thousand times better than your puritan "calls and texts only" ideal phone.
Indeed it is - but that is far from the message you seemed to be saying in your first comment.
Your insistence on saying this goes one way or the other without being able to imagine a million shades of grey means this conversation is going nowhere.
Despite me pointing out that I was simply replying to your black and white statement ("I wish everyone would stop implementing features and perfect the ones that are already there"), and pointing out that I would agree with a far more nuanced position, you're continuing to pretend that that I'm the one who was trying to make it black and white.
I'm guessing from this that you're not actually massively interested in having an adult discussion on the fact that despite continual complaints from consumers about too much complexity, not enough focus on quality etc, the actual purchasing behaviour of those same consumers is driving companies to focus far more on new features than on perfecting their existing ones.
I've got an iphone 4 and two dumb phones, a Nokia C1 and some cruddy samsung thing. I by far prefer the latter two because the batteries last a week, they phone, they sms and they run twitter. You get over the shiny stuff very quickly.
Probably because smartphones are now less about "phone" and more about "communicator". A phone that can only make calls is rightly seen as a huge anachronism. I daresay that I use my smart"phone" more for the applications I can run on it than making calls nowadays.
But that's the point - people complain that things are getting too complex, that they don't work all the time, and that they wish companies would focus on getting the basics right. But then they go out and but the latest products because the brilliant new features instead.
You don't need to abandon a decade's worth of advances to ask that, for example, the Google IME team all get on the same page (Chinese, English, Korean and Japanese IMEs all work slightly differently and appear different) before implementing say... face unlock.
I'm a big fan of single-purpose tools, but if you tried to have EVERYTHING in your life a single purpose tool, you'd need a shopping trolly to carry it all around with you.
I'm not missing the point at all. Companies are run for profit, and they make their decisions on what they believe the market wants.
Do you think that the average punter is more likely to buy their next phone based on new feature like face unlock or because they've fixed an occasional bug in mail sync?
And what about your body? and the world around you? and your relationships? and the instruments you use?
Do your faulty examples in any way contradict anything else you know? do you have a counter example?
Reality is dirty, everything tries to break down all the time, hindered by the traces of its past, and the ambivalence of its future use. We make stuff dreaming of a prefect neat existence. This keeps us going, like moths around a light bulb. And we should keep on doing this nevertheless.
I've spent most of my career for 15 years as a programmer. Some days I just want to throw out my computers and phones and never touch them again. Days when I get overwhelmed by the feeling described in the article.
Every computer environment is layer upon layer of kludges. There is shit all the way down.
batista, I often find myself nodding in agreement when reading your posts on HN -- especially when you take a contrarian position.
I do agree with you in this, also -- the hardware and software combination of a single PC or smartphone is, I guess, among the most complex systems humanity has built, and in such a short time frame.
While my post was mostly me venting (bad Monday, frustration with people/clients/spouse/stuff in general), I have to say that I still agree with Scott. Too often are we putting up with things not working. I use Android, Gmail and Google Calendar. Yet, when I get a calendar request, it shows up in the official Gmail client on my Android phone as
meeting.ics
1 KB Text
VIEW | SAVE
If I click "view", it opens up in a text editor. This is not helpful at all. Does nobody at Google ever get a calendar request to their phone? The only way for me to respond to such a request is either to get to my computer and open it in web mail, or call back and ask what time the meeting is.
Whenever a family member asked me about something failing in a similar manner, I used to feel slightly attacked: This is my line of work and major hobby, and I know that the reason shit fails is, well, shit is hard. I would perhaps try to explain the probable cause and so on, but to what avail? It still doesn't work.
But now, I rather shrug and say yeah, I know, it sucks. It happens to me too, all the time. I just get used to it, and deal with it. Isn't that all we can ever do, after all?
Lately, I've started trying way harder to remove complexity. I constrain myself on purpose, I get rid of software and file formats, and basically, the last thing I ever want to do is to add a new piece of software. If I am convinced I need a new piece of software, it has to be implemented with minimal change to the rest of the system.
Well, that was a bit of a rant. Anyway, in no way do I mean to disrespect any of the programmers who built this ingenious, brilliant piece of shit. I feel for them and, well, the brilliance sometimes shines through. We're still running the world's financial, communications and distribution systems on layers of shit.
>batista, I often find myself nodding in agreement when reading your posts on HN -- especially when you take a contrarian position.
A, thanks. I mostly take a contrarian position when I comment, because at things I already agree with I don't feel the need to comment on (yeah, have the silly urge to correct "someone wrong on the internet" as my motivation).
>This is not helpful at all. Does nobody at Google ever get a calendar request to their phone? The only way for me to respond to such a request is either to get to my computer and open it in web mail, or call back and ask what time the meeting is.
Yes, that's a perfect example of what the article SHOULD BE talking about (far better than the examples in the article). With those kinds of things, I agree, you tend to see neglect like this in all apps.
I just disagree with the particular examples given in the original article, which are far more complex and bug-like, and most of all with the notion of the article that because of those bugs (syncing, FCP crashing, etc) "everything is broken".
Some of the "layers of shit" (e.g, a pet peeve of mine, the traditional UNIX application installation directories and standards such as /usr/bin etc instead of self-contained, versioned, app directories) have historical reasons, and not necessarily incompetence, and it's very difficult to remove them without major financial and time investment.
Depending on who you ask, Apple stopped being that company a few years back.
They will answer Mobile Me, iTunes, Snow Leopard, iCloud, Genius, Ping, iPhones unable to call or any other thing which at some point was delivered in such a shoddy state that it was hard to keep believing Apple was any different than the other tech companies.
Anyway, this is not another Steve Jobs is dead, Apple is going to heck-post. The decay began a long time before that.
He's doing too much with too many different things. The following phrase is valid here: "A man with two watches never knows what time it is".
I rarely get problems of that magnitude. The only unreliable thing I have is my ADSL connection and that's not a problem as I can use my phone as a backup.
Good point. I went through a phase where I offloaded virtually everything that takes electrons bar my laptop and phone (which doubles as my modem), I've been at this baseline for a good year or so now. Between that and limiting myself to one bookmark of any given category or subject matter (eg, HN = news and tech, Juxapoz = art site, rather than multiples of each), I feel like I have a hundred million hours a day in which to do things.
I went from struggling to read a few pages of a book or write some code every evening to currently working on postgrad eduction, other certifications, volunteering, etc. It's not as literally simple a transition (lots of changes in motivation and practices in the mix), but every single device comes with a level of cost in terms of time and cognitive "energy". Stack them all up and it turns into a pretty big percentage of your capacity each day.
So, your amazing feat of engineering phone, with a color retina display, audio-video capabillity, 700.000 apps, gyroscope, HD cameras, etc has some extra stuff taking 3GB drive space (of the 16GB device).
Your amazing, multi million lines of code Windows desktop, the work of some 1000 people or more, has a problem with indexing.
The protocol and apps that connect you via email to everyone you want, free, globally and instantly, sometimes loses a mail. Or the UI is slow to load your new messages.
A program with which you can do on your laptop what it took huge teams, million dollars of equipment, and professional expertise to do (FCP), has a crashing bug in some particular action.
The program that lets you talk to everybody on the planet, instantly, with video, and paying nothing, has a badly designed UI.
etc...
Yes, I can see how "everything is broken".
Because, when we didn't have any of these, when 30 years before you had a rotating dial to dial numbers on your phone that only called landlines and cost mega bucks to call internationally, when you had MS-DOS as the most prevalent desktop OS, when 20MB was a huge disk in a desktop system, and before something like video chat was only possible
in huge organizations with special software, everything was perfect...
Wanting to improve things? Fine.
Not understanding the complexity and magnitude of the technical achievements you use everyday? Bad.
So, your amazing feat of engineering car, with automatic transmission, ABS, a GPS, incredible fuel efficiency etc. stops in the middle of the highway sometimes.
Your incredible display, which somehow manages to use liquid crystals to display beautiful 1080 HD video develops a jitter and bright line down the middle after a month.
The machine gun which lets you launch tiny projectiles at speeds high enough to kill a person sometimes fires rounds without you pulling the trigger and causes a casualty.
...
Yes, the technology is incredibly complex and represents a huge transformation in the way we do
things, but a customer doesn't and shouldn't need to understand that, and certainly shouldn't be offered the complexity as an excuse for it not working correctly. Given the fact that most (all?) of the products mentioned in the post have some kind of price associated to using them, its not unreasonable to expect they work correctly.
This is not to say that the people who made the tech are at fault per se, just that the customer is not at fault either for complaining when things dont work.
>Yes, the technology is incredibly complex and represents a huge transformation in the way we do things, but a customer doesn't and shouldn't need to understand that, and certainly shouldn't be offered the complexity as an excuse for it not working correctly.
In some ideal world, where you can have things with MILLIONS of moving parts and TRILLIONS of states, designed by mere mortals and still have them be faultless, yes.
In the real world, the customer will have to settle for things not being 100% perfect.
He can now do things unheard of even in science fiction 20-30 years ago, and takes for granted things only appearing like 6 years ago (e.g YouTube).
>Given the fact that most (all?) of the products mentioned in the post have some kind of price associated to using them, its not unreasonable to expect they work correctly.
I think that, yes, it is unreasonable. That you pay for something doesn't mean anything related to it's error margin. You cannot demand the impossible just because you paid for something. It's like saying: "hey, I paid for this car, why does it is disfigured when it crashes and can kill me?".
Consumer products (non digital) break all the time. You can even pay top dollar and yet have crap food served to you. And all those are far less complex than software.
My argument is not that consumer products should be perfect; it is that when consumers see deficiencies in them which could reasonably be fixed, they have every right to complain. In fact, they should complain because it will help make things better.
Are they meant to be examples of complex tech that aren't allowed to fail and don't? Or examples of complex tech that does fail, but really shouldn't?
>but a customer doesn't and shouldn't need to understand that, and certainly shouldn't be offered the complexity as an excuse for it not working correctly
It's not an excuse - it's an explanation. These things are complex, and complex things sometimes fail. The average user can be forgiven for not really appreciating this, but lack of knowledge of the nature of complexity doesn't magically make it disappear.
Of couse companies could take the NASA approach of spending huge amounts of time and money on formal requirements/analysis methods, building massively fault-tolerant solutions etc etc, but I doubt there's a vast amount of users out there willing to buy tech that's 5 years behind cutting edge, and costing many times more, simply because it (almost) never fails.
They are meant to be examples of failures which are extremely rare and would be unacceptable to consumers. Sorry, I realize they are quite unimaginative :P
My response to your comment is the same as the previous one:
>My argument is not that consumer products should be perfect; it is that when consumers see deficiencies in them which could reasonably be fixed, they have every right to complain. In fact, they should complain because it will help make things better.
>They are meant to be examples of failures which are extremely rare and would be unacceptable to consumers. Sorry, I realize they are quite unimaginative :P
Cars stop moving on a fairly regular basis, often as a result of the comparatively simple mechanical side of things. In the case of Toyota a couple of years ago, they didn't stop moving at all when the driver wanted them to.
The other examples you gave have happened too - this despite the rather more critical nature of the machine gun issue and again its relative simplicity compared to, for example, a modern phone.
I've got no problem with people calling out where they see problems, expecting someone to at least take their complaints seriously, and in a lot of cases expecting the company to do something about trying to resolve it.
But that's not really the message I took from the article - the idea that that these problems are caused by lack of passion or quality on the part of the people making this stuff rather than being an almost inevitable result of the complex nature of these systems.
TBH, I'm not even sure I buy that it's really that much of a problem. Almost everything isn't actually broken - the vast majority of our tech works remarkably well the vast majority of the time, and I prefer having tech that mostly works and is both available and affordable than having the same tech that will work perfectly when it's delivered in 5 years time at a vastly increased cost.
"Is this a speed problem? Are we feeling we have to develop too fast and loose? Is it a quality issue? Have we forgotten the art and science of Software QA? Is it a people problem? Are folks just not passionate about their software enough to fix it? I think it's all of the above. We need to care and we need the collective will to fix it."
I.e, he attributes things to lack of: care, passionate people, the forgotten art and science of QA, etc. Which is BS. There will ALWAYS be many bugs and problems in systems that large in scope and complexity.
And it's not because "the guys that designed, say, GMail or FCP (that he complains about) do not care, or lack passion, or have forgotten the "art and science" of software QA.
Plus, the kind of bugs he describes are not that important compared to what we have actually achieved and DOES work.
FCP crashing when you "scroll too fast" while rendering?
Give me a break, these linear editing systems cost tens of millions of dollars, took half a room, and didn't operate in real time just 15 years ago. Oh, and had just as many bugs, and you needed support staff from Avid or whatever to come over to set them up. Now thousands of people all over the world edit their films and documentaries in their laptops.
Plus, the kind of bugs he describes are not that important compared to
what we have actually achieved and DOES work.
Bingo! This is one perfect example of the problem he's referring to about people not being passionate enough to fix the problems: "Those bugs are not that important."
That's a lame excuse. Who cares that we are better than 15 years ago, the point is that we have lots of (seemingly) low-hanging fruit that stays there for plenty of releases and that nobody cares enough to fix, because "bah, it's not that important."
The problem is not that the bugs exist, but how fast and how well they are being solved.
>Bingo! This is one perfect example of the problem he's referring to about people not being passionate enough to fix the problems: "Those bugs are not that important." That's a lame excuse. Who cares that we are better than 15 years ago, the point is that we have lots of (seemingly) low-hanging fruit that stays there for plenty of releases and that nobody cares enough to fix, because "bah, it's not that important."
Well, this is my other pet peeve, people not understanding the notion of "opportunity cost".
>the point is that we have lots of (seemingly) low-hanging fruit that stays there for plenty of releases
The key word here is "seemingly".
Do you really think that the guys as Apple/Google that pull all-nighters and work themselves to death to finish iOS/Android don't have "enough passion to fix problems"?
Or do you believe that if they took their sweet time they would have fixed every "low hanging fruit"? Even a low hanging fruit can add a couple of days to a month to a project, or delay other, more important features and/or fixes.
"Go attack all the low hanging fruits" is a meaningless proposition. Some projects you use are open source. Why don't YOU go attack them? Who is gonna make those "low hanging fruit" interesting for a volunteer to work? Who is gonna make them profitable for a for profit company, so that it doesn't die in the market while fixing them?
Mozilla tried to build a better browser. They addressed all the low and high hanging fruits.
What happened?
It took them 5 years to ship something that worked kinda OK, by which time the company had died, and the market share went to IE. And even those releases 5 years after the new code started had lots of problems. Eventually they betted on the more minimal Firefox instead of ever perfecting the full blown Mozilla browser/suite. And it's still not perfect.
Result? Besides the parent company dying, they haven't got that old high Netscape market share back even now.
The key point is who defines what "opportunity" is and, most importantly, why. There are opportunities to build new features, or opportunities to fix what's broken.
Do you really think that the guys as Apple/Google that pull
all-nighters and work themselves to death to finish
iOS/Android don't have "enough passion to fix problems"?
Honestly, I believe their managers give new tasks the a higher priority and that there is a pervasive mentality among all the profession that these are "irrelevant" problems that everyone has become accustomed to put up with and, in addition, are boring to work on.
Who is gonna make those "low hanging fruit" interesting for a volunteer to work?
The pride on creating a mighty fine piece of software should do it. I actually DO try to attack all the user facing (annoying) bugs on my projects, always. I may or may not be successful at that, but I'll never use "we are much better than 15 years ago" as an excuse. And I'm certain you and I have both seen well designed and executed pieces of software, where care has been taken on the UX and have very few if any of these problems, so complexity isn't something that forces you to have annoying UX bugs.
The bottom line is that I feel it's disrespectful to a user to tell him to put up with the annoying "life-wasting five minutes at a time" bugs, only because 60 years ago he would have been playing cards over candlelight instead of trying to sync his iTunes library.
It's like starting to pierce people with a pin and when they complain say "be grateful this is not the medieval times, because the pin would be a broadsword and you'd be already dead."
It's just using past progress to justify current mediocrity. We should accept that those bugs that affect UX are indeed very important, and not dismiss them.
Have you even thought how much better things would be if people actually gave this a higher priority?
About Mozilla, there are lots of things that went wrong, and not many of them were due to fixing UX annoying bugs.
>The key point is who defines what "opportunity" is and, most importantly, why. There are opportunities to build new features, or opportunities to fix what's broken.
Who defines it? The business. Opportunity cost is a business notion (even if that business is making a non for profit OS software).
>The pride on creating a mighty fine piece of software should do it. I actually DO try to attack all the user facing (annoying) bugs on my projects, always. I may or may not be successful at that, but I'll never use "we are much better than 15 years ago" as an excuse.
So you "may not be successful at that". So why don't you stop 100% whatever else you're doing until you are successful 100% at that?
Because, obviously, you also need/want to do other things that you consider more important.
What I'm saying is: give the same courtesy to the makers of software you use.
>The bottom line is that I feel it's disrespectful to a user to tell him to put up with the annoying "life-wasting five minutes at a time" bugs, only because 60 years ago he would have been playing cards over candlelight instead of trying to sync his iTunes library.
Actually I find that the user throwing a fit is immature and disrespectful to what he is offered.
And you can see that sense of entitlement all too often in OS projects: "your software doesn't do X, or has the Y bug, it is crap, etc".
There are programmers that want to fix bugs, and programmers that just don't care. But it's not like the "just don't care" is somehow the prevalent attitude, or that bugs that are not fixed don't have a reason behind them not getting fixed (even if it is the simple: "didn't get to it, yet").
Neither are all those bugs "simple UX bugs" as you seem to imply, meaning that they have no backend or deep dependencies, or are trivial to fix. The bugs the article describes for example are syncing bugs, or bugs in working with video streams a non linear video editor. Those can be very complex and subtle, and may not even appear except in some very specific setups.
>It's like starting to pierce people with a pin and when they complain say "be grateful this is not the medieval times, because the pin would be a broadsword and you'd be already dead."
No it's not like that at all. For one, in this example you compare small pain now to bigger pain in the past. But what people get now is much more features (with some bugs), compared to less features in the past (with some bugs). So, if anything, it's exactly the opposite.
Open Source complaining assholes apart, which can fall high on the disrespect scale sometimes, users have all and every right of complaining about the things that are not working, always. Users are not in debt of software developers in my view. If you think otherwise, then that's the key of our disagreement.
I do think that "don't care about UX bugs" is a prevalent attitude among software developers. I may be mistaken, but let's not forget you even used it as an argument: "those bugs are not that important", which is what compelled me to reply.
I believe that death by a thousand cuts is worse than death by a single blow, each time these bugs occur make a little cut.
And of course some of them might be devilishly complex or E_NOREPRODUCE, but I believe they are pervasive mostly due to the industry being focused on having more features before stabilizing old ones, because, you know, those bugs aren't that important.
(Hint: Multiply 5 minutes wasted by an annoying bug by 12000000 users and you have a million hours down the drain, each time)
Stop. Re-read the post. Try to understand the point of the post. Understand what it is he's saying about process, craftsmanship and trying to fix things that are broken instead of making excuses. Understand it as a call to action to do better, to be better and to care more.
Then re-read your response and see what a defensive crouch you immediately took. How that immediate defensive reaction led you to miss these points. Crying "complexity!" for things that don't work is not a solution. Time, money, education and understanding are required to implement a solution, and I believe that Scott is explicitly calling for the latter and implicitly calling for the rest.
>Stop. Re-read the post. Try to understand the point of the post. Understand what it is he's saying about process, craftsmanship and trying to fix things that are broken instead of making excuses. Understand it as a call to action to do better, to be better and to care more.
"Calls to action to do better" are a dime a dozen.
You can get them in $5 self-help books, motivational posters and bs marketing gurus. For all I know, they come free with Cheetos.
The problems he describes are not because of some "lack of craftmanship". They are inevitable in large scale, enormous complexity systems, that also have to SHIP some day. Things that CAN get fixed, ARE getting fixed.
>Time, money, education and understanding are required to implement a solution, and I believe that Scott is explicitly calling for the latter and implicitly calling for the rest.
Saying that "Time, money, education and understanding are required to implement a solution" means absolutely nothing. At best is a platitude that goes without saying.
Do you or Scott thinks that the major software players do not spend time, money, education and understanding on what they are making?
Microsoft, one of the software makers he complains about (and he knows internally), spends tons of money on testing and QA. And it has some of the top minds in software engineering. Ditto for Apple, ditto for Google.
I completely relate to that feeling. This has led me to use less of everything over time. One day I realized this, that I was in fact applying the KISS principle to my life. Fewer apps + fewer features + fewer gadgets = fewer bugs irritating my day-to-day life.
Examples:
My desktop environment on my laptop is Linux with, 99% of the time, just a bunch of xterms and a browser (without extensions... they tend to crash browsers).
I installed exactly 4 Android apps on my phone (after flashing it to cyanogenmod to get rid of the bloatware): gmaps, youtube, barecode scanner app, some app to write notes on the home screen (NotesWidget). Everything else sucks and is a waste of my time. But even the dead-simple NotesWidget app author managed to mess it up with enough bugs that I am considering writing my own(!) I have tried at least a dozen other notes-taking application and am not satisfied with any of them.
I don't maintain a music library. Sync'ing music across multiple PCs, phones, other devices, etc, suck. Personal libraries "in the cloud" don't work because I am not always online. I just listen to satellite radio in my car.
I own no TV, no game console, no tablet.
And yet, I am a tech enthusiast. I accept a little "complexity" where it makes me happy: I program GPUs/FPGAs, I have a home theater set-up at home, I maintain my own website/blog on colocated servers, etc.
> Sync'ing music across multiple PCs, phones, other devices, etc, suck.
Was thinking the same but I had to do it, because I need a back-up and I need my music at work too. The only sane way: have proper files half-manually arranged in directories synced with a real solid linux tool (unison). Same for pictures.
What I want to emphasize here is that the current trend against files is a disturbing regression, and can only end in a complete mess or loss of the things you own. I have kids pic in my folders, and I owe to my kid to still have them in 20 years, if nothing else.
This discussion reminds me of something weird that occured to me when I was following lifehacker: it had so many advices and nice tricks and apps you should install to your system, and at the same time was very voical against the bloat and the clutter.
Spotify is so much easier. Once you decide to only manage stuff you create rather than stuff you happen to own, then backup and management get so much easier as there is so much less of it.
Problem is that Spotify doesn't have all the music you want necessarily unless you also add your own files to it.
My solution to this would just be a dropbox folder full of MP3 files and a vlc playlist file. I don't use any monolithic player/organiser of music like iTunes or WMP but too a lot of people it seems like it has to be iTunes.
The benefit of liberating yourself from trying to backup and distribute someone else's content is much greater than missing a few tracks. There is plenty of other stuff that you could listen to instead.
That's really quite a subjective thing. It might be true for people who just looking for anything to stick on in the background.
People who are "into" music and have favourite artists that they are very loyal too or who are looking to discovered unsigned or indie artists are not going to want to be restricted to whatever is in the Spotify catalogue.
Personally I'd say around 50% of the music I want to listen to is available on Spotify. There's also a fair number of "big name" artists who's music isn't licensed to them.
The solution for a lot of people seems to be to simply use YouTube as their music player since pretty much anything seems to be available there. On the other hand I'm not sure what the legality of this is.
Ten years ago everybody enthusiastically installed every piece of shareware (windows) or open source (linux) software they could lay their hands on. There were a whole lot of portals devised to desktop software.
People's desktops had all kinds of weird hacks in it, tweaking every imaginable bit of appearance, user experience and features.
But I think we all came to conclusion that it does not pay off. Yes, your 3rd party file manager is much more powerful but does installing it on every of your PCs in life pay off? It does not.
The whole experience becomes much more generic and throwaway. Yes, I tune some programs, but I'm ready to leave the whole setup at any moment and start with a blank screen again - and I actually have to do that every 2-3 years.
No longer I use dozens of programs and have 5 DEs installed but just a few and exactly one.
Same boat. Only my essential developer tools and very few apps. Used to try everything. For Win if it's not on Ninite it's not on my PC. It's just to much hassle when reinstall and I wan't the same tools on my MacBook an PC
Not really. Programs don't tend to read the configuration files of others, and they don't tend to change their own configuration files that much either. Since I started using Debian, six years ago, I probably had to modify three or four files and maybe delete a few more. Time that is more than paid off by the time savings of some of these configurations.
You can eliminate some of the uncertainty by googling the product name and see if there are any complaints of the "Everyone has seen this issue" variety. Of course, even a product with 100% consumer satisfaction can have "No one has ever seen this before" issues.
Android FolderSync would help in your music syncing issues...it syncs folder pairs where the other end of the pair can be literally anything - ftp, http, nfs, samba, skydrive, gdrive, etc. If you aren't online - no biggie it can sync with your PC whenever you are in your home network or sync with your office workstation if you are at office or just about any combination you can think of.
I completely concur. Careful pruning of your toolset will allow you to move forward far faster.
I have basically standardized on Pidgin, Firefox (minimal extensions), emacs, org-mode, and a terminal program. At home, I use Mail.app and the OSX contacts. I'd like to move them out to emacs though. :-)
Well, that's the balance between features, bugs, and cost.
If consumer software companies were working more like, say, people working on Curiosity (Mars' robot) or aircraft navigation software, you could have a phone that does much less but without bugs.
The reason why it is this way is because people usually prefer to cope with minor bugs that giving up on features. Plus, when you buy a product, you usually know the list of features but not the list of potential bugs.
So you can make a company that sells phones with 0 bugs, with a 2004 set of features. Or an OS that focuses purely on providing a bug-free experience, but 5 years late.
Reading his laundry-list of paper cuts, it looks like many of them (around 50%?) relate to one particular issue: synchronisation. It keeps coming up, time and again, from his email woes (seriously, folks, didn't we solve this one back in 1980?) through to the borked address books, contact lists, and photo streams.
Sync software usually takes a conservative approach to deleting or merging records, and leaves duplicates lying around rather than risking deletion of vital user data. This is a good thing. What's bad is that the tools for housekeeping -- merging and deleting duplicates -- are generally rubbish. (I have the same problem with my phone's address book: masses of duplicates due to sync processes that conserve stuff. And trying to get rid of them using the tools provided turns out to be a tedious pain in the neck, requiring multiple mouse-clicks or focus changes per record.)
Further down the list we get into identity management issues. Nobody seems to have a really good handle on how we manage identity across multiple machines, much less how we manage esoteric stuff like family relations for delegating access to photos or music purchases or whatever.
I noticed the same. We don't have a precise underlying model without real unique identities for everyone. That's the rub - people want multiple identities, and don't always want to share their real one. Add to that multiple software systems, and it's messy.
The tradeoff is a more reliable "less messy" world, but much less innovation.
This doesn't mean that software requires less QA or design, just that it's a trade-off of two different modes of operating.
The only solution is to switch to technologies where merging data is a primary core feature. Thus why I use text files and git to manage the vast majority of my data.
The sooner people realize that sync isn't fixable (or a good idea in many cases), the sooner real solutions appear.
well, 'export but give me anything new that's not in conflict', or 'import but don't overwrite anything in conflict'...
'sync' somewhat makes sense, but two sync options labelled easy to understand would go a long way to clearing this up, but... would likely introduce other issues as well.
Synchronization in IBM Lotus Notes/Domino has worked quite well for 20+ years, so obviously sync is not fundamentally broken. More likely we've just failed to learn from history.
I'd love to know if the Notes sync method is documented somewhere. I don't doubt that there are some good implementations, but...
Does it do offline sync with multiple users whose changes may have different priority?
How about if time isn't set properly between multiple devices?
How about a multi-way modify/delete/rename where two records are given identical keys on more than one system, then both systems are reconciled?
I really need to write up a "Sync Gauntlet of Pain" that shows how sync implementations are incapable of making correct decisions, as they just don't have enough information, and giving them more information may not help.
Yes it does offline sync with multiple users. Changes aren't prioritized but you can configure what it does with conflicts (merge if possible, discard, or leave the conflict).
Time synchronization between multiple devices has been a solved problem for years. Not worth worrying about.
Creation of identical record keys — while theoretically possible — really never occurs in practice.
Even git isn't perfect. I spend plenty of time in a three windowed merge tool figuring out which piece of code should go where when we have merge conflicts.
The solution would have to be to store everything in ascii formats (probably taking a hit in terms of filesize and performance) and get everyone to understand the ascii representation each of these data formats and how to merge them effectively.
The alternative would be to build a diff tool for every binary based format out there.
The simplest solution would simply be to implement locking on everything and have one authoritative copy. So you can have your data on any device you want and share it with as many others as you want but only one person/device can have write access at any given time and can only have that once they have updated to the latest version of that rescource.
You can do sync the Right Way, but it's non-trivial. Programs like Google Docs and Etherpad do really good sync for text documents, because they've put serious mental effort into figuring out how to get sync to work correctly under (almost) all possible circumstances. If ten people make conflicting edits to a single region of the document and then sync, their documents will provably reach a consistent and reasonable state.
Many of the same methods can be applied to other types of synchronization, but it's more effort than most people can spare when they're in a hurry to get something released.
It's for this reason I've been keeping my eye on Rich Hickey's Datomic. It's not open source or free, but the idea of immutable data (everything is attached to a timestamp--yes, everything), seems intriguing.
The same thing jumped out at me. Probably because of the months I spent in 2004, staring at the combined desktop + Palm OS databases helpful customers had emailed in, wondering how things had gotten to their present state.
We controlled the code and data 100% on both sides and I still never got it working really well.
Contact software is, IMO, trying to do too much these days.
I have a business contact on my iPhone that has a contact photo of one of my relatives. I certainly didn't set it this way, but I have no idea how this happened. Is it something that my iPhone did? Is it something that happened at Google (it's a Google contact)? Is it something that my Windows 8 contacts app did (syncs to Google contacts)? I don't know, and even if I did, I don't know if I'd be able to fix it.
Frustrating. We sandbox our applications, and the success of the iPhone shows that this is something users want. Why can't we sandbox the other parts of our computers? Sure, I could "delink" everything and maintain it all myself, but I wish it wasn't so "all or nothing".
The blurb on the sidebar proclaims Scott's MS experience. It's surprising to see someone with a Microsoft background making this complaint. MS spends more effort than any software company on testing, not only in just plain hiring lots of testers, but also on formal methods. They have some of the top formal methods people in the world doing research for them, and armies of people trying to put that research into practice. Making stuff work is hard, and I'd expect someone who worked for Microsoft to know that.
I work for a hardware company. Bugs are really, really, bad. If we find a hardware bug in real silicon, at best, we catch it the moment we get the first chip back, and it means that we have a multiple month delay as we fix it and tape out a new chip, not to mention the cost of throwing away all of the partially fabbed chips we've got, plus the multiple million dollar cost of a new mask set. At worst, we have a recall [1]. We take testing very seriously, and we do a lot more formal verification than most software companies.
The only things you can be sure about are things that have been formally verified [2], and the list of things that you can formally verify is tiny. We formally verified our adder. It took months. Then we did the multiplier, which was much harder. It took about the same amount of time because of the experience we gained doing the adder, but it wasn't easy. Division took a lot longer, even with the experience of doing addition and multiplication. To think that we can advance the state of the art of "things that work" from something like a multiplier to a complex piece of software with "care" and our "collective will" seems overly optimistic.
Everything's going to be broken for the foreseeable future. Putting more effort into testing and less into features is a difference in degree, not in kind. It won't even prevent articles like this from being written because, if all you want to do is find ten bugs in all the software you use, that's still going to be trivial. Considering how much progress has been made in formal methods since 1970, I expect that finding 10 annoying bugs in all of the software I use will be trivial for my entire lifetime.
[1] Well, you don't have to do a recall. AMD had a hardware bug that could be fixed by a patch that degraded performance by 10%. Sun famously didn't include ECC in their L2 cache, which resulted in transient failures for a number of customers, and they made customers sign an NDA before replacing their parts. Guess how much people trusted AMD and Sun afterwards?
[2] Even then, you're never really sure. How do you know the formal verification process itself isn't buggy? It's turtles all the way down. I know some folks who were trying to build a formally verified OS, and they stopped using ACL2 after discovering a few bugs in it. After all, how can you trust your proof if the proof system itself has bugs? ACL2 is old and crusty, but that's precisely why it's used for more hardware FV than everything else combined, outside of Intel and IBM (both of whom have their own, excellent, internal tools). It's old enough to have great libraries. There are newer systems that have better architectures, but they don't have anything approaching the same level of library support for hardware. Yet another tradeoff of time to market vs. correctness. It can't be avoided.
Say you're an engineer who's worried that ACL2 is too buggy for your company to use. You tell your manager. She points out that maybe five ACL2 bugs are discovered every year, and they get more minor each year, as the system gets cleaned up. Moreover, none of the bugs discovered in the past three years have affected any of your proofs, and you wouldn't expect them to have an effect on any proof techniques you're going to use. So you stick with ACL2. And, because you do, there's a tiny risk of a bug. What does this example have to do with the original post? Bugs come from making little decisions like this. No single decision is sure to cause a problem, or (in a company that's serious about testing) even ...
I don't think it's necessarily about perfection on release (though certainly sometimes it appears that things were never user tested).
Reading through Scott's article, he points out that it's not uncommon for an issue to be raised by many users and ignored by the product owner (my personal pet issue at the moment is Google Calendar no longer allowing me to accept invites sent to non-GMail addresses).
It might not be cost-practical to fix issues that affect a small section of your audience, but I'd like to think there's a certain qualitative aspect that comes into play, and if the issue affects 'n' people it should get a banner regardless of whether 'n' is only a minute percentage of your audience.
We have many new shiny FM tools now, though, that are far closer to regular programming languages. In particular, Agda, Coq, Isabelle are fairly easy to pick up for people with an FP background (rather than a formal methods background).
The breakthroughs in SMT solver performance have been astounding to watch, and their use for "brute force" FM is certainly growing.
Of course, verified code is still many times the cost of unverified code, but the gap is coming down.
I'm using Coq for a formal method class and the CoqIde is a piece of software that falls into this category. If I have two files open and I run a search, there is a good chance that the CoqIde will crash and I'll lose my work. I've worked around it by saving my work before I search but I shouldn't have to worry about searching in an IDE
Perhaps things have changed now, but previously MS had a setup with 2-4 testers per one developer whereby latter would churn out code as fast as he can (of a respective quality) and testers were expected to identify critical bugs so that the dev can plug them, in the same speedy manner as he'd code the original. I had few close friends work for Microsoft in the 90s and the impression I formed after chatting with them was that the MS products routinely were something that was hacked and hammered into a state of not crashing too frequently. So while Microsoft might have a strong focus on testing, it was used to be completely misplaced and misguided.
A focus on testing is not the same as a focus on quality. Also, if your test criterion is "doesn't crash" then a lot of slowness, resource leaks etc, may be, and probably are, acceptable to you.
My impression is the Microsoft of the 90s has little to do with the Microsoft of today in terms of QA, testing, and security. This impression is "secondhand" (I have never worked for Microsoft). Reforms were made, so if you information comes from the 90s it may be time to update it.
All MS info should come with a grain of salt from the simple fact it's a company of about 90,000 people with thousands of unique teams. I worked at MS and every team I interacted with handled testing and QA very differently.
MS has fantastic formal methods people indeed. Rise4fun.com is some of the great stuff coming out of there. However; are they using this? Because it seems to be only research and most programmers (inside / outside MS) will not even vaguely understand how to write formal proofs, even with brilliant stuff like Dafny (which no-one uses obviously as it is a research thing).
I studied in Eindhoven under a pupil of Dijkstra and my father studied under Dijkstra; formal methods are kind of a natural thing for me since I was introduced to computers 30 years ago, but no clients are paying for the kind of time needed to write these proofs. Well, rephrasing; no client of us.
I think there needs to be a breakthrough in the way proofs and software are written; now it's not very practical in most cases.
Yours is a typical "everything is uncertain and hard" excuse.
There are plenty of cases when developers do avoidable things that will almost certainly cause issues. And then those things do cause issues. And then developers change nothing in their behavior, and continue doing those same kinds of things - because they don't care. I see results of this almost every day.
I'm curious as to whether you really believe more testing is the issue? Half the problems on that list are directly related to political/business decisions. Chrome's installer sucks because Google wants to make sure you can install it with non-admin rights. It breaks basic Windows guideilnes because.. fuck you that's why. Ask google. Their war to get Chrome on limited users desktops is a business decision. When you're asked to build a broken thing, more testing isn't going to fix it.
The other issues are easily addressed by stopping to cater to lazy users so much. Do we need yet another bloaty app to do basic things? Look at itunes. Its a monster. I'm not even sure how to get a CSV of contacts off an iphone. In the past this was trivial with any contact manager because the feature was baked in. Now that's a feature for "enterprise admins."
The remaining things on his list are the 'appification of everything.' Everything is now a shitty touch app that's incredibly dumbed down and buggy. Why try hard, especially when you userbase is locked down by 2 year carrier contracts? Or when all their music is trapped in an itunes database that can't be moved anywhere or given to anyone.
Apple won. This is "easy" and "just works." Big buggy apps with dumbed downed features designed to lock user data as deeply as possible. We've entered a new era of vendor lock-in. It the 1980s all over again. We need open protocols to work just enough for web and email. Everything else is up for grabs.
Get used to it, this is what the market has chosen. Meanwhile, I have to somehow train my users on how to use Windows 8's new tablet-based GUI on their standard PCs. This ain't progress. This is fashion.
Wow, congratulations. I think that one post just about summed up everything I hate about modern software.
It's actually gotten so bad now that I've found myself increasingly hacking together my own small apps and scripts to do some simple things that I want because it's often actually easier to build than figuring out how to use some of the software out there. It's actually an even better investment because I know my own stuff will never magically become shittier because of some update that gets pushed out automatically.
I'm not quite sure I agree with you. User data is always accessible - I can get pretty much every aspect of my iTunes library in XML and there are plenty of 3rd party programs that can interpret it. Contacts on your phone usually sync with your PC contacts app (Outlook on Windows, Contacts on Mac OS X) or via iCloud. You could use those apps to export. On Mac, it can be exported as an "archive" which is a bunch of plist XML which is parseable. You don't bulk export directly from your phone because, I don't think too many people have ever asked for such a feature (beyond vCard, which does work easily).
Basically it seems to be sour grapes that consumers are finally getting what they want after 20 years of geek rule... It's not quite the 80s again.
Making complicated stuff work is hard. There is a reason some people design tools to do one thing and do it well - it's easy to be sure it does that one thing correctly all the time and easier to check it keeps doing it.
Maybe we're betting our simplicity on the stack we build upon (I certainly build a lot of simple stuff on top of very tall stacks of mostly simple stuff), I'm not sure there are no surprises hidden in it. However, we should strive for making things (machines, software) that are simple inside. When we do that, it's easier to make the simplicity transpire and become an elegant form-follows-function kind of design. It will not be possible to avoid all bugs, but by making conscious decisions against complicated designs, we may make some lives less miserable.
I'm totally stealing this from a friend, but the single biggest cause of terrible user experience at large companies is the term "workaround." Late in the release cycle, a pretty grody bug comes up, causing the application to hang. Or maybe the installer just plain breaks at some stage. However, the dev team has found a "workaround" for the issue. Run the installer twice, and it works. Back out of the hung screen and try again, because the bug only repros 1/10.
The bug gets punted because it's on a non-critical path, there's no data lost, it doesn't crash the entire application, and there's a workaround, even though the workaround sucks. Next time around, the bug is weighed against new feature work, and judged based on how it aligns with the product's core pillars. Not important enough this cycle, maybe next cycle.
Next cycle comes around, and the team no longer knows how to fix the bug, because it's no longer fresh in anyone's mind, or the person who wrote it doesn't work there anymore. The broken module is now essentially a black box, and the cost of fixing the bug has increased drastically. The bug gets punted again until the next release, because hey, we've got a workaround.
The project will be cancelled before the bug is fixed.
Not all big companies work this way, but enough of them do, or have subgroups within them that do, that it creates usability problems like the ones in the article. It's not that the problems don't get found by QA, it's just that nobody can be bothered to address them.
> The project will be cancelled before the bug is fixed.
it most certainly won't be cancelled, despite multiple farked edge cases, if the critical path is providing business value. the customer increases revenues, the software company turns a profit, the managers and developers get nice bonuses to give their children a nice education, our 401k's get stable returns, the world gets buggy software but not THAT buggy, and everyone is happy except for a few cranky developers who get paid a lot of money to maintain shitty software from 9-5 inbetween disney world trips and cruises.
I meant "the project will be cancelled" in the same sense as "the heat death of the universe will occur." Basically, the problem will persist until either the end of time, or until such a time as that particular component is deemed completely obsolete and replaced wholesale.
I think I read this from HN but I use this as the best example of mission critical software, the Space Shuttle at NASA.
The most important things the shuttle group does -- carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code -- are not expensive. The process isn't even rocket science. Its standard practice in almost every engineering discipline except software engineering.
The article is from 1996 but even then they were far beyond a few K.
"Take the upgrade of the software to permit the shuttle to navigate with Global Positioning Satellites, a change that involves just 1.5% of the program, or 6,366 lines of code. The specs for that one change run 2,500 pages, a volume thicker than a phone book. The specs for the current program fill 30 volumes and run 40,000 pages."
The brain of NASA’s primary vehicle has the computational power of an IBM 5150, that ’80s icon that goes for $20 at yard sales. According to NASA and IBM, the shuttle’s General Purpose Computer (GPC)—which controls, among other things, the entire launch sequence—is an upgrade of the 500-kilobyte computer the shuttle flew with until 1991.
This process results in low bug counts. But, even then, NASA still programs the software to accept patches as they fly.
I don't know how applicable the NASA way is to commercial firms. They have different goals. National Mission Success vs. shareholder returns. The commercial firms are still making money and happy shareholders with a lot of bugs. While a single unit conversion bug on the Mars Climate Orbiter resulted in the loss of a multi-billion dollar spacecraft.
While a system as complex as ACL2, Coq, or Isabelle most likely will have bugs, the really interesting question is if the proof verifier that is run on the generated proof is too complex or has bugs.
In my view, one should preferably have several independent proof verifiers that have been manually inspected for there to be sufficient trust. It is ok if such verifiers are slow, simplistic, and use lots of memory, given that they should preferably be used as a final check that the verification process worked correctly.
A lot of these problems seem to relate to Apple products. Just saying - there are other options out there.
I notice he uses only one open source product (Google Chrome). One aspect of choosing open source is being able to fix problems you care about yourself (in theory at least).
No more "put your bug in here, trust us, we'll fix it". They won't. They'll say you're the only one with the problem. Everyone will be so uninspired they won't report bugs.
That makes no sense. What if I find a generic hardware problem with my laptop? or a general problem with my apartment complex?
If I have a problem on a Mac, I can report it. I will get no feedback, and maybe the problem will get fixed. If it does get fixed, I will get no information about if my bug report led to the fix: the feedback loop is missing - there is no incentive to report a bug.
Then don't use a Mac. With your appartment complex, I assume you'll receive feedback from the owner or eventually you'll move to a more responsive place.
Open source hardware is a problem, agreed - I hope in the future there will be more of it available. Even open source houses, why not. If there is an open source plan for a house, maybe there will be a community fixing common problems with it.
Or maybe better: create a tool for filing bugs with Apple which also files them in an open database. Make the tool super nice to use, the bugs super easy to browse and search (as in SEO), and market the heck out of it.
If it gets enough attention, Apple will have to care.
Isn't that what companies like getsatisfaction provide? How are they doing on the Apple front?
Edit: to clarify, I was under the impression that there are already companies that provide "complaint forms" (bug trackers) for products of other companies. So I was wondering if they provide such a tracker for Apple and how much activity it provides. I thought getsatisfaction was such a company, but maybe it was another one.
Am I the only one who doesn't want to hear feedback when I report a bug?
Seriously, more often than not the feedback is an excuse why they aren't going to fix it. Look, if you aren't going to fix the bug then you aren't; so be it; your choice. But don't tell me your excuse. I don't want to hear it. It will just annoy me and tempt me to get into an argument and waste both our time. Just throw my bug report in the recycle bin and we can both get on with our lives.
(Mind you there has to be a feedback capability for the rarer occasions when the programmer needs to ask for clarification about how to reproduce the bug.)
Public open bug tracking is good, but sometimes the product owner still doesn't care.
My own personal example is Issue 2600 in Android, which hasn't been fixed several years after it was first , and is a big issue for us non-English-character users (particularly the ñ spanish character ).
As a user of software, I get similarly frustrated as the author. ("user" here includes use of third-party libraries to build on) However, developing system-level software, I've come to realise that even if you really, really care about the quality of your software, you can still be bitten by statistics.
Basically, developing error-free software is comparatively easy if your software effectively performs no I/O, that is, it behaves like a program in a computer science paper: read in some data on launch, grind through some computation, emit output, terminate. Barring catastrophic hardware failure of CPU or memory, this is a nicely deterministic programming model. You stand a chance writing correct code.
Throw "real" I/O into the mix, and almost anything can fail in weird ways, and your code has to be prepared for it. Network I/O is guaranteed to fail sooner or later while the developer is using the software. So it usually gets taken into account in some way, usually only distinguishing between "there is no connection" and "there is a connection". There are a myriad of other cases in between that are usually not even considered.
Disk I/O can fail for a variety of reasons. Not just hardware failure; file systems aren't perfect, especially when confronted with power failure, kernel panics, etc. Randomly flipped bits happen. (yes, really)
Not only are there are bugs in the GUI framework you're using, other GUI programs are running at the same time and they can inadvertently interact with your program due to the shared GUI framework use.
Other programs can inadvertently interact with yours in other ways: locked files, claimed sockets, contention for any kind of resource, race conditions, thread/task scheduling - you name it.
Timing bugs are ubiquitous. Everything you do in your program takes >0 time. Maybe on your system, with your data set, it looks like 0. Maybe because it takes slightly less than one video frame's worth of time. On your customer's system, it takes longer. If they click something before your operation has completed, and you haven't anticipated this, your program will fail in weird ways. Where I live, I can't get an internet connection with less than about 80ms latency even to the nearest servers, let alone to North America, where most servers sit (more like 200ms). You wouldn't believe how much software handles this terribly.
The problem is complexity - in many cases, unavoidable complexity, not the accidental complexity us developers keep railing against. Most of these error cases are extremely rare. The thing is, with thousands or millions of people using your software, extremely rare bugs suddenly become a very frequent occurrence!
Yet the tools for dealing with this kind of thing are somewhere between terrible and non-existent. There are some tools for simulating difficult network conditions; those are comparatively easy to make. I'm not aware of similar software that simulates OS API call failures. Or a "file system from hell" that wreaks havoc with your file I/O. Fuzzing a program in such a way would likely uncover countless bugs. valgrind and its myriad of plugins are great, but as developers we almost certainly under-use it.
Developing such tools is obviously expensive, and even they won't catch all bugs. But I'm pretty sure they could reduce the probability of running into bugs by a few orders of magnitude.
Don't even get me started on how programming languages don't help you handle error conditions or timing problems even if you try.
As someone who works on compilers for a living, even “read in some data on launch, grind through some computation, emit output, terminate” is not an easy problem. Regardless of what tools you use, there are no substitutes for testing, care, and rigour. And testing.
I would not be surprised if compilers were the most complex examples of that kind of program in the wild. Still, I would be surprised if automated testing of a compiler was as difficult as, say, test cases kernel-space driver that simulate hardware failure. (this is one example of something I'm currently dealing with) This is probably why compilers tend to have comprehensive test suites, and why drivers (and other I/O-heavy software) usually don't. To be clear: I'm not saying writing compilers is easy; I'm saying automated testing of compilers is conceptually not that hard to imagine, so it gets done. Whereas testing I/O and other external interaction involves ridiculous levels of yak shaving as it has almost no existing tool support, so it doesn't happen. Yet, most of the software we as humans interact with directly is exactly that I/O-heavy stuff.
...Or a "file system from hell" that wreaks havoc with your file I/O. Fuzzing a program in such a way would likely uncover countless bugs....
Though you are probably familiar with them, there are I/O fuzzers like zzuf[0]. I bet it'd be relatively straightforward to write a similar tool that uses LD_PRELOAD to intercept and randomly delay various library calls. Sometimes I'll test my own network software by piping /dev/urandom over netcat:
Yeah, fuzzing stream inputs is relatively straightforward. It's everything else that affects program outcome that's the issue. Trying to implement something like this via LD_PRELOAD manually is going to be a pretty enormous task.
Realistically, you'd have to automatically detect the calls made, for system calls you have ptrace (most commonly used by strace), though I'm not sure how you reroute them. I guess there must be some kernel-side hook. Still, that's likely to be too low-level for GUIs for example. Preloading dynamic libraries like that also only works well on ELF-based systems, other OSes behave rather differently, and if you're trying to test kernel code, it's a whole other problem.
Once you're simulating errors, you have to specify correct behaviour. For stream input fuzzing for security purposes, you're usually just probing for crashes. In the general case, the test framework will need to know the intended outcome of errors.
For either part, I'm not aware of anything existing like this. I'm slowly custom-building little islands of functionality like it, but it's a far cry from some kind of general solution.
417 comments
[ 3.2 ms ] story [ 357 ms ] threadFast, good, cheap; pick any two.
80% of the people only use 20% of the features anyway. And they never see the bugs that drives the remaining 20% of the people nuts.
One thing to add to the gripes re iOS - I've found that it works beautifully when it does, and horribly when it doesn't. His point on notification clearing reminded me of the Mail app when you have connection failures: I had 5 accounts tied into it, and when the networking failed it would throw 2 modal dialogues for each account. The amount of time I spent glued on the spot hammering away at notifications so I could move on felt staggering after a while.
I had a glut of other misc. quirks and persistent crashes that cut through the gloss on the device, this in combination with a string of Windows 7 bad behaviour (started python development, started hating python development) led me to switch onto linux (started loving python development) and a droid handset. Guaranteed they will have just as many warts and bad behaviours, but it feels more reasonable because I'm expecting them, and on linux, have an opportunity to fix them.
There's two aspects to being a "power user" (not entirely but I try) that I could never take for granted - this capacity to fix things that don't work, but also the opportunity to work with the more atomic tools. There's nothing more soothing than stringing commands together, writing a script, or organising things in a text file or database: mostly because if something breaks, I broke it, I can see the breakage, I can fix the breakage. Minor bliss!
Addendum / edit to this to provide context - I think coming from a control systems background has coloured a lot of my opinions in regards to innovation. I've seen fistfuls more value delivered (in this field, potentially applicable to others), by creating small, clean, highly polished, iterative and well integrated systems as opposed to large, sprawling and constantly evolving...messes. The sometimes popular fail first / fail fast / iterate like crazy mantra makes me itch. I've seen successful lean / agile approaches executed that focus on quick delivery without being so flippant about quality.
Absolutely!
But you are not alone on Linux, and in the 'everyone sees this' scenario, be assured someone will be working on it somewhere, or something slightly similar...
Ubuntu actually run a 'papercuts' bug fixing programme designed to get new people interested in developing...
A lot of this is spoken as a total newbie to both platforms and someone who didn't look into them seriously before changing (coming from a long term Windows 8 / Windows Phone / iPhone background).
Androids intents make it feel much closer to a real operating system in the way it allows applications to interact with each other (compare chrome browser integration on android vs iOS). Linux (Mint in this case) feels incredibly low friction when getting started thanks to apt-get, and a lot of the screw ups that I lived with in Windows seem to fail more spectacularly on Linux, with the caveat they can be fixed to the point of being quite polished by digging into configuration or updating libraries.
Under Windows and iOS it feels like you start at 80% working and finish at 80% working. With linux and derivatives it feels more like starting at 65% and being able to tune your way up to 90%. Prefer the latter at the moment.
At the cafetaria here I pay with my bankcard, if I put the card in too soon, the payment never works. I know that the payment device software is clearly broken. The solution: The clerk stops the payment and restarts it if you put it in too soon, or yanks out your card and puts it back in himself.
Good luck explaining that it's broken.
And somehow you left a comment, using an OS and a browser, on a international network, that put it up so everybody in the world can read it, and I read it in a totally different country.
All totally unimaginable for the common folk just 20 years ago.
And all that with huge color flat monitors, optical mice, mp3s playing in the background, wireless networking, and tons of other stuff going on at the same time. Heck, you might just left the comment from your mobile phone, or I might just read it in mine.
How's that for "nothing ever working"?
Wireless is working right now, that's great. It might stop working sometime today. Things like that tend to happen, on every network more complicated than "I'm sitting two meters away from my home router".
That might have been unimaginable 20 years ago, but somehow, things are about as unreliable as they were 10 years ago.
(I have to admit, optical mice and huge screens are nice, though. But expensive hardware with a single precise objective tends to be reliable, compared to software).
10-12 years ago:
1) Windows was Windows ME (not even in the same league as Windows 7)
2) OS X was 10.1 (or before that). Most people still used OS 9.
3) Linux was not quite ready for heavy enterprise use or home use, had worse memory management, filesystem, window managers, desktop environments, drivers and userland.
So, "about as unreliable"? I beg to differ...
Each of the products mentioned are huge HUGE projects layered on top of hundreds of other projects. A browser has a various networking stacks themselves built on OS stacks themselves built on device drivers etc etc. Pick any part and it's literally counting on millions of lines of code to be flawless. Interact across the net and now you need the software on all parts of that network to be flawless as well
Can you name anything with so many parts that just works?
It's possible it could get better but it seems unlikely. Each year the new stuff is built on top of the old stuff making the hole deeper and deeper as we go. That's why a 1.6ghz atom with a gig of ram sometimes feels slower than my Atari 800
A brand new smartphone or a fresh install of Windows always feels like a well oiled machine for the first day or so.
Would you rather be using a modern OS like OS X , Win 8 , Ubuntu 12.04 or would you rather have a rock solid version of Win 95?
I did kind of hoped that when we got an open source Linux desktop, back in the 1990s, that these things might improve. But they did not make it debuggable, even for an advanced user. I can debug hard server stuff, but I have no idea where to start with most desktop software. It didn't help that its all compiled, would be much easier to add sane debug hooks in say Python than in C++ for this type of software. The web at least has got that right, with far better debug tooling than any desktop environment.
Global warming, destruction of nature, loss of liberty because governments we elect betray us - don't worry, somebody else will fix that, probably some Y Combinator startup. No wait, driverless cars are the answer.
Us humans hallucinate in our own private world more than we interface with the actual world. We can and will rationalize anything. Nobody is upset because we aren't really there, or even here. We are off somewhere else, thinking we are smarter than we are and that everything will be okay.
With the terrifying state the planet is in, we should all be upset.
Eh, really?
What I find so amusing about people like you and me (and OP) whining about how imperfect the world is that the world has gotten so much better, even in our lifetimes. And yeah, if you are a white American-born male, it might not seem that way- in fact, the world might not have gotten better for you. If you aren't skilled, it almost certainly has gotten worse for you; you've got to compete against a huge pool of people that were simply not in the running before. But for the masses of humanity that weren't lucky enough to be born an American white guy? eh, I think things are better than they were. And really, things aren't so bad for us, either. Maybe not quite as cushy as they were; but eh, I'm still a long ways from pretending to be Chinese, or even wanting to learn a language other than American English for business reasons. Things aren't so bad, at least from where I sit.
But yeah. Getting upset, first, takes a lot of personal energy; and quite often is dangerous.
more to the point, quite often, it's counterproductive. The food riots all over the middle east? (I'm sorry. Look at food prices[1] Then tell me, with a straight face, that poor people are okay with the cost of living going up 4x, but have a problem with a high-school talent-show quality video. I mean, I guess it's possible that it really is the video? but it sure seems unlikely, compared to the much more reasonable explanation that people get unhappy and violent when they can't get enough to eat.)
I mean, sure, they are upset, it's difficult to afford food. A perfectly understandable thing to be upset about. But, is this going to help them? probably not. I mean, it's going to be bad for us, too... but for us? bad means paying a little bit more in taxes, maybe, or dealing with fewer public services. Worst case, we experience more inflation than we'd like. For them? I suspect it will be much worse. Yeah, getting upset isn't helping them. (One could argue that it's actively hurting them even if we don't retaliate. We are a major exporter of grain and soy. By destabilizing us, they are destabilizing one source of food, and thus driving global prices up further. Of course, especially in the case of Egypt, well, there's something else going on; Throughout history, Egypt has been a major exporter of grain. I don't know what happened to cause that to change, or if our presence in the area has anything to do with it, but it certainly is... an odd situation that Egypt can't even feed itself. It's possible that if they could get us to leave, they would be better off. I'm certainly not in any position to weigh in either way on that one.)
I mean, I'm not saying you should never work to change anything, but quite often? pretending that there is not a problem does less damage than getting upset and 'taking action' without really understanding the situation or the consequences of those actions.
But yeah; all I'm trying to say is that before you "take action" on a global issue where you don't have all the facts (and that is any global issue; none of us have all the facts. On most issues, even if you combined all human knowledge, we'd still have missing pieces.) you should step back, and make sure you aren't firebombing an American embassy, if you know what I mean.
For example, some suggest that part of why agricultural commodity prices are through the roof is demand for biofuel. Sure, biofuel is a great thing- the people working on that are trying to solve important problems that are real problems. But... as an unintended consequence, they are driving up the price of food.
Go look at graph 1 again. god damn. The thing is, for me? And probably for you, grains are so cheap that they could go up 10x without really altering what I pay for my prepared food. I mean, even now, you can get a bushel of soy for $17. A bushel is a lot. like 35 litres. 150 cups. A metric fuck-tonne of tofu. Man, that sounds so cheap to me....
food prices aren't BIG? I mean, they aren't big for you and I, sure, but for most of the rest of the world, there is nothing bigger.
And really? you are seriously saying that the average person's level of personal liberty and human rights is lower now than it was 30 years ago?
Like I said, that might be true if you are white and male and born in the US... or if you are anything and live in the parts of the middle east we are at war with, but for the vast masses of humanity, the world has gotten rather more free. /they/ now can compete with /us/ for jobs, which is an incredible improvement. (well, it's an incredible improvement for them. For the least skilled of us, well, it kinda stinks. Me? I think it makes things a lot more interesting, and it vastly increases my potential customer base.)
As for liberty and human rights, I concur with my sibling poster - the world has been getting BETTER with regards to those things the last 30 years, Americans are the ones that have been escalating the crazy lately.
It's a kind of, sort of our fault situation because as time has gone on we've stopped caring too much about companies sitting down and just going "Lets get this stuff sorted out and fixed, and improved and more awesome", but started caring about "How many features does it have? Can it do X in Y and Z situations?" which is great, it pushes the state of the art forward. I think companies are spending too much time trying to get stuff out the door, instead of spending the time improving what they've got.
But we end up in a weird situation where we actively want companies to stop adding new features, but a lot of us are like magpies drawn to the new and shiny. It sucks, it's their fault for not getting stuff done properly the first time, and it's our fault for expecting a new shiny thing every few months. And "move fast and break things" needs to stop being a thing.
Optimise. Improve.
This is why I was so upset at Sparrow throwing in the towel - they concentrated on one thing, email, and did it better than I'd seen it done before. By specialising they were able to spend the time to get it right.
Look at the iPhone 5 discussions taking place. The most common topic you'll see is: it doesn't have enough new features. That kind of thinking is one of the reasons that refinement doesn't take place as often as you and I would like.
I think from one perspective advertising refinement is perceived as perpetual incompetence with respect to your capability to deliver a quality product. Horrible inversion of logic.
It would actually be a list of things that were wrong with the previous product - so what's wrong with that?
From a literal perspective, not much, but in terms of perception and marketing I'd estimate a whole lot. Each product is still representing your brand and a potential option for buyers. You want to encourage someone to be excited about moving to your new product or platform without presenting the case that the old one is inferior or somehow deficient.
Consider if they iPhone was released with a strong focus on the improvements and bugfixes on the existing features without many new additions. Personally this is amazing, I'd be excited about that, but for many (average joe consumer) people I'd estimate it raises some key questions - why was there so much wrong? What will be wrong with the new one? Why do these products have so many issues?
Consider if iPhone was listing fixes and corrections and phone x was advertising all of their new features and updates with no mention of any rectification - personally, I'd be tempted just to pursue the one that was "best". Especially in a flooded market where it's hard to make a legitimate choice, it's much easier if one thing looks broken and one thing looks wonderful.
Most companies are really just going through the process of iterative refinement but I think you need the feature icing to sell them to people, or really: to take the focus off of the fact the product needed rework, and on to the fact there's super super shiny new things! You quickly forget to engage your critical thinking when being dazzled with this kind of thing.
To be hyperbolic with the example - consider cars. When a manufacturer releases a new model and advertises the safety and performance enhancements, it may be likely that they were addressing issues with the previous model, but presenting them as new functionality. This is much more appropriate for a brand than saying "we've addressed the issue with our brake and suspension package that was contributing to people losing control of the car" or "we've redesigned the porting of the heads on the engine so it's not running as inefficiency". If you have the choice between the perceived perfection of one brand versus the other admitting a few people wound up wrapped around trees and they needed to iterate their design (even if both companies are following exactly the same process), it becomes a pretty easy choice, right or wrong.
I know "make something small but better" is a nice motto, but will it work for Apple, Microsoft? Heck, even for a proven startup's product, is it a good long term strategy, or a long term gamble?
There aren't much examples of 37Signal's model of "don't implement features but keep polishing" approach.
Having said that, I'll point out that Sparrow (like every other non-webmail client I've used) seems to fall over when dealing with massive volumes of email. I'll get into the office with 500 new emails, skim and archive 490 of them over five or ten minutes or so, and then a few minutes later half of them will just show back up. Overall still a very solid product, so I too was disappointed to see it eaten up and killed off by Google.
Companies like Nokia made some great phone products that did the one thing (well, two if you include SMS) remarkably well in small packages, that had fantastic battery life.
But then the iPhone, and Android, came out and virtually no-one was interested in the old, reliable phones anymore. They wanted the latest, shiniest gadget that they could get their hands on, regardless of how good/poor it was at doing the basic job of making calls.
And I'm a little unclear why you feel like playing "gotcha" with me here anyway...
My point isn't an attempt at a gotcha - it's a comment that if this is how you really feel, then the only way that companies are going to take any notice is by putting your money where your mouth is and buying the more robust and optimised versions of those things that do the basics well rather than buying the models with the advanced features.
And it's not an attack on you specifically - it's something I see time and time again. My parents complain that the new TV they've bought, which is internet-ready, has apps etc, is too compicated for them to use. Meanwhile the old TV that did nothing more than show TV programs got thrown out a couple of years ago, despite still working fine, because they wanted the new model. They complain that the new version of Office that they use is too complex, but they've still got the Word 95 discs sat around somewhere (and they've rarely got any need to share documents with anyone else). And they are far from an isolated example.
Some people want the shiny new stuff - I know I do - but I accept that if I'm going to be on the bleeding edge of tech, I'm probably going to have bits of it that simply don't work properly. And as long as both you and I are out buying these things, rather than the boring but stable stuff, then this is what the market is going to build for.
Every company is different, every product is different, every user is different. Attempting to speak in absolutes like you are simply doesn't work.
As for your suggestion I forgoe a decade of advance in phones... uhh no. A moderately buggy phone from 2012 is still a thousand times better than your puritan "calls and texts only" ideal phone.
The thing is, it could be much better with a little attention to detail.
If that's not what you meant, and instead you were trying to say "I've been thinking for some years now, that a little bit more time was spent on fixing existing features rather than always focusing on new features", then I'd probably agree. Although I would say that most companies are, in reality, already doing this and their doing it to the level that they believe the market is really prepared to pay for.
> A moderately buggy phone from 2012 is still a thousand times better than your puritan "calls and texts only" ideal phone.
Indeed it is - but that is far from the message you seemed to be saying in your first comment.
Despite me pointing out that I was simply replying to your black and white statement ("I wish everyone would stop implementing features and perfect the ones that are already there"), and pointing out that I would agree with a far more nuanced position, you're continuing to pretend that that I'm the one who was trying to make it black and white.
I'm guessing from this that you're not actually massively interested in having an adult discussion on the fact that despite continual complaints from consumers about too much complexity, not enough focus on quality etc, the actual purchasing behaviour of those same consumers is driving companies to focus far more on new features than on perfecting their existing ones.
You don't need to abandon a decade's worth of advances to ask that, for example, the Google IME team all get on the same page (Chinese, English, Korean and Japanese IMEs all work slightly differently and appear different) before implementing say... face unlock.
I'm a big fan of single-purpose tools, but if you tried to have EVERYTHING in your life a single purpose tool, you'd need a shopping trolly to carry it all around with you.
Do you think that the average punter is more likely to buy their next phone based on new feature like face unlock or because they've fixed an occasional bug in mail sync?
Reality is dirty, everything tries to break down all the time, hindered by the traces of its past, and the ambivalence of its future use. We make stuff dreaming of a prefect neat existence. This keeps us going, like moths around a light bulb. And we should keep on doing this nevertheless.
Every computer environment is layer upon layer of kludges. There is shit all the way down.
You missed the AMAZING INGENUITY and BRILLIANCE that is also all the way down.
I do agree with you in this, also -- the hardware and software combination of a single PC or smartphone is, I guess, among the most complex systems humanity has built, and in such a short time frame.
While my post was mostly me venting (bad Monday, frustration with people/clients/spouse/stuff in general), I have to say that I still agree with Scott. Too often are we putting up with things not working. I use Android, Gmail and Google Calendar. Yet, when I get a calendar request, it shows up in the official Gmail client on my Android phone as
If I click "view", it opens up in a text editor. This is not helpful at all. Does nobody at Google ever get a calendar request to their phone? The only way for me to respond to such a request is either to get to my computer and open it in web mail, or call back and ask what time the meeting is.Whenever a family member asked me about something failing in a similar manner, I used to feel slightly attacked: This is my line of work and major hobby, and I know that the reason shit fails is, well, shit is hard. I would perhaps try to explain the probable cause and so on, but to what avail? It still doesn't work.
But now, I rather shrug and say yeah, I know, it sucks. It happens to me too, all the time. I just get used to it, and deal with it. Isn't that all we can ever do, after all?
Lately, I've started trying way harder to remove complexity. I constrain myself on purpose, I get rid of software and file formats, and basically, the last thing I ever want to do is to add a new piece of software. If I am convinced I need a new piece of software, it has to be implemented with minimal change to the rest of the system.
Well, that was a bit of a rant. Anyway, in no way do I mean to disrespect any of the programmers who built this ingenious, brilliant piece of shit. I feel for them and, well, the brilliance sometimes shines through. We're still running the world's financial, communications and distribution systems on layers of shit.
Don't look down.
A, thanks. I mostly take a contrarian position when I comment, because at things I already agree with I don't feel the need to comment on (yeah, have the silly urge to correct "someone wrong on the internet" as my motivation).
>This is not helpful at all. Does nobody at Google ever get a calendar request to their phone? The only way for me to respond to such a request is either to get to my computer and open it in web mail, or call back and ask what time the meeting is.
Yes, that's a perfect example of what the article SHOULD BE talking about (far better than the examples in the article). With those kinds of things, I agree, you tend to see neglect like this in all apps.
I just disagree with the particular examples given in the original article, which are far more complex and bug-like, and most of all with the notion of the article that because of those bugs (syncing, FCP crashing, etc) "everything is broken".
Some of the "layers of shit" (e.g, a pet peeve of mine, the traditional UNIX application installation directories and standards such as /usr/bin etc instead of self-contained, versioned, app directories) have historical reasons, and not necessarily incompetence, and it's very difficult to remove them without major financial and time investment.
Or would that so feature-poor/expensive/slow-moving/low-status that no-one would use it?
They will answer Mobile Me, iTunes, Snow Leopard, iCloud, Genius, Ping, iPhones unable to call or any other thing which at some point was delivered in such a shoddy state that it was hard to keep believing Apple was any different than the other tech companies.
Anyway, this is not another Steve Jobs is dead, Apple is going to heck-post. The decay began a long time before that.
I rarely get problems of that magnitude. The only unreliable thing I have is my ADSL connection and that's not a problem as I can use my phone as a backup.
I went from struggling to read a few pages of a book or write some code every evening to currently working on postgrad eduction, other certifications, volunteering, etc. It's not as literally simple a transition (lots of changes in motivation and practices in the mix), but every single device comes with a level of cost in terms of time and cognitive "energy". Stack them all up and it turns into a pretty big percentage of your capacity each day.
Your amazing, multi million lines of code Windows desktop, the work of some 1000 people or more, has a problem with indexing.
The protocol and apps that connect you via email to everyone you want, free, globally and instantly, sometimes loses a mail. Or the UI is slow to load your new messages.
A program with which you can do on your laptop what it took huge teams, million dollars of equipment, and professional expertise to do (FCP), has a crashing bug in some particular action.
The program that lets you talk to everybody on the planet, instantly, with video, and paying nothing, has a badly designed UI.
etc...
Yes, I can see how "everything is broken".
Because, when we didn't have any of these, when 30 years before you had a rotating dial to dial numbers on your phone that only called landlines and cost mega bucks to call internationally, when you had MS-DOS as the most prevalent desktop OS, when 20MB was a huge disk in a desktop system, and before something like video chat was only possible in huge organizations with special software, everything was perfect...
Wanting to improve things? Fine.
Not understanding the complexity and magnitude of the technical achievements you use everyday? Bad.
Your incredible display, which somehow manages to use liquid crystals to display beautiful 1080 HD video develops a jitter and bright line down the middle after a month.
The machine gun which lets you launch tiny projectiles at speeds high enough to kill a person sometimes fires rounds without you pulling the trigger and causes a casualty.
...
Yes, the technology is incredibly complex and represents a huge transformation in the way we do things, but a customer doesn't and shouldn't need to understand that, and certainly shouldn't be offered the complexity as an excuse for it not working correctly. Given the fact that most (all?) of the products mentioned in the post have some kind of price associated to using them, its not unreasonable to expect they work correctly.
This is not to say that the people who made the tech are at fault per se, just that the customer is not at fault either for complaining when things dont work.
In some ideal world, where you can have things with MILLIONS of moving parts and TRILLIONS of states, designed by mere mortals and still have them be faultless, yes.
In the real world, the customer will have to settle for things not being 100% perfect.
He can now do things unheard of even in science fiction 20-30 years ago, and takes for granted things only appearing like 6 years ago (e.g YouTube).
>Given the fact that most (all?) of the products mentioned in the post have some kind of price associated to using them, its not unreasonable to expect they work correctly.
I think that, yes, it is unreasonable. That you pay for something doesn't mean anything related to it's error margin. You cannot demand the impossible just because you paid for something. It's like saying: "hey, I paid for this car, why does it is disfigured when it crashes and can kill me?".
Consumer products (non digital) break all the time. You can even pay top dollar and yet have crap food served to you. And all those are far less complex than software.
>but a customer doesn't and shouldn't need to understand that, and certainly shouldn't be offered the complexity as an excuse for it not working correctly
It's not an excuse - it's an explanation. These things are complex, and complex things sometimes fail. The average user can be forgiven for not really appreciating this, but lack of knowledge of the nature of complexity doesn't magically make it disappear.
Of couse companies could take the NASA approach of spending huge amounts of time and money on formal requirements/analysis methods, building massively fault-tolerant solutions etc etc, but I doubt there's a vast amount of users out there willing to buy tech that's 5 years behind cutting edge, and costing many times more, simply because it (almost) never fails.
My response to your comment is the same as the previous one:
>My argument is not that consumer products should be perfect; it is that when consumers see deficiencies in them which could reasonably be fixed, they have every right to complain. In fact, they should complain because it will help make things better.
Cars stop moving on a fairly regular basis, often as a result of the comparatively simple mechanical side of things. In the case of Toyota a couple of years ago, they didn't stop moving at all when the driver wanted them to.
The other examples you gave have happened too - this despite the rather more critical nature of the machine gun issue and again its relative simplicity compared to, for example, a modern phone.
I've got no problem with people calling out where they see problems, expecting someone to at least take their complaints seriously, and in a lot of cases expecting the company to do something about trying to resolve it.
But that's not really the message I took from the article - the idea that that these problems are caused by lack of passion or quality on the part of the people making this stuff rather than being an almost inevitable result of the complex nature of these systems.
TBH, I'm not even sure I buy that it's really that much of a problem. Almost everything isn't actually broken - the vast majority of our tech works remarkably well the vast majority of the time, and I prefer having tech that mostly works and is both available and affordable than having the same tech that will work perfectly when it's delivered in 5 years time at a vastly increased cost.
"Is this a speed problem? Are we feeling we have to develop too fast and loose? Is it a quality issue? Have we forgotten the art and science of Software QA? Is it a people problem? Are folks just not passionate about their software enough to fix it? I think it's all of the above. We need to care and we need the collective will to fix it."
I.e, he attributes things to lack of: care, passionate people, the forgotten art and science of QA, etc. Which is BS. There will ALWAYS be many bugs and problems in systems that large in scope and complexity.
And it's not because "the guys that designed, say, GMail or FCP (that he complains about) do not care, or lack passion, or have forgotten the "art and science" of software QA.
Plus, the kind of bugs he describes are not that important compared to what we have actually achieved and DOES work.
FCP crashing when you "scroll too fast" while rendering?
Give me a break, these linear editing systems cost tens of millions of dollars, took half a room, and didn't operate in real time just 15 years ago. Oh, and had just as many bugs, and you needed support staff from Avid or whatever to come over to set them up. Now thousands of people all over the world edit their films and documentaries in their laptops.
That's a lame excuse. Who cares that we are better than 15 years ago, the point is that we have lots of (seemingly) low-hanging fruit that stays there for plenty of releases and that nobody cares enough to fix, because "bah, it's not that important."
The problem is not that the bugs exist, but how fast and how well they are being solved.
Well, this is my other pet peeve, people not understanding the notion of "opportunity cost".
>the point is that we have lots of (seemingly) low-hanging fruit that stays there for plenty of releases
The key word here is "seemingly".
Do you really think that the guys as Apple/Google that pull all-nighters and work themselves to death to finish iOS/Android don't have "enough passion to fix problems"?
Or do you believe that if they took their sweet time they would have fixed every "low hanging fruit"? Even a low hanging fruit can add a couple of days to a month to a project, or delay other, more important features and/or fixes.
"Go attack all the low hanging fruits" is a meaningless proposition. Some projects you use are open source. Why don't YOU go attack them? Who is gonna make those "low hanging fruit" interesting for a volunteer to work? Who is gonna make them profitable for a for profit company, so that it doesn't die in the market while fixing them?
Mozilla tried to build a better browser. They addressed all the low and high hanging fruits.
What happened?
It took them 5 years to ship something that worked kinda OK, by which time the company had died, and the market share went to IE. And even those releases 5 years after the new code started had lots of problems. Eventually they betted on the more minimal Firefox instead of ever perfecting the full blown Mozilla browser/suite. And it's still not perfect.
Result? Besides the parent company dying, they haven't got that old high Netscape market share back even now.
>Who cares that we are better than 15 years ago
I, for one, do.
The bottom line is that I feel it's disrespectful to a user to tell him to put up with the annoying "life-wasting five minutes at a time" bugs, only because 60 years ago he would have been playing cards over candlelight instead of trying to sync his iTunes library.
It's like starting to pierce people with a pin and when they complain say "be grateful this is not the medieval times, because the pin would be a broadsword and you'd be already dead."
It's just using past progress to justify current mediocrity. We should accept that those bugs that affect UX are indeed very important, and not dismiss them.
Have you even thought how much better things would be if people actually gave this a higher priority?
About Mozilla, there are lots of things that went wrong, and not many of them were due to fixing UX annoying bugs.
Who defines it? The business. Opportunity cost is a business notion (even if that business is making a non for profit OS software).
>The pride on creating a mighty fine piece of software should do it. I actually DO try to attack all the user facing (annoying) bugs on my projects, always. I may or may not be successful at that, but I'll never use "we are much better than 15 years ago" as an excuse.
So you "may not be successful at that". So why don't you stop 100% whatever else you're doing until you are successful 100% at that?
Because, obviously, you also need/want to do other things that you consider more important.
What I'm saying is: give the same courtesy to the makers of software you use.
>The bottom line is that I feel it's disrespectful to a user to tell him to put up with the annoying "life-wasting five minutes at a time" bugs, only because 60 years ago he would have been playing cards over candlelight instead of trying to sync his iTunes library.
Actually I find that the user throwing a fit is immature and disrespectful to what he is offered.
And you can see that sense of entitlement all too often in OS projects: "your software doesn't do X, or has the Y bug, it is crap, etc".
There are programmers that want to fix bugs, and programmers that just don't care. But it's not like the "just don't care" is somehow the prevalent attitude, or that bugs that are not fixed don't have a reason behind them not getting fixed (even if it is the simple: "didn't get to it, yet").
Neither are all those bugs "simple UX bugs" as you seem to imply, meaning that they have no backend or deep dependencies, or are trivial to fix. The bugs the article describes for example are syncing bugs, or bugs in working with video streams a non linear video editor. Those can be very complex and subtle, and may not even appear except in some very specific setups.
>It's like starting to pierce people with a pin and when they complain say "be grateful this is not the medieval times, because the pin would be a broadsword and you'd be already dead."
No it's not like that at all. For one, in this example you compare small pain now to bigger pain in the past. But what people get now is much more features (with some bugs), compared to less features in the past (with some bugs). So, if anything, it's exactly the opposite.
I do think that "don't care about UX bugs" is a prevalent attitude among software developers. I may be mistaken, but let's not forget you even used it as an argument: "those bugs are not that important", which is what compelled me to reply.
I believe that death by a thousand cuts is worse than death by a single blow, each time these bugs occur make a little cut.
And of course some of them might be devilishly complex or E_NOREPRODUCE, but I believe they are pervasive mostly due to the industry being focused on having more features before stabilizing old ones, because, you know, those bugs aren't that important.
(Hint: Multiply 5 minutes wasted by an annoying bug by 12000000 users and you have a million hours down the drain, each time)
Then re-read your response and see what a defensive crouch you immediately took. How that immediate defensive reaction led you to miss these points. Crying "complexity!" for things that don't work is not a solution. Time, money, education and understanding are required to implement a solution, and I believe that Scott is explicitly calling for the latter and implicitly calling for the rest.
"Calls to action to do better" are a dime a dozen.
You can get them in $5 self-help books, motivational posters and bs marketing gurus. For all I know, they come free with Cheetos.
The problems he describes are not because of some "lack of craftmanship". They are inevitable in large scale, enormous complexity systems, that also have to SHIP some day. Things that CAN get fixed, ARE getting fixed.
>Time, money, education and understanding are required to implement a solution, and I believe that Scott is explicitly calling for the latter and implicitly calling for the rest.
Saying that "Time, money, education and understanding are required to implement a solution" means absolutely nothing. At best is a platitude that goes without saying.
Do you or Scott thinks that the major software players do not spend time, money, education and understanding on what they are making?
Microsoft, one of the software makers he complains about (and he knows internally), spends tons of money on testing and QA. And it has some of the top minds in software engineering. Ditto for Apple, ditto for Google.
Examples:
My desktop environment on my laptop is Linux with, 99% of the time, just a bunch of xterms and a browser (without extensions... they tend to crash browsers).
I installed exactly 4 Android apps on my phone (after flashing it to cyanogenmod to get rid of the bloatware): gmaps, youtube, barecode scanner app, some app to write notes on the home screen (NotesWidget). Everything else sucks and is a waste of my time. But even the dead-simple NotesWidget app author managed to mess it up with enough bugs that I am considering writing my own(!) I have tried at least a dozen other notes-taking application and am not satisfied with any of them.
I don't maintain a music library. Sync'ing music across multiple PCs, phones, other devices, etc, suck. Personal libraries "in the cloud" don't work because I am not always online. I just listen to satellite radio in my car.
I own no TV, no game console, no tablet.
And yet, I am a tech enthusiast. I accept a little "complexity" where it makes me happy: I program GPUs/FPGAs, I have a home theater set-up at home, I maintain my own website/blog on colocated servers, etc.
> Sync'ing music across multiple PCs, phones, other devices, etc, suck.
Was thinking the same but I had to do it, because I need a back-up and I need my music at work too. The only sane way: have proper files half-manually arranged in directories synced with a real solid linux tool (unison). Same for pictures.
What I want to emphasize here is that the current trend against files is a disturbing regression, and can only end in a complete mess or loss of the things you own. I have kids pic in my folders, and I owe to my kid to still have them in 20 years, if nothing else.
This discussion reminds me of something weird that occured to me when I was following lifehacker: it had so many advices and nice tricks and apps you should install to your system, and at the same time was very voical against the bloat and the clutter.
My solution to this would just be a dropbox folder full of MP3 files and a vlc playlist file. I don't use any monolithic player/organiser of music like iTunes or WMP but too a lot of people it seems like it has to be iTunes.
People who are "into" music and have favourite artists that they are very loyal too or who are looking to discovered unsigned or indie artists are not going to want to be restricted to whatever is in the Spotify catalogue.
Personally I'd say around 50% of the music I want to listen to is available on Spotify. There's also a fair number of "big name" artists who's music isn't licensed to them.
The solution for a lot of people seems to be to simply use YouTube as their music player since pretty much anything seems to be available there. On the other hand I'm not sure what the legality of this is.
Pretty much all the music on youtube is illegal...
People's desktops had all kinds of weird hacks in it, tweaking every imaginable bit of appearance, user experience and features.
But I think we all came to conclusion that it does not pay off. Yes, your 3rd party file manager is much more powerful but does installing it on every of your PCs in life pay off? It does not.
The whole experience becomes much more generic and throwaway. Yes, I tune some programs, but I'm ready to leave the whole setup at any moment and start with a blank screen again - and I actually have to do that every 2-3 years.
No longer I use dozens of programs and have 5 DEs installed but just a few and exactly one.
I just keep a git repository that contains my dotfiles, /etc and the output of 'dpkg --get-selections'.
It's a perfectly legitimate position, but it's not really helping progress, is it?
Some of these problem reports are just going to written by people who are all doing something wrong. Others might be legit bugs.
I can't think of any technology that I own that doesn't have some issue that drives me nuts.
I have basically standardized on Pidgin, Firefox (minimal extensions), emacs, org-mode, and a terminal program. At home, I use Mail.app and the OSX contacts. I'd like to move them out to emacs though. :-)
If consumer software companies were working more like, say, people working on Curiosity (Mars' robot) or aircraft navigation software, you could have a phone that does much less but without bugs.
The reason why it is this way is because people usually prefer to cope with minor bugs that giving up on features. Plus, when you buy a product, you usually know the list of features but not the list of potential bugs.
So you can make a company that sells phones with 0 bugs, with a 2004 set of features. Or an OS that focuses purely on providing a bug-free experience, but 5 years late.
Not sure all that would sell well.
Sync software usually takes a conservative approach to deleting or merging records, and leaves duplicates lying around rather than risking deletion of vital user data. This is a good thing. What's bad is that the tools for housekeeping -- merging and deleting duplicates -- are generally rubbish. (I have the same problem with my phone's address book: masses of duplicates due to sync processes that conserve stuff. And trying to get rid of them using the tools provided turns out to be a tedious pain in the neck, requiring multiple mouse-clicks or focus changes per record.)
Further down the list we get into identity management issues. Nobody seems to have a really good handle on how we manage identity across multiple machines, much less how we manage esoteric stuff like family relations for delegating access to photos or music purchases or whatever.
The tradeoff is a more reliable "less messy" world, but much less innovation.
This doesn't mean that software requires less QA or design, just that it's a trade-off of two different modes of operating.
Sync is a fundamentally broken.
The only solution is to switch to technologies where merging data is a primary core feature. Thus why I use text files and git to manage the vast majority of my data.
The sooner people realize that sync isn't fixable (or a good idea in many cases), the sooner real solutions appear.
Yep. It's weird that everything is built around just one button that says "Sync", when there are two different directions involved.
Either you want to save the state of whatever device you're currently using, or you want to revert it to the state stored in the cloud.
Export <--> Import, pretty much.
'sync' somewhat makes sense, but two sync options labelled easy to understand would go a long way to clearing this up, but... would likely introduce other issues as well.
'sync' works fine, except for when it doesn't. :/
Does it do offline sync with multiple users whose changes may have different priority?
How about if time isn't set properly between multiple devices?
How about a multi-way modify/delete/rename where two records are given identical keys on more than one system, then both systems are reconciled?
I really need to write up a "Sync Gauntlet of Pain" that shows how sync implementations are incapable of making correct decisions, as they just don't have enough information, and giving them more information may not help.
Yes it does offline sync with multiple users. Changes aren't prioritized but you can configure what it does with conflicts (merge if possible, discard, or leave the conflict).
Time synchronization between multiple devices has been a solved problem for years. Not worth worrying about.
Creation of identical record keys — while theoretically possible — really never occurs in practice.
This looks like a really good system, and far more transparent in how it works vs. the "Black box" approach most systems use.
The solution would have to be to store everything in ascii formats (probably taking a hit in terms of filesize and performance) and get everyone to understand the ascii representation each of these data formats and how to merge them effectively.
The alternative would be to build a diff tool for every binary based format out there.
The simplest solution would simply be to implement locking on everything and have one authoritative copy. So you can have your data on any device you want and share it with as many others as you want but only one person/device can have write access at any given time and can only have that once they have updated to the latest version of that rescource.
Many of the same methods can be applied to other types of synchronization, but it's more effort than most people can spare when they're in a hurry to get something released.
It's for this reason I've been keeping my eye on Rich Hickey's Datomic. It's not open source or free, but the idea of immutable data (everything is attached to a timestamp--yes, everything), seems intriguing.
We controlled the code and data 100% on both sides and I still never got it working really well.
I have a business contact on my iPhone that has a contact photo of one of my relatives. I certainly didn't set it this way, but I have no idea how this happened. Is it something that my iPhone did? Is it something that happened at Google (it's a Google contact)? Is it something that my Windows 8 contacts app did (syncs to Google contacts)? I don't know, and even if I did, I don't know if I'd be able to fix it.
Frustrating. We sandbox our applications, and the success of the iPhone shows that this is something users want. Why can't we sandbox the other parts of our computers? Sure, I could "delink" everything and maintain it all myself, but I wish it wasn't so "all or nothing".
I work for a hardware company. Bugs are really, really, bad. If we find a hardware bug in real silicon, at best, we catch it the moment we get the first chip back, and it means that we have a multiple month delay as we fix it and tape out a new chip, not to mention the cost of throwing away all of the partially fabbed chips we've got, plus the multiple million dollar cost of a new mask set. At worst, we have a recall [1]. We take testing very seriously, and we do a lot more formal verification than most software companies.
The only things you can be sure about are things that have been formally verified [2], and the list of things that you can formally verify is tiny. We formally verified our adder. It took months. Then we did the multiplier, which was much harder. It took about the same amount of time because of the experience we gained doing the adder, but it wasn't easy. Division took a lot longer, even with the experience of doing addition and multiplication. To think that we can advance the state of the art of "things that work" from something like a multiplier to a complex piece of software with "care" and our "collective will" seems overly optimistic.
Everything's going to be broken for the foreseeable future. Putting more effort into testing and less into features is a difference in degree, not in kind. It won't even prevent articles like this from being written because, if all you want to do is find ten bugs in all the software you use, that's still going to be trivial. Considering how much progress has been made in formal methods since 1970, I expect that finding 10 annoying bugs in all of the software I use will be trivial for my entire lifetime.
[1] Well, you don't have to do a recall. AMD had a hardware bug that could be fixed by a patch that degraded performance by 10%. Sun famously didn't include ECC in their L2 cache, which resulted in transient failures for a number of customers, and they made customers sign an NDA before replacing their parts. Guess how much people trusted AMD and Sun afterwards?
[2] Even then, you're never really sure. How do you know the formal verification process itself isn't buggy? It's turtles all the way down. I know some folks who were trying to build a formally verified OS, and they stopped using ACL2 after discovering a few bugs in it. After all, how can you trust your proof if the proof system itself has bugs? ACL2 is old and crusty, but that's precisely why it's used for more hardware FV than everything else combined, outside of Intel and IBM (both of whom have their own, excellent, internal tools). It's old enough to have great libraries. There are newer systems that have better architectures, but they don't have anything approaching the same level of library support for hardware. Yet another tradeoff of time to market vs. correctness. It can't be avoided.
Say you're an engineer who's worried that ACL2 is too buggy for your company to use. You tell your manager. She points out that maybe five ACL2 bugs are discovered every year, and they get more minor each year, as the system gets cleaned up. Moreover, none of the bugs discovered in the past three years have affected any of your proofs, and you wouldn't expect them to have an effect on any proof techniques you're going to use. So you stick with ACL2. And, because you do, there's a tiny risk of a bug. What does this example have to do with the original post? Bugs come from making little decisions like this. No single decision is sure to cause a problem, or (in a company that's serious about testing) even ...
Reading through Scott's article, he points out that it's not uncommon for an issue to be raised by many users and ignored by the product owner (my personal pet issue at the moment is Google Calendar no longer allowing me to accept invites sent to non-GMail addresses).
It might not be cost-practical to fix issues that affect a small section of your audience, but I'd like to think there's a certain qualitative aspect that comes into play, and if the issue affects 'n' people it should get a banner regardless of whether 'n' is only a minute percentage of your audience.
We have many new shiny FM tools now, though, that are far closer to regular programming languages. In particular, Agda, Coq, Isabelle are fairly easy to pick up for people with an FP background (rather than a formal methods background).
The breakthroughs in SMT solver performance have been astounding to watch, and their use for "brute force" FM is certainly growing.
Of course, verified code is still many times the cost of unverified code, but the gap is coming down.
Perhaps things have changed now, but previously MS had a setup with 2-4 testers per one developer whereby latter would churn out code as fast as he can (of a respective quality) and testers were expected to identify critical bugs so that the dev can plug them, in the same speedy manner as he'd code the original. I had few close friends work for Microsoft in the 90s and the impression I formed after chatting with them was that the MS products routinely were something that was hacked and hammered into a state of not crashing too frequently. So while Microsoft might have a strong focus on testing, it was used to be completely misplaced and misguided.
I studied in Eindhoven under a pupil of Dijkstra and my father studied under Dijkstra; formal methods are kind of a natural thing for me since I was introduced to computers 30 years ago, but no clients are paying for the kind of time needed to write these proofs. Well, rephrasing; no client of us.
I think there needs to be a breakthrough in the way proofs and software are written; now it's not very practical in most cases.
There are plenty of cases when developers do avoidable things that will almost certainly cause issues. And then those things do cause issues. And then developers change nothing in their behavior, and continue doing those same kinds of things - because they don't care. I see results of this almost every day.
The other issues are easily addressed by stopping to cater to lazy users so much. Do we need yet another bloaty app to do basic things? Look at itunes. Its a monster. I'm not even sure how to get a CSV of contacts off an iphone. In the past this was trivial with any contact manager because the feature was baked in. Now that's a feature for "enterprise admins."
The remaining things on his list are the 'appification of everything.' Everything is now a shitty touch app that's incredibly dumbed down and buggy. Why try hard, especially when you userbase is locked down by 2 year carrier contracts? Or when all their music is trapped in an itunes database that can't be moved anywhere or given to anyone.
Apple won. This is "easy" and "just works." Big buggy apps with dumbed downed features designed to lock user data as deeply as possible. We've entered a new era of vendor lock-in. It the 1980s all over again. We need open protocols to work just enough for web and email. Everything else is up for grabs.
Get used to it, this is what the market has chosen. Meanwhile, I have to somehow train my users on how to use Windows 8's new tablet-based GUI on their standard PCs. This ain't progress. This is fashion.
It's actually gotten so bad now that I've found myself increasingly hacking together my own small apps and scripts to do some simple things that I want because it's often actually easier to build than figuring out how to use some of the software out there. It's actually an even better investment because I know my own stuff will never magically become shittier because of some update that gets pushed out automatically.
Basically it seems to be sour grapes that consumers are finally getting what they want after 20 years of geek rule... It's not quite the 80s again.
Apple uses a lot of sqllite and xml for your user data. I'd be curious as to what part of your data you are unable to get access to?
Making complicated stuff work is hard. There is a reason some people design tools to do one thing and do it well - it's easy to be sure it does that one thing correctly all the time and easier to check it keeps doing it.
Maybe we're betting our simplicity on the stack we build upon (I certainly build a lot of simple stuff on top of very tall stacks of mostly simple stuff), I'm not sure there are no surprises hidden in it. However, we should strive for making things (machines, software) that are simple inside. When we do that, it's easier to make the simplicity transpire and become an elegant form-follows-function kind of design. It will not be possible to avoid all bugs, but by making conscious decisions against complicated designs, we may make some lives less miserable.
The bug gets punted because it's on a non-critical path, there's no data lost, it doesn't crash the entire application, and there's a workaround, even though the workaround sucks. Next time around, the bug is weighed against new feature work, and judged based on how it aligns with the product's core pillars. Not important enough this cycle, maybe next cycle.
Next cycle comes around, and the team no longer knows how to fix the bug, because it's no longer fresh in anyone's mind, or the person who wrote it doesn't work there anymore. The broken module is now essentially a black box, and the cost of fixing the bug has increased drastically. The bug gets punted again until the next release, because hey, we've got a workaround.
The project will be cancelled before the bug is fixed.
Not all big companies work this way, but enough of them do, or have subgroups within them that do, that it creates usability problems like the ones in the article. It's not that the problems don't get found by QA, it's just that nobody can be bothered to address them.
it most certainly won't be cancelled, despite multiple farked edge cases, if the critical path is providing business value. the customer increases revenues, the software company turns a profit, the managers and developers get nice bonuses to give their children a nice education, our 401k's get stable returns, the world gets buggy software but not THAT buggy, and everyone is happy except for a few cranky developers who get paid a lot of money to maintain shitty software from 9-5 inbetween disney world trips and cruises.
The most important things the shuttle group does -- carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code -- are not expensive. The process isn't even rocket science. Its standard practice in almost every engineering discipline except software engineering.
http://www.fastcompany.com/28121/they-write-right-stuff
The Space Shuttle went up the first time with a few K of core memory. The software effort was really pretty trivial compared with systems today.
"Take the upgrade of the software to permit the shuttle to navigate with Global Positioning Satellites, a change that involves just 1.5% of the program, or 6,366 lines of code. The specs for that one change run 2,500 pages, a volume thicker than a phone book. The specs for the current program fill 30 volumes and run 40,000 pages."
I don't know how applicable the NASA way is to commercial firms. They have different goals. National Mission Success vs. shareholder returns. The commercial firms are still making money and happy shareholders with a lot of bugs. While a single unit conversion bug on the Mars Climate Orbiter resulted in the loss of a multi-billion dollar spacecraft.
In my view, one should preferably have several independent proof verifiers that have been manually inspected for there to be sufficient trust. It is ok if such verifiers are slow, simplistic, and use lots of memory, given that they should preferably be used as a final check that the verification process worked correctly.
I notice he uses only one open source product (Google Chrome). One aspect of choosing open source is being able to fix problems you care about yourself (in theory at least).
No more "put your bug in here, trust us, we'll fix it". They won't. They'll say you're the only one with the problem. Everyone will be so uninspired they won't report bugs.
If I have a problem on a Mac, I can report it. I will get no feedback, and maybe the problem will get fixed. If it does get fixed, I will get no information about if my bug report led to the fix: the feedback loop is missing - there is no incentive to report a bug.
Open source hardware is a problem, agreed - I hope in the future there will be more of it available. Even open source houses, why not. If there is an open source plan for a house, maybe there will be a community fixing common problems with it.
Your solution to the dead-end of reporting bugs to Apple, is to recommend that I don't use a Mac?
No, the solution is that Apple open their bug reporting up.
If it gets enough attention, Apple will have to care.
Edit: to clarify, I was under the impression that there are already companies that provide "complaint forms" (bug trackers) for products of other companies. So I was wondering if they provide such a tracker for Apple and how much activity it provides. I thought getsatisfaction was such a company, but maybe it was another one.
Seriously, more often than not the feedback is an excuse why they aren't going to fix it. Look, if you aren't going to fix the bug then you aren't; so be it; your choice. But don't tell me your excuse. I don't want to hear it. It will just annoy me and tempt me to get into an argument and waste both our time. Just throw my bug report in the recycle bin and we can both get on with our lives.
(Mind you there has to be a feedback capability for the rarer occasions when the programmer needs to ask for clarification about how to reproduce the bug.)
My own personal example is Issue 2600 in Android, which hasn't been fixed several years after it was first , and is a big issue for us non-English-character users (particularly the ñ spanish character ).
http://code.google.com/p/android/issues/detail?id=2600
The good thing with open bug trackers? You can contribute a patch if upstream is ignoring your request or taking too long to fix it.
Basically, developing error-free software is comparatively easy if your software effectively performs no I/O, that is, it behaves like a program in a computer science paper: read in some data on launch, grind through some computation, emit output, terminate. Barring catastrophic hardware failure of CPU or memory, this is a nicely deterministic programming model. You stand a chance writing correct code.
Throw "real" I/O into the mix, and almost anything can fail in weird ways, and your code has to be prepared for it. Network I/O is guaranteed to fail sooner or later while the developer is using the software. So it usually gets taken into account in some way, usually only distinguishing between "there is no connection" and "there is a connection". There are a myriad of other cases in between that are usually not even considered.
Disk I/O can fail for a variety of reasons. Not just hardware failure; file systems aren't perfect, especially when confronted with power failure, kernel panics, etc. Randomly flipped bits happen. (yes, really)
Not only are there are bugs in the GUI framework you're using, other GUI programs are running at the same time and they can inadvertently interact with your program due to the shared GUI framework use.
Other programs can inadvertently interact with yours in other ways: locked files, claimed sockets, contention for any kind of resource, race conditions, thread/task scheduling - you name it.
Timing bugs are ubiquitous. Everything you do in your program takes >0 time. Maybe on your system, with your data set, it looks like 0. Maybe because it takes slightly less than one video frame's worth of time. On your customer's system, it takes longer. If they click something before your operation has completed, and you haven't anticipated this, your program will fail in weird ways. Where I live, I can't get an internet connection with less than about 80ms latency even to the nearest servers, let alone to North America, where most servers sit (more like 200ms). You wouldn't believe how much software handles this terribly.
The problem is complexity - in many cases, unavoidable complexity, not the accidental complexity us developers keep railing against. Most of these error cases are extremely rare. The thing is, with thousands or millions of people using your software, extremely rare bugs suddenly become a very frequent occurrence!
Yet the tools for dealing with this kind of thing are somewhere between terrible and non-existent. There are some tools for simulating difficult network conditions; those are comparatively easy to make. I'm not aware of similar software that simulates OS API call failures. Or a "file system from hell" that wreaks havoc with your file I/O. Fuzzing a program in such a way would likely uncover countless bugs. valgrind and its myriad of plugins are great, but as developers we almost certainly under-use it.
Developing such tools is obviously expensive, and even they won't catch all bugs. But I'm pretty sure they could reduce the probability of running into bugs by a few orders of magnitude.
Don't even get me started on how programming languages don't help you handle error conditions or timing problems even if you try.
Though you are probably familiar with them, there are I/O fuzzers like zzuf[0]. I bet it'd be relatively straightforward to write a similar tool that uses LD_PRELOAD to intercept and randomly delay various library calls. Sometimes I'll test my own network software by piping /dev/urandom over netcat:
[0] http://caca.zoy.org/wiki/zzufRealistically, you'd have to automatically detect the calls made, for system calls you have ptrace (most commonly used by strace), though I'm not sure how you reroute them. I guess there must be some kernel-side hook. Still, that's likely to be too low-level for GUIs for example. Preloading dynamic libraries like that also only works well on ELF-based systems, other OSes behave rather differently, and if you're trying to test kernel code, it's a whole other problem.
Once you're simulating errors, you have to specify correct behaviour. For stream input fuzzing for security purposes, you're usually just probing for crashes. In the general case, the test framework will need to know the intended outcome of errors.
For either part, I'm not aware of anything existing like this. I'm slowly custom-building little islands of functionality like it, but it's a far cry from some kind of general solution.