21 ms·

The problematic culture of “Worse is Better”

126 points by jamii 12y ago

Fuzzwah 12y ago
The font used on this page is difficult to read. I'm running current Chrome on Win7. http://i.imgur.com/QB8RJwl.png http://i.imgur.com/QB8RJwl.png note: I checked that screenshot on another machine and it didn't seem so bad.... so maybe this is also something strange with the monitor / res I'm using... still thought I'd mention it.
- rkuykendall-com 12y ago
  The same website on Chrome, OS X, Retina: http://i.imgur.com/KdvPoEB.png http://i.imgur.com/KdvPoEB.png
  - Fuzzwah 12y ago
    Thanks for taking the time to take a screenie and share it. Looks like I need to investigate why some sites fonts look so bad on this machine.
    - scholia 12y ago
      Firefox, Windows 7 - I don't like the text either http://i.imgur.com/s3V1dwf.jpg http://i.imgur.com/s3V1dwf.jpg
yuliyp 12y ago
The viewpoint the author seems to expound reeks of second system syndrome. That is, he seems to argue that incremental evolution is broken, since the state at any given point is suboptimal given what someone building from scratch would build, having all the lessons of hindsight with them. Of course it is. Yet computer science history is full of overly ambitious projects (Plan9, Vista, Lisp) falling by the wayside as inferior solutions which were more incremental continued to chug along. The author didn't stop to consider why those failed, only to blame a myopic community; as if Lisp being better would have proven itself if only more people gave it a chance. Incremental changes are how we progress. We take the lessons we have learned from what we're doing now, and then try something a little bit different. We can't try and redesign everything at once, so we pick a few things, and other compromises get left in. Compromise is an essential requirement to getting anything big done.
- samstokes 12y ago
  he seems to argue that incremental evolution is broken I think he argues that this sort of absolutism is broken. The author isn't proposing that we discard incremental change, just the uncritical assumption that incremental is the only reasonable change. See his analogy with portfolio theory: he's not even challenging incrementalism as the default, any more than he'd suggest putting 90% of your money into emerging markets.
  - sanderjd 12y ago
    It seems more like a historical observation than an uncritical assumption, that incremental change has shown itself to be more successful. The author's claim seems to be that incremental change has been more successful historically because it has more mindshare. I think that causality is backward.
haberman 12y ago
> “Worse is Better”, in other words, asks us to accept a false dichotomy: either we write software that is ugly and full of hacks, or we are childish idealists who try to create software artifacts of beauty and elegance. I think this criticism is slightly misattributed. Ideologues ask us to accept a false dichotomy. Ideologues exist on both sides of an issue usually. For example, there are most definitely ideologues who believe this same dichotomy exists, but believe that the only option is to choose beauty and elegance, even at the expense of practicality. These are the people who (for example) wish Lisp machines had won and that we lived in a monoculture of only Lisp. I like C++ because I think it's useful, but I'm not a Worse is Better Ideologue. For example, I like Rust as a potential "better is better" replacement for a lot of C++'s use cases. I like Rust particularly because it seriously addresses nearly all of the practical advantages of C++. Many "Better is Better" ideologues would rather just hand-wave away the negatives of the compromises required to achieve their vision (like mandatory GC). Rust proves that "better is better" design can address real-world practical challenges, while also providing an escape hatch back into a more primitive "Worse is Better" kind of world (unsafe blocks). It will be interesting to see if this approach gains the traction that I hope it will.
- pcwalton 12y ago
  I think "worse is better" vs. "better is better" is best understood as a continuum rather than a black-and-white dichotomy. The popular impression of Rust is indeed better-is-better as you say, but many folks coming from Haskell think of Rust as a worse-is-better language, as it has control flow, impurity, strictness, no higher-kinded types, method notation, object types (as opposed to first-class existentials), curly brackets, etc. The truth is that they're both right: Rust is pragmatic where it needed to be and novel where it needed to be. I think"worse is better" vs. "better is better" is fundamentally business-driven: does your product deliver value through compatibility/familiarity or by doing things in a technically better way than the competition? Both have been successful, and choosing the right one is basically a question of business judgment.
- handsomeransoms 12y ago
  Great point, just a nit: Rust does not have mandatory GC.
dasil003 12y ago
I was heavily critical of the author's original rant about CSS, and my citation of worse-is-better probably at least partially inspired him to write this post (http://pchiusano.github.io/2014-07-02/css-is-unnecessary#comment-1468335855 http://pchiusano.github.io/2014-07-02/css-is-unnecessary#com...). However he completely misunderstood my point to suggest that worst-is-better is a conscious design quality. In no way did I mean that, and I don't believe Richard Gabriel meant that either. Worse-is-better is about the reason certain solutions win in the market; it's about an evolutionary trait, not a design philosophy. Look at it this way. If there are 100 possible technical solutions to a given computing problem, the ones that solve the problem more comprehensively are naturally going to tend to be more complex, this complexity comes with an adoption cost, and that cost works against the likelihood of adoption. Furthermore, when you are talking about something that solves the scope of problems which CSS solves, there is no way you can just sit down and design a better system, it will need to go through many iterations to solve all the things that CSS solves (which no single human being is comprehensively aware of btw). In order to see that kind of investment a system needs buy-in from downstream users over long a period of time. So the strawman that the author sets up is the idea that someone is out there selling a worse solution on purpose because of this meme which is simply an observation of how technical adoption markets play out. Of course such foolish people may be out there, but no intelligent developer sets out to create something that is deliberately worse. Rather, each tradeoff is considered in its specific contemporary context of the imperfect information available. Whether a solution gains traction and wins in the marketplace is has nothing to do with the subjective qualities of "worse" or "better", but rather is a confluence of the state of the market at various points in time: how well it solves immediate problems, how well it works with existing tech, how easy to adopt, and of course some amount of hype loosely related to the aforementioned. What doesn't play a huge role is how ugly the evolution of this tech is going to look 20 years down the line when the entire landscape has evolved. It's a little tiresome when a young idealist comes into a 25-year-old field (I'm guessing the author is not much older than that himself), pisses on the hard work of thousands of people pushing web tech forward bit by bit over decades, and says it should be replaced wholesale because it's just rubbish, and then when someone tells them that you're welcome to try but you'll never get any traction in that Sisyphean task, he responds that people aren't engaging in a rational discussion.
pron 12y ago
I can argue with many points made in this article, but there's one assumption at the very core that I think is false: that we know how to do it better. There have been many ideas in software development floating around in the last couple of decades, from pure functional programming to interactive programming and programming by example. All of these approaches -- and the many others I haven't mentioned -- have explored interesting and possibly promising future directions, but all are yet to demonstrate consistently superior results, across various domains, to the "broken" system we have today. We are still exploring, and maybe some of the ideas people play with today will serve as the seeds of future, revolutionary development procedures. But it's not like we know today how to do it significantly better even if we wanted to do away with the "old" ways right noe.
- jamii 12y ago
  I read it more as frustration with the commonly expressed opinion that revolutionary attempts cannot succeed and that only incremental evolution is worth attempting. Not arguing that everything should be revolutionised, just that there is room for attempts and that they should be evaluated on their merits rather than dismissed out of hand. I suspect a lot of programmers develop a kind of immune response to talk of revolution, simply because it so often comes from people who haven't understood the problem, are not aware of the history or choose to ignore the realities of compatibility and market momentum.
