9 ms·

Why software sucks?

113 points by jjude 15y ago

javascriptlol 15y ago
Software is too complicated. Now that we have a generation growing up with computers software engineers are happily brain-damaging them into expecting hugely complex software that doesn't really work. The browser is the perfect example. Why can the user manually reload a page? Shouldn't it all update automatically? The answer is: it's that way because it was convenient for lazy designers a long time ago and nobody bothered fixing it. And it will be rationalised as a good decision now that people have been damaged into thinking it's a good thing. What's there has blinded people to what is possible. Don't let people fool you into thinking that there are good reasons why we ended up with, say, C instead of Forth. It's all rubbish. We've become a field of charlatans.
- gaius 15y ago
  Err, what are you supposed to do when you edit a file on your webserver and want to see how it looks? HTTP is not NFS! But you are mostly right, software has far, far too many pointless layers of abstraction now, requiring vast resources just to do trivial tasks. There's nothing 99% of people use a wordprocessor or a spreadsheet for that you couldn't do on an 8-bit micro in the 80s. Games these days are just not fun, whereas the 8-bit days were a golden era of creativity. We need to take it back to the old school.
  - jacobr 15y ago
    "HTTP is not NFS" is a technical challenge that is potentially solvable. With single page apps the reload button is becoming increasingly irrelevant anyway though.
    - gaius 15y ago
      Writing desktop apps within a browser running on a desktop is what's crazy... Pointless layers of abstraction.
      - lbotos 15y ago
        It's only pointless because we are still using the "Desktop" model. I'm not advocating one over the other but as we see Mozilla try boot to gecko and Google trying Chrome OS we are seeing the early stages of the "webtopbrowserthing" being refined. We are in that transition state where we are trying to figure out what platform is where the money is.
        gaius 15y ago
        Those of us who have been around for a while look at what Google are doing with a sense of deja vu http://en.wikipedia.org/wiki/NeWS http://en.wikipedia.org/wiki/NeWS And NeWS was better in the sense that it used PS for everything rather than an unholy mess of JavaScript, CSS, HTML, etc etc.
        dasil003 15y ago
        It just goes to show that market forces do not care about technical merit and ultimate purpose in the least. NeWS never got traction, yet the advance of the web is inexorable. Why? Well the web is supported everywhere because it was simple. The fact that it is available everywhere (which is actually pretty amazing and unique in the entire history of media if you stop and think about it) meant people kept pushing the boundaries. The limitations caused standards to be pushed forward. Wide use of the standards means no platform can break free from supporting it (Microsoft did their best for almost a decade!). Obviously it looks like a Frankenstein monster from an engineering perspective, but it doesn't matter because that's where the investment is going. The good news is it will evolve and improve, and soon enough the grey beards who remember that there could have been a better way will all be dead; a lot like UNIX actually ;) edit: I'd appreciate if bitter GUI developers would respond rather than misdirect their anger at the down vote button.
        unimpressive 15y ago
        Well. You're getting downvoted for wishing death on people you've never met. >The good news is it will evolve and improve, and soon enough the grey beards who remember that there could have been a better way will all be dead; a lot like UNIX actually ;) That sounds like some sort of evil plot. For that matter my beard isn't anywhere close to being gray and I know that things could have been better. And if you didn't have +8000 karma I would think you were trolling. That you're not just makes it worse.
  - dhx 15y ago
    On automatic website refreshing: See guidelines 97 and 98 from Jakob Nielsen and Marie Tahir's book 50 Websites Deconstructed [1] for the primary reason why there has been little interest in removing the "refresh" button from browsers. Technical limitations don't really exist (and if they do exist it'd be fairly easy to solve). Server-sent events[2] and WebSocket[3] are already implemented in the latest versions of popular browsers. Modules or implementations within popular HTTP servers already exist for doing HTTP push (they tend to use older AJAX-like techniques though). If usability was no concern (or very carefully handled) it'd be fairly easy to write your own nginx module or "WebSocket server"[4] that uses inotify to check for file system changes. For each change that impacts an open WebSocket connection, a "refresh this page" notification can be sent to the browser (which then uses JavaScript to force a page refresh). There is a potential for smarter refresh mechanisms in browsers that maintain the current scroll state, field values, etc but you'd still be frustrating the user with severe usability problems. [1] http://www.useit.com/homepageusability/guidelines.html http://www.useit.com/homepageusability/guidelines.html [2] https://en.wikipedia.org/wiki/Server-sent_events https://en.wikipedia.org/wiki/Server-sent_events [3] https://en.wikipedia.org/wiki/WebSockets https://en.wikipedia.org/wiki/WebSockets [4] http://altdevblogaday.com/2012/01/23/writing-your-own-websocket-server/ http://altdevblogaday.com/2012/01/23/writing-your-own-websoc...
    - gaius 15y ago
      Yes but none of these things existed in 1993. You can call it "lazy" I suppose that TBL didn't implement all the features you take for granted 20 years later before releasing the first browser(!)
      - javascriptlol 15y ago
        It's lazy when your platform still has mandatory polling decades after interrupt driven programming was invented.
        icebraining 15y ago
        Interrupts are not without drawbacks. There are valid reasons to not implement them, particularly on the web.
- mgkimsal 15y ago
  This isn't rationalizing, but... no, automatic refreshing isn't being 'lazy'. They're called browsers because they were meant to let people browse, not consume as a TV watcher. If I was reading a book, and the author made an update, I wouldn't necessarily want the new update from the author. Notify me there's an update? Sure! Automatically replace the copy I'm reading with the update, simultaneously removing my ability to ever get back to the version I was reading? No thanks. "What's there has blinded people to what is possible." As someone who has a good idea of what's possible, I tend to agree, and think of browser 'cookie' support as a good example. 'cookies' were lambasted as the embodiment of evil in the mid-late 90's. The hysteria around them was insane. Why? We had little control over the visibility of what a cookie was, what it said, and how to manage them. Even today, in 2012, cookies are little understood, and to 'manager' them requires multiple clicks in to layers of menus often marked 'advanced' or 'privacy' (both are silly labels for cookie data, imo). We could have given people easier access to view/manage/understand cookie data, and probably avoided national legislation like we see in some countries now, but that would have meant breaking the status quo. Far easier to focus on browser market share and "standards compliance" as the primary measurements of browser utility and acceptance.
  - javascriptlol 15y ago
    <blockquote>Automatically replace the copy I'm reading with the update, simultaneously removing my ability to ever get back to the version I was reading?</blockquote> This is an asinine example. Why would the author do this except to correct typos or update the kind of information you want updated? Who are these nefarious authors trying to destroy your reading experience? They don't exist, and this kind of lazy thinking is why it took until very recently for browsers to even have the possibility of auto-update without polling (hello 1970).
- benohear 15y ago
  Refresh does have a bit of an "implementation model of yesteryear" feel to it. On the other hand I've never observed it to be a massive pain point for users and removing it would need to be done very carefully so as not to create more problems than it solves. A warning from experience if you are thinking of implementing Alan Cooper's theories on the topic of legacy UI: Be very careful when removing conventional things because they seem archaic and make sure that they respond to a genuine pain point and your dev team has the chops to fully implement the solution you propose. Otherwise you're going to end up with a half-arsed unconventional UI which will just confuse everyone.
  - javascriptlol 15y ago
    I might agree with this statement if the web had produced anything like a "conventional UI" that is consistent. Every website is completely different. Just look at Facebook. This is a horribly confusing website and most of the features are the kind of self-justifying nonsense I'm talking about. Nobody wanted Facebook until Facebook came along and convinced people to turn photo/comment sharing into a sterile game.
- dasil003 15y ago
  Your first sentence is in conflict with your example. The UI complication of the refresh button is minuscule in comparison to the technical complexity of implementing universally canonical web page views. But even assuming you could make that work well enough it's impossible to make software that anticipates all needs correctly. A good example was brought up on 5by5 a few weeks ago: should the iPhone alarm be silenced by silent mode. People will expect it to work one way or another and they will be burned badly when it doesn't do what they expect (think setting an alarm to catch an early flight vs being in an opera). It's easy to sit on a mountain top and spout off declarations about how things should be, but in no place is the old adage "the devil is in the details" more apropos then software development. Even the UI designer runs into these fundamental conflicts, but the low-level programmer is inundated with them. And worse yet, software stacks are so deep and CPUs so powerful that the scope of what software actually does is increasingly difficult to mentally model. The only way out of this is to ruthlessly narrow the scope and have an organization-wide emphasis on UX. This works for Apple, but consider that in order to do this they basically punt on all the hairiest business requirements because it just doesn't serve their vision. Nevertheless those requirements are real and unignorable which is why SAP et al thrive. The reason most software is bad is not for lack of effort, it's just damn hard to do right. It's good to ask big questions, but then go try to solve some of them rather than admonish those of us who pour our lives into this.
  - javascriptlol 15y ago
    Stop making stupid excuses. The fact that some people might get confused by some detail (like your iPhone alarm example) does not change the fact that some some other things are idiotic (like the refresh button). And your take on the refresh problem shows why this whole thing is a complete mess: I'm not suggesting "universal" auto-refresh. This is why the browsers is such a failure technologically: people want to try to solve all the problems in the platform instead of just providing simple, powerful primitives. As you recognise we need to restrict scope. The only software that actually works is simple and small. And I'm not just "admonishing others". I dropped out of academia and industry and moved into a cheaper neighbourhood to be independent so I can write the simplest software possible. To me that's better than empty talk about "UX" and other modernistic double-talk about how hard we've got it. And having an independent perspective, I can see that it's rationalisations all the way down. We will have botnets etc forever until people tackle the problems as a basic level by simple designs that eliminate the problems. But people can't even conceive of putting ethics before their own financial well-being because as an industry we have no ethics. Just pride in spreading our bullshit around as much as possible. If software engineers built bridges we'd make it drive up and down the river, put in a few houses to be "efficient". And then when the thing breaks down we'd complain that it's "too hard". No shit it's too hard: because we promise more than we can deliver, hiding the risks and problems from the user. Firefox has as a feature in every version the ability for criminals to install rogue programs on your computer. And yet you won't see this in their marketing material. This is a solved problem. We know how to eliminate memory-safety problems, but Mozilla would rather take N years to do their rust rewrite (if it even happens) because it's in their self interest. If we had any ethics as an industry Firefox would come with a warning that it makes it possible to install rogue programs on your computer. But it won't.
benohear 15y ago
Software tends to suck when either you build the wrong thing or you bit off more than you could chew and the implementation of a good thing ends in disaster. Or both. Generally the "lean startup" credo holds true here: Build an MVP fast, get feedback and iterate. However, there is one technique which doesn't get enough airtime in my view and that is paper prototyping. It gives you a surprising amount of quality feedback with a fraction of the effort of coding something up (and no bugs!), and allows you to iterate there and then.
- gaius 15y ago
  Very amusing that you think that as that approach is what got us into this mess. MS (not to single anyone out in particular) has always been notorious for rushing a buggy 1.0 to market then iterating it. That's why you need a quad-core 3Ghz PC with 8G RAM to write a single page of A4 now.
  - serbrech 15y ago
    I can't agree that a buggy and slow version of a product is an MVP. There are a lot of things that you can cut from a product to make it minimal. I don't believe quality is one of them. However, I also believe that user feedback cannot be the only factor to build something truly great.
    - gaius 15y ago
      Windows 1.0 and Word 1.0 were viable by definition, as people did buy them.
  - benohear 15y ago
    Point taken, though I meant minimal feature set, not buggy. Also, 2000 and later Office and Windows are hardly the worst offenders in terms of "software that sucks"
gaius 15y ago
There is one thing that makes software suck, and that's how far apart its developers and users are. I dream of going to SAP's offices in Germany and seeing how they book their own vacation and submit their own expenses. I can't believe they do it with their own product, or it would be slick...
- cubicle67 15y ago
  absolutely. I worked for a few years at a place that used SAP for everything HR related. I still recall the pain of trying to record a sick day or book a day off (for extra points, try a half day!) we also used a ticket tracking packages called, I think, CAMS. possibly a CA product. oh, and we used Harvest for source control. I still recall the joy in learning CAMS would be replaced, and the horror that followed as we came to grips with ManageNow. Never dreamt I'd wish for CAMS to return, but I did. So, yes, I agree. I can't believe the companies that peddle this crap actually use it.
- mkilling 15y ago
  surprising thing is: they do
  - Lennie 15y ago
    Let me guess they send an email to a secretary and they do the rest ?
    - syncopate 15y ago
      who opens a ticket in the bug reporting database detailing what they want to do and then letting IT support do it.
- singular 15y ago
  There certainly can be a disconnect which impacts a developers ability to see what a user wants, but even if there is no disconnect, bad software can still result. Consider internal software - there is literally no disconnect whatsoever, but very often the software is terrible. This is relevant because it raises the issue that the business simply may not care about quality, and thus putting in the work required to make the thing good might simply not be possible. There are many, many factors involved in determining whether software sucks or not, and key is the understanding or lack thereof of what the users want and need, agreed. But keep in mind, there is a big difference between seeing what the users' need superficially vs. understanding clearly and deeply what the users' need and implementing it well.
cubicle67 15y ago
We were discussing this recently whilst trying to come up with a guideline about when the computer should "help" and when it should just leave you in peace. We looked at lots of software we hated and loved, and tried to pinpoint the why. One of the things that came up most about hated software was that it had a high frustration level Who's ever wished for a giant red "PLEASE STOP HELPING ME" button on their computer? Everyone, right? One of the causes of frustration we looked at was when the software helps you, but gets it wrong. Frustration is increased when the effort to fix the software's "help" is anything other than minor, and increased again when the computer repeats it's efforts at helping. Throw in no obvious way to get it to stop and you're in for some blood-boiling times. The guideline we came up with was to not concentrate so much on how cool it is when things go well, but think about what happens when the software guesses user intent incorrectly. Consider: * How often is the software likely to get it wrong? * what was the level of irritation is caused by getting it wrong? * How much effort is required to undo the computer's help? and weight it up against how much effort you're saving the user when you get it right. Thinking about this has caused us not to add a particular cool feature we had planned, because even though (we thought) it was very cool, there was about 30% chance or so of it being wrong, and the payoff wasn't worth it.
lwhi 15y ago
Surely the banner of user experience, and it's component disciplines, try to directly tackle this problem? There is a disconnection between the motivation of developers and the needs of users, but areas like IxD, IA, usability research, user experience planning and HCi all help to bridge the gap.
pinaceae 15y ago
Software sucking is a direct outcome of future user's involvement in the design process. as in: if you're writing software for a client and the client drives the specs directly, the outcome will suck balls. evidence: all enterprise software installations ever done. from ERP to CRM, the vanilla software packages might even have good UX/UI, but once implementation with all its "critical" customizations is done, you'll end up with a turd.
- zdw 15y ago
  I tend to think that splitting development into API and front end solves some of this. The main problem with "enterprise" software is that it's done cheaply, and violates levels of abstraction. Thus why it frequently requires specific versions of antiquated technology ("Our CRM requires IE6", "We can't upgrade past Windows 2000"). If it was designed properly, you could easily rip out both parts and iteratively redesign them to meet business and technical goals.
  - mattquinn 15y ago
    Seconded. The university I'm attending uses PeopleSoft (acquired by Oracle) as their ERP system, and it's horrendous. Not a week goes by where I don't hear students and faculty members openly complain about it. I've got a live PeopleSoft installation running on a server in my apartment that I'm outfitting with code to do exactly what you mentioned - split out the back-end from the front-end. So far it's going brilliantly - for some sadistic reason, I enjoy trying to reduce the complexities of these applications.
    - shurane 15y ago
      You know, I wanted to do something very similar with my university's installation of PeopleSoft - but my intent was more focus on improving the UI and frontend than backend. But I have to ask: how did you get a copy of PeopleSoft?
      - mattquinn 15y ago
david927 15y ago
If we invented the car, but there was no reverse and no left turn, we could say that the problems were due to poor drivers and poor planning, but the problem would clearly be that the car is not sufficiently wieldy. You can say that software sucks because of poor programmers and poor project management, but the truth is that the code is not sufficiently wieldy. There's no way to manage the code. I can't query all places in the code where the UI interacts with a database column. Accounting systems can give you a variety of reports based on abstractions at a variety of layers, slicing the information in different ways (horizontally, vertically, etc). Software systems? Go fish. Software sucks because at some point we got too excited about what we were doing and stopped (sufficiently) caring about how we were doing it.
- pbz 15y ago
  "I can't query all places in the code where the UI interacts with a database column." Why can't you?
michaelochurch 15y ago
Here are some thoughts I'd put into the mix. 1. Software that is built to deadline will decay, even if the developers are good. That doesn't mean that an occasional deadline is the end, but if a long-term "deadline culture" sets in, get out. A long-standing deadline-oriented culture means you should be looking to jump to another project or company before the maintenance phase starts, because (1) the maintainers will be underappreciated (that's typical deadline culture) and (2) once the original architects get promoted it will be politically impossible to point out the real reason maintainers are unable to deliver in a timely fashion, and the slowest one to run away will get eaten by the bear. It means that technical debt will never be paid off; management will never budget time, and engineers will be too busy to clean up the code. Software engineers generally lack both the political pull and the broad-based knowledge to push back on deadlines and tease out which ones actually matter and which don't. 2. Entropy. Good software is less stable than bad software. Think of this as akin to the "broken windows" theory. Once software reaches a certain state of degradation, each change, although it might fix a bug or add a feature, will make the state of the software worse. There are creeping kinds of badness that can't be caught in incremental code reviews, such as adding 10 lines to a long for-loop or a "necessary" boolean parameter to a method that over time ends up with 15 boolean parameters. Often the managerial solution (once it's far past too late) is to put maintenance of this bad system on the calendar and make it someone's full-time job (instead of a shared responsibility) but no one wants that job and often that work is allocated to marginally skilled junior programmers with no clout. Then you get adverse selection: the more skilled people in that set will leave the project (or company) before they put in enough time to become decent at it. 3. "Pay as you go" maintenance, which includes periodic fixit spells, is always better than after-shit-breaks maintenance. That said, existing tools don't make it easy to revert quality degradation. IDEs really don't perform this function as commonly used. (I'm sure IDEs can be really powerful if well-learned, but people who are dedicated enough to master IDEs are also dedicated enough to jump wholesale to better languages for which IDEs are unnecessary and often poorly-supported. IDEs, in large part, exist to compensate for weak languages.) Code can rot in any language, but one advantage that languages like Scala and Python have is that, because they have REPLs, which are far more useful than any IDE, people can interact with the software at a code-level and fix things while the code is in that "moderately bad" state before it is too late. In 2012, I wouldn't start anything important in a REPL-less language. (C is not "REPL-less" because Unix is the C programming environment. C++ is, not on account of language intrinsics but because it has departed from the small-program Unix philosophy and is used for large-object programming which requires interactivity at a code level.) At least some programmers will have enough of a sense of ownership and citizenry to clean up failing code as they work with it, but if you deprive them of the REPL, the one tool that any good programmer will recognize as essential, they won't put in the work. REPL or Fail: http://michaelochurch.wordpress.com/2012/02/07/repl-or-fail/ http://michaelochurch.wordpress.com/2012/02/07/repl-or-fail/ 4. The transition from being a mediocre to a good and then to a great engineer is about moving away from being an "adder" (someone who increases codebase complexity and functionality, thereby having an additive business value-- ignoring long-term costs of complexity, which may or may not offset that additive value) to a "multiplier" (someone with broad-based positive effects that make the whole team more productive). Contemporary tools and programming environments (Java, C++, IDEs, IOC, dependency injection frameworks) are about helping more mediocre engineers become solid adders at the expense of the really great engineers, whose creativity is constrained by less powerful languages and tools. One of the goals behind Microsoft's professional certifications, the design of VB (and later, the hijacking of Java), and the attempted ghettoization of the command-line (which good engineers like) was to make it possible for huge teams of "commodity" programmers to be productive as adders, with the hope that "someone" would have the patience to staple together the zillion classes they cranked out. From an MBA perspective, this is a win, because 2-4 times more people are eligible to be adders, but it also holds people back from becoming multipliers. The long-term problem is that a team without any multipliers will accumulate complexity and the emergent design (because you want a solid engineer doing your design work, and you can't get them in commodity-programmer environments, "design" coming out of a commodity shop will be ad hoc) will be disastrous. 5. With a few exceptions, the real fuckups in software don't seem to be blameable on a single person. They usually emerge either from jobs no one does (because the people who care about them being done aren't in power) or that too many people do (once code has been passed over by too many hands, it turns to shit).
j45 15y ago
Software sucks because too often developers fail to learn what the software is supposed to do. Developers trivialize things and interpret them in far "superior" ways that lead to huge gaps of "they never told us". Development has to move from just coding, to learning to first understand what details are being managed, and how those details interact in a system in all the stages the details/data exist. If we believe every business is becoming a software business, the reverse is true, all software developers must understand the business more and continually develop the skills to be the bridge between business goals and technology. How to do that? Shut the hell up and learn. Ask (and learn) why things are done a certain way. Uncover any competitive advantages the business has from doing things a certain way before getting on the high horse and deciding to improve the world because it's so obvious. Developers may be surrounded by non-techs, but they certainly might be surprised to see the organization itself does have processes and competitive advantages that have to be maintained for the business to survive. Avoiding the classic SAP-esq kiss of death of doing it the SAP way, wiping out the competitive advantage (seen first hand), and then spending tons of money customizing and automating any ERP to get back to what they had before (and more) seems silly, but I can't say the 70% of failed software projects fare much better. So, before we think we understand something, shut up. Before we think we know better, shut up. Before we think we can simplify things, shut up. Before we think we can make things more efficient, shut up. Shut up, listen to the people using the current systems and processes and learn what is working for them, or not, first. Shut up and learn. Don't finish people's sentences. Don't tune out. Don't think things are beneath you. Don't think you've seen it before, or built it before. At each step ask them if you understand their process correctly before going off to formulate a faster way of doing things for their confirmation. Software has the power to uplift the lives of people and help them get more done with less effort. If you don't value this, don't make the rest of us look bad for your laziness and inability to continually develop your own skills. Once you have learnt why the business does what it does, the way it does, it's fair to ask the question "How should it be?", and see what differs. That, is the beginning of what you should start thinking about. Having integrated custom systems and built new ones to replace existing ones since '99, this is the single worst thing I see. Enough developers simply don't have a healthy paranoia of their understanding. Knowing a little bit about something can make developers just as dangerous as the "business" folks they judge for doing the same. It all comes out in the wash with the 70% software failure rate. Without understanding the data of the business, how it interacts, exists in different stages, and how it needs to be input/output, and why, amongst other things is the leading contributor to software failure. It's as much "the customer didn't know what they wanted" as "developers failed to understand their job is to go learn the business first and then design something to build". To be clear, this can mean working in people's positions first hand to see what they're going through / facing that they can't explain to you. It can mean seeing what state a business is in, infancy (no systems or processes), adolescence (some systems or processes), or maturity (a mature system and process, even if it's all manual). Do those three scenarios equal one approach to all of them? Hell no. There is, though, a few common things to keep in mind: - Ask customers to teach you the business as they know it first. Pretend you're the next apprentice, or the owner's right hand man. Ask to be taught not just how to do everything, but why it's done that way. - Your goal is to get more done with less effort. The software you design and build should not simply make less work for some, and more for others. It should free people from BEING the tools and systems, to USING the tools and systems. The people of an organization should do what they know best, instead of being computers, they should be interacting with each other, and customers. I could go on a long time about this. But it's Sunday and I hope the positive wishes come through.
sodiumphosphate 15y ago
The human race excels at engineering shovels and hammers, knives and other primitive tools; for anything more complex than that our capabilities are still pretty much infantile. Give it a few thousand years. If we can manage to survive it, the miserable suckiness of our software will taper off.
evincarofautumn 15y ago
“No one makes bad software on purpose” is not strictly true: many esoteric programming languages are designed to be “bad” in interesting ways. That extends to any subversion of highly-regarded tropes in games and other media, even the non-interactive kind. It’s also not true that “in order for people to say ‘this sucks’ they have to care enough about the thing you’ve made to spend time with it and recognize how bad it is”. People routinely criticise programming languages and other software they’ve never used before, even if said software doesn’t actually suck much at all.
ken 15y ago
A little while ago I overhead a conversation between some friends of mine, one of whom is an interior designer who does residential remodeling: a: "We always tear out everything, down to the rafters." b: "That sounds expensive." a: "It can be, especially if you find out the wiring or something isn't up to code." b: "What if someone wants only---" a: "No, there's no 'only'." In my experience, if programmers always had a complete design specification before starting, and if we always "tore up" the old mess (down to something unquestionably stable) before making any improvements, our software would be much, much better. It'd probably also cost more. The biggest cause of this that I see is that the people paying for it are not the people using it. In the consumer market we are starting to see that good design does sell (I think it was Gropius who predicted that the cost of design is amortized). But with enterprise software, the people paying for it are rarely the ones using it, so they're perfectly willing to buy a lousy program if it means saving cash in the short term.
- icebraining 15y ago
  In my experience, if programmers always had a complete design specification before starting, and if we always "tore up" the old mess (down to something unquestionably stable) before making any improvements, our software would be much, much better. It'd probably also cost more. And by the time the software was done, it'd be useless. A house doesn't get obsolete in ten years, but software - which is much more complex than a house - can be obsolete in ten months. Not to mention that I'd rather not be reinventing the wheel every six months.
  - 4as198sGxV 15y ago
    I often hear that but it is no true in my experience. Maybe your run-of-the-mill flavour-of-the-month hipster web 2.0 app has a limited shelf life but most enterprise apps stay deployed for years.
    - icebraining 15y ago
      But is it because the needs haven't changed a bit, or because it's good enough and it'd cost too much to replace it? Because if software was always tored out, that would only accentuate the latter problem.
