24 ms·

A Generation Lost in the Bazaar (2012)

444 points by akkartik 10y ago

dsr_ 10y ago
Cathedrals are beautiful. They represent the vision of one person or a very small group made real by the hard work of hundreds or thousands of skilled and semi-skilled workers over dozens of years. Cathedrals are not, generally speaking, profitable. They represent the expenditure of lots of capital over a long period of time. Bazaars don't cost much to start. You can start quite small and have a functioning system that does useful things for people. They can grow quite large, and when they grow too large it becomes difficult to find exactly what you want without a really good map. But you can probably quickly find a bunch of things that are more or less close to what you want. Cathedrals are not easy or cheap to repair, but the investment is so large that people usually prefer to repair them. A bazaar that doesn't work out makes some local people sad, but they will go to another bazaar that is a little less convenient for them, and perhaps do better there. It's nice to have some cathedrals, because they feed the soul. But you need to eat every day, so there will always be bazaars, and if you need to make a choice, the bazaar is going to win unless you have a lot of resources stored up to fall back on.
- derefr 10y ago
  You can build a cathedral around the stalls of a successful bazaar, no? Like OSX or Android.
  - Ologn 10y ago
    Android a cathedral? If you wanted tabs in Android prior to 13, you'd setup a TabHost with a LocalActivityManager ( https://developer.android.com/reference/android/widget/TabHost.html#setup(android.app.LocalActivityManager) https://developer.android.com/reference/android/widget/TabHo... ). Then in version 11 ActionBar.Tab is added and LocalActivityManager is deprecated in version 13. By version 21 they became bored with that and deprecated it ( https://developer.android.com/reference/android/app/ActionBar.Tab.html https://developer.android.com/reference/android/app/ActionBa... ). You wouldn't know it was deprecated though as the most current training documentation still recommends using this now-deprecated method ( https://developer.android.com/training/implementing-navigation/lateral.html#tabs https://developer.android.com/training/implementing-navigati... ). All you are left with is a pointer to a vague, ambiguous page in the context of the deprecation method. Welcome to the cathedral of Android developing. BTW the release dates for these APIs: API 11 - February 2011 API 13 - July 2011 API 21 - November 2014 The annoyance isn't that they changed it, it's that they didn't like the old way, so they changed it, then three years later they changed it again. They do this all the time. Plus they deprecated it, but still recommend the deprecated method in the tutorial, and leave it as a mystery how it should be implemented in current best practices. The current most up-to-date tutorial on their web site is chock full of recommending things which they deprecated already.
    - anabis 10y ago
      I wish they would at least put dates on the documentation. I find myself reading halfway through a outdated tutorial before some names or versions makes me realize it.
      - flukus 10y ago
        I wish google would favor newer, more accurate solutions. Or at least provide away to flag no longer useful content.
    - HillaryBriss 10y ago
      Agree. Definitely no cathedral. And what about customizing a Spinner's font and background color and popupBackground color and putting a non-standard element at the top? And the amount of time it took before Android got percentage based spacing in layouts? And the fun of remembering what UI attribute-values like android:gravity="center_horizontal", android:layout_centerHorizontal="true" and android:layout_gravity="center" mean? And the awkwardness of using non-standard typefaces and using things like the RecyclerView and it's weird Adapter? And the fact that for some reason they used an XML element named "layout" when they implemented their data binding feature? And the fact that some attribute names are camelCased while others are underscore_cased? And the ease with which memory leaks are introduced by inadvertently closing around context instances because you need context instances all over the place because the Activity is a god object? It's all so very ... not ... like ... a cathedral.
      - pjmlp 10y ago
        Sometimes I have this feeling that they just offshore everything and just do some kind of integration at Mountain View.
        HillaryBriss 10y ago
        interesting. i often wonder how the Android SDK got the way it is too. my hazy guess was that Google simply hired a bunch of extremely smart programmers and let them code whatever they wanted. but there is no equally smart architecture/design team to guide, organize and filter the work. there's just a build system. maybe that's essentially the same as your theory.
  - adamnemecek 10y ago
    macos (nee osx) is the result of combining freebsd and the mach kernel, both very cathedraly technologies.
    - mturmon 10y ago
      And now we see just how confused this discussion is. It's conflating a bunch of concepts via a historically weighted analogy, which itself has a lot of baggage at this point. For more, see this perceptive comment: https://news.ycombinator.com/item?id=12251705 https://news.ycombinator.com/item?id=12251705
    - nickpsecurity 10y ago
      I'd consider what's on top the more cathedraly part. It has the consistency in design and implementations. Merging FreeBSD with Mach might have been centralized developers looking for good results but actual results seem a bit more bazaar. QNX was the older cathedral of mixing UNIX and microkernels with good design + performance. There were others but it stands out.
    - josteink 10y ago
      > macos (nee osx) is the result of combining freebsd and the mach kernel, both very cathedraly technologies. Not to mention the remains of NextStep. Also very Cacthedraly. Edit: thinking about it, I wonder why Apple didn't keep using that name/brand. It's obviously there all over the API. Was the NextStep name/brand tainted as a doomed technology at the time?
- CookieMon 10y ago
  > Cathedrals are not, generally speaking, profitable. This is getting lost in the metaphore, instead of the topic. Architected software is profitable.
  - erikpukinskis 10y ago
    Architected software would be profitable in fewer scenarios if we (software developers) didn't maintain such a high barrier to entry. We design our tools for ourselves and other professional programmers so that we don't have to compete with non-professionals with a better sense of the requirements. We force people to come to us, to defer to our understanding of how much architecture is necessary. We make our codebases just easy enough for a pro developer and no easier, refactoring and simplifying only when it becomes painful for a pro developer, and no sooner. That way they have to keep us as gatekeepers to all code. It's essentially like you only made building tools for cathedrals, and no tools for thatched stick homes, and you create a culture around always building a cathedral so no one really knows how to build a thatched home. Essentially, creating a market irregularity through cultural expectations about how serious software has to be and who is going to be writing it. (The complaint people always make when I say this is that making software isn't easy, it's hard, and notices couldn't possibly build useful software. I would half agree: some software problems are hard, and require a grizzled developer and some hard planning. But much of software involves no difficult computer science problems, and is more about understanding requirements well enough to be able to assign them to the right basic programming primitive, or a handful of common libraries. This is the kind of code that we use cultural friction to keep inside Engineering, and build cathedral-style, even though it could be done in thatched-home style by notices, if we structured our codebases for that.)
    - dietrichepp 10y ago
      I almost spit out my drink. High barrier to entry? The barrier is lower than it ever has been. Any nut-job with a few weeks of training can make a shitty website with PHP or Node.js and have it instantly accessible to the most of the English-speaking world. Most of the tools I see for software development seem to be organized around the needs of the bazaar (or thatched huts) not the needs of the cathedral. A million toy languages which might solve your problem well, but don't scale to a million users. Websites like GitLab and GitHub so you can share last week's 1 kloc project with collaborators. Libraries that do that one weird thing you need for your project, and nothing else. By comparison, the cathedral builders (Google, Facebook, Apple, Microsoft, etc.) seem to be building a lot of their own tools. This includes programming languages, frameworks, build systems, version control, operating systems, and so many other things. They build their own stuff because the tools of the bazaar don't work quite well enough for cathedrals.
- Clubber 10y ago
  A few points just for fun: 1. Christianity, the group who builds Cathedrals, is probably the most profitable organization in the history of mankind. 2. Bazaars blow away when the wind picks up. If too many people show up, things start falling down. Cathedrals, and their close cousins, castles, last centuries. 3. I think Bazaars have their place, when you really need to ramp up something to show. We used to call that prototyping. If it gets past that, you gotta build it right eventually.
  - hexane360 10y ago
    2. Bazaars pop back up seconds after they blow away. http://youtu.be/MENjFkEAj9g http://youtu.be/MENjFkEAj9g
    - happyslobro 10y ago
      An epic win for cross platform compatibility ;)
    - taneq 10y ago
      Yeah, but nothing's quite where you left it, your favourite curry stall is gone for good, and you'll never be able to get a refund on that thing you bought that stopped working the day before the storm.
  - aaron695 10y ago
    > 1. Christianity, the group who builds Cathedrals, is probably the most profitable organization in the history of mankind. I don't need to be the richest organization ever. I'd be happy for 1000th place and those billions rather than overreaching for number one and the risk that entails.
  - eggy 10y ago
    Point 3 is what I consider a good model for the building metaphor. Let Bazaars spring up where needed and wanted. When the ground is proven, then clear and build a well-architectured Bazaar, not necessarily a full-blown cathedral unless it really calls for it. This sometimes happens when codebase if re-written from scratch with the old code as reference, not just cleaning up old code. I think AutoDesk did this when Inventor came along, but I am not sure. A big re-write if ever there were one.
