12 ms·

Shipping Culture Is Hurting Us

231 points by uam 12y ago

didgeoridoo 12y ago
The author talks about languages and technologies (JS, Mongo), but he's really getting at something deeper. The real danger of the "ship it" culture is that things that can't be "shipped" right away — things that require solving really hard problems — tend to fall off our collective radar because there is just SO MUCH cool and (relatively) easy stuff to do right now. PG has a great term for this: "schlep blindness": http://paulgraham.com/schlep.html http://paulgraham.com/schlep.html
- digi_owl 12y ago
  Makes me wonder if this is why i find the whole "devops" concept to be raising my hackles.
  - saidajigumi 12y ago
    Maybe that depends on who's uttering the phrase and what it means to them. Some points in the space: - "Devops" as a movement encompassing the ideas that developers should not be walled off from operational realities, and that software operations tasks should be encoded as repeatable, testable software (vs ad-hoc stuff a sysadmin does on a box somewhere). - "Devops" as "oh look, we can hire less people and just get some 'devops' to do it all."
    - digi_owl 12y ago
      The way i have seen it used was more like the inverse of your first example, where one go from encoded and tested sysadmin tasks to "lets throw into production any newfangled thing the devs (monkeys hammering keyboards, more like it) wants to use".
      - 23david 12y ago
        Devops can definitely be used as a very expensive bandaid around poor engineering practices. But there's more to it... sometimes the engineering work it takes to prevent something from crashing is much less than just monitoring and restarting when failures are detected. Maybe "failure engineering" is a good term for a lot of the value Devops techniques can bring to a team?
        dkarapetyan 12y ago
        But isn't that what all systems engineering is all about? Feedback loops with resiliency. Why is it that the software folks think they have discovered something new?
        nitrogen 12y ago
        When implementing a failure-tolerant system, one has to remember that "crash" can often be parlayed into "exploit" or at least "denial of service", and thus not become too tolerant of failure.
  - dkarapetyan 12y ago
    How about "full-stack developer"?
    - makeitsuckless 12y ago
      That's the one. That's basically short hand for "you don't need to do anything really well, you just need to do everything barely good enough to ship it now".
      - CmonDev 12y ago
        The sad bit is that many full-stack developers are actually better that specialized developers in respective skills. (unless of course they are JS/Node.js types)
        _pmf_ 12y ago
        > The sad bit is that many full-stack developers are actually better that specialized developers in respective skills. But those do not call themselves full-stack-developers.
    - _pmf_ 12y ago
      > How about "full-stack developer"? It means you can play both kinds of music: country and western
    - EliRivers 12y ago
      Which really means "OUR stack developer, being a subset of the full-stack in our particular narrow domain, going as high as we go, and as low as we go".
      - dkarapetyan 12y ago
        I agree and that's exactly what job adverts should say. Spell out the stack and the amount of experience required. None of the nonsense with vague phrases like "full-stack developer".
  - pjmlp 12y ago
    I agree. Almost 30 years into this and I still don't see the point. It is almost as when cleaning became health assistance.
  - SeanDav 12y ago
    DevOps is an integral part of Continuous Deployment. I am not sure why methods used to make deployment of software more frequent and less error prone should raise anyone's hackles. I guess it is not understanding what DevOps is and what it is trying to achieve.
    - TeMPOraL 12y ago
      You pretty much answered yourself right there in your comment. See how you capitalize "Continous Deployment" and "DevOps"? That's because they're recently invented feel-good buzzwords.
- hackuser 12y ago
  Perhaps ship-it-now is the right answer for the times. With so many rapid changes in technology there should be 1) a lot of low-hanging fruit (i.e., quick, high-value solutions), making short-term project more valuable and 2) a shorter shelf-life for any solution (i.e., a new tech will make it obsolete), making long-term projects less valuable.
  - mattlutze 12y ago
    I wonder if ship-it-now isn't more a reflection of the times, rather than the right answer. "Pick off the low-hanging fruit" works for a shop looking to turn some mad profit without having to do a lot of deep thinking. And that's certainly fine. But if that's the culture of the industry, we'd be sacrificing progress and innovation for a quick and ephemeral dollar. There's a quiet theme that runs through the community here, and tech in general, that suggests everything that's new is often just old-again. A lot of these "rapid changes" really do feel like reinvention and change for its own sake, and seems plagued with the same issue as above -- building new iterations on existing ideas, picking off low-hanging fruit but not really going anywhere. edit: The problem is that these technologies, being so beginner-friendly and aggressively marketed, rapidly pick up steam and become the “cool” things to use, regardless of actual merit or lack thereof. This line hit it on the head for me. I've been in the business for a while but have only been programming directly for a fraction of that -- I can readily admit, a lot of the newer JS libraries and frameworks made me feel like a superhero with almost no proper training or understanding of computer science.
    - chii 12y ago
      > we'd be sacrificing progress and innovation for a quick and ephemeral dollar. until the low hanging fruit all got picked.
      - rprospero 12y ago
        The problem with that proposal is that we're currently waiting until all of the low hanging fruit got picked. I'm no masochist - if there are nice fruit on the bottom branches, I'm going to pick those. The problem is that the low hanging branches have been picked of all their nice fruit, just leaving the sour, the rotten, and the immature. We could start putting in the effort and climbing the tree for the nice, ripe fruits at the top, but we're being lazy and waiting until we've picked every last worm-filled mush at the bottom.
- fijal 12y ago
  The problem runs deeper than that even. Even if you like doing stuff that requires more effort, it's shockingly difficult to find places/people who want to invest/hire you to work on such technology. You have essentially a choice between academia (which is, well, sometimes very academic) and large corpos which have their own share of problems and not everyone fits.
  - deleted 12y ago
    [deleted]
  - hugs 12y ago
    There is another option: work for a salary, live frugally, and stockpile savings. Then later (maybe 5-10 years later), work on the tech you really want to work on that has no obvious & immediate business need. The upside is that because no one invested or hired you to work on it, you own 100% of that work.
    - shiven 12y ago
      Also, make sure you are (a). young (< 30yrs) (b). have little to no responsibilities (family, kids) (c). have great healthcare or health insurance and (d). lucky as a little green leprechaun! Yea, if you have met all those conditions, then that approach may work for you.
  - romaniv 12y ago
    And even in big corps, 95% of all IT is usually plumbing and hectically applying band-aids for past issues that should not have been there in the first place. To me, the fact that IT is currently seen as rapidly progressing is laughable. It is rapidly changing, true, but for the most part we're solving old problems with new tools that work only marginally better than the old tools (because, like the article says, the underlying mentality is the same). Very often they change fast enough to keep everyone always "learning" at the expense of the users, so the marginal benefits are cancelled out. (Seriously, I know people who made the same excuse for bad quality for the last decade. "Oh, I'm just learning [over-hyped tool]. Everyone makes mistakes at first." Learning tools is a fake kind of learning. Real advances happen when your conceptual basis is improved, so you get better at doing something with whatever tool. That's real learning. ) --- Also, sometimes we're using new tools that work significantly worse than some old tools.... because at some point conceptual development branched and "our" branch is at the same level of development as another branch was in, say, 60s or 70s. Sometimes I read about old tech and it just blows my mind. "What? They've been doing this three decades ago? How come this is marketed as awesome new thing right now?"
- hiou 12y ago
  I think many people confuse "ship it" culture with just doing crap work. I've seen too many ship it projects die because the biggest feedback from the customers was "This thing doesn't actually seem to work" or "This is useless". Ship it can apply to hard problems as much as easy ones, it's more about not doing extra work before you know what your customers want. But if you MVP it to the point where it barely works and has no real functionality then customers will often view it as trivial and useless and you'll likely confuse missing product market fit with under delivering.