b1daly 15y ago
One reason I don't think gets mentioned enough for software sucking: developers don't really use the product enough to optimize it (they don't have time). Especially for complex applications. If there isn't an effective feedback loop from users about pain points, and an institutional drive to address them, major problems in software persist version after version.
cousin_it 15y ago
In this thread many people give different reasons why they think software sucks. This prompts some meta-questions: 1) Why are all these people so confident, if only a minority of them can be right? 2) What procedure would make everyone converge on the same correct answer?

113 points by jjude 15y ago

Software is too complicated. Now that we have a generation growing up with computers software engineers are happily brain-damaging them into expecting hugely complex software that doesn't really work. The browser is the perfect example. Why can the user manually reload a page? Shouldn't it all update automatically? The answer is: it's that way because it was convenient for lazy designers a long time ago and nobody bothered fixing it. And it will be rationalised as a good decision now that people have been damaged into thinking it's a good thing. What's there has blinded people to what is possible. Don't let people fool you into thinking that there are good reasons why we ended up with, say, C instead of Forth. It's all rubbish. We've become a field of charlatans.

gaius 15y ago
Err, what are you supposed to do when you edit a file on your webserver and want to see how it looks? HTTP is not NFS! But you are mostly right, software has far, far too many pointless layers of abstraction now, requiring vast resources just to do trivial tasks. There's nothing 99% of people use a wordprocessor or a spreadsheet for that you couldn't do on an 8-bit micro in the 80s. Games these days are just not fun, whereas the 8-bit days were a golden era of creativity. We need to take it back to the old school.
- jacobr 15y ago
  "HTTP is not NFS" is a technical challenge that is potentially solvable. With single page apps the reload button is becoming increasingly irrelevant anyway though.
  - gaius 15y ago
    Writing desktop apps within a browser running on a desktop is what's crazy... Pointless layers of abstraction.
    - lbotos 15y ago
      It's only pointless because we are still using the "Desktop" model. I'm not advocating one over the other but as we see Mozilla try boot to gecko and Google trying Chrome OS we are seeing the early stages of the "webtopbrowserthing" being refined. We are in that transition state where we are trying to figure out what platform is where the money is.
      - gaius 15y ago
        Those of us who have been around for a while look at what Google are doing with a sense of deja vu http://en.wikipedia.org/wiki/NeWS http://en.wikipedia.org/wiki/NeWS And NeWS was better in the sense that it used PS for everything rather than an unholy mess of JavaScript, CSS, HTML, etc etc.
        dasil003 15y ago
        It just goes to show that market forces do not care about technical merit and ultimate purpose in the least. NeWS never got traction, yet the advance of the web is inexorable. Why? Well the web is supported everywhere because it was simple. The fact that it is available everywhere (which is actually pretty amazing and unique in the entire history of media if you stop and think about it) meant people kept pushing the boundaries. The limitations caused standards to be pushed forward. Wide use of the standards means no platform can break free from supporting it (Microsoft did their best for almost a decade!). Obviously it looks like a Frankenstein monster from an engineering perspective, but it doesn't matter because that's where the investment is going. The good news is it will evolve and improve, and soon enough the grey beards who remember that there could have been a better way will all be dead; a lot like UNIX actually ;) edit: I'd appreciate if bitter GUI developers would respond rather than misdirect their anger at the down vote button.
        unimpressive 15y ago
        Well. You're getting downvoted for wishing death on people you've never met. >The good news is it will evolve and improve, and soon enough the grey beards who remember that there could have been a better way will all be dead; a lot like UNIX actually ;) That sounds like some sort of evil plot. For that matter my beard isn't anywhere close to being gray and I know that things could have been better. And if you didn't have +8000 karma I would think you were trolling. That you're not just makes it worse.