- jaza 10y ago
  Perhaps what we need are shopping malls. Aren't they, after all, the modern cathedrals of consumerism? (And aren't they just what we need more of in this world?) :P Shopping malls aspire to be beautiful (primarily on the inside), but they can never be as beautiful or as well-architected as cathedrals, in form or in spirit. Shopping malls have a bigger overhead than bazaars, and are less flexible. But their overhead is much less, and their flexibility much greater, than that of cathedrals. Shopping malls provide more foundation and infrastructure than bazaars do. A bazaar minus its stalls is just a dusty field. A shopping mall minus its shops still has multiple levels, maps / directories, elevators / escalators, parking, loading docks, etc. It costs more to set up shop in a mall than in a bazaar, but your shop will be more trusted, you won't have to squabble for space with your neighbours every day, and you won't get blown away by the next storm. Shopping malls are designed with dedicated spaces that are tailored to different businesses. A supermarket has very different needs compared to a shoe shop. Shopping malls are bazaars with a tonne of design, engineering, and regulation thrown in. But they're still bazaars. They're still where you get your groceries.
  - HillaryBriss 10y ago
    you're on to something good are you the one who writes "The Shopping Mall and the Bazaar" and leads us into a better era?
    - DonHopkins 10y ago
      "Software development is hard. Let's go shopping!" -Tech Talk Barbie
      - cvs268 10y ago
        > Software development is hard. Let's go shopping!" -Tech Talk Barbie ...or Yahoo, or Google, or IBM, or Hooli, or <Big-Fat-Tech-Giant>.
  - mbrock 10y ago
    A shopping mall is also an example of what some theorists call "antimarkets": places which resemble a typical market with competition and choice but which are heavily regulated and controlled to exclude open participation. Kind of like if the iOS App Store only had room for 15 apps, and Apple Inc decided which, and the roster was only updated every few years at most.
- caseymarquis 10y ago
  Cathedrals are very profitable; as long as there's religion.
gavinpc 10y ago
Mods, please add 2012. Most recently discussed here at https://news.ycombinator.com/item?id=9403124 https://news.ycombinator.com/item?id=9403124
k__ 10y ago
I like the Bazaar. It's a bit like "normal" people sticking it to the elite. The rest of the world getting a piece of the cake too...
- droopyEyelids 10y ago
  In your analogy the people who get stuck trying to fix crazy shit with makefiles are the elite. Which will probably be you one day. Which means you're sticking it to yourself.
  - pjc50 10y ago
    In Free Software, everyone gets a turn at being the Man.
qwertyuiop924 10y ago
...And if you think the Bazaar precludes somebody making decisions about quality, you haven't payed attention to how linux development works. Except epoll. And vsyscalls. And... You know, maybe Linux isn't well managed.
- Annatar 10y ago
  Shhh! Don't criticize Linux even if it's true, you'll get downvoted faster than you can bat an eyelash! That's extremely unpopular here. 'Cause you know, man. Linux.
  - qwertyuiop924 10y ago
    Hey, I run Linux. I just think that it's worth acknowledging that it's got some flaws. One of the reasons I listen to people like Bryan Cantrill. I don't take what he and the BSD folks say at face value - If they're working on competing projects, they obviously don't like Linux technically - but sometimes, they're right. Especially about epoll. Jesus. Anyway, GP is +3. It got downvoted a ton, but it bounced back.
    - Annatar 10y ago
      Competing projects or not, Bryan is correct. The FreeBSD folks also have a pretty good clue.
      - qwertyuiop924 10y ago
        Well, yeah. But I can't trust him out of hand. Are you a Plan9 user, by any chance?
        Annatar 10y ago
        Nope; Solaris / illumos / SmartOS.
        10y ago
haddr 10y ago
It's a very nice read with many good points, but any person with some experience in IT projects could argue with it. The author is taking one side without any self-criticism. It is true that configure scripts are probably doing some useless things, "31,085 lines of configure for libtool still check if <sys/stat.h> and <stdlib.h> exist, even though the Unixen, which lacked them, had neither sufficient memory to execute libtool nor disks big enough for its 16-MB source code", etc. But then what is the alternative? Writing a configure module each time by every programmer who wants to release some software? This is called code reuse and yes, it's not perfect but it saves time. By not reinventing the wheel again and again. By reusing something that is stable and has been there for some time. Probably such thing is generalizing over many architectures, and making useless things, but then again, who cares for some extra 5-10 seconds of the "configure" command, when you are covered for all those strange corner cases that it already handles?
- x0x0 10y ago
  Insane complexity in build systems just makes your life sad. Trust me, I know -- I write java for a living. We have ivy, maven, ant, gradle, sbt, leiningen, and I'm sure a few more.
  - d_burfoot 10y ago
    Hey, I write Java for a living and my build script is just a Python program that marshals a javac call.
    - qwertyuiop924 10y ago
      I write scheme not for a living. My build script is a scheme file or a makefile, depending on the project. The build complexity is one of the reasons I stay away from Java: If these people think they need XML for builds, what other needlessly complex horrors have they perpetrated? And that sort of thing. Do you have your buildscript template on github?
      - quantumhobbit 10y ago
amasad 10y ago
I've been thinking a lot about this in the context of software development tools. It is now just expected that IDEs, compilers, tooling etc are free and OSS. On the one hand this enables bottom-up innovation and shorter development cycles. On the other hand setting up a development environment is a royal pain in the butt. And a big turnoff for newbies -- they begin to think that programming is some sort of IT job about installing and troubleshooting software. Even when you manage to set everything up there is constant maintenance cost as you update software and as new things come out. At the very least, I would love to see companies created around popular open source tools and verticals to create designed end-to-end experiences. Download, double-click, start coding, and see something on the screen.
- csours 10y ago
  And if you work behind a corporate proxy, expect all of the above to be an order of magnitude worse. Oh you set the proxy setting in the IDE/Shell/Package Manager? You forgot about x, y and z; and websites foo, bar, and bas are blocked!
  - voltagex_ 10y ago
    I remember a few years ago, before Git had NTLM support (for proxies), I had to use all kinds of terrible hacks to get online. Recently, the proxy I'm behind for at least 8 hours a day has been changed to accept Basic and Negotiate, but I didn't realise that until I'd spent a not insignificant amount of time yelling at NPM. Even if you do get online, don't forget to configure the MITM CA cert! Next up, apps that try to execute from %LOCALAPPDATA% (Squirrel installers). This is blocked by most AppLocker configs. Isn't "enterprise" computing fun?
  - superuser2 10y ago
    Transparent proxies and 802.1x auth have been around for a while. Even my high school got off the "you must configure a proxy server in every application" train. IMO that is just poor IT.
- douche 10y ago
  There are non-terrible development stacks. Some of them are even free. Unfortunately too much of it is endless turtles-all-the-way-down yak shaving marathons, like in the JS world. I forget whether I'm supposed to grunt, gulp, babble, or barf. You just have to get out of the churn-for-churn's-sake cesspools. There are high-quality, stable software stacks out there, where the Cambrian explosions and rediscovery of ideas from a generation ago have already passed.
davidw 10y ago
> compiling even my Spartan work environment from source code takes a full day Maybe compiling everything on every computer is not the best approach...
- phkamp 10y ago
  For everybody ? No. But some minority have to take the open SOURCE seriously, if we want it to actually work. I'm part of that minority.
  - emmelaich 10y ago
    I don't understand that point of view at all. If you control the dependencies, you get a predictable result.* Why do it again and again? To be sure to be sure? * Debian's work on reproducible builds will help here.
- josteink 10y ago
  > Maybe compiling everything on every computer is not the best approach... If you're working on a FOSS operating system (freeBSD), where one of the components/features you provide your users are the ability to install almost any software, customized to your needs (the ports system), you probably want that part of the system checked and working. You know, dogfooding your own delivery, and I for one am glad someone is still willing to adhere to that standard of software development.
  - davidw 10y ago
    > customized You can do this with Debian style packages too - it's perhaps a bit more involved, but entirely possible. And there's an argument for only customizing the few things you need to and just getting binaries for the rest.
vessenes 10y ago
And yet..I think this critique gets less strong as time goes on. The amount of productivity available to Mr. Kamp for free today is conservatively double or triple that available in 1999. Databases, web frameworks, scale know-how, IDEs, hosting platforms, the list goes on. He harkens back, sadly, to an era in which codebases like Genuity Black Rocket cost $100k in licensing, and ran on $30k/month Sun servers. Seriously. Languages are faster, development times are shorter, and chips are WAY faster. And, code can be pushed out for tinkering and innovation onto github for free. Combine that with his estimate that we have 100x more people in computing, and the combination is a riot of creativity, crap, fascinating tech and everything in between. The bazaar is messy, but I'm not aware of any solid critiques which show cathedrals are more efficient at the multiples-of-efficiency kind of gains we get from legions of self-interested, self-motivated coders.
- _bpo 10y ago
  > Languages are faster, development times are shorter, and chips are WAY faster. This is due to Moore's law, not the software design choices that the article bemoans. Those $30k/month Sun servers were many times faster and cheaper than the earlier machines they replaced as well.
  - vessenes 10y ago
    While Moore's law helps, languages are more expressive, safer, more performant and have more batteries included yielding a whole bunch of improvements. We've had software and hardware gains, massive ones, and they compound.
    - SolarNet 10y ago
      > While Moore's law helps, languages are more expressive, safer, more performant and have more batteries included yielding a whole bunch of improvements. I have to disagree, compilers may have gotten a bit better at making faster binaries. But languages, like new languages, are increasing in expressiveness and safety, sure, but very rarely efficiency. Go and Rust are not faster than C or C++, likely never will be (for one C has decades of lead time), Go and Rust may be faster than C was 20 years ago, but that doesn't matter.
RachelF 10y ago
Having seen the source for a non-Bazaar OS (Windows), I can say that they are not built like cathedrals: Most of the original developers have long since moved on, there are design problems, various teams and managers rebuild or duplicate work, and management sometimes imposes big changes just before release. Software quality is hard to judge from the outside, and takes longer to build.
- flukus 10y ago
  This is a good point, I wonder if cathedrals really exist in the real world? I suspect they are all just isolated bazaar's.