mpweiher 12y ago
Yes. If your problems are essentially trivial and you are just trying to gauge customer moods, shipping and shipping again quickly is the way to go...and thinking about the problem will probably not help. However, while quick iterations converge rapidly on a local maximum, they really, really suck at getting you out of that local maximum. I notice this with trying to create a new and different programming language (http://objective.st http://objective.st): for almost all the problems I am tackling, there are quick and obvious answers...that get me stuck in the same mess we are already in. So I've found it necessary to deliberately delay implementing stuff, going slower than I can and make sure I leave the time for my not-quite-conscious thought processes to work out the problem and present the results during a relaxing shower.
danschuller 12y ago
An interesting read but poor tools can't only be attributed to shipping culture. A more important reason is the tools are good enough (only just, but that's enough) and at that point priorities change. And once momentum becomes big it's hard to change direction i.e. Javascript, so hard to revisit the fundamentals. Better tools are coming, such as Lighttable / Bret Victor's talk: https://vimeo.com/71278954 https://vimeo.com/71278954 . But it's not clear when they'll arrive! Will we still be developing web-apps in Javascript after another decade? It feels like we can do better.
ChuckMcM 12y ago
The problem that I have with this thesis (that shipping culture is hurting us) is the results people have. You can certainly argue that a better result could be achieved by taking more care with your design, but it is unclear that in doing so you would have achieved something more "valuable" than you did by shipping and iterating. I do agree with Gary Bernhardt that infrastructure is not getting the attention it deserves, but as we saw with GPG it isn't something that is easily funded. Sun paid an engineer who did mostly nothing but maintain xterm (and the Sun tools equivalent) for several years. Where are you going to find a sponsor for a new terminal? Current terminal code could be improved of course, but in so doing would you get better code? Better systems?
- spitfire 12y ago
  The thing is the "Think carefully and create deliberately" approach has been tried so very few times. But when we have tried it we've gotten Lisp machines, ACID RDBMs, strong typing, and many other important and very useful tools. I'd say it's worth a shot more often. We know we're in a world of hurt now, but the argument against it is "oww. Devil we don't know!". Math is hard, lets go shopping.
  - nostrademons 12y ago
    The "think carefully and create deliberately" approach has given us a lot more than that - there's also Smalltalk, Xanadu, Eros/E, NextStep, BeOS, microkernels, Plan9, Dylan, and General Magic. A look at that list is pretty instructive for why more people don't take the "think carefully and create deliberately" approach: by and large, the creators of those projects failed to profit from their inventions. In many cases, they wasted years of their life slaving away in pursuit of perfection, and the market didn't care. If you study any of the systems I mentioned, you'll find some incredibly elegant and beautiful CS concepts, ones I wish I could use for every-day programming all the time. But the problem is that none of these innovations exist in a vacuum, and in the time it took to perfect the product, the market passed them by and the world changed in a way that made them no longer relevant.
  - ChuckMcM 12y ago
wodenokoto 12y ago
While it is great using hyperlink to point readers to sources, it shouldn't become a substitution for actual words.
DiThi 12y ago
> Instead we get some bizarro-world where where the type of NaN (“Not a Number”) is number, where NaN !== NaN*, and a chart like this exists for something as simple as comparing two values. That's the definition of NaN in virtually any programming language with floating point numbers. And the comparison table makes sense with the rule "when types are incompatible, both are casted to strings". Just use === instead of ==, which is only really useful for comparing against null/undefined.
- andrewstuart2 12y ago
  Also in logic. Not something is never equal to not the same thing. A bird is not a rock. A computer is also not a rock. Clearly not equal to each other.
  - mxfh 12y ago
    I think people confuse the nature of NaN with the result of isNaN() a lot, this being the source of this confusion.
    - mjevans 12y ago
      It's easier if you think of it like a database NULL.
- kazinator 12y ago
  The stupid thing about IEEE NaN is that it's not equal to itself! If variable x holds a NaN, then (x == x) is false. This violates: http://en.wikipedia.org/wiki/Law_of_identity http://en.wikipedia.org/wiki/Law_of_identity If (x == x) tests false, then it asserts that x is not itself, which is logically preposterous. ANSI Common Lisp has a bit of this problem in it too, but it's not required; it is there for some weird historic implementations. That is to say, if x holds a number like 1, then (eq x x) is not required. (But in sane implementations it does yield t; and it yields t even if x is a bignum, because (eq x x) is given the same object as two arguments. Two separately computed bignums of equal value will likely, of course, not be eq. How this can be explained is that eq tests "implementation identity", and somehow different instances of a number are treated as different implementations. Argument passing is by value, and the two reductions of the expression x in (eq x x) to a value somehow produce a different implementation of the value. This rationale is unrelated to IEEE NaN-s, though.
deleted 12y ago
[deleted]
- angersock 12y ago
  It's not even a good rant. Author is fundamentally wrong in their choice of examples and targets.
angersock 12y ago
So, there's a great argument to be made about the negative impacts of "Shipping Culture". One could argue that it encourages underdesigning of ultimately complex systems. One could argue that it encourages excessive code and infratstructure reuse, to the point that even trivial projects pull in more than is needed and consume more resources than even remotely necessary. One could even argue that it creates in customers an unreasonable expectation about ongoing fixes to a project, about ongoing support contracts and culture, and generally discourages creating artifacts that later generations can use in favor of ongoing maintenance performed by morlocks. Sadly, the author makes none of those arguments, and instead gripes about hackathons, about Javascript (badly), and about MongoDB (which is fun, but doesn't go anywhere). Author bemoans "ship it now" culture, bemoans shipping things before they're technically good--and then has the gal to use a Netscape Navigator screenshot! Does anyone else find irony in that? Netscape was never known for good quality code or sane implementations--go read old kvetching by Brendan Eich or Jamie Zawinski. You know what they did do, though? Fucking shipped. Author complains about NaN--which is a goddamn standard in IEEE 754, which is exactly how C++ (their pet language) handles things, and which is completely reasonable behavior for any JS implementation. Not having an integer type? Newsflash kid: JS supports bit-accurate integers up to Int32s. Author claims systems stopped using coopterative multitasking two decades ago. Author has presumably never written code for hard-real-time embedded systems. Author goes on to complain about ancient standards. I have an ancient 120v 60-hertz AC circuit running my house. I have an ancient system of measurement for the beer on my desk. Funny thing about ancient systems: if they're still around, it's because they've perhaps solved the problem well enough to stay around. "Shipping Culture", as defined by the author, isn't what's hurting us: it's the influx of jackasses with loud mouths and no appreciation for history, business, or engineering loudly proclaiming that perhaps the most productive decade in software engineering is somehow wrong.
- 91bananas 12y ago
  All I can say is, thank you.
- username223 12y ago
  Yeah, the title and the article have very little to do with each other. Complaining about NaN semantics is especially irrelevant. OTOH, it's funny you bring up Netscape. Yes, they shipped. Back in the Netscape 3-4 days of the Browser Wars, every new version was a crap shoot. It might un-break some page you wanted to use, but it might also be drastically slower, crash a page that you needed, lose your preferences, or whatever. But the cool thing is that you could choose when or if to update! You could install the new version alongside the old one, try it out for awhile, and junk it if it was worse overall. If most people thought Netscape was getting worse, then most people would stick to the old, working version. Nowadays browsers follow the same "random walk" development model, but shove the latest version down most users' throats whenever they feel like it, and make it hard or impossible to revert the latest breakage. "Ship crap" combined with "software force-feeding" is good for no one but lazy coders.
andrewstuart2 12y ago
Every time I see someone quote that JavaScript was designed in ten days I cringe. JavaScript was designed in 1995. It was standardized as ECMAScript in 1997. Ever since then, it's been under active development by a thriving community of engineers pushing for better standards. It's been a bit longer than ten days.
- tedunangst 12y ago
  How many of the first ten days design decisions have been reversed by subsequent standards?