- dhx 15y ago
  On automatic website refreshing: See guidelines 97 and 98 from Jakob Nielsen and Marie Tahir's book 50 Websites Deconstructed [1] for the primary reason why there has been little interest in removing the "refresh" button from browsers. Technical limitations don't really exist (and if they do exist it'd be fairly easy to solve). Server-sent events[2] and WebSocket[3] are already implemented in the latest versions of popular browsers. Modules or implementations within popular HTTP servers already exist for doing HTTP push (they tend to use older AJAX-like techniques though). If usability was no concern (or very carefully handled) it'd be fairly easy to write your own nginx module or "WebSocket server"[4] that uses inotify to check for file system changes. For each change that impacts an open WebSocket connection, a "refresh this page" notification can be sent to the browser (which then uses JavaScript to force a page refresh). There is a potential for smarter refresh mechanisms in browsers that maintain the current scroll state, field values, etc but you'd still be frustrating the user with severe usability problems. [1] http://www.useit.com/homepageusability/guidelines.html http://www.useit.com/homepageusability/guidelines.html [2] https://en.wikipedia.org/wiki/Server-sent_events https://en.wikipedia.org/wiki/Server-sent_events [3] https://en.wikipedia.org/wiki/WebSockets https://en.wikipedia.org/wiki/WebSockets [4] http://altdevblogaday.com/2012/01/23/writing-your-own-websocket-server/ http://altdevblogaday.com/2012/01/23/writing-your-own-websoc...
  - gaius 15y ago
    Yes but none of these things existed in 1993. You can call it "lazy" I suppose that TBL didn't implement all the features you take for granted 20 years later before releasing the first browser(!)
    - javascriptlol 15y ago
      It's lazy when your platform still has mandatory polling decades after interrupt driven programming was invented.
      - icebraining 15y ago
        Interrupts are not without drawbacks. There are valid reasons to not implement them, particularly on the web.
mgkimsal 15y ago
This isn't rationalizing, but... no, automatic refreshing isn't being 'lazy'. They're called browsers because they were meant to let people browse, not consume as a TV watcher. If I was reading a book, and the author made an update, I wouldn't necessarily want the new update from the author. Notify me there's an update? Sure! Automatically replace the copy I'm reading with the update, simultaneously removing my ability to ever get back to the version I was reading? No thanks. "What's there has blinded people to what is possible." As someone who has a good idea of what's possible, I tend to agree, and think of browser 'cookie' support as a good example. 'cookies' were lambasted as the embodiment of evil in the mid-late 90's. The hysteria around them was insane. Why? We had little control over the visibility of what a cookie was, what it said, and how to manage them. Even today, in 2012, cookies are little understood, and to 'manager' them requires multiple clicks in to layers of menus often marked 'advanced' or 'privacy' (both are silly labels for cookie data, imo). We could have given people easier access to view/manage/understand cookie data, and probably avoided national legislation like we see in some countries now, but that would have meant breaking the status quo. Far easier to focus on browser market share and "standards compliance" as the primary measurements of browser utility and acceptance.
- javascriptlol 15y ago
  <blockquote>Automatically replace the copy I'm reading with the update, simultaneously removing my ability to ever get back to the version I was reading?</blockquote> This is an asinine example. Why would the author do this except to correct typos or update the kind of information you want updated? Who are these nefarious authors trying to destroy your reading experience? They don't exist, and this kind of lazy thinking is why it took until very recently for browsers to even have the possibility of auto-update without polling (hello 1970).
benohear 15y ago
Refresh does have a bit of an "implementation model of yesteryear" feel to it. On the other hand I've never observed it to be a massive pain point for users and removing it would need to be done very carefully so as not to create more problems than it solves. A warning from experience if you are thinking of implementing Alan Cooper's theories on the topic of legacy UI: Be very careful when removing conventional things because they seem archaic and make sure that they respond to a genuine pain point and your dev team has the chops to fully implement the solution you propose. Otherwise you're going to end up with a half-arsed unconventional UI which will just confuse everyone.
- javascriptlol 15y ago
  I might agree with this statement if the web had produced anything like a "conventional UI" that is consistent. Every website is completely different. Just look at Facebook. This is a horribly confusing website and most of the features are the kind of self-justifying nonsense I'm talking about. Nobody wanted Facebook until Facebook came along and convinced people to turn photo/comment sharing into a sterile game.
dasil003 15y ago
Your first sentence is in conflict with your example. The UI complication of the refresh button is minuscule in comparison to the technical complexity of implementing universally canonical web page views. But even assuming you could make that work well enough it's impossible to make software that anticipates all needs correctly. A good example was brought up on 5by5 a few weeks ago: should the iPhone alarm be silenced by silent mode. People will expect it to work one way or another and they will be burned badly when it doesn't do what they expect (think setting an alarm to catch an early flight vs being in an opera). It's easy to sit on a mountain top and spout off declarations about how things should be, but in no place is the old adage "the devil is in the details" more apropos then software development. Even the UI designer runs into these fundamental conflicts, but the low-level programmer is inundated with them. And worse yet, software stacks are so deep and CPUs so powerful that the scope of what software actually does is increasingly difficult to mentally model. The only way out of this is to ruthlessly narrow the scope and have an organization-wide emphasis on UX. This works for Apple, but consider that in order to do this they basically punt on all the hairiest business requirements because it just doesn't serve their vision. Nevertheless those requirements are real and unignorable which is why SAP et al thrive. The reason most software is bad is not for lack of effort, it's just damn hard to do right. It's good to ask big questions, but then go try to solve some of them rather than admonish those of us who pour our lives into this.
- javascriptlol 15y ago
  Stop making stupid excuses. The fact that some people might get confused by some detail (like your iPhone alarm example) does not change the fact that some some other things are idiotic (like the refresh button). And your take on the refresh problem shows why this whole thing is a complete mess: I'm not suggesting "universal" auto-refresh. This is why the browsers is such a failure technologically: people want to try to solve all the problems in the platform instead of just providing simple, powerful primitives. As you recognise we need to restrict scope. The only software that actually works is simple and small. And I'm not just "admonishing others". I dropped out of academia and industry and moved into a cheaper neighbourhood to be independent so I can write the simplest software possible. To me that's better than empty talk about "UX" and other modernistic double-talk about how hard we've got it. And having an independent perspective, I can see that it's rationalisations all the way down. We will have botnets etc forever until people tackle the problems as a basic level by simple designs that eliminate the problems. But people can't even conceive of putting ethics before their own financial well-being because as an industry we have no ethics. Just pride in spreading our bullshit around as much as possible. If software engineers built bridges we'd make it drive up and down the river, put in a few houses to be "efficient". And then when the thing breaks down we'd complain that it's "too hard". No shit it's too hard: because we promise more than we can deliver, hiding the risks and problems from the user. Firefox has as a feature in every version the ability for criminals to install rogue programs on your computer. And yet you won't see this in their marketing material. This is a solved problem. We know how to eliminate memory-safety problems, but Mozilla would rather take N years to do their rust rewrite (if it even happens) because it's in their self interest. If we had any ethics as an industry Firefox would come with a warning that it makes it possible to install rogue programs on your computer. But it won't.

benohear 15y ago

Software tends to suck when either you build the wrong thing or you bit off more than you could chew and the implementation of a good thing ends in disaster. Or both. Generally the "lean startup" credo holds true here: Build an MVP fast, get feedback and iterate. However, there is one technique which doesn't get enough airtime in my view and that is paper prototyping. It gives you a surprising amount of quality feedback with a fraction of the effort of coding something up (and no bugs!), and allows you to iterate there and then.

gaius 15y ago
Very amusing that you think that as that approach is what got us into this mess. MS (not to single anyone out in particular) has always been notorious for rushing a buggy 1.0 to market then iterating it. That's why you need a quad-core 3Ghz PC with 8G RAM to write a single page of A4 now.
- serbrech 15y ago
  I can't agree that a buggy and slow version of a product is an MVP. There are a lot of things that you can cut from a product to make it minimal. I don't believe quality is one of them. However, I also believe that user feedback cannot be the only factor to build something truly great.
  - gaius 15y ago
    Windows 1.0 and Word 1.0 were viable by definition, as people did buy them.
- benohear 15y ago
  Point taken, though I meant minimal feature set, not buggy. Also, 2000 and later Office and Windows are hardly the worst offenders in terms of "software that sucks"

gaius 15y ago

There is one thing that makes software suck, and that's how far apart its developers and users are. I dream of going to SAP's offices in Germany and seeing how they book their own vacation and submit their own expenses. I can't believe they do it with their own product, or it would be slick...

cubicle67 15y ago
absolutely. I worked for a few years at a place that used SAP for everything HR related. I still recall the pain of trying to record a sick day or book a day off (for extra points, try a half day!) we also used a ticket tracking packages called, I think, CAMS. possibly a CA product. oh, and we used Harvest for source control. I still recall the joy in learning CAMS would be replaced, and the horror that followed as we came to grips with ManageNow. Never dreamt I'd wish for CAMS to return, but I did. So, yes, I agree. I can't believe the companies that peddle this crap actually use it.
mkilling 15y ago
surprising thing is: they do
- Lennie 15y ago
  Let me guess they send an email to a secretary and they do the rest ?
  - syncopate 15y ago
    who opens a ticket in the bug reporting database detailing what they want to do and then letting IT support do it.
singular 15y ago
There certainly can be a disconnect which impacts a developers ability to see what a user wants, but even if there is no disconnect, bad software can still result. Consider internal software - there is literally no disconnect whatsoever, but very often the software is terrible. This is relevant because it raises the issue that the business simply may not care about quality, and thus putting in the work required to make the thing good might simply not be possible. There are many, many factors involved in determining whether software sucks or not, and key is the understanding or lack thereof of what the users want and need, agreed. But keep in mind, there is a big difference between seeing what the users' need superficially vs. understanding clearly and deeply what the users' need and implementing it well.

cubicle67 15y ago

We were discussing this recently whilst trying to come up with a guideline about when the computer should "help" and when it should just leave you in peace. We looked at lots of software we hated and loved, and tried to pinpoint the why. One of the things that came up most about hated software was that it had a high frustration level Who's ever wished for a giant red "PLEASE STOP HELPING ME" button on their computer? Everyone, right? One of the causes of frustration we looked at was when the software helps you, but gets it wrong. Frustration is increased when the effort to fix the software's "help" is anything other than minor, and increased again when the computer repeats it's efforts at helping. Throw in no obvious way to get it to stop and you're in for some blood-boiling times. The guideline we came up with was to not concentrate so much on how cool it is when things go well, but think about what happens when the software guesses user intent incorrectly. Consider: * How often is the software likely to get it wrong? * what was the level of irritation is caused by getting it wrong? * How much effort is required to undo the computer's help? and weight it up against how much effort you're saving the user when you get it right. Thinking about this has caused us not to add a particular cool feature we had planned, because even though (we thought) it was very cool, there was about 30% chance or so of it being wrong, and the payoff wasn't worth it.

lwhi 15y ago

Surely the banner of user experience, and it's component disciplines, try to directly tackle this problem? There is a disconnection between the motivation of developers and the needs of users, but areas like IxD, IA, usability research, user experience planning and HCi all help to bridge the gap.

pinaceae 15y ago

Software sucking is a direct outcome of future user's involvement in the design process. as in: if you're writing software for a client and the client drives the specs directly, the outcome will suck balls. evidence: all enterprise software installations ever done. from ERP to CRM, the vanilla software packages might even have good UX/UI, but once implementation with all its "critical" customizations is done, you'll end up with a turd.

zdw 15y ago
I tend to think that splitting development into API and front end solves some of this. The main problem with "enterprise" software is that it's done cheaply, and violates levels of abstraction. Thus why it frequently requires specific versions of antiquated technology ("Our CRM requires IE6", "We can't upgrade past Windows 2000"). If it was designed properly, you could easily rip out both parts and iteratively redesign them to meet business and technical goals.
- mattquinn 15y ago
  Seconded. The university I'm attending uses PeopleSoft (acquired by Oracle) as their ERP system, and it's horrendous. Not a week goes by where I don't hear students and faculty members openly complain about it. I've got a live PeopleSoft installation running on a server in my apartment that I'm outfitting with code to do exactly what you mentioned - split out the back-end from the front-end. So far it's going brilliantly - for some sadistic reason, I enjoy trying to reduce the complexities of these applications.
  - shurane 15y ago
    You know, I wanted to do something very similar with my university's installation of PeopleSoft - but my intent was more focus on improving the UI and frontend than backend. But I have to ask: how did you get a copy of PeopleSoft?
    - mattquinn 15y ago

david927 15y ago

If we invented the car, but there was no reverse and no left turn, we could say that the problems were due to poor drivers and poor planning, but the problem would clearly be that the car is not sufficiently wieldy. You can say that software sucks because of poor programmers and poor project management, but the truth is that the code is not sufficiently wieldy. There's no way to manage the code. I can't query all places in the code where the UI interacts with a database column. Accounting systems can give you a variety of reports based on abstractions at a variety of layers, slicing the information in different ways (horizontally, vertically, etc). Software systems? Go fish. Software sucks because at some point we got too excited about what we were doing and stopped (sufficiently) caring about how we were doing it.

pbz 15y ago
"I can't query all places in the code where the UI interacts with a database column." Why can't you?

michaelochurch 15y ago

Here are some thoughts I'd put into the mix. 1. Software that is built to deadline will decay, even if the developers are good. That doesn't mean that an occasional deadline is the end, but if a long-term "deadline culture" sets in, get out. A long-standing deadline-oriented culture means you should be looking to jump to another project or company before the maintenance phase starts, because (1) the maintainers will be underappreciated (that's typical deadline culture) and (2) once the original architects get promoted it will be politically impossible to point out the real reason maintainers are unable to deliver in a timely fashion, and the slowest one to run away will get eaten by the bear. It means that technical debt will never be paid off; management will never budget time, and engineers will be too busy to clean up the code. Software engineers generally lack both the political pull and the broad-based knowledge to push back on deadlines and tease out which ones actually matter and which don't. 2. Entropy. Good software is less stable than bad software. Think of this as akin to the "broken windows" theory. Once software reaches a certain state of degradation, each change, although it might fix a bug or add a feature, will make the state of the software worse. There are creeping kinds of badness that can't be caught in incremental code reviews, such as adding 10 lines to a long for-loop or a "necessary" boolean parameter to a method that over time ends up with 15 boolean parameters. Often the managerial solution (once it's far past too late) is to put maintenance of this bad system on the calendar and make it someone's full-time job (instead of a shared responsibility) but no one wants that job and often that work is allocated to marginally skilled junior programmers with no clout. Then you get adverse selection: the more skilled people in that set will leave the project (or company) before they put in enough time to become decent at it. 3. "Pay as you go" maintenance, which includes periodic fixit spells, is always better than after-shit-breaks maintenance. That said, existing tools don't make it easy to revert quality degradation. IDEs really don't perform this function as commonly used. (I'm sure IDEs can be really powerful if well-learned, but people who are dedicated enough to master IDEs are also dedicated enough to jump wholesale to better languages for which IDEs are unnecessary and often poorly-supported. IDEs, in large part, exist to compensate for weak languages.) Code can rot in any language, but one advantage that languages like Scala and Python have is that, because they have REPLs, which are far more useful than any IDE, people can interact with the software at a code-level and fix things while the code is in that "moderately bad" state before it is too late. In 2012, I wouldn't start anything important in a REPL-less language. (C is not "REPL-less" because Unix is the C programming environment. C++ is, not on account of language intrinsics but because it has departed from the small-program Unix philosophy and is used for large-object programming which requires interactivity at a code level.) At least some programmers will have enough of a sense of ownership and citizenry to clean up failing code as they work with it, but if you deprive them of the REPL, the one tool that any good programmer will recognize as essential, they won't put in the work. REPL or Fail: http://michaelochurch.wordpress.com/2012/02/07/repl-or-fail/ http://michaelochurch.wordpress.com/2012/02/07/repl-or-fail/ 4. The transition from being a mediocre to a good and then to a great engineer is about moving away from being an "adder" (someone who increases codebase complexity and functionality, thereby having an additive business value-- ignoring long-term costs of complexity, which may or may not offset that additive value) to a "multiplier" (someone with broad-based positive effects that make the whole team more productive). Contemporary tools and programming environments (Java, C++, IDEs, IOC, dependency injection frameworks) are about helping more mediocre engineers become solid adders at the expense of the really great engineers, whose creativity is constrained by less powerful languages and tools. One of the goals behind Microsoft's professional certifications, the design of VB (and later, the hijacking of Java), and the attempted ghettoization of the command-line (which good engineers like) was to make it possible for huge teams of "commodity" programmers to be productive as adders, with the hope that "someone" would have the patience to staple together the zillion classes they cranked out. From an MBA perspective, this is a win, because 2-4 times more people are eligible to be adders, but it also holds people back from becoming multipliers. The long-term problem is that a team without any multipliers will accumulate complexity and the emergent design (because you want a solid engineer doing your design work, and you can't get them in commodity-programmer environments, "design" coming out of a commodity shop will be ad hoc) will be disastrous. 5. With a few exceptions, the real fuckups in software don't seem to be blameable on a single person. They usually emerge either from jobs no one does (because the people who care about them being done aren't in power) or that too many people do (once code has been passed over by too many hands, it turns to shit).