- dfox 10y ago
  Windows (at least for userspace components) has significantly less self-contained modules (which thus contain larger amounts of functionality) than any modern unix-based system and there are almost no modules that are widely used and not supplied by Microsoft (excluding stuff that is ported from unix and various third-party hardware APIs). One of reasons for that is probably that before .NET, there was essentially no support in VS for building applications as anything other than big self-contained .EXEs and the current solution/project mechanism leaves much to be desired.
  - asveikau 10y ago
    What the hell are you talking about? Just take your Unix mentality and make a few substitutions: * gcc -> cl.exe * ar -> lib.exe * ld -> link.exe * make -> nmake.exe * libfoo.so -> foo.dll And there you have it, the world that "didn't exist before .NET" ... This is crazy amounts of ironic because Windows had DLLs at a time when shared libraries were not so much a thing on Unix. Not to mention things like COM which are all about creating de-coupled components.
    - douche 10y ago
      Do you remember DLL hell? Pepperidge Farms remembers /s
hyperpallium 10y ago
Successful bazaars have a flat architecture, meaning you can easily add another component, to handle a new case. It's not always the ideal technical architecture for the problem.
danblick 10y ago
Slightly OT, but I enjoyed the discussion about (physical building) construction in the book "the Checklist Manifesto". In The Mythical Man Month, Brooks advocates the use of something like the "master builder" model for software. It turns out that in actual (physical building) construction, the master builder model is no longer used, because the construction process has become much too complex to be understood by a single person. Instead, in construction, they use a system of checks to ensure that different experts consult one another so that every decision is reviewed by a relevant expert. I suspect that the "chief architect" approach that Brooks advocates may have become obsolete as well since the Mythical Man Month was written. Perhaps software developers could learn something from the newer methods that replaced the "master builder" model in construction.
- DigitalJack 10y ago
  The checklist manifesto was a great book. Probably time i read it again.
  - bordercases 10y ago
    It was too breezy, too slim and too hyped for my taste. The insights themselves still are valuable, but perhaps worth only half the size of the book.
    - djtriptych 10y ago
      But would you have paid $15 for a 25 page pamphlet? :)
      - 13of40 10y ago
        That's a very good point - I've always felt it was a shame that in order for a thesis to be "publishable" you have to frame it in 300 to 500 pages. The Design of Everyday Things by Don Norman is a great example. It's an awesome book, and anyone who's designing user-facing-anything should read it, but I think the story could have been told in about half as many words.
haberman 10y ago
There are way too many dichotomies that are getting muddled in this discussion: - hacky vs. beautiful - professional vs. amateur - waterfall-designed vs. evolving - centralized control vs. consensus control - crufty vs. well-maintained - open-source vs. closed-source With so many axes to argue about, we can project whatever we are feeling about software today onto this "cathedral/bazaar" debate. We may think we are having one discussion, but we're actually having six discussions (or more) at the same time.
- qwertyuiop924 10y ago
  Hacky vs beautiful is diferent from The Right Thing vs. Worse is Better. Worse is Better is a very specific philosophy (at least, as it is described in Lisp: The Good News, The Bad News, And How to Win Big) The Right Thing philsophy is, in essence, that simplicity of interface is the most important thing: every interface is an abstraction, abstractions shouldn't leak. Have a simple interface, be correct, be consistant, be complete. If the implementation is complex, so be it. By contrast, the worse is better philosophy prioritizes simplicity of implementation: Be simple, be as complete, correct, and consistant as possible, but between having a simple design, and being slightly wrong, a little inconsistant, and not as complete, and having a complex design that is all of those things, take simplicity: 90% now is better than 100% never. Over time, Unix has adoped some Right Thing ideas (plan9 took this to 11), and Lisp has adopted some New Jerseyisms (Scheme's dynamic-wind is definitely this).
  - haberman 10y ago
    You are right. I wrote that too quickly before thinking about it. I removed that part of the post.
    - qwertyuiop924 10y ago
      You are far from the first person to misunderstand/misrepresent worse is better. The best part is when people recommend reading the essay, and then demonstrate they they don't know what it meant: It's not about the battle between simplicity and complexity, it's about the battle between simplicity of interface and the simplicity of implementation.
smegel 10y ago
> The bazaar meme advocated by Raymond, "Just hack it," as opposed to the carefully designed cathedrals More like carefully designed procedures (not the software kind), meetings, and suit ties. The waterfall process can be as technically deficient as you want it to be, just like agile.
csours 10y ago
Recurrent calamities, fires and earthquakes hit the Grand Bazaar. The first fire occurred in 1515; another in 1548.[9] Other fires ravaged the complex in 1588, 1618 (when the Bit Pazari was destroyed), 1645, 1652, 1658, 1660 (on that occasion the whole city was devastated), 1687, 1688 (great damage occurred to the Uzun Carsi) 1695, 1701.[14] The fire of 1701 was particularly fierce, forcing in 1730-31 Grand Vizier Nevşehirli Damad Ibrahim Pasha to rebuild several parts of the complex. In 1738 the Kizlar Aĝasi Beşir Ağa endowed the Fountain (still existing) near Mercan Kapi. https://en.wikipedia.org/wiki/Grand_Bazaar,_Istanbul#History https://en.wikipedia.org/wiki/Grand_Bazaar,_Istanbul#History
- spitfire 10y ago
  That's a good idea, maybe the Baazar needs a good fire. Fires help forests stay healthy returning a lot of biomass for new healthy forests to grow. Maybe the ecosystem needs a good fire to clear out the diseased old growth?
  - kardos 10y ago
    > Maybe the ecosystem needs a good fire to clear out the diseased old growth? Ehhh, the analogy works better in terms of competing species. If a stronger invasive species rolls in and takes over due to raw excellence, we can see the eviction of the old cruft. For example, once the dust is finally settled in a few more years, we may come to see systemd as such a force.
ktRolster 10y ago
The article says that to have quality, someone needs to be responsible for it. Of course, the "Bazaar" included the project named "Linux," which does have a single person in charge. So "single person in charge (or not in charge)" isn't really what the bazaar is about. More generally, the article laments the lack of quality in modern software. I don't think that's a problem of Cathedral vs Bazaar, though, since software designed top down with authority telling everyone what to do can be low quality (indeed, you can see this sort of thing happening in many scrum style companies). Rather low quality software is a reflection of the skill of the people who built it.
asragab 10y ago
I love how this article makes its reappearance on HN every two years... https://news.ycombinator.com/item?id=4407188 https://news.ycombinator.com/item?id=4407188 https://news.ycombinator.com/item?id=8812724 https://news.ycombinator.com/item?id=8812724
- HillaryBriss 10y ago
  nice
- Annatar 10y ago
  And judging by how much garbage software there is out there, written by people without a clue who think they have one, it needs to reappear a hell of a lot more!
- whatever_dude 10y ago
  And it's still relevant. I read it every year or so and still finding myself nodding to it.
BadassFractal 10y ago
It's why I use OSX at home for anything non-work related, I want an integrated experience that just works, I don't want to be IT guy at home. No messing around with video card drivers, no figuring out why my printer chops off pieces of the page, no constant wifi or bluetooth crapouts, support for Adobe suite or popular digital audio workstation software. At work I'm happy to use Linux, but I use it for things it's great at, such as simulating our prod environment, coding, etc, but at home I just don't want to think after a long ass day, I want to enjoy computing.
- c22 10y ago
  I'm not sure which linuxes you use but sans Adobe support I haven't had any of those issues for at least 7 or 8 years. In fact Debian just works with both my printer and my graphics card while Windows 10 refuses to print or display a resolution above 1024x768.
  - BadassFractal 10y ago
    Been using Ubuntu for about 5-6 years now. On laptops the wifi drops all the time. Bluetooth fails to connect half of the time or gets stuck and needs a reboot. I can use my Brother printer, those drivers "work", but it fails to center the page properly out of the box, comes out all mangled. Just got a 16.04 fresh install from a vendor, software update immediately borked permanently, had to find https://www.youtube.com/watch?v=vjfMYjRjAv8 https://www.youtube.com/watch?v=vjfMYjRjAv8 to be able to move past it. Again, I'm expected to be IT guy or Geeksquad Man to be able to use this OS, which I'm happy to do at work, just not on my time. If you go over Ethernet, use extremely conventional hardware and only expect to use it as a machine to browse the Internet then you'll generally be just fine. It's free, I can't complain, but it doesn't make it any less of a shit show.
- linuxhansl 10y ago
  Printer support (as an example) worked much better with Linux (Fedora) than my MacBook. On the Mac I had know the IP address, download a driver myself, fiddle around with it. On Fedora, it said it found this printer, installed the driver, and whether I wanted to print a test page. The test page printed fine. That was a while ago, and things may have changed. But it's not the only example. With OSX I am boxed into what Apple thinks is best for me. With Linux I can do whatever I like, while most things also just work. None of the issues you mention are an issue with Linux anymore. Wifi, Bluetooth, printers, sound, video, etc, all just work, most (IMHO) more intuitively than with OSX. Only for faster 3D graphics I had to install the vendor driver from a non-free Fedora repository.