- austinz 12y ago
  Given that the ECMAScript community has (for good reason; "don't break the web") decided to avoid backwards-incompatible changes, that necessarily places a limit on the amount of "fixing" they can do to the language. New or enhanced features are okay, rectifying mistakes is harder. (This isn't just a JS thing; go talk to any random Python developer and ask them what they think of Python 2 vs 3. There are tradeoffs to both approaches.) http://www.2ality.com/2014/12/one-javascript.html http://www.2ality.com/2014/12/one-javascript.html
  - CmonDev 12y ago
    "don't break the web" I know it's not your fault but this statement doesn't make any sense. Web is made of hyper-linked content not jQuery animations and AJAX.
    - emodendroket 12y ago
      No one cares what the Web was originally intended to be, frankly.
      - CmonDev 12y ago
        Then why care about language designed for animating monkeys?
kazinator 12y ago
This is not just the last several years. It comes from a slogan that was popularized by Eric S. Raymond some 18 years ago: http://en.wikipedia.org/wiki/Release_early,_release_often http://en.wikipedia.org/wiki/Release_early,_release_often
- irickt 12y ago
  Or Guy Kawasaki, circa 2000 >>> Don't worry, be crappy. Revolutionary means you ship and then test... Lots of things made the first Mac in 1984 a piece of crap - but it was a revolutionary piece of crap.
d_b42 12y ago
All things in moderation.. To me, "ship it" as a philosophy means the most important thing we do as developers is deliver working code to customers. On my team, when we encounter a concept that is just too complicated to ship right away, we try to branch-by-abstraction and keep shipping changes, even if the feature isn't "ready" yet. To me, the marginal returns on trying to be right diminish more rapidly than the returns on making it easy to fix to stuff when I'm wrong. Maybe I'm just not as smart as everyone else here, but it seems to work.
- Sir_Substance 12y ago
  It's more of a business necessity then a philosophical point of view. The history of software development is littered with companies that failed because they spent so long polishing the beautiful crystal tower they were developing that someone released a concrete one instead and everyone bought that, and then no one needed a crystal one any more. Unfortunately, it can be really hard to find out about these companies because of how hard they've been trodden into the ground by their successors, but Xerox and Netscape would be two high profile examples. Shipping constantly may not be the best thing for technology, it may not be the best thing for quality and it may not, at times, even be the best thing for your users. But if you don't, someone else will.
saidajigumi 12y ago
This whole article makes me want to scream, if only because the author seems to have never heard of the concept of Path Dependence[1]. I could utter a similar rant, on how terrible it is that we're stuck with awful legacy dumb AC lightbulb sockets everywhere, and wouldn't it be nice if the entropy fairy just waved a magic wand and we all had 'net-connected DC smart sockets for our wonderful Future Bulbs. But that kind of talk utterly dismisses the important reality that 1) we don't have a magic wand and 2) we have to deal with things like path dependence and network effects as phenomena. Example: if you chart out historical network bandwidth, you'll get a Moore's-law-esque curve, but with a significant step function depending on which network aspect you study. Why? Path dependence and (literal!) network effects: we don't see the benefits of network bandwidth improvements until enough hardware has been upgraded to see an end-to-end improvement. [1] https://en.wikipedia.org/wiki/Path_dependence https://en.wikipedia.org/wiki/Path_dependence
- soup10 12y ago
  Javascript has become the defacto browser programming language, even though it's objectively awful for complex software. The only reason it's achieved it's high status is because browser developers refused to cooperate and develop something better. Microsoft and Apple view software lockin as a competitive advantage and have actively undermined technologies they thought were threatening(java and flash amongst others). The explosion of Html5 and javascript was more of a 'nature will find a way' type development and can almost entirely be credited to Google and various web companies pushing it and making it better. It's still a very flawed technology stack for complex web-apps though and it's very reasonable to suggest that we could do a lot better.
  - nulltype 12y ago
    If you think Javascript is bad for complex software, you should try C++.
    - angersock 12y ago
      Hey, they're trying with ES6!
cageface 12y ago
You see the same thing in natural organisms. Vestigial adaptations and odd or even awkward designs abound, yet they are functional. Some people take "Worse is Better" to the extreme of "Worst is Best" but there is some wisdom in the idea that it's better to get an adequate solution into play early than to wait for for a perfect, clean-room design. The important thing is to setup a feedback loop that continually refines your solution. For an inspiring take on the power of chaos in evolution check out Errol' Morris' film "Fast, Cheap & Out of Control": http://en.wikipedia.org/wiki/Fast,_Cheap_%26_Out_of_Control http://en.wikipedia.org/wiki/Fast,_Cheap_%26_Out_of_Control
kazinator 12y ago
> Systems stopped using cooperative multitasking at least 20 years ago because it sucked compared to the alternative of automatic, preemptive multitasking. And yet Node.js harks back to those dark days with its callback-based concurrency, all running in a single thread. Uh, no. For instance, Unix kernels have been traditionally cooperative---at least when executing kernel code. That is to say, user space can be preempted but not the execution of kernel code. The introduction of SMP brings concurrency into the kernel, though, and with that, preemption can follow. Linux development followed this path. Still today, you don't have to turn on CONFIG_PREEMPT when building your kernel. If you don't have SMP either, then you have a cooperative kernel: one task is in there at a time, and it has the CPU until it voluntarily calls into the scheduler. Cooperative tasking has the enormous advantage that it makes a whackload of potential race conditions go away, and that could be a possible reason why Node.js is the way it is. Unix might not have been successful had Ken Thompson decided to make the kernel preemptive, and then spent 1973-1987 debugging it. :)
- pjmlp 12y ago
  >Unix might not have been successful had Ken Thompson decided to make the kernel preemptive, and then spent 1973-1987 debugging it. :) Sadly that didn't happen, UNIX was adopted by 80's hipsters into their startups, became adopted by the industry at large, thus spreading C into the industry. Now we have patch <choose day of week>.
  - rjblackman 12y ago
    people working on computers in the 80s were not hipsters.
    - pjmlp 12y ago
      The persons called hipsters in computer culture already exited back then, we just didn't called ourselves hipsters. The remark was for the younger readers. Me, I was into the demoscene and couldn't care less about UNIX until around 1993.
  - cben 12y ago
deleted 12y ago
[deleted]
McUsr 12y ago
I haven't tried Mongo.db, but Node.js takes up a lot of resources in a browser, Node.js apps feels a bit like the widest book strategy in the bookstore, you have to shove other stuff out of your browser, in order to use stuff that uses Node.js, and I feel that as a rather arrogant approach to deliver software, especially, when the functionality of Node.js apps doesn't really dictate the necessity. AS for Javscript, there are worser languages out there, and the debuggers are good enough now, so it can be perceived as a "normal" language.
- computmaxer 12y ago
  > but Node.js takes up a lot of resources in a browser You must be confused. Node.js is used to run JavaScript on the server, not in a browser (the client).
  - McUsr 12y ago
    That may be so, but when I run something with Node.js in my browser, then I may have to close other things. So, wherever it runs, it really uses too much resources, and therefore I find it as a bad idea from the consumer perspective. It shouldn't be so, that somebody else, should dictate the content of your browser.
    - BSousa 12y ago
      Are you sure you know what node.js is?
      - McUsr 12y ago
        The short definition would be: "node.js is something that eats up my browsers latency", something along those lines, and as far as I am concerned, that is everything I have to know about it. Node.js is a no stop for me.
        pavlov 12y ago
        Can you name some of those Node.js apps that have been causing problems for you?
narrator 12y ago
People use mongo and node because they want to get a site up really really fast and see if it gets traction. When they actually get somewhere they'll rewrite it in a better language. If you want to set yourself up with really slick tooling and a great language you can code in Scala with Intellij. You can even avoid touching any ugly dynamically typed stuff by coding your JS in scala.js. If you're doing it better than the other guys then great, you can code rings around them. Maybe it's not worth all the extra complexity when just starting out though. When you get to big corp size code bases static languages are more common. That's because to be able to navigate and maintain that big of a code base, a good IDE, a static typing compiler and refactoring tools are a huge help.
- edejong 12y ago
  The interesting thing is that all these big-corp code-bases started out relatively small. The origins were actually able to overcome the complexity-wall that arises when a product is successful.
- falcolas 12y ago
  > When they actually get somewhere they'll rewrite it in a better language. Anecdata for you: Not necessairly. I'm working for a company which has "actually gotten somewhere", and our development team is still writing in Node with Mongo. Of course, there is a reason for it, the front end development team has spare cycles, and the backend team does not. Ergo, Node!
  - alxndr 12y ago
    I'm inclined to repurpose a cliche, and say that now your backend team has two problems!
