Live data from Hacker News

Shipping Culture Is Hurting Us

bitbashing.io

81–90 of 169 posts

Re: Shipping Culture Is Hurting Us

#81

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":…

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.

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.

Re: Shipping Culture Is Hurting Us

#82
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.

Re: Shipping Culture Is Hurting Us

#83
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.

Re: Shipping Culture Is Hurting Us

#84
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

Re: Shipping Culture Is Hurting Us

#85

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 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.

Re: Shipping Culture Is Hurting Us

#86

Earlier quoted context omitted.

How about "full-stack developer"?

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".

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)

Re: Shipping Culture Is Hurting Us

#87
post #38

Earlier quoted context omitted.

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).…

> it's very reasonable to suggest that we could do a lot better. Yes, and it's so damn obvious now that you'd better have something salient to add. To wit: this has been done much better by others. C'mon, the book is called Javascript: The Good Parts (cough, 2008 vintage) This post is just chock full of bizarre straw-men in the guise of actual argument: Systems stopped using cooperative multitasking at least 20 years…

Node.js is just a http://en.wikipedia.org/wiki/Reactor_pattern

http://wtfjs.com

Re: Shipping Culture Is Hurting Us

#88
post #19

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.

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…

"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.

Re: Shipping Culture Is Hurting Us

#89
post #71

Earlier quoted context omitted.

> 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).

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.

Node.js is something that runs on server ONLY. It's 100% like PHP but with JS instead. Your browser never sees nor executes Node.js code. It only operates on text a Node.js server produces.

Re: Shipping Culture Is Hurting Us

#90

Earlier quoted context omitted.

Yes. The research culture that produced Haskell, for example, is far from the "shipping culture" that produced JavaScript 1.0, and yet: > let x = 0/0 > x NaN > x == x False > :type x x :: Double (and yes, Double is an instance of the Num type class) The author programs in C++ and D. I wonder if he knows the value of (NaN == NaN) in those languages?

I think the author just picked an awkward example. The real point is the existence of that table of weird (non)equalities and (non)truthinesses in JS [1]. [1] https://dorey.github.io/JavaScript-Equality-Table/

I cracked up over the famous NaNNaNNaNNaN Batman presentation. But, IMO that table is very predictable for a 'dynamic' language, for the normal use-cases. It only gets strange on the outer edges with oddball arrays and objects.

But, if you have code which compares one-element arrays with strings, you have bigger problems than javascript. I can't recall seeing any serious comparison Batman-style bug. Hypothetically, that kind of stuff wouldn't even be a logic bug, but a design issue that was allowed by the dynamic type system. Solution: don't bitch about Javascript, use something else.

Post reply on HN