j45 15y ago

Software sucks because too often developers fail to learn what the software is supposed to do. Developers trivialize things and interpret them in far "superior" ways that lead to huge gaps of "they never told us". Development has to move from just coding, to learning to first understand what details are being managed, and how those details interact in a system in all the stages the details/data exist. If we believe every business is becoming a software business, the reverse is true, all software developers must understand the business more and continually develop the skills to be the bridge between business goals and technology. How to do that? Shut the hell up and learn. Ask (and learn) why things are done a certain way. Uncover any competitive advantages the business has from doing things a certain way before getting on the high horse and deciding to improve the world because it's so obvious. Developers may be surrounded by non-techs, but they certainly might be surprised to see the organization itself does have processes and competitive advantages that have to be maintained for the business to survive. Avoiding the classic SAP-esq kiss of death of doing it the SAP way, wiping out the competitive advantage (seen first hand), and then spending tons of money customizing and automating any ERP to get back to what they had before (and more) seems silly, but I can't say the 70% of failed software projects fare much better. So, before we think we understand something, shut up. Before we think we know better, shut up. Before we think we can simplify things, shut up. Before we think we can make things more efficient, shut up. Shut up, listen to the people using the current systems and processes and learn what is working for them, or not, first. Shut up and learn. Don't finish people's sentences. Don't tune out. Don't think things are beneath you. Don't think you've seen it before, or built it before. At each step ask them if you understand their process correctly before going off to formulate a faster way of doing things for their confirmation. Software has the power to uplift the lives of people and help them get more done with less effort. If you don't value this, don't make the rest of us look bad for your laziness and inability to continually develop your own skills. Once you have learnt why the business does what it does, the way it does, it's fair to ask the question "How should it be?", and see what differs. That, is the beginning of what you should start thinking about. Having integrated custom systems and built new ones to replace existing ones since '99, this is the single worst thing I see. Enough developers simply don't have a healthy paranoia of their understanding. Knowing a little bit about something can make developers just as dangerous as the "business" folks they judge for doing the same. It all comes out in the wash with the 70% software failure rate. Without understanding the data of the business, how it interacts, exists in different stages, and how it needs to be input/output, and why, amongst other things is the leading contributor to software failure. It's as much "the customer didn't know what they wanted" as "developers failed to understand their job is to go learn the business first and then design something to build". To be clear, this can mean working in people's positions first hand to see what they're going through / facing that they can't explain to you. It can mean seeing what state a business is in, infancy (no systems or processes), adolescence (some systems or processes), or maturity (a mature system and process, even if it's all manual). Do those three scenarios equal one approach to all of them? Hell no. There is, though, a few common things to keep in mind: - Ask customers to teach you the business as they know it first. Pretend you're the next apprentice, or the owner's right hand man. Ask to be taught not just how to do everything, but why it's done that way. - Your goal is to get more done with less effort. The software you design and build should not simply make less work for some, and more for others. It should free people from BEING the tools and systems, to USING the tools and systems. The people of an organization should do what they know best, instead of being computers, they should be interacting with each other, and customers. I could go on a long time about this. But it's Sunday and I hope the positive wishes come through.