chvid 12y ago
I wonder if "hurtful shipping culture" has a parallel in the blogging world?
mrgriscom 12y ago
Reminded me of this essay: http://www.jwz.org/blog/2012/08/a-generation-lost-in-the-bazaar/ http://www.jwz.org/blog/2012/08/a-generation-lost-in-the-baz... I don't think it's fair to attribute the issues he brings up to "shipping culture". Rather, the causes are two-fold: 1) Lack of appreciation for history, being doomed to repeat it, all that 2) Making anything above the level of 'just not-terrible enough' without a benevolent dictator is hard.
igl 12y ago
The problem is that the Author is assuming that 90% of software we write to make a living is set into stone and suppose to run forever. Almost everything we do is disposable and replaced within the same decade. So he does not like Javascript and Nosql. Is it hard to find a JavaEE job? I think not.
- hyc_symas 12y ago
  I think the real problem is the disposability attitude you just described. It's prevalent in our real world consumerist economy and it's killing us there too. Building software that's to be thrown away is a waste of mental resources and physical resources. Society and civilization advances on top of our lasting creations, not the ephemeral ones. Reinventing the wheel doesn't advance the state of the art. You want to build one good set of tools that will last a long time, so you can stop thinking about them and be free to tackle the next truly new challenge. Doing anything else is just a waste of life.
  - igl 12y ago
    wat? How can you even compare the "problems" of building commercial software to the problems of consumerism in capitalism? The standards applied here are whack in the scope of what js and mongo are used for. Also: You only get better by reiterating.
yason 12y ago
Shipping doesn't always need to mean shipping to the public. I write complex software too but I "ship" to myself early and often. I start by trying to solve a hard problem as fast and as quickly as possible in a naive way so that I can experiment more freely. This gives me more insight into the problem itself and into the solution space. The solution often changes -- sometimes it's the problem that changes. If I were working with a customer or a startup I would definitely "ship" early and often, too, but I wouldn't give much weight to these "releases". They're just something to play with and to cut the shape for the problem.
halayli 12y ago
It's a spectrum. Trying to ship a perfect software from the start will probably end up like OS/360 project. Then K&R came along and designed what we know now as unix. An OS that wasn't complete and fully featured like OS/360 was intended to be, but it worked! Making the wrong choices is inevitable, but correcting them is part of the software life cycle. We aren't working with concrete and building bridges here. If we built Pisa tower like software, we can still fix it. So yes, ship when you can as long as it works and delivers what it promises. It doesn't have to be perfect.
- hyc_symas 12y ago
  Delays getting OS/360 were a blessing, really - it prompted many universities to develop their own mainframe OSs, thus helping OS research flourish around the world.
erikb 12y ago
I actually watched the screen cast this blog post is about. [1] And I would like to say something about that here, because the questions from the screen cast were also coined in the blog post. The Question is this: "Why do people not replace VT100 style terminals?" There are two reasons. tl;dr Terminals have other reasons than programming in them and people actually reinvent how you can program on a daily basis. See more in depth arguments below. The first thing is that people actually still need the old terminal stuff. There are loads of old computers you want to communicate with (just think of your pa trying to relive old times be trying to get the 80's game console to work). And there are also a lot of technologies that really need something that stupid, e.g., if you develop your own embedded system you might actually communicate with it using these VT100 commands. So yeah. Wow. A Terminal (emulator) doesn't have the task to show your text editor. You can start GVim if you just want to show your editor. They have the task to communicate. They can communicate with the system you are running them on or you can use them to communicate with another terminal. If you want to replace them, you have to replace the software in your pa's console (and probably some hardware), you have to find a new way to develop fresh, small computers, you have to find a new way SSH works, you have to find a new way to show your text editor. It's not impossible, but it's probably so hard that nobody would like to spend their whole life (work time, spare time, youth to death) doing it. It's not worth that much. Summary: It's not worth it, if you consider the whole picture. And second argument: People actually do, if you just think about use cases like coding, gaming, etc. A modern game doesn't run in a Text shell as e.g. Nethack could. It runs in a graphical shell and is represented to you in 3D, e.g., GTA 5. Also there are many people who use IDEs. Unix+Bash+Texteditor was actually an IDE. Eclipse etc are a new way of thinking about the editing task with helpers like compilers, static analysers, debuggers, performance analysers, unit test runners, etc. There are even people who reinvent the programming wheel from another point of view, e.g., have a look at NoFlow. The reason the other stuff is not dying is because it's useful for other reasons. That doesn't mean you have to still use it for programming (also some people, like me, choose to). Summary: People do work on finding modern ways to program. [1] https://www.destroyallsoftware.com/talks/a-whole-new-world https://www.destroyallsoftware.com/talks/a-whole-new-world
annnnd 12y ago
While I agree with the facts in the article, my own conclusions are quite the opposite (feel free to downvote / flame, but please read the whole response first). I guess it depends on values - for me, what matters is the value added to customer. Iterating quickly (often) yields better results in this area because it allows you to guess customer expectations early in development process. I have often encountered die-hard engineers who want 100% specification upfront... In my experience, world doesn't work this way. It would be nice if it did, but it doesn't. And yes, I am guilty. I am using MongoDB AND JavaScript (but not Node.js - not that I have anything against it, just never had the need for it). I don't use these technologies because they are "cool", but because they solve specific problems in an efficient way. Which is probably why hackathon devs used them too. And yes, I would appreciate schema in MongoDB and types in JS, but I can live without it. Life is made of tradeoffs. Does it really matter if latest Fart App (tm) builds on transaction-safe DB and uses strong type language? So, are we seeing a rise of "shipping culture"? Yes. Does it change how we work? Yes. Is it in some ways worse? Yes. Is it hurting us? No.
foombarder 12y ago
Oh yeah, right - I forgot that we write code for the sake of engineering - why would you wanna get stuck in the shipping loop? ...
logicallee 12y ago
honest question. do you guys want a piece of crap from me that illustrates a new application type? (the way bittorrent or bitcoin or napster or wikipedia was new?) or should I wait. I don't have any resources to put into this but can release a piece of crap myself. (I don't personally program professionally.) honest question - discuss. would you like a piece of crap - or for me to wait. (Nobody more competent is going to just code this for me, at least not until the piece of crap exists and has traction.) I don't really envision other options but am open to them. What should I do? Get it right (not happening) or get it out?
jtth 12y ago
im from tumblr and what is this
whiskeySix 12y ago
The first two comments in the linked article are gold.
EGreg 12y ago
I would say Ship Often and A/B test. And before that, get really big test pool! The first part to success is making it safe to fail
dustingetz 12y ago
Seth Godin wrote that 5 years ago, i think (hope) the economics are shifting, in the last 5 years a lot of the omgcats apps (market opportunities that can be captured with lousy software) have already been written, i think it may not be so easy for companies started today. However with the pace of innovation in the last 5 years (basically the coming of age of functional programming) it's a lot easier for a single person to write high quality software. Anyway common wisdom is always going to lag behind today's actual best practices
RangerScience 12y ago
The author's bit about how we forget about the problems and solutions of our forefathers - that resonates with me. We do seem to keep re-inventing the wheel, and while part of that is out of joy of creation, I think a lot of that is that we're not writing down the problems, and we're not teaching the problems. We're only paying attention to solutions, and that's limiting. Code is a solution to a problem, but it's not always apparent what that problem /was/ when you just look at it. So NodeJS (according to the authoer) is doing something that was thought of as a good idea at first, and then people learned why it wasn't, and /nobody wrote that down/. Or, at least, when they wrote it down, nobody taught it. Solutions are /answers/, problems are /questions/. Here's a beautiful illustration of this dichotomy: http://dead-logic.blogspot.com/2012/09/a-collection-of-questions.html http://dead-logic.blogspot.com/2012/09/a-collection-of-quest... This is then part of why the TDD movement is in the right direction - you write down the problem you're going to solve, and later, someone can come read it. And maybe teach it. (Not saying TDD has gotten "there", but it's in the right direction)