- sanderjd 12y ago
  Yep, in my experience with my own software, today's "revolutionary, way better designed approach" is tomorrow's "hacky awfulness that needs a revolutionary, way better redesign", ad infinitum. It's much cheaper to accept and incrementally improve an imperfect solution. But I recognize the possibility that this is purely a personal experience and better developers than I really do know "how to do it better".
  - RyanZAG 12y ago
    > better developers than I really do know "how to do it better". They don't. They're just selling something. Not to say some approaches aren't better than others, it's just the only way to know which approach is really better is to implement the same problem space in both and compare. Anybody telling you that X is better than Y at Z without personally using both X and Y to do Z is just trying to sell you something. Beware. It's also why the best test when deciding on a programming language or framework is to look at what others have actually created with it.
jasode 12y ago
Discussing the meme "worse is better" is difficult because there are different interpretations and usages of that phrase. It's description vs prescription. The blog author chose the prescription interpretation. I can't tell if the author unknowingly did this because he did not see a separate evolution of that meme. First interpretation is the descriptive usage. We could explicitly prefix the meme and qualify it as RGWIB (Richard-Gabriel-Worse-is-Better). The original label was the observation that "simpler" software was more successful than more full-featured software with ambitious goals. Richard's thesis wasn't about "hacks" but about small and simple things that satisfy users and builds momentum. Second interpretation is the prescriptive (or self-justifying) stance which I might call HOBWIB (Hacks-Ok-Because-Worse-is-Better.) This appears to be what the blogger is complaining about. However, HOBWIB isn't Richard Gabriel's thesis. That "worse is better" has taken on a life of its own and repurposed by others who are unaware of RG's original meaning is just a circumstance of adopting snappy soundbites. Whatever behavior the author is complaining about would exist whether the exact phrase "worse is better" existed or not. >“Worse is Better”, in other words, asks us to accept a false dichotomy: either we write software that is ugly and full of hacks, or we are childish idealists who try to create software artifacts of beauty and elegance. That label does not have that power over us. For example, we have a label for certain human behavior and call it "passive aggressive." The existence of that phrase did not force us to choose whether to be passive aggressive or not. Likewise, thinking that the existence of 3 words "worse is better" is forcing us into a dichotomy of bad vs good design is flawed analysis.
- akkartik 12y ago
  Totally. RPG's WIB said nothing about bad design. C didn't do better than lisp because it was a hack. It was an incredibly clean design, as clean as the original lisp. RPG was comparing two clean designs, and trying to describe the evolutionary properties of one that made it more fit in its environment (ie us) than the other. The biggest such property is simplicity of implementation. (Later C compilers have gotten more complex and ++, but a modern compiler wouldn't have been as competitive in an earlier world where C wasn't already adopted: http://www.ribbonfarm.com/2011/09/23/the-milo-criterion http://www.ribbonfarm.com/2011/09/23/the-milo-criterion)
- 12y ago
michaelochurch 12y ago
"Worse Is Better" has evolved into a monster. Originally, it looked like this: * MIT philosophy: never compromise on correctness, even in bizarre corner cases. Aim for conceptual beauty to a programmer. * New Jersey (Bell Labs) philosophy: comprise on correctness for simplicity or performance. In 1985, six years before "Worse Is Better" was originally written, the "New Jersey" attitude was probably more useful. Most people, if they wanted to write acceptably performant software, had to do it in assembly. C was less of a leap, conceptually and in terms of average-case performance, than Lisp was. People who'd been writing assembly programs for years could learn how to write performant C. Writing performant Lisp would be much harder. A contemporary Common Lisp executable is at least 40 MB (obviously, that wasn't the case in the 1980s); at that time, 1 MB was a powerful machine. "Worse is better" worked in the 1970s and '80s. If every piece of computing work had to be perfect before it could be shipped, we'd be far behind where we are. Also, quite a number of the original Unix programs were for natural-language processing (at a level that'd be primitive today) and paper formatting. With the resources of the time, it would've been impossible to get much of that stuff perfectly right anyway. Bell Labs wasn't full of the anti-intellectual idiots who invoke worse-is-better, lean-startup tripe today. They knew what they were doing. They knew the compromises they were working under. They bet on Unix and C rather than Lisp machines, and they were right. In 2014, thanks to our ability to stand on the shoulders of giants that were built using C, we have machines that can efficiently run code in pretty much any language, so the C programmers and the Lispers have won. At least, on that front. However, the "worse is better" lesson doesn't apply nearly as well in 2014. We can do about 500,000 times as much computation per dollar as we could in 1991. That's 500,000 times (at least!) as many opportunities for things to go wrong. A bug that happens once per 100 billion operations used to be negligible and now it's often not. Unfortunately, we have an industry beset by mediocrity, in which commodity developers are managed by commodity business executives to work on boring problems, and low software quality is simply tolerated as something we'll always have to deal with. Instead of the knowing compromise of Bell Labs, "worse is better" has evolved into the slipshod fatalism of business people who just assume that software will be buggy, ugly, hard to use, and usually discarded after about 5 years. Yet we're now in a time where, for most problems, we can affordably do them correctly and, because things happen so much faster now, we often put ourselves and our businesses at serious risk if we don't.
jhallenworld 12y ago
"Perfect is the enemy of better"
zubairismail 12y ago
I agree with the points in 100%
al2o3cr 12y ago
"Other professions, like medicine, the law, and engineering, have values and a professional ethic, where certain things are valued for their own sake." [citation needed] I can't parse what exactly this is supposed to refer to. Doctors treat the patients they get - and frequently wind up with no choice but to use treatments that are only barely worse than the disease (see the history of chemotherapy drugs, for instance). Outside of legal academia, the legal profession is always working with imperfect information, imperfect systems, imperfect people making the calls (ffs, I feel a Law and Order episode breaking out)... To me, the giant disconnect is that we've still got two threads of thought still mixed together under "Computer Science": the actual science-y bit, and the "shovel bits from A to B" software construction part. It's as if materials science, structural engineering, and construction management were all lumped together. Putting a new sidewalk in does not require the development of an entirely new method for making concrete.
- karmelapple 12y ago
  How long did it take these three different fields to fully separate and have their own concentrations in universities? That may give us a timeline on how long it could be in the computer science, software engineering/architecture (does such a concentration exist involving architecture?), and software development methodology (project management... which is almost no existent in academia) fields.
  - dreamfactory2 12y ago
    Computer science used to be quite separate from application development and the nearest it would come to actual software was low level OS componentry. Any conglomeration is more recent.
- im3w1l 12y ago
  Software is different from laying concrete. When you lay concrete, you do the same thing over and over again. In software, on the other, we try to automate any recurring task. We are trying to stand on the shoulders of our predecessors, and in turn allow those that come after to reach even higher.
- 12y ago
orangeduck 12y ago
I'm a big advocate of "worse is better" - in fact I put it in my bio even at the risk of scaring off potential colleagues or employers. The real meaning of "worse is better" is of course subjective and complicated. And as has been pointed out in these comments, "worse is better" is not about creating "worse" software and then marketing it as "better". It is something much more philosophical. In my eyes "worse is better" is about the mindset of approaching a task. It is about diving right in and learning through production - without being paralysed by the idea of introducing hacks or ugly design. It is the idea that, for the moment, there isn't a need to be worried about covering every edge case or possible failure option. It persuades you to focus on something simple and easy to explain, with a single purpose or intent. It is better to produce something (anything) and see where it takes you. It also says how important it is to embrace contribution and collaboration. How important it is to, after some threshold, release yourself from feelings of ownership. But if I had to nail down exactly why I believe "worse" is so successful ("better") it is because those that create "worse" software don't focus on the software - they focus on the idea. From that the software is painfully drawn. The software might suck, but I believe ideas are better. They are more persistant, easily explored, dynamic, and shareable than software. Ideas that are good, simple, and easily taught are far more important than well designed software. That is why they survive. There are lots of programmers and hackers who don't believe in "worse is better". Sometimes you seen them on HN with a fantastic new programming language (or something) they have designed and built in isolation - perfect in every aspect (at least to them). Nothing quite hurts like their confusion when interest dwindles and their software is forgotten. All they had seen on HN were "worse" links every day, and after years they had provided "better" - to them it is criminal that it hasn't been picked and gained momentum. Worse is better is not going away, and I think you can either engage yourself in it as a philosophy, or struggle.
- empthought 12y ago
  "Sometimes you seen them on HN with a fantastic new programming language (or something) they have designed and built in isolation - perfect in every aspect (at least to them). Nothing quite hurts like their confusion when interest dwindles and their software is forgotten." I suspect you've described Rich Hickey to a tee here. /s
Animats 12y ago
The one-line summary: "Basically, no one seems to grasp that when stuff that's fundamental is broken, what you get is a combinatorial explosion of bullshit." Exactly. A few examples. - C's "the language has no idea how big an array is" problem. Result: decades of buffer overflows, and a whole industry finding them, patching them, and exploiting them. - Delayed ACKs in TCP. OK idea, but the fixed timer was based on human typing speed, copied from X.25 accumulation timers. Result: elaborate workarounds, network stalls. - C's "#include" textual approach to definition inclusion. Result: huge, slow builds, hacks like "precompiled headers". - HTML float/clear as a layout mechanism. Result: Javascript libraries for layout on top of the browser's layout engine. Absolute positioning errors. Text on top of text or offscreen. - The UNIX protection model, where the finest-grain entity is the user. Any program can do anything the user can do, and hostile programs do. Result: the virus and anti-virus industries. - Makefiles. Using dependency relationships was a good idea. Having them be independent of the actual dependencies in the program wasn't. Result: "make depend", "./configure", and other painful hacks. - Peripheral-side control of DMA. Before PCs, IBM mainframes had "channels", which effectively had an MMU between device and memory, so that devices couldn't blither all over memory. Channels also provided a uniform interface for all devices. IBM PCs, like many minicomputers, originally had memory and devices on the same bus. This reduced transistor count back when it mattered. But it meant that devices could write all over memory, and devices and drivers had be trusted. Three decades later, when transistor counts don't matter, we still have that basic architecture. Result: drivers still crashing operating systems, many drivers still in kernel, devices able to inject malware into systems. - Poor interprocess communication in operating systems. What's usually needed is a subroutine call. What the OS usually gives you is an I/O operation. QNX gets this right. IPC was a retrofit in the UNIX/Linux world, and still isn't very good. Fast IPC requires very tight coordination between scheduling and IPC, or each IPC operation puts somebody at the end of the line for CPU time. Result: elaborate, slow IPC systems built on top of sockets, pipes, channels, shared memory, etc. Programs too monolithic. - Related to this, poor support for "big objects". A "big object" is something which can be called and provides various functions, but has an arms-length relationship with the caller and needs some protection from it. Examples are databases, network stacks, and other services. We don't even have a standard term for this. Special-purpose approaches include talking to the big object over a socket (databases), putting the big object in the kernel (network stacks), and trying to use DLL/shared object mechanisms in the same or partially shared address space. General purpose approaches include CORBA, OLE, Google protocol buffers and, perhaps, REST/JSON. Result: ad-hoc hacks for each shared object.
jamii 12y ago
Calling people out as #worseisworse is almost certainly going to be ineffective - attacking people just makes them defensive and argumentative. Instead, can we find useful principles to steer us away from the two bogeymen (hack-it-till-it-works vs useless-ivory-tower-wankery)? Some ideas: The real world exists. Successful solutions usually come from actually understanding the problem and all it's constraints. Solutions that are dismissed as overly academic tend to fall afoul of solving just the immediate problem and ignoring eg compatibility, switching costs, accessibility to beginners. Similarly, the linux community spent a long time burying it's head in the sane w.r.t. usability and appearance. Sure, people shouldn't care how pretty your UI is. But they do and you can't change that by burying your head in the sand. Everything has a cost. The benefits of your new solution and the switching cost have to outweigh the pain of the old solution by a large margin. The original 'worse is better' was really an observation that simple solutions that do half the job are often cheaper than a hugely complicated solution that can do everything. If you spend every day coming up with better ways to make widgets, it's easy to believe that everyone wants to have as much widget-customising power as possible and is willing to invest time in learning to get that power. If you actually talk to your users you might find that only having three kinds of widget isn't annoying enough to make them spend time learning something better.
- afarrell 12y ago
  I agree with this except possibly one thing. Saying "Sure, people shouldn't care how pretty your UI is." mischaracterizes user interface design as being about prettiness rather than interaction. But that might in fact be your very point and you might actually talking about the mischaracterization of others.
  - jamii 12y ago
    I was thinking of the fact that beautiful software is perceived as more usable, all else being equal (http://www.ergonomicsclass.com/wp-content/uploads/2011/11/Tractinsky_2000.pdf http://www.ergonomicsclass.com/wp-content/uploads/2011/11/Tr...). This is irrational but not controllable. Unfortunately many good solutions lose out in the market because their developers make the mistake of expecting users to be rational econs, rather than accepting reality and working around it.
slashnull 12y ago
I'm just gonna go full Poindexter and say that Richard Gabriel did try to distance himself from worse is better, at first, but then he veered wildly in the following years between the two positions. And, the fundamental idea of Worse is Better is so incredibly older than UNIX, even in the field of computer science; John Von Neumann said himself that the Von Neumann machine was a temporary workaround and that a better architecture would quickly replace it. I live in a near constant fight in the rebel factions of Better and so far, I have to reckon we get constantly massacred by the Empire of Worse.
slashnull 12y ago
But seriously, it takes some nerve to write a blogpost against Worse is Better that's on every aspect worse than the paper that originally codified Worse is Better. Oh wait, no, is this lack of quality justifiable because this content-free 2 minutes read is more efficient and easier to write than a serious exploration of the consequences of whatever the author was ranting about?
- account_306 12y ago
  I'll probably get shadow banned for agreeing with this, but who cares anyway. The article ignores LEAKY ABSTRACTION. that's all there is to say. Now lets have some marketers tell us why that's a good thing and we can get back on this irony loop, this irony loop, this irony loop.
dkarapetyan 12y ago
Isn't twitter also an example of worse is better. Why send the people willing to engage with your argument to twitter then?
Htsthbjig 12y ago
What this man calls "worse" actually means "something that in better in ways I fail to understand in my simplistic reduction of the complex world". I love Lisp. I used it a lot for creating code that elegantly modifies itself. But my entire software company succeeded because of languages like C/C++ and python, not because of Lisp or any "functional programming language of the week". C gives you raw power that nobody else does. The fact that we could use c on c++ did become very useful so many times. Some people believe that forcing other people not to use things like pointers is a good thing, it is "better". For me it is the same as forcing people not to use sharpen edges on knifes for their own good. Yes, it is better in the sense that people wont cut themselves with knifes. But it is worse on other areas too. And if you let people choose, they will choose to continue using their knifes until something genuinely better appears. This is exactly what people like this man can't stand, people choosing on their own to use something they don't like so they want to force their "better" way(my way or the highway). If you have something better, well, show us the code, instead of ranting, and you will discover the fact that making anything that people actually want to use is way harder than ranting in a blog.
- dllthomas 12y ago
  "For me it is the same as forcing people not to use sharpen edges on knifes for their own good. Yes, it is better in the sense that people wont cut themselves with knifes." People cut themselves far worse trying to use a knife that's too dull for their task than a knife that's too sharp. Sharp knives are only safer when you're not using the knife (more likely to be cut by a sharp knife in a drawer than a dull knife in a drawer, &c).
neito 12y ago
Honestly, I think it's deeper than this. Even today, we have people who intentionally seek out ugly, imperfect designs because they think they work better. We have a cultural idea (at least, I can speak for the United States, hopefully some others will chime in) that "real" work is ugly, gross, and messy. Heck, I even had a friend who chided people who played a particular version of CounterStrike because it was "Too polished". We're measuring in one dimension something that's two dimensional: Work vs. Not work and Beauty vs. Uglyness. We steep in this cultural broth of the idea that "real work is ugly", and then wonder why the tools we decide to do "work" in are "ugly".
cwyers 12y ago
"This 'Worse is Better' notion that only incremental change is possible, desirable, or even on the table for discussion is not only impractical, it makes no sense." It makes all kinds of sense. Consider for a second the sort-of parable of Chesterton's fence. As G.K. Chesterton wrote: "In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, 'I don’t see the use of this; let us clear it away.' To which the more intelligent type of reformer will do well to answer: 'If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.'" It's basically that whole Spolsky think about why you shouldn't rewrite code from scratch[1]: "Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95. Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters. When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work." Broadly speaking: you, for ANY definition of you, are unable to design a perfect system at the first go. You will not account for all use cases, there will be edge cases you don't consider, so on and so forth. But it goes further than that: if you want to design something better than C++, you need to understand why so many people use C++. If you want to replace CSS, you need to understand why CSS is popular. If your thinking on the matter hasn't evolved much past "CSS is unnecessary" and blaming a single catchy essay for every decision you disagree with, then instead of writing essays about how everyone else is doing it wrong, maybe you should spend more time trying to understand what everyone is trying to do, why they're trying to do it and what resources they have to do it with. And THEN maybe I'll let you tear that fence down. 1) http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
dreamfactory2 12y ago
I always associated worse is better with VHS vs Betamax rather than incrementalism i.e. utility realised > potential utility
dools 12y ago
For the record I think that writing software commercially should only consider the bottom line. What you do in your own time is your business; that's why open source is good for innovation through revolution. Ethics for legal and medical professions is a broken analogy because all of their ethical considerations focus on outcomes for clients/patients, not the details of how their services are executed.
dbenhur 12y ago
The author's Closing Remarks give rather short-shrift to the nuanced thinking Dick Gabriel has contributed to this idea. Gabriel's "Worse is Better" page https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html concludes with: "You might think that by the year 2000 I would have settled what I think of worse is better - after over a decade of thinking and speaking about it, through periods of clarity and periods of muck, and through periods of multi-mindedness on the issues. But, at OOPSLA 2000, I was scheduled to be on a panel entitled "Back to the Future: Is Worse (Still) Better?" And in preparation for this panel, the organizer, Martine Devos, asked me to write a position paper, which I did, called "Back to the Future: Is Worse (Still) Better?" In this short paper, I came out against worse is better. But a month or so later, I wrote a second one, called "Back to the Future: Worse (Still) is Better!" which was in favor of it. I still can’t decide. Martine combined the two papers into the single position paper for the panel, and during the panel itself, run as a fishbowl, participants routinely shifted from the pro-worse-is-better side of the table to the anti-side. I sat in the audience, having lost my voice giving my Mob Software talk that morning, during which I said, "risk-taking and a willingness to open one’s eyes to new possibilities and a rejection of worse-is-better make an environment where excellence is possible. Xenia invites the duende, which is battled daily because there is the possibility of failure in an aesthetic rather than merely a technical sense." Decide for yourselves."

126 points by jamii 12y ago

The font used on this page is difficult to read. I'm running current Chrome on Win7. http://i.imgur.com/QB8RJwl.png http://i.imgur.com/QB8RJwl.png note: I checked that screenshot on another machine and it didn't seem so bad.... so maybe this is also something strange with the monitor / res I'm using... still thought I'd mention it.

rkuykendall-com 12y ago
The same website on Chrome, OS X, Retina: http://i.imgur.com/KdvPoEB.png http://i.imgur.com/KdvPoEB.png
- Fuzzwah 12y ago
  Thanks for taking the time to take a screenie and share it. Looks like I need to investigate why some sites fonts look so bad on this machine.
  - scholia 12y ago
    Firefox, Windows 7 - I don't like the text either http://i.imgur.com/s3V1dwf.jpg http://i.imgur.com/s3V1dwf.jpg

yuliyp 12y ago

The viewpoint the author seems to expound reeks of second system syndrome. That is, he seems to argue that incremental evolution is broken, since the state at any given point is suboptimal given what someone building from scratch would build, having all the lessons of hindsight with them. Of course it is. Yet computer science history is full of overly ambitious projects (Plan9, Vista, Lisp) falling by the wayside as inferior solutions which were more incremental continued to chug along. The author didn't stop to consider why those failed, only to blame a myopic community; as if Lisp being better would have proven itself if only more people gave it a chance. Incremental changes are how we progress. We take the lessons we have learned from what we're doing now, and then try something a little bit different. We can't try and redesign everything at once, so we pick a few things, and other compromises get left in. Compromise is an essential requirement to getting anything big done.

samstokes 12y ago
he seems to argue that incremental evolution is broken I think he argues that this sort of absolutism is broken. The author isn't proposing that we discard incremental change, just the uncritical assumption that incremental is the only reasonable change. See his analogy with portfolio theory: he's not even challenging incrementalism as the default, any more than he'd suggest putting 90% of your money into emerging markets.
- sanderjd 12y ago
  It seems more like a historical observation than an uncritical assumption, that incremental change has shown itself to be more successful. The author's claim seems to be that incremental change has been more successful historically because it has more mindshare. I think that causality is backward.

haberman 12y ago

> “Worse is Better”, in other words, asks us to accept a false dichotomy: either we write software that is ugly and full of hacks, or we are childish idealists who try to create software artifacts of beauty and elegance. I think this criticism is slightly misattributed. Ideologues ask us to accept a false dichotomy. Ideologues exist on both sides of an issue usually. For example, there are most definitely ideologues who believe this same dichotomy exists, but believe that the only option is to choose beauty and elegance, even at the expense of practicality. These are the people who (for example) wish Lisp machines had won and that we lived in a monoculture of only Lisp. I like C++ because I think it's useful, but I'm not a Worse is Better Ideologue. For example, I like Rust as a potential "better is better" replacement for a lot of C++'s use cases. I like Rust particularly because it seriously addresses nearly all of the practical advantages of C++. Many "Better is Better" ideologues would rather just hand-wave away the negatives of the compromises required to achieve their vision (like mandatory GC). Rust proves that "better is better" design can address real-world practical challenges, while also providing an escape hatch back into a more primitive "Worse is Better" kind of world (unsafe blocks). It will be interesting to see if this approach gains the traction that I hope it will.

pcwalton 12y ago
I think "worse is better" vs. "better is better" is best understood as a continuum rather than a black-and-white dichotomy. The popular impression of Rust is indeed better-is-better as you say, but many folks coming from Haskell think of Rust as a worse-is-better language, as it has control flow, impurity, strictness, no higher-kinded types, method notation, object types (as opposed to first-class existentials), curly brackets, etc. The truth is that they're both right: Rust is pragmatic where it needed to be and novel where it needed to be. I think"worse is better" vs. "better is better" is fundamentally business-driven: does your product deliver value through compatibility/familiarity or by doing things in a technically better way than the competition? Both have been successful, and choosing the right one is basically a question of business judgment.
handsomeransoms 12y ago
Great point, just a nit: Rust does not have mandatory GC.

dasil003 12y ago

I was heavily critical of the author's original rant about CSS, and my citation of worse-is-better probably at least partially inspired him to write this post (http://pchiusano.github.io/2014-07-02/css-is-unnecessary#comment-1468335855 http://pchiusano.github.io/2014-07-02/css-is-unnecessary#com...). However he completely misunderstood my point to suggest that worst-is-better is a conscious design quality. In no way did I mean that, and I don't believe Richard Gabriel meant that either. Worse-is-better is about the reason certain solutions win in the market; it's about an evolutionary trait, not a design philosophy. Look at it this way. If there are 100 possible technical solutions to a given computing problem, the ones that solve the problem more comprehensively are naturally going to tend to be more complex, this complexity comes with an adoption cost, and that cost works against the likelihood of adoption. Furthermore, when you are talking about something that solves the scope of problems which CSS solves, there is no way you can just sit down and design a better system, it will need to go through many iterations to solve all the things that CSS solves (which no single human being is comprehensively aware of btw). In order to see that kind of investment a system needs buy-in from downstream users over long a period of time. So the strawman that the author sets up is the idea that someone is out there selling a worse solution on purpose because of this meme which is simply an observation of how technical adoption markets play out. Of course such foolish people may be out there, but no intelligent developer sets out to create something that is deliberately worse. Rather, each tradeoff is considered in its specific contemporary context of the imperfect information available. Whether a solution gains traction and wins in the marketplace is has nothing to do with the subjective qualities of "worse" or "better", but rather is a confluence of the state of the market at various points in time: how well it solves immediate problems, how well it works with existing tech, how easy to adopt, and of course some amount of hype loosely related to the aforementioned. What doesn't play a huge role is how ugly the evolution of this tech is going to look 20 years down the line when the entire landscape has evolved. It's a little tiresome when a young idealist comes into a 25-year-old field (I'm guessing the author is not much older than that himself), pisses on the hard work of thousands of people pushing web tech forward bit by bit over decades, and says it should be replaced wholesale because it's just rubbish, and then when someone tells them that you're welcome to try but you'll never get any traction in that Sisyphean task, he responds that people aren't engaging in a rational discussion.

pron 12y ago

I can argue with many points made in this article, but there's one assumption at the very core that I think is false: that we know how to do it better. There have been many ideas in software development floating around in the last couple of decades, from pure functional programming to interactive programming and programming by example. All of these approaches -- and the many others I haven't mentioned -- have explored interesting and possibly promising future directions, but all are yet to demonstrate consistently superior results, across various domains, to the "broken" system we have today. We are still exploring, and maybe some of the ideas people play with today will serve as the seeds of future, revolutionary development procedures. But it's not like we know today how to do it significantly better even if we wanted to do away with the "old" ways right noe.

jamii 12y ago
I read it more as frustration with the commonly expressed opinion that revolutionary attempts cannot succeed and that only incremental evolution is worth attempting. Not arguing that everything should be revolutionised, just that there is room for attempts and that they should be evaluated on their merits rather than dismissed out of hand. I suspect a lot of programmers develop a kind of immune response to talk of revolution, simply because it so often comes from people who haven't understood the problem, are not aware of the history or choose to ignore the realities of compatibility and market momentum.
sanderjd 12y ago
Yep, in my experience with my own software, today's "revolutionary, way better designed approach" is tomorrow's "hacky awfulness that needs a revolutionary, way better redesign", ad infinitum. It's much cheaper to accept and incrementally improve an imperfect solution. But I recognize the possibility that this is purely a personal experience and better developers than I really do know "how to do it better".
- RyanZAG 12y ago
  > better developers than I really do know "how to do it better". They don't. They're just selling something. Not to say some approaches aren't better than others, it's just the only way to know which approach is really better is to implement the same problem space in both and compare. Anybody telling you that X is better than Y at Z without personally using both X and Y to do Z is just trying to sell you something. Beware. It's also why the best test when deciding on a programming language or framework is to look at what others have actually created with it.

jasode 12y ago

Discussing the meme "worse is better" is difficult because there are different interpretations and usages of that phrase. It's description vs prescription. The blog author chose the prescription interpretation. I can't tell if the author unknowingly did this because he did not see a separate evolution of that meme. First interpretation is the descriptive usage. We could explicitly prefix the meme and qualify it as RGWIB (Richard-Gabriel-Worse-is-Better). The original label was the observation that "simpler" software was more successful than more full-featured software with ambitious goals. Richard's thesis wasn't about "hacks" but about small and simple things that satisfy users and builds momentum. Second interpretation is the prescriptive (or self-justifying) stance which I might call HOBWIB (Hacks-Ok-Because-Worse-is-Better.) This appears to be what the blogger is complaining about. However, HOBWIB isn't Richard Gabriel's thesis. That "worse is better" has taken on a life of its own and repurposed by others who are unaware of RG's original meaning is just a circumstance of adopting snappy soundbites. Whatever behavior the author is complaining about would exist whether the exact phrase "worse is better" existed or not. >“Worse is Better”, in other words, asks us to accept a false dichotomy: either we write software that is ugly and full of hacks, or we are childish idealists who try to create software artifacts of beauty and elegance. That label does not have that power over us. For example, we have a label for certain human behavior and call it "passive aggressive." The existence of that phrase did not force us to choose whether to be passive aggressive or not. Likewise, thinking that the existence of 3 words "worse is better" is forcing us into a dichotomy of bad vs good design is flawed analysis.

akkartik 12y ago
Totally. RPG's WIB said nothing about bad design. C didn't do better than lisp because it was a hack. It was an incredibly clean design, as clean as the original lisp. RPG was comparing two clean designs, and trying to describe the evolutionary properties of one that made it more fit in its environment (ie us) than the other. The biggest such property is simplicity of implementation. (Later C compilers have gotten more complex and ++, but a modern compiler wouldn't have been as competitive in an earlier world where C wasn't already adopted: http://www.ribbonfarm.com/2011/09/23/the-milo-criterion http://www.ribbonfarm.com/2011/09/23/the-milo-criterion)
12y ago

michaelochurch 12y ago

"Worse Is Better" has evolved into a monster. Originally, it looked like this: * MIT philosophy: never compromise on correctness, even in bizarre corner cases. Aim for conceptual beauty to a programmer. * New Jersey (Bell Labs) philosophy: comprise on correctness for simplicity or performance. In 1985, six years before "Worse Is Better" was originally written, the "New Jersey" attitude was probably more useful. Most people, if they wanted to write acceptably performant software, had to do it in assembly. C was less of a leap, conceptually and in terms of average-case performance, than Lisp was. People who'd been writing assembly programs for years could learn how to write performant C. Writing performant Lisp would be much harder. A contemporary Common Lisp executable is at least 40 MB (obviously, that wasn't the case in the 1980s); at that time, 1 MB was a powerful machine. "Worse is better" worked in the 1970s and '80s. If every piece of computing work had to be perfect before it could be shipped, we'd be far behind where we are. Also, quite a number of the original Unix programs were for natural-language processing (at a level that'd be primitive today) and paper formatting. With the resources of the time, it would've been impossible to get much of that stuff perfectly right anyway. Bell Labs wasn't full of the anti-intellectual idiots who invoke worse-is-better, lean-startup tripe today. They knew what they were doing. They knew the compromises they were working under. They bet on Unix and C rather than Lisp machines, and they were right. In 2014, thanks to our ability to stand on the shoulders of giants that were built using C, we have machines that can efficiently run code in pretty much any language, so the C programmers and the Lispers have won. At least, on that front. However, the "worse is better" lesson doesn't apply nearly as well in 2014. We can do about 500,000 times as much computation per dollar as we could in 1991. That's 500,000 times (at least!) as many opportunities for things to go wrong. A bug that happens once per 100 billion operations used to be negligible and now it's often not. Unfortunately, we have an industry beset by mediocrity, in which commodity developers are managed by commodity business executives to work on boring problems, and low software quality is simply tolerated as something we'll always have to deal with. Instead of the knowing compromise of Bell Labs, "worse is better" has evolved into the slipshod fatalism of business people who just assume that software will be buggy, ugly, hard to use, and usually discarded after about 5 years. Yet we're now in a time where, for most problems, we can affordably do them correctly and, because things happen so much faster now, we often put ourselves and our businesses at serious risk if we don't.

jhallenworld 12y ago

"Perfect is the enemy of better"

zubairismail 12y ago

I agree with the points in 100%

al2o3cr 12y ago

"Other professions, like medicine, the law, and engineering, have values and a professional ethic, where certain things are valued for their own sake." [citation needed] I can't parse what exactly this is supposed to refer to. Doctors treat the patients they get - and frequently wind up with no choice but to use treatments that are only barely worse than the disease (see the history of chemotherapy drugs, for instance). Outside of legal academia, the legal profession is always working with imperfect information, imperfect systems, imperfect people making the calls (ffs, I feel a Law and Order episode breaking out)... To me, the giant disconnect is that we've still got two threads of thought still mixed together under "Computer Science": the actual science-y bit, and the "shovel bits from A to B" software construction part. It's as if materials science, structural engineering, and construction management were all lumped together. Putting a new sidewalk in does not require the development of an entirely new method for making concrete.

karmelapple 12y ago
How long did it take these three different fields to fully separate and have their own concentrations in universities? That may give us a timeline on how long it could be in the computer science, software engineering/architecture (does such a concentration exist involving architecture?), and software development methodology (project management... which is almost no existent in academia) fields.
- dreamfactory2 12y ago
  Computer science used to be quite separate from application development and the nearest it would come to actual software was low level OS componentry. Any conglomeration is more recent.
im3w1l 12y ago
Software is different from laying concrete. When you lay concrete, you do the same thing over and over again. In software, on the other, we try to automate any recurring task. We are trying to stand on the shoulders of our predecessors, and in turn allow those that come after to reach even higher.
12y ago

orangeduck 12y ago

I'm a big advocate of "worse is better" - in fact I put it in my bio even at the risk of scaring off potential colleagues or employers. The real meaning of "worse is better" is of course subjective and complicated. And as has been pointed out in these comments, "worse is better" is not about creating "worse" software and then marketing it as "better". It is something much more philosophical. In my eyes "worse is better" is about the mindset of approaching a task. It is about diving right in and learning through production - without being paralysed by the idea of introducing hacks or ugly design. It is the idea that, for the moment, there isn't a need to be worried about covering every edge case or possible failure option. It persuades you to focus on something simple and easy to explain, with a single purpose or intent. It is better to produce something (anything) and see where it takes you. It also says how important it is to embrace contribution and collaboration. How important it is to, after some threshold, release yourself from feelings of ownership. But if I had to nail down exactly why I believe "worse" is so successful ("better") it is because those that create "worse" software don't focus on the software - they focus on the idea. From that the software is painfully drawn. The software might suck, but I believe ideas are better. They are more persistant, easily explored, dynamic, and shareable than software. Ideas that are good, simple, and easily taught are far more important than well designed software. That is why they survive. There are lots of programmers and hackers who don't believe in "worse is better". Sometimes you seen them on HN with a fantastic new programming language (or something) they have designed and built in isolation - perfect in every aspect (at least to them). Nothing quite hurts like their confusion when interest dwindles and their software is forgotten. All they had seen on HN were "worse" links every day, and after years they had provided "better" - to them it is criminal that it hasn't been picked and gained momentum. Worse is better is not going away, and I think you can either engage yourself in it as a philosophy, or struggle.

empthought 12y ago
"Sometimes you seen them on HN with a fantastic new programming language (or something) they have designed and built in isolation - perfect in every aspect (at least to them). Nothing quite hurts like their confusion when interest dwindles and their software is forgotten." I suspect you've described Rich Hickey to a tee here. /s

Animats 12y ago

The one-line summary: "Basically, no one seems to grasp that when stuff that's fundamental is broken, what you get is a combinatorial explosion of bullshit." Exactly. A few examples. - C's "the language has no idea how big an array is" problem. Result: decades of buffer overflows, and a whole industry finding them, patching them, and exploiting them. - Delayed ACKs in TCP. OK idea, but the fixed timer was based on human typing speed, copied from X.25 accumulation timers. Result: elaborate workarounds, network stalls. - C's "#include" textual approach to definition inclusion. Result: huge, slow builds, hacks like "precompiled headers". - HTML float/clear as a layout mechanism. Result: Javascript libraries for layout on top of the browser's layout engine. Absolute positioning errors. Text on top of text or offscreen. - The UNIX protection model, where the finest-grain entity is the user. Any program can do anything the user can do, and hostile programs do. Result: the virus and anti-virus industries. - Makefiles. Using dependency relationships was a good idea. Having them be independent of the actual dependencies in the program wasn't. Result: "make depend", "./configure", and other painful hacks. - Peripheral-side control of DMA. Before PCs, IBM mainframes had "channels", which effectively had an MMU between device and memory, so that devices couldn't blither all over memory. Channels also provided a uniform interface for all devices. IBM PCs, like many minicomputers, originally had memory and devices on the same bus. This reduced transistor count back when it mattered. But it meant that devices could write all over memory, and devices and drivers had be trusted. Three decades later, when transistor counts don't matter, we still have that basic architecture. Result: drivers still crashing operating systems, many drivers still in kernel, devices able to inject malware into systems. - Poor interprocess communication in operating systems. What's usually needed is a subroutine call. What the OS usually gives you is an I/O operation. QNX gets this right. IPC was a retrofit in the UNIX/Linux world, and still isn't very good. Fast IPC requires very tight coordination between scheduling and IPC, or each IPC operation puts somebody at the end of the line for CPU time. Result: elaborate, slow IPC systems built on top of sockets, pipes, channels, shared memory, etc. Programs too monolithic. - Related to this, poor support for "big objects". A "big object" is something which can be called and provides various functions, but has an arms-length relationship with the caller and needs some protection from it. Examples are databases, network stacks, and other services. We don't even have a standard term for this. Special-purpose approaches include talking to the big object over a socket (databases), putting the big object in the kernel (network stacks), and trying to use DLL/shared object mechanisms in the same or partially shared address space. General purpose approaches include CORBA, OLE, Google protocol buffers and, perhaps, REST/JSON. Result: ad-hoc hacks for each shared object.

jamii 12y ago

Calling people out as #worseisworse is almost certainly going to be ineffective - attacking people just makes them defensive and argumentative. Instead, can we find useful principles to steer us away from the two bogeymen (hack-it-till-it-works vs useless-ivory-tower-wankery)? Some ideas: The real world exists. Successful solutions usually come from actually understanding the problem and all it's constraints. Solutions that are dismissed as overly academic tend to fall afoul of solving just the immediate problem and ignoring eg compatibility, switching costs, accessibility to beginners. Similarly, the linux community spent a long time burying it's head in the sane w.r.t. usability and appearance. Sure, people shouldn't care how pretty your UI is. But they do and you can't change that by burying your head in the sand. Everything has a cost. The benefits of your new solution and the switching cost have to outweigh the pain of the old solution by a large margin. The original 'worse is better' was really an observation that simple solutions that do half the job are often cheaper than a hugely complicated solution that can do everything. If you spend every day coming up with better ways to make widgets, it's easy to believe that everyone wants to have as much widget-customising power as possible and is willing to invest time in learning to get that power. If you actually talk to your users you might find that only having three kinds of widget isn't annoying enough to make them spend time learning something better.

afarrell 12y ago
I agree with this except possibly one thing. Saying "Sure, people shouldn't care how pretty your UI is." mischaracterizes user interface design as being about prettiness rather than interaction. But that might in fact be your very point and you might actually talking about the mischaracterization of others.
- jamii 12y ago
  I was thinking of the fact that beautiful software is perceived as more usable, all else being equal (http://www.ergonomicsclass.com/wp-content/uploads/2011/11/Tractinsky_2000.pdf http://www.ergonomicsclass.com/wp-content/uploads/2011/11/Tr...). This is irrational but not controllable. Unfortunately many good solutions lose out in the market because their developers make the mistake of expecting users to be rational econs, rather than accepting reality and working around it.

slashnull 12y ago

I'm just gonna go full Poindexter and say that Richard Gabriel did try to distance himself from worse is better, at first, but then he veered wildly in the following years between the two positions. And, the fundamental idea of Worse is Better is so incredibly older than UNIX, even in the field of computer science; John Von Neumann said himself that the Von Neumann machine was a temporary workaround and that a better architecture would quickly replace it. I live in a near constant fight in the rebel factions of Better and so far, I have to reckon we get constantly massacred by the Empire of Worse.

slashnull 12y ago

But seriously, it takes some nerve to write a blogpost against Worse is Better that's on every aspect worse than the paper that originally codified Worse is Better. Oh wait, no, is this lack of quality justifiable because this content-free 2 minutes read is more efficient and easier to write than a serious exploration of the consequences of whatever the author was ranting about?

account_306 12y ago
I'll probably get shadow banned for agreeing with this, but who cares anyway. The article ignores LEAKY ABSTRACTION. that's all there is to say. Now lets have some marketers tell us why that's a good thing and we can get back on this irony loop, this irony loop, this irony loop.

dkarapetyan 12y ago

Isn't twitter also an example of worse is better. Why send the people willing to engage with your argument to twitter then?

Htsthbjig 12y ago

What this man calls "worse" actually means "something that in better in ways I fail to understand in my simplistic reduction of the complex world". I love Lisp. I used it a lot for creating code that elegantly modifies itself. But my entire software company succeeded because of languages like C/C++ and python, not because of Lisp or any "functional programming language of the week". C gives you raw power that nobody else does. The fact that we could use c on c++ did become very useful so many times. Some people believe that forcing other people not to use things like pointers is a good thing, it is "better". For me it is the same as forcing people not to use sharpen edges on knifes for their own good. Yes, it is better in the sense that people wont cut themselves with knifes. But it is worse on other areas too. And if you let people choose, they will choose to continue using their knifes until something genuinely better appears. This is exactly what people like this man can't stand, people choosing on their own to use something they don't like so they want to force their "better" way(my way or the highway). If you have something better, well, show us the code, instead of ranting, and you will discover the fact that making anything that people actually want to use is way harder than ranting in a blog.

dllthomas 12y ago
"For me it is the same as forcing people not to use sharpen edges on knifes for their own good. Yes, it is better in the sense that people wont cut themselves with knifes." People cut themselves far worse trying to use a knife that's too dull for their task than a knife that's too sharp. Sharp knives are only safer when you're not using the knife (more likely to be cut by a sharp knife in a drawer than a dull knife in a drawer, &c).

neito 12y ago

Honestly, I think it's deeper than this. Even today, we have people who intentionally seek out ugly, imperfect designs because they think they work better. We have a cultural idea (at least, I can speak for the United States, hopefully some others will chime in) that "real" work is ugly, gross, and messy. Heck, I even had a friend who chided people who played a particular version of CounterStrike because it was "Too polished". We're measuring in one dimension something that's two dimensional: Work vs. Not work and Beauty vs. Uglyness. We steep in this cultural broth of the idea that "real work is ugly", and then wonder why the tools we decide to do "work" in are "ugly".

cwyers 12y ago

"This 'Worse is Better' notion that only incremental change is possible, desirable, or even on the table for discussion is not only impractical, it makes no sense." It makes all kinds of sense. Consider for a second the sort-of parable of Chesterton's fence. As G.K. Chesterton wrote: "In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, 'I don’t see the use of this; let us clear it away.' To which the more intelligent type of reformer will do well to answer: 'If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.'" It's basically that whole Spolsky think about why you shouldn't rewrite code from scratch[1]: "Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95. Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters. When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work." Broadly speaking: you, for ANY definition of you, are unable to design a perfect system at the first go. You will not account for all use cases, there will be edge cases you don't consider, so on and so forth. But it goes further than that: if you want to design something better than C++, you need to understand why so many people use C++. If you want to replace CSS, you need to understand why CSS is popular. If your thinking on the matter hasn't evolved much past "CSS is unnecessary" and blaming a single catchy essay for every decision you disagree with, then instead of writing essays about how everyone else is doing it wrong, maybe you should spend more time trying to understand what everyone is trying to do, why they're trying to do it and what resources they have to do it with. And THEN maybe I'll let you tear that fence down. 1) http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html

dreamfactory2 12y ago

I always associated worse is better with VHS vs Betamax rather than incrementalism i.e. utility realised > potential utility

dools 12y ago

For the record I think that writing software commercially should only consider the bottom line. What you do in your own time is your business; that's why open source is good for innovation through revolution. Ethics for legal and medical professions is a broken analogy because all of their ethical considerations focus on outcomes for clients/patients, not the details of how their services are executed.

dbenhur 12y ago

The author's Closing Remarks give rather short-shrift to the nuanced thinking Dick Gabriel has contributed to this idea. Gabriel's "Worse is Better" page https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html concludes with: "You might think that by the year 2000 I would have settled what I think of worse is better - after over a decade of thinking and speaking about it, through periods of clarity and periods of muck, and through periods of multi-mindedness on the issues. But, at OOPSLA 2000, I was scheduled to be on a panel entitled "Back to the Future: Is Worse (Still) Better?" And in preparation for this panel, the organizer, Martine Devos, asked me to write a position paper, which I did, called "Back to the Future: Is Worse (Still) Better?" In this short paper, I came out against worse is better. But a month or so later, I wrote a second one, called "Back to the Future: Worse (Still) is Better!" which was in favor of it. I still can’t decide. Martine combined the two papers into the single position paper for the panel, and during the panel itself, run as a fishbowl, participants routinely shifted from the pro-worse-is-better side of the table to the anti-side. I sat in the audience, having lost my voice giving my Mob Software talk that morning, during which I said, "risk-taking and a willingness to open one’s eyes to new possibilities and a rejection of worse-is-better make an environment where excellence is possible. Xenia invites the duende, which is battled daily because there is the possibility of failure in an aesthetic rather than merely a technical sense." Decide for yourselves."