Hacker News Reader

Comment by mynegation | Hacker News Reader

Oh the irony of an analogy... The point of these complications is that you are able to travel farther and faster on a jumbo jet than on a bicycle and these journeys will take you to many more interesting places (once you are set up, that is).

Version control, build systems, compilated makefiles, testing frameworks, profiler sessions, deployment scripts - all that takes time to set up, but pays handsomely on all projects of non-trivial size and length.

The right thing to do is not to get rid of this "overhead" but make this setup as easy as possible.

View on HN

> Oh the irony of an analogy... The point of these complications is that you are able to travel farther and faster on a jumbo jet than on a bicycle and these journeys will take you to many more interesting places (once you are set up, that is).

Yes, but his analogy was about how he got into programming because it was enjoyable like riding a bike, and recently the bike-riding process was replaced by airport-processing-and-jet-flying-process, which is not fun at all. He cares more about the travel experience than the destination.

As an aside, this is also often a difference between "business guys" and "tech guys" - on the extreme ends of spectrum, the former care about getting money doing pretty much whatever (be it selling potatoes or building jet engines, whatever sells) while the latter care about doing what they like regardless of "business value".

That's the difference between a job and and a hobby. He likes biking but to be efficiently deliver pizzas from shop to homes, he needs to drive a car. He could still ride a bike in his spare time, but don't expect to get paid the same way as driving a delivery car. Note that even if he's a super fit guy, and is as efficient as another guy with a car, there are always other rules that make it complicated: insurance, customer expectation, etc. Now we can always dream about a world where we can just work on our hobbies, but the reality is we are not there yet.

That's very well put.

Having been in the industry for what feels like a long time, I definitely struggle with that. Having a deep understanding of systems was useful and valuable back in the day. It still can be useful today, but an awful lot of software gets made through relatively unsophisticated people gluing together a bunch of stuff they don't understand very well.

I suspect a much greater proportion of cyclists really understands their bikes than car drivers understands their cars. Which would be problematic if those people were, say, race car drivers. But that's not the case.

> Version control, build systems, compilated makefiles, testing frameworks, profiler sessions, deployment scripts - all that takes time to set up, but pays handsomely on all projects of non-trivial size and length.

Part of what the OP was trying to say is that these tools sure are valuable and necessary in all non-trivial projects, but you can't get away without them even if the task at hand is trivial. Like the simple mobile app that the OP was talking about.

Once a project grows too big to be one or two source files, you're going to have to invest time to set up version control, build systems, testing, deployment, etc. It's like you'd have to take the jumbo jet to go to the grocery store and not being allowed to ride a bike.

I recently went through bootstrapping a project like this, I had been working in a single C file in Vim (:setlocal makeprg=gcc\ -o\ %:p:r\ %:p $CFLAGS) which was rather nice and I was very productive initially (and enjoying myself). Now I've spent about 5 working days setting up builds and automated testing, test coverage, profiling, continuous integration, etc and I'm still not done. That's 5 days worth of time not going to solving a problem.

That's a big reason why I developed the centipede framework

https://github.com/paulhoule/centipede

It handles all the BS that it takes to do Java projects so you can start a new project with all the boring stuff taken care of for you in 1 minute.

But by the author's logic now I have to learn your new tool! And it's on Github...the horror.

It's your personal project; no one's forcing you to use version control, a non-standard build system, etc. Many of us spent many years/decades coding without, and personally I never never never want to go back to working that way. It's the standard tradeoff of automation: some extra time up front learning and setting up some workflow tools (download them, write your own scripts, whatever) ends up saving you from an absurd amount of repetitive, error-prone manual activity.

> It's your personal project; no one's forcing you to use version control, a non-standard build system, etc

This is simply not the case any more. If we go back to the example in the OP - a trivial mobile application - even if the code would fit in one simple file and would take no longer than a few hours to write, doing all the mundane setup work would still be there. You can't build an Android or an iOS app without using the toolchains the platforms provide. You're going to have to write XML manifests and build scripts and whatnot (and/or learn the respective preferred IDEs for both of them).

The same applies for any practical sized application, no matter how simple.

> personally I never never never want to go back to working that way.

Me neither, I just wish the overhead of setting all this up would be less.

Now the best thing we have are language-specific tools and conventions, no universal established best practices exist. This is also why "Java shops" hire "Java Programmers" and not C# programmers. A proficient programmer in either should be up-to-speed on the other in no time if it weren't for all the new tools that have to be learned.

> Now the best thing we have are language-specific tools and conventions