231 points by uam 12y ago

The author talks about languages and technologies (JS, Mongo), but he's really getting at something deeper. The real danger of the "ship it" culture is that things that can't be "shipped" right away — things that require solving really hard problems — tend to fall off our collective radar because there is just SO MUCH cool and (relatively) easy stuff to do right now. PG has a great term for this: "schlep blindness": http://paulgraham.com/schlep.html http://paulgraham.com/schlep.html

digi_owl 12y ago
Makes me wonder if this is why i find the whole "devops" concept to be raising my hackles.
- saidajigumi 12y ago
  Maybe that depends on who's uttering the phrase and what it means to them. Some points in the space: - "Devops" as a movement encompassing the ideas that developers should not be walled off from operational realities, and that software operations tasks should be encoded as repeatable, testable software (vs ad-hoc stuff a sysadmin does on a box somewhere). - "Devops" as "oh look, we can hire less people and just get some 'devops' to do it all."
  - digi_owl 12y ago
    The way i have seen it used was more like the inverse of your first example, where one go from encoded and tested sysadmin tasks to "lets throw into production any newfangled thing the devs (monkeys hammering keyboards, more like it) wants to use".
    - 23david 12y ago
      Devops can definitely be used as a very expensive bandaid around poor engineering practices. But there's more to it... sometimes the engineering work it takes to prevent something from crashing is much less than just monitoring and restarting when failures are detected. Maybe "failure engineering" is a good term for a lot of the value Devops techniques can bring to a team?
      - dkarapetyan 12y ago
        But isn't that what all systems engineering is all about? Feedback loops with resiliency. Why is it that the software folks think they have discovered something new?
      - nitrogen 12y ago
        When implementing a failure-tolerant system, one has to remember that "crash" can often be parlayed into "exploit" or at least "denial of service", and thus not become too tolerant of failure.
- dkarapetyan 12y ago
  How about "full-stack developer"?
  - makeitsuckless 12y ago
    That's the one. That's basically short hand for "you don't need to do anything really well, you just need to do everything barely good enough to ship it now".
    - CmonDev 12y ago
      The sad bit is that many full-stack developers are actually better that specialized developers in respective skills. (unless of course they are JS/Node.js types)
      - _pmf_ 12y ago
        > The sad bit is that many full-stack developers are actually better that specialized developers in respective skills. But those do not call themselves full-stack-developers.
  - _pmf_ 12y ago
    > How about "full-stack developer"? It means you can play both kinds of music: country and western
  - EliRivers 12y ago
    Which really means "OUR stack developer, being a subset of the full-stack in our particular narrow domain, going as high as we go, and as low as we go".
    - dkarapetyan 12y ago
      I agree and that's exactly what job adverts should say. Spell out the stack and the amount of experience required. None of the nonsense with vague phrases like "full-stack developer".
- pjmlp 12y ago
  I agree. Almost 30 years into this and I still don't see the point. It is almost as when cleaning became health assistance.
- SeanDav 12y ago
  DevOps is an integral part of Continuous Deployment. I am not sure why methods used to make deployment of software more frequent and less error prone should raise anyone's hackles. I guess it is not understanding what DevOps is and what it is trying to achieve.
  - TeMPOraL 12y ago
    You pretty much answered yourself right there in your comment. See how you capitalize "Continous Deployment" and "DevOps"? That's because they're recently invented feel-good buzzwords.
hackuser 12y ago
Perhaps ship-it-now is the right answer for the times. With so many rapid changes in technology there should be 1) a lot of low-hanging fruit (i.e., quick, high-value solutions), making short-term project more valuable and 2) a shorter shelf-life for any solution (i.e., a new tech will make it obsolete), making long-term projects less valuable.
- mattlutze 12y ago
  I wonder if ship-it-now isn't more a reflection of the times, rather than the right answer. "Pick off the low-hanging fruit" works for a shop looking to turn some mad profit without having to do a lot of deep thinking. And that's certainly fine. But if that's the culture of the industry, we'd be sacrificing progress and innovation for a quick and ephemeral dollar. There's a quiet theme that runs through the community here, and tech in general, that suggests everything that's new is often just old-again. A lot of these "rapid changes" really do feel like reinvention and change for its own sake, and seems plagued with the same issue as above -- building new iterations on existing ideas, picking off low-hanging fruit but not really going anywhere. edit: The problem is that these technologies, being so beginner-friendly and aggressively marketed, rapidly pick up steam and become the “cool” things to use, regardless of actual merit or lack thereof. This line hit it on the head for me. I've been in the business for a while but have only been programming directly for a fraction of that -- I can readily admit, a lot of the newer JS libraries and frameworks made me feel like a superhero with almost no proper training or understanding of computer science.
  - chii 12y ago
    > we'd be sacrificing progress and innovation for a quick and ephemeral dollar. until the low hanging fruit all got picked.
    - rprospero 12y ago
      The problem with that proposal is that we're currently waiting until all of the low hanging fruit got picked. I'm no masochist - if there are nice fruit on the bottom branches, I'm going to pick those. The problem is that the low hanging branches have been picked of all their nice fruit, just leaving the sour, the rotten, and the immature. We could start putting in the effort and climbing the tree for the nice, ripe fruits at the top, but we're being lazy and waiting until we've picked every last worm-filled mush at the bottom.
fijal 12y ago
The problem runs deeper than that even. Even if you like doing stuff that requires more effort, it's shockingly difficult to find places/people who want to invest/hire you to work on such technology. You have essentially a choice between academia (which is, well, sometimes very academic) and large corpos which have their own share of problems and not everyone fits.
- deleted 12y ago
  [deleted]
- hugs 12y ago
  There is another option: work for a salary, live frugally, and stockpile savings. Then later (maybe 5-10 years later), work on the tech you really want to work on that has no obvious & immediate business need. The upside is that because no one invested or hired you to work on it, you own 100% of that work.
  - shiven 12y ago
    Also, make sure you are (a). young (< 30yrs) (b). have little to no responsibilities (family, kids) (c). have great healthcare or health insurance and (d). lucky as a little green leprechaun! Yea, if you have met all those conditions, then that approach may work for you.
- romaniv 12y ago
  And even in big corps, 95% of all IT is usually plumbing and hectically applying band-aids for past issues that should not have been there in the first place. To me, the fact that IT is currently seen as rapidly progressing is laughable. It is rapidly changing, true, but for the most part we're solving old problems with new tools that work only marginally better than the old tools (because, like the article says, the underlying mentality is the same). Very often they change fast enough to keep everyone always "learning" at the expense of the users, so the marginal benefits are cancelled out. (Seriously, I know people who made the same excuse for bad quality for the last decade. "Oh, I'm just learning [over-hyped tool]. Everyone makes mistakes at first." Learning tools is a fake kind of learning. Real advances happen when your conceptual basis is improved, so you get better at doing something with whatever tool. That's real learning. ) --- Also, sometimes we're using new tools that work significantly worse than some old tools.... because at some point conceptual development branched and "our" branch is at the same level of development as another branch was in, say, 60s or 70s. Sometimes I read about old tech and it just blows my mind. "What? They've been doing this three decades ago? How come this is marketed as awesome new thing right now?"
hiou 12y ago
I think many people confuse "ship it" culture with just doing crap work. I've seen too many ship it projects die because the biggest feedback from the customers was "This thing doesn't actually seem to work" or "This is useless". Ship it can apply to hard problems as much as easy ones, it's more about not doing extra work before you know what your customers want. But if you MVP it to the point where it barely works and has no real functionality then customers will often view it as trivial and useless and you'll likely confuse missing product market fit with under delivering.

mpweiher 12y ago