sodiumphosphate 15y ago

The human race excels at engineering shovels and hammers, knives and other primitive tools; for anything more complex than that our capabilities are still pretty much infantile. Give it a few thousand years. If we can manage to survive it, the miserable suckiness of our software will taper off.

evincarofautumn 15y ago

“No one makes bad software on purpose” is not strictly true: many esoteric programming languages are designed to be “bad” in interesting ways. That extends to any subversion of highly-regarded tropes in games and other media, even the non-interactive kind. It’s also not true that “in order for people to say ‘this sucks’ they have to care enough about the thing you’ve made to spend time with it and recognize how bad it is”. People routinely criticise programming languages and other software they’ve never used before, even if said software doesn’t actually suck much at all.

ken 15y ago

A little while ago I overhead a conversation between some friends of mine, one of whom is an interior designer who does residential remodeling: a: "We always tear out everything, down to the rafters." b: "That sounds expensive." a: "It can be, especially if you find out the wiring or something isn't up to code." b: "What if someone wants only---" a: "No, there's no 'only'." In my experience, if programmers always had a complete design specification before starting, and if we always "tore up" the old mess (down to something unquestionably stable) before making any improvements, our software would be much, much better. It'd probably also cost more. The biggest cause of this that I see is that the people paying for it are not the people using it. In the consumer market we are starting to see that good design does sell (I think it was Gropius who predicted that the cost of design is amortized). But with enterprise software, the people paying for it are rarely the ones using it, so they're perfectly willing to buy a lousy program if it means saving cash in the short term.

