I agree with the overall point: tool complexity can be a major downer and impose residual drag throughout a project's life cycle. I too "just want to code".
However, I don't agree with some of the author's examples.
Git has proven to be rather simple, minus the initial 1 week learning curve (of casual use, give or take). I use it in solo private projects and in teams. Branching and merging, in particular, are part of why I love it so much; much better than the CVS and SVN days.
And isn't using SCM considered a best practice? I think so, but I'd be interested in hearing any counters.
I also find build tools essential. Even for web apps, simple ant scripts that automate remote tasks have proven invaluable, especially wrt deployments.
What if the source code needs to be maintained internally? Our source code cannot be stored in "the cloud" where someone outside or most likely inside the CDN (our competitor) will take it.
There are a lot of things deemed best practice. Best practice for who? And, to what end? Here is a best practice: release developer tools for your platform that are the only way to build software for your platform. Locks in developers to your platform. Makes it difficult to switch or port to other platforms. Enables ways to thwart competitors, by slowing down their development cycle or even stopping it at the approval point. Enables ways to steal ideas and even code. Why do you think each major platform has their very own programming language and plethora of platform specific APIs? A floor of moving snakes is not much fun. One vendor even called their platform ASP.
Simple build tools. The ant script is simple, but installing ant is not. And, we don't really want ant and the dependencies it requires. But, whatever works for you.
> What if the source code needs to be maintained internally? Our source code cannot be stored in "the cloud" where someone outside or most likely inside the CDN (our competitor) will take it.
It sounds like you are mixing up Github with Git itself? You don't have to host your code at github to use git. It's just one of the more popular ways for open source projects.
> The ant script is simple, but installing ant is not.
It isn't? Ant is packaged in most major distros; what kind of servers do you normally deploy on that doesn't have it?
> What if the source code needs to be maintained internally? Our source code cannot be stored in "the cloud" ...
Then move your SCM server wherever "internally" is? SCM does not require "the cloud".
Regarding ant not being simple to install ... would you mind elaborating? I've installed ant a handful of times, either via "sudo apt-get install ant" or as a plugin to my editor; both ways were simple IMO.
And I agree with simplicity, particularly with dependencies. I mentioned ant off the cuff, though I also use shell scripts when I can. They handle most remote tasks I can do in ant, but w/a smaller foot print.
However, I don't agree with some of the author's examples.
Git has proven to be rather simple, minus the initial 1 week learning curve (of casual use, give or take). I use it in solo private projects and in teams. Branching and merging, in particular, are part of why I love it so much; much better than the CVS and SVN days.
And isn't using SCM considered a best practice? I think so, but I'd be interested in hearing any counters.
I also find build tools essential. Even for web apps, simple ant scripts that automate remote tasks have proven invaluable, especially wrt deployments.