Sometimes we do, sometimes we don't. I've been learning Ruby toolchains to code Erlang in a company, seen C++ code for robots running AVR being compiled and deployed by a Scala build tool, and webdev is a total mess; every other library uses weird tools written in unrelated languages.

> You can't build an Android or an iOS app without using the toolchains the platforms provide.

That's because of the way Android and iOS were designed. The amount of crap around coding is not a constant, it's very easy to inflate it with things like XML manifests and IDEs.

>The point of these complications is that you are able to travel farther and faster on a jumbo jet than on a bicycle and these journeys will take you to many more interesting places

That's a rather insightful thought that I didn't think of while reading the article.

Keeping the analogy going, I'll point out that there is a large difference between bike riding and jetting around the world. As far as traveling goes, one could think of bikes being analogous with enjoying the journey, and flying being analogous with enjoying the destination. Despite the fables and memes, enjoying one over over the other isn't inherently wrong in my opinion, but different people will prefer one over the other.

Some people will prefer the simple act of creating something with your own hands using (relatively) simple tools. Like a craftsman building a nice table. Others will prefer huge projects, the skyscrapers and the like. When I first read the article, I was only thinking of the one side, but your post has helped me see that creativity takes many forms.

I have another apt application of this already-stretched analogy, but I think it works well w.r.t. the pain of doing large projects without the right tools:

A bicycle ride to the next town is enjoyable. Paddle boating across the Atlantic gets old fast.

But don't overdo it.

You need a version control, not an extensive strategy on how to do it from day one.

You don't need to automate deployment of your Hello World web app from day 1 so you can press a button and this will set a load-balancing setup in AWS. You may eventually need something, which will be simpler.

Also don't go for overbloated tools

OH but you NEED a CSS minification tool! You HAVE TO HAVE IT!!!!1111

You don't have to have it, in fact I've caught some major websites not using it.

    OH but you NEED a CSS minification tool! You HAVE TO HAVE IT!!!!1111

One way to keep things simple while still getting the benefits of minification is to code your whole simply, and then later install an optimization package like mod_pagespeed on the server. This keeps your code and flow simple, and then later on when it's worth your time you can install/enable the optimizer.

(Disclaimer: I'm the TL for mod_pagespeed.)

Precisely my thoughts. I would summarize with being mindful of all of these things, and building with flexibility in mind so that should the need arise, these additional "complications" can be added.

To put it bluntly, it just comes down to being smart about what you're doing. Don't mimic the other guy for the sake of appearances.

> The point of these complications is that you are able to travel farther and faster on a jumbo jet than on a bicycle and these journeys will take you to many more interesting places (once you are set up, that is).

That's the theory of those complications. Often it never pays off. You can have too many moving parts.

What development teams need to do is assess the TCO of the various tools they use to see if they can reduce it and get a sense of whether they are getting a real advantage after they have.

I know plenty of developers who are all too ready to reassess the TCO of source control or bug tracking, or who are already as free as a newborn puppy of the complication of a "deployment process"---which can be a problem if you are the one responsible for making sure their app gets deployed and stays deployed.

I really like the go(1) approach of testing and profiling, and together with Docker and git it really makes for a easy-to-setup environment.

Library-first (as opposed to framework-first), write your foo.go and foo_test.go, run go test -bench ., iterate, deploy to devenv, run integration tests, push to live. Works great, no hassle.

Yes, but ultimately the old farts won't admit that code is overrated when it comes to writing real share. Not to mention how most the tools he rails against are certainly code in any real sense.

Yes, but ultimately the old farts won't admit that code is overrated when it comes to writing real software. The old "programmer" job died years ago. Not to mention how most the tools he rails against are certainly code in any real sense.

It's funny how all of these complexities are put in place to make software as convenient for the user as possible, but in doing so it just ramps up the difficulty for the developers. There are some sites out now that do try and make the setup as easy as possible while keeping the power that the "overhead" yields. Nitrous.io orchardup.github.io/fig and bowery.io do a great job in simplifying the setup. This laracast explains it all pretty well: https://laracasts.com/lessons/bowery-is-pretty-darn-insanely...

>The point of these complications is that you are able to travel farther and faster on a jumbo jet than on a bicycle and these journeys will take you to many more interesting places

But perhaps really good tools would offer all of that without losing the ease of use of a bicycle.

The problem is that current tools are working at the toolchain equivalent of assembler - or maybe C, for something like git.

Tools that work at the toolchain equivalent of a good functional programming language - never mind a toolchain with useful AI assistance - haven't been built yet.

can you pass the salt? http://xkcd.com/974/

Reply on news.ycombinator.com