cbsmith 10y ago
I still hate this essay as much as I did when it first published it. It misunderstands the problems. Unix was fragmented long before 1991, when autoconf was created. Prior to autoconf, Perl's Metaconfig did this dance, and a lot of other, lower quality systems like imake were used to work around the problem. The forces behind Unix's fragmentation was actually not the Bazaar (open source software), but attempts by multiple parties to independently build their own Cathedrals (in attempts to differentiate/provide value with proprietary systems). Of course, autoconf, as a GNU system, was, in Cathedral & Bazaar terms, a Cathedral, not a Bazaar. Autoconf is ugly/copy-paste code because it is comparatively rarely run, so as long as it produces a passable result, people use it and focus their efforts on other, bigger itches. There's also a long history of open source products which have enjoyed higher quality implementations than their proprietary equivalent. The Apache project itself stood as a higher quality web server than a lot of other choices (not as true today, but it was true for quite some time). One could go on...
- cpeterso 10y ago
  Do we still need autoconf in 2016? Systems are becoming more homogeneous with the spread of Linux, GNU, and common programming conventions.
  - swolchok 10y ago
    You could argue that autoconf sucks and clearly everyone should use your favorite build system, but you need something to do the job. Not even two systems running the same release of the same distribution are going to have all the same packages installed. I might have put a newer version of X in /usr/local. I might want to cross-compile. Even considering all Linuxes the same, I might want to build for x86, x86_64, MIPS (routers), ARM, PowerPC, or some more esoteric chip. Android has its own special problems, including a different libc. I might want to ship on BSD (which one?), OS X, iOS, cygwin, mingw, or that newfangled Windows subsystem.
    - cbsmith 10y ago
      > You could argue that autoconf sucks and clearly everyone should use your favorite build system Well, in fairness, build systems often deal with a different set of problems.
peterwwillis 10y ago
He's complaining that the Bazaar is not efficient, and that it's a pile of hacks. No. Shit. Yes, it's an inefficient pile of garbage built one heap on top of another. But it's also incredibly useful. Modularity and code reuse are, of course, A Good Thing. Even in the most trivially simple case, however, the CS/IT dogma of code reuse is totally foreign in the bazaar: the software in the FreeBSD ports collection contains at least 1,342 copied and pasted cryptographic algorithms. If that resistance/ignorance of code reuse had resulted in self-contained and independent packages of software, the price of the code duplication might actually have been a good tradeoff for ease of package management. But that was not the case: the packages form a tangled web of haphazard dependencies that results in much code duplication and waste. Code duplication, waste, and a tangled web of haphazard dependencies are only a bad thing in theory. PHK talks about "CS/IT dogma" like it's the rule rather than the exception. But the CS/IT dogma, like most other dogma, always runs into exceptions when put into practice. When you have many, many independent teams of people developing software, you may want to implement something someone else has already done. As a member of your team, you have two choices: 1) re-implement the original as part of your own cathedral, or 2) put some glue around the existing solution. Sometimes, 1) will be the best choice. But sometimes - and this is usually the case with Unix tools - 2) works just as well, and you get the benefit of only having to write and maintain glue, rather than a constantly morphing feature implementation. If the original was done well, and your glue supports it well, you get a feature without paying for it. The foundation of Unix is a strong Cathedral. But this foundation is what makes the Bazaar fit so well around it: it provides something strong to glue other shit to. As long as you have someone to continue gluing shit together, you can keep adding pieces ad infinitum, and what you lose in the end is essentially disk space and compilation time. I'm willing to accept that.
deleted 10y ago
[deleted]
duncan_bayne 10y ago
ESR agrees with the criticism of Autotools: http://esr.ibiblio.org/?p=1877 http://esr.ibiblio.org/?p=1877 "Autotools must die"
jesstaa 10y ago
"the ruins of the beautiful cathedral of Unix, deservedly famous for its simplicity of design, its economy of features, and its elegance of execution" unix is the bazaar enabler. An OS that is so simple as to be mostly useless without third party additions but also without enough of an overall design to give the third parties much of a guide on how things should fit together. The mess that unix enabled is also the reason we can't get away from it and move on to better architectured systems.
njharman 10y ago
For any given software thing you can 1) pay for the cathedral 2) use the bazaar, possibly needing to seed it 3) do without Since 1) is typically very expensive and lacks guarantees of suitability to purpose and continued existence, the ROI is so massively negative few can even try it. 3) often isn't an option. the bazaar is an inevitability. No one has been mandating it for past decades. No laws enforce it. It occurs cause it is the only available/possible option.
lifeisstillgood 10y ago
So a while back I had a JIRA ticket, to go add a feature to a pile of JS front end. I did not understand the pile very well, but that's OK, neither did anyone else, and I expected to add a large amount of tests and code to get the job done. But I like understanding the code, so I read and read and puzzled and fended off "hurry up" comments. And then I added two lines and it basically worked. I am in favour of a slow code movement (http://www.mikadosoftware.com/articles/slowcodemovement http://www.mikadosoftware.com/articles/slowcodemovement) which seems relevant here. Even better was a guy I worked with, physics PHd from central China, whose daily stand up reports mostly consisted of "Inspent yesterday reading around the subject, I shall spend today, reading around the subject." Love him, love the brass balls.
jmspring 10y ago
When it comes to ecosystems, the definition of the Cathedral becomes interesting. Say what you will about business practices in the 80s, 90s, early 2000s... In a sense Windows was a cathedral. It bent over backwards while accepting the new. Welcoming many under the umbrella. Sure it is a stretch, but the Windows platform (for years) required backward compatibility. That was the world Microsoft worked in. Today, the OS still maintains cathedral aspects, but the company is embracing the bazaar way more than I ever thought I would see in my lifetime.
phkamp 10y ago
(Author of the essay here) It is discussions like this which make me truly admire Douglas Adams for his insights and ability to express them. For instance, when I read through the debate here, I can't help notice how many of the arguments are really variations of "It's a bypass! You've got to build bypasses! Not really any alternative."
- isuckatcoding 10y ago
  For me the highlight was: 'That is the sorry reality of the bazaar Raymond praised in his book: a pile of old festering hacks, endlessly copied and pasted by a clueless generation of IT "professionals" who wouldn't recognize sound IT architecture if you hit them over the head with it.' I was hoping for some kind of expansion or attempt at a solution here (which of course would be non-trivial).
  - phkamp 10y ago
    The (only) solution is for people to care about quality in computing. There's still too much money to be made on kludges for that to happen.
    - pjc50 10y ago
      .. and no money to be made on quality. It's Akerlof's "Market For Lemons" writ large. Users can't assess the quality of software before they buy it and sink ages of their own time into learning it. Often users can't assess quality problems even after they've bought it. So the market isn't going to reward quality. (The original paper was about cars; now we have software in our cars the problem is twice as bad. VW 'defeat devices' and Toyota 'unintended acceleration' passim).
- sutro 10y ago
  Thanks for your words and your code, phk. Thanks especially for Varnish, a beautiful cathedral.
sgt101 10y ago
petty point; the author says "growth by 2 orders of magnitude or 10000%" is it just me or is that 4 orders of magnitude?
- mdpopescu 10y ago
  10000% = 10000 / 100 = 100 = 2 orders of magnitude