Yes. If your problems are essentially trivial and you are just trying to gauge customer moods, shipping and shipping again quickly is the way to go...and thinking about the problem will probably not help. However, while quick iterations converge rapidly on a local maximum, they really, really suck at getting you out of that local maximum. I notice this with trying to create a new and different programming language (http://objective.st http://objective.st): for almost all the problems I am tackling, there are quick and obvious answers...that get me stuck in the same mess we are already in. So I've found it necessary to deliberately delay implementing stuff, going slower than I can and make sure I leave the time for my not-quite-conscious thought processes to work out the problem and present the results during a relaxing shower.

danschuller 12y ago

An interesting read but poor tools can't only be attributed to shipping culture. A more important reason is the tools are good enough (only just, but that's enough) and at that point priorities change. And once momentum becomes big it's hard to change direction i.e. Javascript, so hard to revisit the fundamentals. Better tools are coming, such as Lighttable / Bret Victor's talk: https://vimeo.com/71278954 https://vimeo.com/71278954 . But it's not clear when they'll arrive! Will we still be developing web-apps in Javascript after another decade? It feels like we can do better.

ChuckMcM 12y ago

The problem that I have with this thesis (that shipping culture is hurting us) is the results people have. You can certainly argue that a better result could be achieved by taking more care with your design, but it is unclear that in doing so you would have achieved something more "valuable" than you did by shipping and iterating. I do agree with Gary Bernhardt that infrastructure is not getting the attention it deserves, but as we saw with GPG it isn't something that is easily funded. Sun paid an engineer who did mostly nothing but maintain xterm (and the Sun tools equivalent) for several years. Where are you going to find a sponsor for a new terminal? Current terminal code could be improved of course, but in so doing would you get better code? Better systems?

spitfire 12y ago
The thing is the "Think carefully and create deliberately" approach has been tried so very few times. But when we have tried it we've gotten Lisp machines, ACID RDBMs, strong typing, and many other important and very useful tools. I'd say it's worth a shot more often. We know we're in a world of hurt now, but the argument against it is "oww. Devil we don't know!". Math is hard, lets go shopping.
- nostrademons 12y ago
  The "think carefully and create deliberately" approach has given us a lot more than that - there's also Smalltalk, Xanadu, Eros/E, NextStep, BeOS, microkernels, Plan9, Dylan, and General Magic. A look at that list is pretty instructive for why more people don't take the "think carefully and create deliberately" approach: by and large, the creators of those projects failed to profit from their inventions. In many cases, they wasted years of their life slaving away in pursuit of perfection, and the market didn't care. If you study any of the systems I mentioned, you'll find some incredibly elegant and beautiful CS concepts, ones I wish I could use for every-day programming all the time. But the problem is that none of these innovations exist in a vacuum, and in the time it took to perfect the product, the market passed them by and the world changed in a way that made them no longer relevant.
- ChuckMcM 12y ago

wodenokoto 12y ago

While it is great using hyperlink to point readers to sources, it shouldn't become a substitution for actual words.

DiThi 12y ago

> Instead we get some bizarro-world where where the type of NaN (“Not a Number”) is number, where NaN !== NaN*, and a chart like this exists for something as simple as comparing two values. That's the definition of NaN in virtually any programming language with floating point numbers. And the comparison table makes sense with the rule "when types are incompatible, both are casted to strings". Just use === instead of ==, which is only really useful for comparing against null/undefined.

andrewstuart2 12y ago
Also in logic. Not something is never equal to not the same thing. A bird is not a rock. A computer is also not a rock. Clearly not equal to each other.
- mxfh 12y ago
  I think people confuse the nature of NaN with the result of isNaN() a lot, this being the source of this confusion.
  - mjevans 12y ago
    It's easier if you think of it like a database NULL.
kazinator 12y ago
The stupid thing about IEEE NaN is that it's not equal to itself! If variable x holds a NaN, then (x == x) is false. This violates: http://en.wikipedia.org/wiki/Law_of_identity http://en.wikipedia.org/wiki/Law_of_identity If (x == x) tests false, then it asserts that x is not itself, which is logically preposterous. ANSI Common Lisp has a bit of this problem in it too, but it's not required; it is there for some weird historic implementations. That is to say, if x holds a number like 1, then (eq x x) is not required. (But in sane implementations it does yield t; and it yields t even if x is a bignum, because (eq x x) is given the same object as two arguments. Two separately computed bignums of equal value will likely, of course, not be eq. How this can be explained is that eq tests "implementation identity", and somehow different instances of a number are treated as different implementations. Argument passing is by value, and the two reductions of the expression x in (eq x x) to a value somehow produce a different implementation of the value. This rationale is unrelated to IEEE NaN-s, though.

deleted 12y ago

[deleted]

angersock 12y ago
It's not even a good rant. Author is fundamentally wrong in their choice of examples and targets.

angersock 12y ago

So, there's a great argument to be made about the negative impacts of "Shipping Culture". One could argue that it encourages underdesigning of ultimately complex systems. One could argue that it encourages excessive code and infratstructure reuse, to the point that even trivial projects pull in more than is needed and consume more resources than even remotely necessary. One could even argue that it creates in customers an unreasonable expectation about ongoing fixes to a project, about ongoing support contracts and culture, and generally discourages creating artifacts that later generations can use in favor of ongoing maintenance performed by morlocks. Sadly, the author makes none of those arguments, and instead gripes about hackathons, about Javascript (badly), and about MongoDB (which is fun, but doesn't go anywhere). Author bemoans "ship it now" culture, bemoans shipping things before they're technically good--and then has the gal to use a Netscape Navigator screenshot! Does anyone else find irony in that? Netscape was never known for good quality code or sane implementations--go read old kvetching by Brendan Eich or Jamie Zawinski. You know what they did do, though? Fucking shipped. Author complains about NaN--which is a goddamn standard in IEEE 754, which is exactly how C++ (their pet language) handles things, and which is completely reasonable behavior for any JS implementation. Not having an integer type? Newsflash kid: JS supports bit-accurate integers up to Int32s. Author claims systems stopped using coopterative multitasking two decades ago. Author has presumably never written code for hard-real-time embedded systems. Author goes on to complain about ancient standards. I have an ancient 120v 60-hertz AC circuit running my house. I have an ancient system of measurement for the beer on my desk. Funny thing about ancient systems: if they're still around, it's because they've perhaps solved the problem well enough to stay around. "Shipping Culture", as defined by the author, isn't what's hurting us: it's the influx of jackasses with loud mouths and no appreciation for history, business, or engineering loudly proclaiming that perhaps the most productive decade in software engineering is somehow wrong.

91bananas 12y ago
All I can say is, thank you.
username223 12y ago
Yeah, the title and the article have very little to do with each other. Complaining about NaN semantics is especially irrelevant. OTOH, it's funny you bring up Netscape. Yes, they shipped. Back in the Netscape 3-4 days of the Browser Wars, every new version was a crap shoot. It might un-break some page you wanted to use, but it might also be drastically slower, crash a page that you needed, lose your preferences, or whatever. But the cool thing is that you could choose when or if to update! You could install the new version alongside the old one, try it out for awhile, and junk it if it was worse overall. If most people thought Netscape was getting worse, then most people would stick to the old, working version. Nowadays browsers follow the same "random walk" development model, but shove the latest version down most users' throats whenever they feel like it, and make it hard or impossible to revert the latest breakage. "Ship crap" combined with "software force-feeding" is good for no one but lazy coders.

andrewstuart2 12y ago

Every time I see someone quote that JavaScript was designed in ten days I cringe. JavaScript was designed in 1995. It was standardized as ECMAScript in 1997. Ever since then, it's been under active development by a thriving community of engineers pushing for better standards. It's been a bit longer than ten days.