icebraining 15y ago
In my experience, if programmers always had a complete design specification before starting, and if we always "tore up" the old mess (down to something unquestionably stable) before making any improvements, our software would be much, much better. It'd probably also cost more. And by the time the software was done, it'd be useless. A house doesn't get obsolete in ten years, but software - which is much more complex than a house - can be obsolete in ten months. Not to mention that I'd rather not be reinventing the wheel every six months.
- 4as198sGxV 15y ago
  I often hear that but it is no true in my experience. Maybe your run-of-the-mill flavour-of-the-month hipster web 2.0 app has a limited shelf life but most enterprise apps stay deployed for years.
  - icebraining 15y ago
    But is it because the needs haven't changed a bit, or because it's good enough and it'd cost too much to replace it? Because if software was always tored out, that would only accentuate the latter problem.

b1daly 15y ago

One reason I don't think gets mentioned enough for software sucking: developers don't really use the product enough to optimize it (they don't have time). Especially for complex applications. If there isn't an effective feedback loop from users about pain points, and an institutional drive to address them, major problems in software persist version after version.

cousin_it 15y ago

In this thread many people give different reasons why they think software sucks. This prompts some meta-questions: 1) Why are all these people so confident, if only a minority of them can be right? 2) What procedure would make everyone converge on the same correct answer?