kuharich 10y ago
Previous discussions: http://news.ycombinator.com/item?id=4407188 http://news.ycombinator.com/item?id=4407188 https://news.ycombinator.com/item?id=8812724 https://news.ycombinator.com/item?id=8812724
sbarski 10y ago
One of my favourite ACM articles. I think I read it twice the first time I came across it. Also bought "The Design of Design" thanks to it.
veddox 10y ago
It sounds like a lot of stuff that the author complains about falls under Sturgeon's Law. To paraphrase him: "Sure, 90% of FOSS is crud. That's because 90% of everything is crud." Not to lessen the many valid criticisms that the article contains, but I think the low average quality of code can be adequately explained with the above law.
neo2006 10y ago
I like to think of software as a living entity that grow evolve, get sick and eventually die. There is nothing wrong with refactoring or diying code it's part of the natural process of engineering software. Sometime we take the decision to not refactor, that's also ok as long as you know that this will make cost you more to do it later or will code will end up diying. Your code is like a pet, his love depend on how much effort you put to take care of him. Sometime, it's sick by design and where ever effort you put in won't save it. So now if we talk about how to design software that will live long and prospere you need to guess/predict the future and have an idea on all the forms that your software will evolve to and all the intented and non intended use possible for it and avoid all mistakes in you design and then you will have a warranty otherwise you need to design the simplest way and make it evolve when needed by refactoring, fixing and patching...
Jtsummers 10y ago
> This is probably also why libtool's configure probes no fewer than 26 different names for the Fortran compiler my system does not have, and then spends another 26 tests to find out if each of these nonexistent Fortran compilers supports the -g option. It's been awhile since I've dealt with autoconf and company, but I remember seeing things like this. This is bizarre, to me. It should be a simple process. Make a pass to detect fortran compilers, make a second pass to detect support for -g. (This is, of course, assuming that we even want to use this at all.) I remember cleaning up a coworkers project that did something similarly inane. A pass over the data revealed something wasn't present. But his test scripts continued processing, including rereading the original data, as if the something were present. Wasted 20 minutes each time it was executed until I rewrote it to break early. If X depends on Y and Y is absent, then don't do X.
futuremeats 10y ago
What are some examples of cathedrals? Based on my reading of the original article, these would need to meet two requirements... 1. Software has been in service for a long time (let's say more than 10 years, though some will debate the timeframe). 2. Software is recognized as of enduring, well-conceived design. The second point is an important one. I have read that there are some government (IRS tax calculation) and industry (airline reservation systems) which have been in place for far longer than 10 years, but their longevity is more a function of the risk-aversion of the organizations that needed them, and less a testament to their "beauty."
aeorgnoieang 10y ago
rolls-eyes This is a terrible, whiny perspective and the author could use a heaping dose of economic thinking. Sure, there's lots of 'terrible' software and it would be great if it were better or there was less of it! Except there are real costs to improving software or to preventing 'terrible' software from being released, or used, or disseminated. I am so happy the author is not a position to make decisions about this stuff for everyone else. All software is to some degree a hack or kludge.

444 points by akkartik 10y ago

dsr_ 10y ago

Cathedrals are beautiful. They represent the vision of one person or a very small group made real by the hard work of hundreds or thousands of skilled and semi-skilled workers over dozens of years. Cathedrals are not, generally speaking, profitable. They represent the expenditure of lots of capital over a long period of time. Bazaars don't cost much to start. You can start quite small and have a functioning system that does useful things for people. They can grow quite large, and when they grow too large it becomes difficult to find exactly what you want without a really good map. But you can probably quickly find a bunch of things that are more or less close to what you want. Cathedrals are not easy or cheap to repair, but the investment is so large that people usually prefer to repair them. A bazaar that doesn't work out makes some local people sad, but they will go to another bazaar that is a little less convenient for them, and perhaps do better there. It's nice to have some cathedrals, because they feed the soul. But you need to eat every day, so there will always be bazaars, and if you need to make a choice, the bazaar is going to win unless you have a lot of resources stored up to fall back on.

derefr 10y ago
You can build a cathedral around the stalls of a successful bazaar, no? Like OSX or Android.
- Ologn 10y ago
  Android a cathedral? If you wanted tabs in Android prior to 13, you'd setup a TabHost with a LocalActivityManager ( https://developer.android.com/reference/android/widget/TabHost.html#setup(android.app.LocalActivityManager) https://developer.android.com/reference/android/widget/TabHo... ). Then in version 11 ActionBar.Tab is added and LocalActivityManager is deprecated in version 13. By version 21 they became bored with that and deprecated it ( https://developer.android.com/reference/android/app/ActionBar.Tab.html https://developer.android.com/reference/android/app/ActionBa... ). You wouldn't know it was deprecated though as the most current training documentation still recommends using this now-deprecated method ( https://developer.android.com/training/implementing-navigation/lateral.html#tabs https://developer.android.com/training/implementing-navigati... ). All you are left with is a pointer to a vague, ambiguous page in the context of the deprecation method. Welcome to the cathedral of Android developing. BTW the release dates for these APIs: API 11 - February 2011 API 13 - July 2011 API 21 - November 2014 The annoyance isn't that they changed it, it's that they didn't like the old way, so they changed it, then three years later they changed it again. They do this all the time. Plus they deprecated it, but still recommend the deprecated method in the tutorial, and leave it as a mystery how it should be implemented in current best practices. The current most up-to-date tutorial on their web site is chock full of recommending things which they deprecated already.
  - anabis 10y ago
    I wish they would at least put dates on the documentation. I find myself reading halfway through a outdated tutorial before some names or versions makes me realize it.
    - flukus 10y ago
      I wish google would favor newer, more accurate solutions. Or at least provide away to flag no longer useful content.
  - HillaryBriss 10y ago
    Agree. Definitely no cathedral. And what about customizing a Spinner's font and background color and popupBackground color and putting a non-standard element at the top? And the amount of time it took before Android got percentage based spacing in layouts? And the fun of remembering what UI attribute-values like android:gravity="center_horizontal", android:layout_centerHorizontal="true" and android:layout_gravity="center" mean? And the awkwardness of using non-standard typefaces and using things like the RecyclerView and it's weird Adapter? And the fact that for some reason they used an XML element named "layout" when they implemented their data binding feature? And the fact that some attribute names are camelCased while others are underscore_cased? And the ease with which memory leaks are introduced by inadvertently closing around context instances because you need context instances all over the place because the Activity is a god object? It's all so very ... not ... like ... a cathedral.
    - pjmlp 10y ago
      Sometimes I have this feeling that they just offshore everything and just do some kind of integration at Mountain View.
      - HillaryBriss 10y ago
        interesting. i often wonder how the Android SDK got the way it is too. my hazy guess was that Google simply hired a bunch of extremely smart programmers and let them code whatever they wanted. but there is no equally smart architecture/design team to guide, organize and filter the work. there's just a build system. maybe that's essentially the same as your theory.
- adamnemecek 10y ago
  macos (nee osx) is the result of combining freebsd and the mach kernel, both very cathedraly technologies.
  - mturmon 10y ago
    And now we see just how confused this discussion is. It's conflating a bunch of concepts via a historically weighted analogy, which itself has a lot of baggage at this point. For more, see this perceptive comment: https://news.ycombinator.com/item?id=12251705 https://news.ycombinator.com/item?id=12251705
  - nickpsecurity 10y ago
    I'd consider what's on top the more cathedraly part. It has the consistency in design and implementations. Merging FreeBSD with Mach might have been centralized developers looking for good results but actual results seem a bit more bazaar. QNX was the older cathedral of mixing UNIX and microkernels with good design + performance. There were others but it stands out.
  - josteink 10y ago
    > macos (nee osx) is the result of combining freebsd and the mach kernel, both very cathedraly technologies. Not to mention the remains of NextStep. Also very Cacthedraly. Edit: thinking about it, I wonder why Apple didn't keep using that name/brand. It's obviously there all over the API. Was the NextStep name/brand tainted as a doomed technology at the time?
CookieMon 10y ago
> Cathedrals are not, generally speaking, profitable. This is getting lost in the metaphore, instead of the topic. Architected software is profitable.
- erikpukinskis 10y ago
  Architected software would be profitable in fewer scenarios if we (software developers) didn't maintain such a high barrier to entry. We design our tools for ourselves and other professional programmers so that we don't have to compete with non-professionals with a better sense of the requirements. We force people to come to us, to defer to our understanding of how much architecture is necessary. We make our codebases just easy enough for a pro developer and no easier, refactoring and simplifying only when it becomes painful for a pro developer, and no sooner. That way they have to keep us as gatekeepers to all code. It's essentially like you only made building tools for cathedrals, and no tools for thatched stick homes, and you create a culture around always building a cathedral so no one really knows how to build a thatched home. Essentially, creating a market irregularity through cultural expectations about how serious software has to be and who is going to be writing it. (The complaint people always make when I say this is that making software isn't easy, it's hard, and notices couldn't possibly build useful software. I would half agree: some software problems are hard, and require a grizzled developer and some hard planning. But much of software involves no difficult computer science problems, and is more about understanding requirements well enough to be able to assign them to the right basic programming primitive, or a handful of common libraries. This is the kind of code that we use cultural friction to keep inside Engineering, and build cathedral-style, even though it could be done in thatched-home style by notices, if we structured our codebases for that.)
  - dietrichepp 10y ago
    I almost spit out my drink. High barrier to entry? The barrier is lower than it ever has been. Any nut-job with a few weeks of training can make a shitty website with PHP or Node.js and have it instantly accessible to the most of the English-speaking world. Most of the tools I see for software development seem to be organized around the needs of the bazaar (or thatched huts) not the needs of the cathedral. A million toy languages which might solve your problem well, but don't scale to a million users. Websites like GitLab and GitHub so you can share last week's 1 kloc project with collaborators. Libraries that do that one weird thing you need for your project, and nothing else. By comparison, the cathedral builders (Google, Facebook, Apple, Microsoft, etc.) seem to be building a lot of their own tools. This includes programming languages, frameworks, build systems, version control, operating systems, and so many other things. They build their own stuff because the tools of the bazaar don't work quite well enough for cathedrals.
Clubber 10y ago
A few points just for fun: 1. Christianity, the group who builds Cathedrals, is probably the most profitable organization in the history of mankind. 2. Bazaars blow away when the wind picks up. If too many people show up, things start falling down. Cathedrals, and their close cousins, castles, last centuries. 3. I think Bazaars have their place, when you really need to ramp up something to show. We used to call that prototyping. If it gets past that, you gotta build it right eventually.
- hexane360 10y ago
  2. Bazaars pop back up seconds after they blow away. http://youtu.be/MENjFkEAj9g http://youtu.be/MENjFkEAj9g
  - happyslobro 10y ago
    An epic win for cross platform compatibility ;)
  - taneq 10y ago
    Yeah, but nothing's quite where you left it, your favourite curry stall is gone for good, and you'll never be able to get a refund on that thing you bought that stopped working the day before the storm.
- aaron695 10y ago
  > 1. Christianity, the group who builds Cathedrals, is probably the most profitable organization in the history of mankind. I don't need to be the richest organization ever. I'd be happy for 1000th place and those billions rather than overreaching for number one and the risk that entails.
- eggy 10y ago
  Point 3 is what I consider a good model for the building metaphor. Let Bazaars spring up where needed and wanted. When the ground is proven, then clear and build a well-architectured Bazaar, not necessarily a full-blown cathedral unless it really calls for it. This sometimes happens when codebase if re-written from scratch with the old code as reference, not just cleaning up old code. I think AutoDesk did this when Inventor came along, but I am not sure. A big re-write if ever there were one.