tedunangst 12y ago
How many of the first ten days design decisions have been reversed by subsequent standards?
austinz 12y ago
Given that the ECMAScript community has (for good reason; "don't break the web") decided to avoid backwards-incompatible changes, that necessarily places a limit on the amount of "fixing" they can do to the language. New or enhanced features are okay, rectifying mistakes is harder. (This isn't just a JS thing; go talk to any random Python developer and ask them what they think of Python 2 vs 3. There are tradeoffs to both approaches.) http://www.2ality.com/2014/12/one-javascript.html http://www.2ality.com/2014/12/one-javascript.html
- CmonDev 12y ago
  "don't break the web" I know it's not your fault but this statement doesn't make any sense. Web is made of hyper-linked content not jQuery animations and AJAX.
  - emodendroket 12y ago
    No one cares what the Web was originally intended to be, frankly.
    - CmonDev 12y ago
      Then why care about language designed for animating monkeys?

kazinator 12y ago

This is not just the last several years. It comes from a slogan that was popularized by Eric S. Raymond some 18 years ago: http://en.wikipedia.org/wiki/Release_early,_release_often http://en.wikipedia.org/wiki/Release_early,_release_often

irickt 12y ago
Or Guy Kawasaki, circa 2000 >>> Don't worry, be crappy. Revolutionary means you ship and then test... Lots of things made the first Mac in 1984 a piece of crap - but it was a revolutionary piece of crap.

d_b42 12y ago

All things in moderation.. To me, "ship it" as a philosophy means the most important thing we do as developers is deliver working code to customers. On my team, when we encounter a concept that is just too complicated to ship right away, we try to branch-by-abstraction and keep shipping changes, even if the feature isn't "ready" yet. To me, the marginal returns on trying to be right diminish more rapidly than the returns on making it easy to fix to stuff when I'm wrong. Maybe I'm just not as smart as everyone else here, but it seems to work.

Sir_Substance 12y ago
It's more of a business necessity then a philosophical point of view. The history of software development is littered with companies that failed because they spent so long polishing the beautiful crystal tower they were developing that someone released a concrete one instead and everyone bought that, and then no one needed a crystal one any more. Unfortunately, it can be really hard to find out about these companies because of how hard they've been trodden into the ground by their successors, but Xerox and Netscape would be two high profile examples. Shipping constantly may not be the best thing for technology, it may not be the best thing for quality and it may not, at times, even be the best thing for your users. But if you don't, someone else will.

saidajigumi 12y ago

This whole article makes me want to scream, if only because the author seems to have never heard of the concept of Path Dependence[1]. I could utter a similar rant, on how terrible it is that we're stuck with awful legacy dumb AC lightbulb sockets everywhere, and wouldn't it be nice if the entropy fairy just waved a magic wand and we all had 'net-connected DC smart sockets for our wonderful Future Bulbs. But that kind of talk utterly dismisses the important reality that 1) we don't have a magic wand and 2) we have to deal with things like path dependence and network effects as phenomena. Example: if you chart out historical network bandwidth, you'll get a Moore's-law-esque curve, but with a significant step function depending on which network aspect you study. Why? Path dependence and (literal!) network effects: we don't see the benefits of network bandwidth improvements until enough hardware has been upgraded to see an end-to-end improvement. [1] https://en.wikipedia.org/wiki/Path_dependence https://en.wikipedia.org/wiki/Path_dependence

soup10 12y ago
Javascript has become the defacto browser programming language, even though it's objectively awful for complex software. The only reason it's achieved it's high status is because browser developers refused to cooperate and develop something better. Microsoft and Apple view software lockin as a competitive advantage and have actively undermined technologies they thought were threatening(java and flash amongst others). The explosion of Html5 and javascript was more of a 'nature will find a way' type development and can almost entirely be credited to Google and various web companies pushing it and making it better. It's still a very flawed technology stack for complex web-apps though and it's very reasonable to suggest that we could do a lot better.
- nulltype 12y ago
  If you think Javascript is bad for complex software, you should try C++.
  - angersock 12y ago
    Hey, they're trying with ES6!

cageface 12y ago

You see the same thing in natural organisms. Vestigial adaptations and odd or even awkward designs abound, yet they are functional. Some people take "Worse is Better" to the extreme of "Worst is Best" but there is some wisdom in the idea that it's better to get an adequate solution into play early than to wait for for a perfect, clean-room design. The important thing is to setup a feedback loop that continually refines your solution. For an inspiring take on the power of chaos in evolution check out Errol' Morris' film "Fast, Cheap & Out of Control": http://en.wikipedia.org/wiki/Fast,_Cheap_%26_Out_of_Control http://en.wikipedia.org/wiki/Fast,_Cheap_%26_Out_of_Control

kazinator 12y ago

> Systems stopped using cooperative multitasking at least 20 years ago because it sucked compared to the alternative of automatic, preemptive multitasking. And yet Node.js harks back to those dark days with its callback-based concurrency, all running in a single thread. Uh, no. For instance, Unix kernels have been traditionally cooperative---at least when executing kernel code. That is to say, user space can be preempted but not the execution of kernel code. The introduction of SMP brings concurrency into the kernel, though, and with that, preemption can follow. Linux development followed this path. Still today, you don't have to turn on CONFIG_PREEMPT when building your kernel. If you don't have SMP either, then you have a cooperative kernel: one task is in there at a time, and it has the CPU until it voluntarily calls into the scheduler. Cooperative tasking has the enormous advantage that it makes a whackload of potential race conditions go away, and that could be a possible reason why Node.js is the way it is. Unix might not have been successful had Ken Thompson decided to make the kernel preemptive, and then spent 1973-1987 debugging it. :)

pjmlp 12y ago
>Unix might not have been successful had Ken Thompson decided to make the kernel preemptive, and then spent 1973-1987 debugging it. :) Sadly that didn't happen, UNIX was adopted by 80's hipsters into their startups, became adopted by the industry at large, thus spreading C into the industry. Now we have patch <choose day of week>.
- rjblackman 12y ago
  people working on computers in the 80s were not hipsters.
  - pjmlp 12y ago
    The persons called hipsters in computer culture already exited back then, we just didn't called ourselves hipsters. The remark was for the younger readers. Me, I was into the demoscene and couldn't care less about UNIX until around 1993.
- cben 12y ago

deleted 12y ago

[deleted]

McUsr 12y ago

I haven't tried Mongo.db, but Node.js takes up a lot of resources in a browser, Node.js apps feels a bit like the widest book strategy in the bookstore, you have to shove other stuff out of your browser, in order to use stuff that uses Node.js, and I feel that as a rather arrogant approach to deliver software, especially, when the functionality of Node.js apps doesn't really dictate the necessity. AS for Javscript, there are worser languages out there, and the debuggers are good enough now, so it can be perceived as a "normal" language.

computmaxer 12y ago
> but Node.js takes up a lot of resources in a browser You must be confused. Node.js is used to run JavaScript on the server, not in a browser (the client).
- McUsr 12y ago
  That may be so, but when I run something with Node.js in my browser, then I may have to close other things. So, wherever it runs, it really uses too much resources, and therefore I find it as a bad idea from the consumer perspective. It shouldn't be so, that somebody else, should dictate the content of your browser.
  - BSousa 12y ago
    Are you sure you know what node.js is?
    - McUsr 12y ago
      The short definition would be: "node.js is something that eats up my browsers latency", something along those lines, and as far as I am concerned, that is everything I have to know about it. Node.js is a no stop for me.
      - pavlov 12y ago
        Can you name some of those Node.js apps that have been causing problems for you?

narrator 12y ago

People use mongo and node because they want to get a site up really really fast and see if it gets traction. When they actually get somewhere they'll rewrite it in a better language. If you want to set yourself up with really slick tooling and a great language you can code in Scala with Intellij. You can even avoid touching any ugly dynamically typed stuff by coding your JS in scala.js. If you're doing it better than the other guys then great, you can code rings around them. Maybe it's not worth all the extra complexity when just starting out though. When you get to big corp size code bases static languages are more common. That's because to be able to navigate and maintain that big of a code base, a good IDE, a static typing compiler and refactoring tools are a huge help.

edejong 12y ago
The interesting thing is that all these big-corp code-bases started out relatively small. The origins were actually able to overcome the complexity-wall that arises when a product is successful.
falcolas 12y ago
> When they actually get somewhere they'll rewrite it in a better language. Anecdata for you: Not necessairly. I'm working for a company which has "actually gotten somewhere", and our development team is still writing in Node with Mongo. Of course, there is a reason for it, the front end development team has spare cycles, and the backend team does not. Ergo, Node!
- alxndr 12y ago
  I'm inclined to repurpose a cliche, and say that now your backend team has two problems!

