6 ms·

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 jour

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.

deleted 12y ago
[deleted]
TheCraiggers 12y ago
>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.
- nmrm 12y ago
  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.
sebcat 12y ago
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.
- hack_edu 12y ago
  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.
- hack_edu 12y ago
  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.
raverbashing 12y ago
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 No You don't have to have it, in fact I've caught some major websites not using it.
- cbr 12y ago
  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.)
- prawks 12y ago
  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.
michaelfeathers 12y ago
> 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.
- mcguire 12y ago
  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.
exDM69 12y ago
> 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.
- PaulHoule 12y ago
  That's a big reason why I developed the centipede framework https://github.com/paulhoule/centipede 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.
  - optimusclimb 12y ago
    But by the author's logic now I have to learn your new tool! And it's on Github...the horror.
- tdumitrescu 12y ago
  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.
mundizzle 12y ago
can you pass the salt? http://xkcd.com/974/ http://xkcd.com/974/
TheOtherHobbes 12y ago
>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.
TeMPOraL 12y ago
> 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".
- boomzilla 12y ago
  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.
  - wpietri 12y ago
    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.
vortexts 12y ago
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-cool https://laracasts.com/lessons/bowery-is-pretty-darn-insanely...

deleted 12y ago

[deleted]

TheCraiggers 12y ago

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

nmrm 12y ago
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.

sebcat 12y ago

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.

hack_edu 12y ago
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.
hack_edu 12y ago
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.

raverbashing 12y ago

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 No You don't have to have it, in fact I've caught some major websites not using it.

cbr 12y ago
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.)
prawks 12y ago
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.

michaelfeathers 12y ago

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

mcguire 12y ago
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.

exDM69 12y ago

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

PaulHoule 12y ago
That's a big reason why I developed the centipede framework https://github.com/paulhoule/centipede 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.
- optimusclimb 12y ago
  But by the author's logic now I have to learn your new tool! And it's on Github...the horror.
tdumitrescu 12y ago
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.

mundizzle 12y ago

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

TheOtherHobbes 12y ago

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

TeMPOraL 12y ago

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

boomzilla 12y ago
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.
- wpietri 12y ago
  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.

vortexts 12y ago

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-cool https://laracasts.com/lessons/bowery-is-pretty-darn-insanely...