jaza 10y ago
Perhaps what we need are shopping malls. Aren't they, after all, the modern cathedrals of consumerism? (And aren't they just what we need more of in this world?) :P Shopping malls aspire to be beautiful (primarily on the inside), but they can never be as beautiful or as well-architected as cathedrals, in form or in spirit. Shopping malls have a bigger overhead than bazaars, and are less flexible. But their overhead is much less, and their flexibility much greater, than that of cathedrals. Shopping malls provide more foundation and infrastructure than bazaars do. A bazaar minus its stalls is just a dusty field. A shopping mall minus its shops still has multiple levels, maps / directories, elevators / escalators, parking, loading docks, etc. It costs more to set up shop in a mall than in a bazaar, but your shop will be more trusted, you won't have to squabble for space with your neighbours every day, and you won't get blown away by the next storm. Shopping malls are designed with dedicated spaces that are tailored to different businesses. A supermarket has very different needs compared to a shoe shop. Shopping malls are bazaars with a tonne of design, engineering, and regulation thrown in. But they're still bazaars. They're still where you get your groceries.
- HillaryBriss 10y ago
  you're on to something good are you the one who writes "The Shopping Mall and the Bazaar" and leads us into a better era?
  - DonHopkins 10y ago
    "Software development is hard. Let's go shopping!" -Tech Talk Barbie
    - cvs268 10y ago
      > Software development is hard. Let's go shopping!" -Tech Talk Barbie ...or Yahoo, or Google, or IBM, or Hooli, or <Big-Fat-Tech-Giant>.
- mbrock 10y ago
  A shopping mall is also an example of what some theorists call "antimarkets": places which resemble a typical market with competition and choice but which are heavily regulated and controlled to exclude open participation. Kind of like if the iOS App Store only had room for 15 apps, and Apple Inc decided which, and the roster was only updated every few years at most.
caseymarquis 10y ago
Cathedrals are very profitable; as long as there's religion.

gavinpc 10y ago

Mods, please add 2012. Most recently discussed here at https://news.ycombinator.com/item?id=9403124 https://news.ycombinator.com/item?id=9403124

k__ 10y ago

I like the Bazaar. It's a bit like "normal" people sticking it to the elite. The rest of the world getting a piece of the cake too...

droopyEyelids 10y ago
In your analogy the people who get stuck trying to fix crazy shit with makefiles are the elite. Which will probably be you one day. Which means you're sticking it to yourself.
- pjc50 10y ago
  In Free Software, everyone gets a turn at being the Man.

qwertyuiop924 10y ago

...And if you think the Bazaar precludes somebody making decisions about quality, you haven't payed attention to how linux development works. Except epoll. And vsyscalls. And... You know, maybe Linux isn't well managed.

Annatar 10y ago
Shhh! Don't criticize Linux even if it's true, you'll get downvoted faster than you can bat an eyelash! That's extremely unpopular here. 'Cause you know, man. Linux.
- qwertyuiop924 10y ago
  Hey, I run Linux. I just think that it's worth acknowledging that it's got some flaws. One of the reasons I listen to people like Bryan Cantrill. I don't take what he and the BSD folks say at face value - If they're working on competing projects, they obviously don't like Linux technically - but sometimes, they're right. Especially about epoll. Jesus. Anyway, GP is +3. It got downvoted a ton, but it bounced back.
  - Annatar 10y ago
    Competing projects or not, Bryan is correct. The FreeBSD folks also have a pretty good clue.
    - qwertyuiop924 10y ago
      Well, yeah. But I can't trust him out of hand. Are you a Plan9 user, by any chance?
      - Annatar 10y ago
        Nope; Solaris / illumos / SmartOS.
        10y ago

haddr 10y ago

It's a very nice read with many good points, but any person with some experience in IT projects could argue with it. The author is taking one side without any self-criticism. It is true that configure scripts are probably doing some useless things, "31,085 lines of configure for libtool still check if <sys/stat.h> and <stdlib.h> exist, even though the Unixen, which lacked them, had neither sufficient memory to execute libtool nor disks big enough for its 16-MB source code", etc. But then what is the alternative? Writing a configure module each time by every programmer who wants to release some software? This is called code reuse and yes, it's not perfect but it saves time. By not reinventing the wheel again and again. By reusing something that is stable and has been there for some time. Probably such thing is generalizing over many architectures, and making useless things, but then again, who cares for some extra 5-10 seconds of the "configure" command, when you are covered for all those strange corner cases that it already handles?

x0x0 10y ago
Insane complexity in build systems just makes your life sad. Trust me, I know -- I write java for a living. We have ivy, maven, ant, gradle, sbt, leiningen, and I'm sure a few more.
- d_burfoot 10y ago
  Hey, I write Java for a living and my build script is just a Python program that marshals a javac call.
  - qwertyuiop924 10y ago
    I write scheme not for a living. My build script is a scheme file or a makefile, depending on the project. The build complexity is one of the reasons I stay away from Java: If these people think they need XML for builds, what other needlessly complex horrors have they perpetrated? And that sort of thing. Do you have your buildscript template on github?
    - quantumhobbit 10y ago

amasad 10y ago

I've been thinking a lot about this in the context of software development tools. It is now just expected that IDEs, compilers, tooling etc are free and OSS. On the one hand this enables bottom-up innovation and shorter development cycles. On the other hand setting up a development environment is a royal pain in the butt. And a big turnoff for newbies -- they begin to think that programming is some sort of IT job about installing and troubleshooting software. Even when you manage to set everything up there is constant maintenance cost as you update software and as new things come out. At the very least, I would love to see companies created around popular open source tools and verticals to create designed end-to-end experiences. Download, double-click, start coding, and see something on the screen.

csours 10y ago
And if you work behind a corporate proxy, expect all of the above to be an order of magnitude worse. Oh you set the proxy setting in the IDE/Shell/Package Manager? You forgot about x, y and z; and websites foo, bar, and bas are blocked!
- voltagex_ 10y ago
  I remember a few years ago, before Git had NTLM support (for proxies), I had to use all kinds of terrible hacks to get online. Recently, the proxy I'm behind for at least 8 hours a day has been changed to accept Basic and Negotiate, but I didn't realise that until I'd spent a not insignificant amount of time yelling at NPM. Even if you do get online, don't forget to configure the MITM CA cert! Next up, apps that try to execute from %LOCALAPPDATA% (Squirrel installers). This is blocked by most AppLocker configs. Isn't "enterprise" computing fun?
- superuser2 10y ago
  Transparent proxies and 802.1x auth have been around for a while. Even my high school got off the "you must configure a proxy server in every application" train. IMO that is just poor IT.
douche 10y ago
There are non-terrible development stacks. Some of them are even free. Unfortunately too much of it is endless turtles-all-the-way-down yak shaving marathons, like in the JS world. I forget whether I'm supposed to grunt, gulp, babble, or barf. You just have to get out of the churn-for-churn's-sake cesspools. There are high-quality, stable software stacks out there, where the Cambrian explosions and rediscovery of ideas from a generation ago have already passed.

davidw 10y ago

> compiling even my Spartan work environment from source code takes a full day Maybe compiling everything on every computer is not the best approach...

phkamp 10y ago
For everybody ? No. But some minority have to take the open SOURCE seriously, if we want it to actually work. I'm part of that minority.
- emmelaich 10y ago
  I don't understand that point of view at all. If you control the dependencies, you get a predictable result.* Why do it again and again? To be sure to be sure? * Debian's work on reproducible builds will help here.
josteink 10y ago
> Maybe compiling everything on every computer is not the best approach... If you're working on a FOSS operating system (freeBSD), where one of the components/features you provide your users are the ability to install almost any software, customized to your needs (the ports system), you probably want that part of the system checked and working. You know, dogfooding your own delivery, and I for one am glad someone is still willing to adhere to that standard of software development.
- davidw 10y ago
  > customized You can do this with Debian style packages too - it's perhaps a bit more involved, but entirely possible. And there's an argument for only customizing the few things you need to and just getting binaries for the rest.

vessenes 10y ago

And yet..I think this critique gets less strong as time goes on. The amount of productivity available to Mr. Kamp for free today is conservatively double or triple that available in 1999. Databases, web frameworks, scale know-how, IDEs, hosting platforms, the list goes on. He harkens back, sadly, to an era in which codebases like Genuity Black Rocket cost $100k in licensing, and ran on $30k/month Sun servers. Seriously. Languages are faster, development times are shorter, and chips are WAY faster. And, code can be pushed out for tinkering and innovation onto github for free. Combine that with his estimate that we have 100x more people in computing, and the combination is a riot of creativity, crap, fascinating tech and everything in between. The bazaar is messy, but I'm not aware of any solid critiques which show cathedrals are more efficient at the multiples-of-efficiency kind of gains we get from legions of self-interested, self-motivated coders.

_bpo 10y ago
> Languages are faster, development times are shorter, and chips are WAY faster. This is due to Moore's law, not the software design choices that the article bemoans. Those $30k/month Sun servers were many times faster and cheaper than the earlier machines they replaced as well.
- vessenes 10y ago
  While Moore's law helps, languages are more expressive, safer, more performant and have more batteries included yielding a whole bunch of improvements. We've had software and hardware gains, massive ones, and they compound.
  - SolarNet 10y ago
    > While Moore's law helps, languages are more expressive, safer, more performant and have more batteries included yielding a whole bunch of improvements. I have to disagree, compilers may have gotten a bit better at making faster binaries. But languages, like new languages, are increasing in expressiveness and safety, sure, but very rarely efficiency. Go and Rust are not faster than C or C++, likely never will be (for one C has decades of lead time), Go and Rust may be faster than C was 20 years ago, but that doesn't matter.

RachelF 10y ago

Having seen the source for a non-Bazaar OS (Windows), I can say that they are not built like cathedrals: Most of the original developers have long since moved on, there are design problems, various teams and managers rebuild or duplicate work, and management sometimes imposes big changes just before release. Software quality is hard to judge from the outside, and takes longer to build.