chvid 12y ago

I wonder if "hurtful shipping culture" has a parallel in the blogging world?

mrgriscom 12y ago

Reminded me of this essay: http://www.jwz.org/blog/2012/08/a-generation-lost-in-the-bazaar/ http://www.jwz.org/blog/2012/08/a-generation-lost-in-the-baz... I don't think it's fair to attribute the issues he brings up to "shipping culture". Rather, the causes are two-fold: 1) Lack of appreciation for history, being doomed to repeat it, all that 2) Making anything above the level of 'just not-terrible enough' without a benevolent dictator is hard.

igl 12y ago

The problem is that the Author is assuming that 90% of software we write to make a living is set into stone and suppose to run forever. Almost everything we do is disposable and replaced within the same decade. So he does not like Javascript and Nosql. Is it hard to find a JavaEE job? I think not.

hyc_symas 12y ago
I think the real problem is the disposability attitude you just described. It's prevalent in our real world consumerist economy and it's killing us there too. Building software that's to be thrown away is a waste of mental resources and physical resources. Society and civilization advances on top of our lasting creations, not the ephemeral ones. Reinventing the wheel doesn't advance the state of the art. You want to build one good set of tools that will last a long time, so you can stop thinking about them and be free to tackle the next truly new challenge. Doing anything else is just a waste of life.
- igl 12y ago
  wat? How can you even compare the "problems" of building commercial software to the problems of consumerism in capitalism? The standards applied here are whack in the scope of what js and mongo are used for. Also: You only get better by reiterating.

yason 12y ago

Shipping doesn't always need to mean shipping to the public. I write complex software too but I "ship" to myself early and often. I start by trying to solve a hard problem as fast and as quickly as possible in a naive way so that I can experiment more freely. This gives me more insight into the problem itself and into the solution space. The solution often changes -- sometimes it's the problem that changes. If I were working with a customer or a startup I would definitely "ship" early and often, too, but I wouldn't give much weight to these "releases". They're just something to play with and to cut the shape for the problem.

halayli 12y ago

It's a spectrum. Trying to ship a perfect software from the start will probably end up like OS/360 project. Then K&R came along and designed what we know now as unix. An OS that wasn't complete and fully featured like OS/360 was intended to be, but it worked! Making the wrong choices is inevitable, but correcting them is part of the software life cycle. We aren't working with concrete and building bridges here. If we built Pisa tower like software, we can still fix it. So yes, ship when you can as long as it works and delivers what it promises. It doesn't have to be perfect.

hyc_symas 12y ago
Delays getting OS/360 were a blessing, really - it prompted many universities to develop their own mainframe OSs, thus helping OS research flourish around the world.

erikb 12y ago

I actually watched the screen cast this blog post is about. [1] And I would like to say something about that here, because the questions from the screen cast were also coined in the blog post. The Question is this: "Why do people not replace VT100 style terminals?" There are two reasons. tl;dr Terminals have other reasons than programming in them and people actually reinvent how you can program on a daily basis. See more in depth arguments below. The first thing is that people actually still need the old terminal stuff. There are loads of old computers you want to communicate with (just think of your pa trying to relive old times be trying to get the 80's game console to work). And there are also a lot of technologies that really need something that stupid, e.g., if you develop your own embedded system you might actually communicate with it using these VT100 commands. So yeah. Wow. A Terminal (emulator) doesn't have the task to show your text editor. You can start GVim if you just want to show your editor. They have the task to communicate. They can communicate with the system you are running them on or you can use them to communicate with another terminal. If you want to replace them, you have to replace the software in your pa's console (and probably some hardware), you have to find a new way to develop fresh, small computers, you have to find a new way SSH works, you have to find a new way to show your text editor. It's not impossible, but it's probably so hard that nobody would like to spend their whole life (work time, spare time, youth to death) doing it. It's not worth that much. Summary: It's not worth it, if you consider the whole picture. And second argument: People actually do, if you just think about use cases like coding, gaming, etc. A modern game doesn't run in a Text shell as e.g. Nethack could. It runs in a graphical shell and is represented to you in 3D, e.g., GTA 5. Also there are many people who use IDEs. Unix+Bash+Texteditor was actually an IDE. Eclipse etc are a new way of thinking about the editing task with helpers like compilers, static analysers, debuggers, performance analysers, unit test runners, etc. There are even people who reinvent the programming wheel from another point of view, e.g., have a look at NoFlow. The reason the other stuff is not dying is because it's useful for other reasons. That doesn't mean you have to still use it for programming (also some people, like me, choose to). Summary: People do work on finding modern ways to program. [1] https://www.destroyallsoftware.com/talks/a-whole-new-world https://www.destroyallsoftware.com/talks/a-whole-new-world

annnnd 12y ago

While I agree with the facts in the article, my own conclusions are quite the opposite (feel free to downvote / flame, but please read the whole response first). I guess it depends on values - for me, what matters is the value added to customer. Iterating quickly (often) yields better results in this area because it allows you to guess customer expectations early in development process. I have often encountered die-hard engineers who want 100% specification upfront... In my experience, world doesn't work this way. It would be nice if it did, but it doesn't. And yes, I am guilty. I am using MongoDB AND JavaScript (but not Node.js - not that I have anything against it, just never had the need for it). I don't use these technologies because they are "cool", but because they solve specific problems in an efficient way. Which is probably why hackathon devs used them too. And yes, I would appreciate schema in MongoDB and types in JS, but I can live without it. Life is made of tradeoffs. Does it really matter if latest Fart App (tm) builds on transaction-safe DB and uses strong type language? So, are we seeing a rise of "shipping culture"? Yes. Does it change how we work? Yes. Is it in some ways worse? Yes. Is it hurting us? No.

foombarder 12y ago

Oh yeah, right - I forgot that we write code for the sake of engineering - why would you wanna get stuck in the shipping loop? ...

logicallee 12y ago

honest question. do you guys want a piece of crap from me that illustrates a new application type? (the way bittorrent or bitcoin or napster or wikipedia was new?) or should I wait. I don't have any resources to put into this but can release a piece of crap myself. (I don't personally program professionally.) honest question - discuss. would you like a piece of crap - or for me to wait. (Nobody more competent is going to just code this for me, at least not until the piece of crap exists and has traction.) I don't really envision other options but am open to them. What should I do? Get it right (not happening) or get it out?

jtth 12y ago

im from tumblr and what is this

whiskeySix 12y ago

The first two comments in the linked article are gold.

EGreg 12y ago

I would say Ship Often and A/B test. And before that, get really big test pool! The first part to success is making it safe to fail

dustingetz 12y ago

Seth Godin wrote that 5 years ago, i think (hope) the economics are shifting, in the last 5 years a lot of the omgcats apps (market opportunities that can be captured with lousy software) have already been written, i think it may not be so easy for companies started today. However with the pace of innovation in the last 5 years (basically the coming of age of functional programming) it's a lot easier for a single person to write high quality software. Anyway common wisdom is always going to lag behind today's actual best practices

RangerScience 12y ago

The author's bit about how we forget about the problems and solutions of our forefathers - that resonates with me. We do seem to keep re-inventing the wheel, and while part of that is out of joy of creation, I think a lot of that is that we're not writing down the problems, and we're not teaching the problems. We're only paying attention to solutions, and that's limiting. Code is a solution to a problem, but it's not always apparent what that problem /was/ when you just look at it. So NodeJS (according to the authoer) is doing something that was thought of as a good idea at first, and then people learned why it wasn't, and /nobody wrote that down/. Or, at least, when they wrote it down, nobody taught it. Solutions are /answers/, problems are /questions/. Here's a beautiful illustration of this dichotomy: http://dead-logic.blogspot.com/2012/09/a-collection-of-questions.html http://dead-logic.blogspot.com/2012/09/a-collection-of-quest... This is then part of why the TDD movement is in the right direction - you write down the problem you're going to solve, and later, someone can come read it. And maybe teach it. (Not saying TDD has gotten "there", but it's in the right direction)