flukus 10y ago
This is a good point, I wonder if cathedrals really exist in the real world? I suspect they are all just isolated bazaar's.
dfox 10y ago
Windows (at least for userspace components) has significantly less self-contained modules (which thus contain larger amounts of functionality) than any modern unix-based system and there are almost no modules that are widely used and not supplied by Microsoft (excluding stuff that is ported from unix and various third-party hardware APIs). One of reasons for that is probably that before .NET, there was essentially no support in VS for building applications as anything other than big self-contained .EXEs and the current solution/project mechanism leaves much to be desired.
- asveikau 10y ago
  What the hell are you talking about? Just take your Unix mentality and make a few substitutions: * gcc -> cl.exe * ar -> lib.exe * ld -> link.exe * make -> nmake.exe * libfoo.so -> foo.dll And there you have it, the world that "didn't exist before .NET" ... This is crazy amounts of ironic because Windows had DLLs at a time when shared libraries were not so much a thing on Unix. Not to mention things like COM which are all about creating de-coupled components.
  - douche 10y ago
    Do you remember DLL hell? Pepperidge Farms remembers /s

hyperpallium 10y ago

Successful bazaars have a flat architecture, meaning you can easily add another component, to handle a new case. It's not always the ideal technical architecture for the problem.

danblick 10y ago

Slightly OT, but I enjoyed the discussion about (physical building) construction in the book "the Checklist Manifesto". In The Mythical Man Month, Brooks advocates the use of something like the "master builder" model for software. It turns out that in actual (physical building) construction, the master builder model is no longer used, because the construction process has become much too complex to be understood by a single person. Instead, in construction, they use a system of checks to ensure that different experts consult one another so that every decision is reviewed by a relevant expert. I suspect that the "chief architect" approach that Brooks advocates may have become obsolete as well since the Mythical Man Month was written. Perhaps software developers could learn something from the newer methods that replaced the "master builder" model in construction.

DigitalJack 10y ago
The checklist manifesto was a great book. Probably time i read it again.
- bordercases 10y ago
  It was too breezy, too slim and too hyped for my taste. The insights themselves still are valuable, but perhaps worth only half the size of the book.
  - djtriptych 10y ago
    But would you have paid $15 for a 25 page pamphlet? :)
    - 13of40 10y ago
      That's a very good point - I've always felt it was a shame that in order for a thesis to be "publishable" you have to frame it in 300 to 500 pages. The Design of Everyday Things by Don Norman is a great example. It's an awesome book, and anyone who's designing user-facing-anything should read it, but I think the story could have been told in about half as many words.

haberman 10y ago

There are way too many dichotomies that are getting muddled in this discussion: - hacky vs. beautiful - professional vs. amateur - waterfall-designed vs. evolving - centralized control vs. consensus control - crufty vs. well-maintained - open-source vs. closed-source With so many axes to argue about, we can project whatever we are feeling about software today onto this "cathedral/bazaar" debate. We may think we are having one discussion, but we're actually having six discussions (or more) at the same time.

qwertyuiop924 10y ago
Hacky vs beautiful is diferent from The Right Thing vs. Worse is Better. Worse is Better is a very specific philosophy (at least, as it is described in Lisp: The Good News, The Bad News, And How to Win Big) The Right Thing philsophy is, in essence, that simplicity of interface is the most important thing: every interface is an abstraction, abstractions shouldn't leak. Have a simple interface, be correct, be consistant, be complete. If the implementation is complex, so be it. By contrast, the worse is better philosophy prioritizes simplicity of implementation: Be simple, be as complete, correct, and consistant as possible, but between having a simple design, and being slightly wrong, a little inconsistant, and not as complete, and having a complex design that is all of those things, take simplicity: 90% now is better than 100% never. Over time, Unix has adoped some Right Thing ideas (plan9 took this to 11), and Lisp has adopted some New Jerseyisms (Scheme's dynamic-wind is definitely this).
- haberman 10y ago
  You are right. I wrote that too quickly before thinking about it. I removed that part of the post.
  - qwertyuiop924 10y ago
    You are far from the first person to misunderstand/misrepresent worse is better. The best part is when people recommend reading the essay, and then demonstrate they they don't know what it meant: It's not about the battle between simplicity and complexity, it's about the battle between simplicity of interface and the simplicity of implementation.

smegel 10y ago

> The bazaar meme advocated by Raymond, "Just hack it," as opposed to the carefully designed cathedrals More like carefully designed procedures (not the software kind), meetings, and suit ties. The waterfall process can be as technically deficient as you want it to be, just like agile.

csours 10y ago

Recurrent calamities, fires and earthquakes hit the Grand Bazaar. The first fire occurred in 1515; another in 1548.[9] Other fires ravaged the complex in 1588, 1618 (when the Bit Pazari was destroyed), 1645, 1652, 1658, 1660 (on that occasion the whole city was devastated), 1687, 1688 (great damage occurred to the Uzun Carsi) 1695, 1701.[14] The fire of 1701 was particularly fierce, forcing in 1730-31 Grand Vizier Nevşehirli Damad Ibrahim Pasha to rebuild several parts of the complex. In 1738 the Kizlar Aĝasi Beşir Ağa endowed the Fountain (still existing) near Mercan Kapi. https://en.wikipedia.org/wiki/Grand_Bazaar,_Istanbul#History https://en.wikipedia.org/wiki/Grand_Bazaar,_Istanbul#History

spitfire 10y ago
That's a good idea, maybe the Baazar needs a good fire. Fires help forests stay healthy returning a lot of biomass for new healthy forests to grow. Maybe the ecosystem needs a good fire to clear out the diseased old growth?
- kardos 10y ago
  > Maybe the ecosystem needs a good fire to clear out the diseased old growth? Ehhh, the analogy works better in terms of competing species. If a stronger invasive species rolls in and takes over due to raw excellence, we can see the eviction of the old cruft. For example, once the dust is finally settled in a few more years, we may come to see systemd as such a force.

ktRolster 10y ago

The article says that to have quality, someone needs to be responsible for it. Of course, the "Bazaar" included the project named "Linux," which does have a single person in charge. So "single person in charge (or not in charge)" isn't really what the bazaar is about. More generally, the article laments the lack of quality in modern software. I don't think that's a problem of Cathedral vs Bazaar, though, since software designed top down with authority telling everyone what to do can be low quality (indeed, you can see this sort of thing happening in many scrum style companies). Rather low quality software is a reflection of the skill of the people who built it.

asragab 10y ago

I love how this article makes its reappearance on HN every two years... https://news.ycombinator.com/item?id=4407188 https://news.ycombinator.com/item?id=4407188 https://news.ycombinator.com/item?id=8812724 https://news.ycombinator.com/item?id=8812724

HillaryBriss 10y ago
nice
Annatar 10y ago
And judging by how much garbage software there is out there, written by people without a clue who think they have one, it needs to reappear a hell of a lot more!
whatever_dude 10y ago
And it's still relevant. I read it every year or so and still finding myself nodding to it.

BadassFractal 10y ago

It's why I use OSX at home for anything non-work related, I want an integrated experience that just works, I don't want to be IT guy at home. No messing around with video card drivers, no figuring out why my printer chops off pieces of the page, no constant wifi or bluetooth crapouts, support for Adobe suite or popular digital audio workstation software. At work I'm happy to use Linux, but I use it for things it's great at, such as simulating our prod environment, coding, etc, but at home I just don't want to think after a long ass day, I want to enjoy computing.

c22 10y ago
I'm not sure which linuxes you use but sans Adobe support I haven't had any of those issues for at least 7 or 8 years. In fact Debian just works with both my printer and my graphics card while Windows 10 refuses to print or display a resolution above 1024x768.
- BadassFractal 10y ago
  Been using Ubuntu for about 5-6 years now. On laptops the wifi drops all the time. Bluetooth fails to connect half of the time or gets stuck and needs a reboot. I can use my Brother printer, those drivers "work", but it fails to center the page properly out of the box, comes out all mangled. Just got a 16.04 fresh install from a vendor, software update immediately borked permanently, had to find https://www.youtube.com/watch?v=vjfMYjRjAv8 https://www.youtube.com/watch?v=vjfMYjRjAv8 to be able to move past it. Again, I'm expected to be IT guy or Geeksquad Man to be able to use this OS, which I'm happy to do at work, just not on my time. If you go over Ethernet, use extremely conventional hardware and only expect to use it as a machine to browse the Internet then you'll generally be just fine. It's free, I can't complain, but it doesn't make it any less of a shit show.
linuxhansl 10y ago
Printer support (as an example) worked much better with Linux (Fedora) than my MacBook. On the Mac I had know the IP address, download a driver myself, fiddle around with it. On Fedora, it said it found this printer, installed the driver, and whether I wanted to print a test page. The test page printed fine. That was a while ago, and things may have changed. But it's not the only example. With OSX I am boxed into what Apple thinks is best for me. With Linux I can do whatever I like, while most things also just work. None of the issues you mention are an issue with Linux anymore. Wifi, Bluetooth, printers, sound, video, etc, all just work, most (IMHO) more intuitively than with OSX. Only for faster 3D graphics I had to install the vendor driver from a non-free Fedora repository.

cbsmith 10y ago

I still hate this essay as much as I did when it first published it. It misunderstands the problems. Unix was fragmented long before 1991, when autoconf was created. Prior to autoconf, Perl's Metaconfig did this dance, and a lot of other, lower quality systems like imake were used to work around the problem. The forces behind Unix's fragmentation was actually not the Bazaar (open source software), but attempts by multiple parties to independently build their own Cathedrals (in attempts to differentiate/provide value with proprietary systems). Of course, autoconf, as a GNU system, was, in Cathedral & Bazaar terms, a Cathedral, not a Bazaar. Autoconf is ugly/copy-paste code because it is comparatively rarely run, so as long as it produces a passable result, people use it and focus their efforts on other, bigger itches. There's also a long history of open source products which have enjoyed higher quality implementations than their proprietary equivalent. The Apache project itself stood as a higher quality web server than a lot of other choices (not as true today, but it was true for quite some time). One could go on...

cpeterso 10y ago
Do we still need autoconf in 2016? Systems are becoming more homogeneous with the spread of Linux, GNU, and common programming conventions.
- swolchok 10y ago
  You could argue that autoconf sucks and clearly everyone should use your favorite build system, but you need something to do the job. Not even two systems running the same release of the same distribution are going to have all the same packages installed. I might have put a newer version of X in /usr/local. I might want to cross-compile. Even considering all Linuxes the same, I might want to build for x86, x86_64, MIPS (routers), ARM, PowerPC, or some more esoteric chip. Android has its own special problems, including a different libc. I might want to ship on BSD (which one?), OS X, iOS, cygwin, mingw, or that newfangled Windows subsystem.
  - cbsmith 10y ago
    > You could argue that autoconf sucks and clearly everyone should use your favorite build system Well, in fairness, build systems often deal with a different set of problems.

peterwwillis 10y ago

He's complaining that the Bazaar is not efficient, and that it's a pile of hacks. No. Shit. Yes, it's an inefficient pile of garbage built one heap on top of another. But it's also incredibly useful. Modularity and code reuse are, of course, A Good Thing. Even in the most trivially simple case, however, the CS/IT dogma of code reuse is totally foreign in the bazaar: the software in the FreeBSD ports collection contains at least 1,342 copied and pasted cryptographic algorithms. If that resistance/ignorance of code reuse had resulted in self-contained and independent packages of software, the price of the code duplication might actually have been a good tradeoff for ease of package management. But that was not the case: the packages form a tangled web of haphazard dependencies that results in much code duplication and waste. Code duplication, waste, and a tangled web of haphazard dependencies are only a bad thing in theory. PHK talks about "CS/IT dogma" like it's the rule rather than the exception. But the CS/IT dogma, like most other dogma, always runs into exceptions when put into practice. When you have many, many independent teams of people developing software, you may want to implement something someone else has already done. As a member of your team, you have two choices: 1) re-implement the original as part of your own cathedral, or 2) put some glue around the existing solution. Sometimes, 1) will be the best choice. But sometimes - and this is usually the case with Unix tools - 2) works just as well, and you get the benefit of only having to write and maintain glue, rather than a constantly morphing feature implementation. If the original was done well, and your glue supports it well, you get a feature without paying for it. The foundation of Unix is a strong Cathedral. But this foundation is what makes the Bazaar fit so well around it: it provides something strong to glue other shit to. As long as you have someone to continue gluing shit together, you can keep adding pieces ad infinitum, and what you lose in the end is essentially disk space and compilation time. I'm willing to accept that.

deleted 10y ago

[deleted]

duncan_bayne 10y ago

ESR agrees with the criticism of Autotools: http://esr.ibiblio.org/?p=1877 http://esr.ibiblio.org/?p=1877 "Autotools must die"

jesstaa 10y ago

"the ruins of the beautiful cathedral of Unix, deservedly famous for its simplicity of design, its economy of features, and its elegance of execution" unix is the bazaar enabler. An OS that is so simple as to be mostly useless without third party additions but also without enough of an overall design to give the third parties much of a guide on how things should fit together. The mess that unix enabled is also the reason we can't get away from it and move on to better architectured systems.

njharman 10y ago

For any given software thing you can 1) pay for the cathedral 2) use the bazaar, possibly needing to seed it 3) do without Since 1) is typically very expensive and lacks guarantees of suitability to purpose and continued existence, the ROI is so massively negative few can even try it. 3) often isn't an option. the bazaar is an inevitability. No one has been mandating it for past decades. No laws enforce it. It occurs cause it is the only available/possible option.

lifeisstillgood 10y ago

So a while back I had a JIRA ticket, to go add a feature to a pile of JS front end. I did not understand the pile very well, but that's OK, neither did anyone else, and I expected to add a large amount of tests and code to get the job done. But I like understanding the code, so I read and read and puzzled and fended off "hurry up" comments. And then I added two lines and it basically worked. I am in favour of a slow code movement (http://www.mikadosoftware.com/articles/slowcodemovement http://www.mikadosoftware.com/articles/slowcodemovement) which seems relevant here. Even better was a guy I worked with, physics PHd from central China, whose daily stand up reports mostly consisted of "Inspent yesterday reading around the subject, I shall spend today, reading around the subject." Love him, love the brass balls.

jmspring 10y ago

When it comes to ecosystems, the definition of the Cathedral becomes interesting. Say what you will about business practices in the 80s, 90s, early 2000s... In a sense Windows was a cathedral. It bent over backwards while accepting the new. Welcoming many under the umbrella. Sure it is a stretch, but the Windows platform (for years) required backward compatibility. That was the world Microsoft worked in. Today, the OS still maintains cathedral aspects, but the company is embracing the bazaar way more than I ever thought I would see in my lifetime.

phkamp 10y ago

(Author of the essay here) It is discussions like this which make me truly admire Douglas Adams for his insights and ability to express them. For instance, when I read through the debate here, I can't help notice how many of the arguments are really variations of "It's a bypass! You've got to build bypasses! Not really any alternative."

isuckatcoding 10y ago
For me the highlight was: 'That is the sorry reality of the bazaar Raymond praised in his book: a pile of old festering hacks, endlessly copied and pasted by a clueless generation of IT "professionals" who wouldn't recognize sound IT architecture if you hit them over the head with it.' I was hoping for some kind of expansion or attempt at a solution here (which of course would be non-trivial).
- phkamp 10y ago
  The (only) solution is for people to care about quality in computing. There's still too much money to be made on kludges for that to happen.
  - pjc50 10y ago
    .. and no money to be made on quality. It's Akerlof's "Market For Lemons" writ large. Users can't assess the quality of software before they buy it and sink ages of their own time into learning it. Often users can't assess quality problems even after they've bought it. So the market isn't going to reward quality. (The original paper was about cars; now we have software in our cars the problem is twice as bad. VW 'defeat devices' and Toyota 'unintended acceleration' passim).
sutro 10y ago
Thanks for your words and your code, phk. Thanks especially for Varnish, a beautiful cathedral.

sgt101 10y ago

petty point; the author says "growth by 2 orders of magnitude or 10000%" is it just me or is that 4 orders of magnitude?

mdpopescu 10y ago
10000% = 10000 / 100 = 100 = 2 orders of magnitude

kuharich 10y ago

Previous discussions: http://news.ycombinator.com/item?id=4407188 http://news.ycombinator.com/item?id=4407188 https://news.ycombinator.com/item?id=8812724 https://news.ycombinator.com/item?id=8812724

sbarski 10y ago

One of my favourite ACM articles. I think I read it twice the first time I came across it. Also bought "The Design of Design" thanks to it.

veddox 10y ago

It sounds like a lot of stuff that the author complains about falls under Sturgeon's Law. To paraphrase him: "Sure, 90% of FOSS is crud. That's because 90% of everything is crud." Not to lessen the many valid criticisms that the article contains, but I think the low average quality of code can be adequately explained with the above law.

neo2006 10y ago

I like to think of software as a living entity that grow evolve, get sick and eventually die. There is nothing wrong with refactoring or diying code it's part of the natural process of engineering software. Sometime we take the decision to not refactor, that's also ok as long as you know that this will make cost you more to do it later or will code will end up diying. Your code is like a pet, his love depend on how much effort you put to take care of him. Sometime, it's sick by design and where ever effort you put in won't save it. So now if we talk about how to design software that will live long and prospere you need to guess/predict the future and have an idea on all the forms that your software will evolve to and all the intented and non intended use possible for it and avoid all mistakes in you design and then you will have a warranty otherwise you need to design the simplest way and make it evolve when needed by refactoring, fixing and patching...

Jtsummers 10y ago

> This is probably also why libtool's configure probes no fewer than 26 different names for the Fortran compiler my system does not have, and then spends another 26 tests to find out if each of these nonexistent Fortran compilers supports the -g option. It's been awhile since I've dealt with autoconf and company, but I remember seeing things like this. This is bizarre, to me. It should be a simple process. Make a pass to detect fortran compilers, make a second pass to detect support for -g. (This is, of course, assuming that we even want to use this at all.) I remember cleaning up a coworkers project that did something similarly inane. A pass over the data revealed something wasn't present. But his test scripts continued processing, including rereading the original data, as if the something were present. Wasted 20 minutes each time it was executed until I rewrote it to break early. If X depends on Y and Y is absent, then don't do X.

futuremeats 10y ago

What are some examples of cathedrals? Based on my reading of the original article, these would need to meet two requirements... 1. Software has been in service for a long time (let's say more than 10 years, though some will debate the timeframe). 2. Software is recognized as of enduring, well-conceived design. The second point is an important one. I have read that there are some government (IRS tax calculation) and industry (airline reservation systems) which have been in place for far longer than 10 years, but their longevity is more a function of the risk-aversion of the organizations that needed them, and less a testament to their "beauty."

aeorgnoieang 10y ago

rolls-eyes This is a terrible, whiny perspective and the author could use a heaping dose of economic thinking. Sure, there's lots of 'terrible' software and it would be great if it were better or there was less of it! Except there are real costs to improving software or to preventing 'terrible' software from being released, or used, or disseminated. I am so happy the author is not a position to make decisions about this stuff for everyone else. All software is to some degree a hack or kludge.