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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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

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.

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.

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.

What I am trying to say so eloquently (or not) is that maybe the problem is not the modern development world but the developer. The idea that you need just another tool to solve a problem, that is what is flawed. Skill and balance and a set of powerful, basic tools, that is what solves the problem.

Try watching someone who is an expert at Cocoa/XCode and you will see that they also have extremely tight, natural interaction with their toolset. They know where the rough corners are and avoid them. Their environment is already configured so that builds just work. etc.

Those of us who work in the browser have similar tools and workflows so that, once we have them working well and meld with the tools, we work very productively. Yet any time I have to show someone new how I do my work, it involves many layers of learning over the course of months before they can get to that point.

Similarly, though your workflow seems quite natural to you, I doubt it would make any sense to me. Yes, I know git and vim, and I can probably read the python code just fine. But knowing how to build the project, how to test incremental changes, how to debug and do performance profiling, and how to have a basic feeling for when I'm done? It would take me quite a while pairing with you before I felt comfortable.

What's the lesson? While there certainly are better and worse development environments, if you judge the one you know well against the one you know poorly, you will always think that what you know is best. I appreciate the sentiment that says learn one thing and learn it well, rather than chasing every fad. But I also think that, if you're going to be well-rounded or wise, you need to have the perspective and take the time to go deep in other environments before judging them.

Even with Python and the Unix tool chain, you still have to learn new libraries and look up API doc when they come out, unless you plan to keep doing the same old things.

Software career is a process of learning new stuffs from time to time, expanding the comfort zone.

I completely agree that there is no common denominator when it comes to build scripts. There are so many variations out there. But I think if I know make, automake, CMake and Ant I'm fine with many projects and some more when I ask the authors nicely to provide me either of these.

But it's not really a problem, actually. Often these people who work in these environments don't understand what freedom of mind is anyway (like try to tell an Apple guy what a FOSS OS would do good for them). The need to implement the whole Unix philosophy and all it's tools didn't stop the Java world from avoiding Linux and BSD which already has the Unix philosophy and tools available. They wanted to develop everything themselves again (and sometimes did a brilliant job!) because that's how they are. I don't like that. I am lazy and don't want to develop what is actually already there and I am not so smart. All my tools would suck compared what already exists. So I am actually quite happy not to work in the Java world even though that's what I studied in university. When git came out I learned how to use it (so much that I would be able to write my own git now), although in school we always used SVN. Now I can happily merge, rebase and cherry-pick and can focus on coding because everybody uses git. Learning git even made my coding better because I learned some great things about software development there.

(This now became more of a novel than a response to your text. Sorry!)

Ironic how the choice of Java and sandboxing was meant to make this not necessary

If you are running the same application on equivalent hardware at the same API level then you should be fine.

Android has issues with hardware as well as the various API versions. The closest parallel in Java would be comparing a Pentium 4 running Java 1.3 vs some 12 core server running Java 1.7 or something.

So a closer parallel would be that 12 core server running Java 1.7 can have its UI skinned by different device manufacturers, and that the UI actually makes a great deal for acceptance of the app in the marketplace.

This is great, but if everybody was doing like you we wouldn't have mobile apps, or in fact anything that has to run on something non standard.

"The Zen of Unix and the Tao of Testing are my companions. Nothing disturbs my chi."

Good, then keep doing your chee. The rest of us are going to use the right tool for the job, instead of some mythical pain-modifier that you think is the "One True Way".

For iOS, however, it seems you're indeed kinda screwed - you have to go through Xcode and the atrocious storyboards stuff.

The main benefit is that you end-up with no merge conflicts in semi-opaque files.

Though I think you're still stuck with xcode ? can you use a CLI toolchain (directly calling clang and so on) to compile, build and sign an IPA ? from the little I've seen of Xcode, it sucks (a lot): random crashes, GUI & behaviour inconsistencies, bad file management, etc...

FWIW, Apple has never required storyboard. You can do everything in code if you -really- want to do it that way, no problem. Personally, I like offloading a lot of the visual stuff to storyboard/xibs unless you start getting crazy with custom animations and so forth.

There is a third party IDE: AppCode by jetbrains which does most of what you need (and apparently lots of things better than Xcode) but i've never used it for any long periods

Xcode gets a bad rap, but i use it every day and can't remember the last time the current version crashed or did something strange, maybe i'm just used to it by now though

Also, banging out code is overrated. I've found that when I take time to think, my actual coding becomes closer to what you see in the movies. I can find my flow and quickly materialize my ideas, and most importantly, solve the problems that arise. When I try to just "code" it ends up being poorly designed and written.

The point here is that when you do have the desire to "just code" take a step back and consider taking pride in the code you publish. The tools and systems in place are there to make you a better code publisher. The goal is to write well written code that others (including yourself) can maintain. Rather than being frustrated you have to deal with the intricacies of rebasing or 3-way merges, take a moment to understand these skills will help you publish better code.

"Just use Rails!" you hear, ignoring the small voice in your head wondering if all of the beauty of computation can really be foisted into ill-chosen paradigms. The cognitive killswitch that is mass acceptance and cultural success overrides that voice, though, so it's all good.

Then, when you inevitably get things into a mess, you consult the inevitable cottage industry of people who give you tricks to ward off the pain temporarily.

this. Not really important for small and/or personal projects, but for anything beyond that simply spitting out code ends up in a bad design violating SOLID and everything else out there, more often than not. After I figured that out, "code" now actually for me means something along the lines of "think about how components should cooperate with a minimum dependency, [enter rest of SOLID and everything else out there here], then start spitting out the tiniest functional pieces needed to implement it from the bottom up". Might not work for everyone, but it has done wonders for me. Especially the more my knowledge/experience about the first part grows (i.e. thinking about design upfront), the better the second part (i.e. spit out actual code gets), and the more proud I am of it. Heck, code from past two weeks is actaully a new personal record for me. So beautiful and well-cratfed :]. Then again, I thought the same thing about a piece I wrote 6 months ago. And the same goes for the way I use all other tools in the build process actually.

I trained as a 2D animator. When you start, it's great - there's just you and the drawings. You can make anything happen. But once you start to want to make something bigger than a couple of seconds, things get complicated; you have to plan a script, wrangle multiple scenes, start involving other people to break up the process in various ways - inbetweeners fill in frames between what the lead animator draws, cleanup artists neaten things up, colorists, background painters, 3D people for stuff that's a pain to do by hand... plus all the non-drawing support people. Watch the credits at the end of any animated feature. All of them. Every single one of those people put in a lot of hours to make that film happen; not all of them did work that shows up directly on the screen. But all of those people had an important part to play, and all of them had to have ways to communicate with each other.

I burnt out on that because I didn't want to be a cog in a machine designed to tell stories to the largest possible market. Now I draw comics. And guess what? I've got to deal with learning how to put together a website, put together a book for print, promote my work, go to conventions and sell stuff, etc. It is just barely doable by one person; I've been spending three years doing a ~400p graphic novel by myself, and I've got about a half a year left before it's done. I have template InDesign documents, scripts to help fill those templates, friends willing to try to make sense of the in-progress work and tell me when things don't make sense, sprawling directory structures full of source files and web/print res files, sketchbooks full of planning, etc etc etc. It helps that I was already able to wrangle a website; I'm slowly turning my custom templates into something anyone who wants to present a comic online the same way I am can use. If I wanted to start telling a lot more stories a lot more quickly, I could start parallelizing: separate the job into writer/artist/colors/lettering, find an existing publisher willing to handle packaging/printing/distributing to comic stores, bookstores, and e-stores, as well as shop it around to Hollywood.

I can knock out a nice standalone drawing in a few hours. I still do that every now and then when I need a break. But my aspirations are higher; I want to create a world for the reader to inhabit for a few hours. And that takes a lot more work.

Every kind of complex project has its own kind of scaffolding that users of the final project will never see.

Similar patterns, short is exciting until you hit the next complexity wall.

Good process makes your work of being "a cog in the machine" much more easier (and abstracts the rest for you - and of course, your work will be abstracted away for other people)

While we're generally OK at doing this in the scope of one piece of software, we suck at doing it in workflow terms, particularly where other humans, inter-organizational dependencies, money and existing systems are involved. What this article is really talking about is shifting the complexity of the varying development and deployment toolchains and processes adopted by each different project and organization away from the developer.

The author cites a fairly simple example from the commercial programming world. The complexities he refers to are version control systems, editors/IDEs, build tools, language selection, database/persistence layer selection, test deployment, bug tracking, release processes.

Let's assume learning basic git, how to use web-based issue trackers and a text editor are reasonably considered non-negotiable, per-programmer overhead. The author still has a fair point that IDEs can be a plague in some sectors (mobile and Java in particular).

He is also correct that build tools are numerous, but what makes them so painful? Doug McIlroy famously stated Keep it simple, make it general, and make it intelligible. Is part of the pain that many of them are language-specific, with zero or poor integration with external (eg. system-wide) software package databases / dependency trees? It seems that, today, every operating system distribution and every programming language running upon them generally has (at least) one half-baked, error-prone, cross-platform package management solution with its own versioning scheme, configuration overhead, network assumptions, poorly implemented caching system and probably a broken use of cryptographic primitives. They're not general.

Database/persistence layer selection is an architectural question that is easy to either delay or perhaps - if extensive performance tuning is certainly expected, or deployment environments will certainly be heterogeneous in their persistence layers - sidestep through a layer of abstraction (CRUD) to facilitate provider abstraction. These paths are considered good practice - Ken Thompson teaches us to Spell creat with an 'e' (ie. premature optimization is a fallacy), Eric S. Raymond restates Prototype before polishing. Get it working before you optimize it. and RFC3439 summarizes most eloquently Optimization considered harmful: In particular, optimization introduces complexity, and as well as introducing tighter coupling between components and layers.

The final points of pain (test deployment, release processes) are essentially process design and infrastructure interaction and management issues. While the author mentions the additional complexity of the cloud, in truth this area has become a point of pain so intense that many projects now write their code and internal test/release processes specifically targeting one infrastructure provider (EC2, docker, etc.). That's not very general either, now is it?

So where is there clear room for improvement? The build tool issues are mostly a convention versus configuration question, which is philosophical and not going away. The process/infrastructure issues do seem to be the main candidates for change, and this does appear to be the focus of the author's call for approaches.

Tesler's Law of Conservation of Complexity: Every application has an inherent amount of irreducible complexity. The only question is who will have to deal with it - the user, the application developer, or the platform developer? - Larry Tesler (ca. 1984)

One could take the same view of the development process itself. Well, then... who are we pushing the complexity to? Is it...

(1) a single cloud provider of choice (EC2)?

(2) a platform-specific virtualization wrapper of choice (docker)?

(3) a person or team within the organization who just delegates truth from above (BOFH-style)?

(4) Some lightweight, open source workflow solution that enables us to step beyond the provider/technology lock-in of (1) or (2) and remains painless and configurable enough for mass adoption?

I believe that (1) and (2) do not meet the complexity requirements of larger scale users, and that (3) is not scalable or efficient. I think (3) will exist, but focus more on policy, whereas (4) style solutions will appear in the same vein as the literate, simplistically ops-oriented command line interfaces championed most recently by heroku, vagrant and docker. Regarding (4), if we get it right, we don't even need to notice the implementation. As Minsky said: We're more aware of simple processes that don't work well than of complex ones that work flawlessly..

Sure, back when I learned to code I could just type some stuff in on the machine in my basement, type "RUN", and have magic happen. Yes, it was stuck in my basement, and it couldn't do much, and it wasn't connected to anything. And yes, it could do exactly one thing at a time. But it was still pretty magic.

This guy wants the same experience when building for a computer a million times more powerful, one that fits in his pocket. And he'd like to access a global network of satellites that shout timestamps so that he can, in real time, calculate his precise position and then record it. While that computer continues to do all the things that he expects of it, like letting him take phone calls and receive email from anybody in the world while playing whatever song or movie he'd care to watch. Oh, and he'd like other people to be able to run his app, suggest improvements, view his source code, and offer fixes.

I think it's great to want things to be easy; that sort of irritation is what drives us to make better tools. But a big problem here isn't that the tools are overly complex, it's that he wants a lot more than he did 30 years ago.

I'm sure the tools could be improved. But I think he should acknowledge that a simple developer experience 30 years ago was simple because his desires were relatively simple. (And because the tools had been polished enough that simple desires were simply accomplished.) What he's asking for is more complicated. Should the tools mainly hide that complexity? Sure. But that doesn't come for free.

But his desires are more complex relative to the platform. He wants to do open-source development with distributed version control and collaborative bug tracking. Try that on a C64.

Further, the C64 was a consumer device, carefully engineered to make it easy for novices to a constrained set of basic stuff. I agree that we should have Android development tools like that. Sort of a Logo or Visual Basic for the modern age. But the current mobile tools are for professional developers to do complex, professional things. That's because they mostly want to make complicated, highly polished, consumer-friendly apps.

Those tools may also be needlessly complex for the purpose, and I think we should fix that. But we won't do that if we can't acknowledge the essential complexity of the domain. As Einstein wrote, "Everything should be made as simple as possible, but no simpler."

But for me, Git is integral to writing code. I couldn't image writing code without version control. Git makes experimenting risk free and encourages me to try things and move quickly. There is no risk of breaking anything because you can always go back to the previous working state.

There are other tools that are surely just as good or better than Git, but I'm pretty convinced it is a 40 year technology, much like Unix or Vim. It's worth the time to get really, really good at Git. I see it no differently than learning how to use a decent text editor.

Having built a large project without version control I can safely say git is the best thing to ever happen to my coding productivity and enjoyment.

Without version control my anxiety goes through the roof any time I have to work on a large codebase.

"In fac­t, for ev­ery hour I’ve put in­to ac­tu­al­ly fid­dling with Ja­va code, I’ve in­vest­ed an­oth­er fight­ing git submodule sub­com­mand­s, and now I’m star­ing at what feels like a thousand-meter-high Gra­dle rock-face."

"I should count my­self for­tu­nate that I’m not build­ing a browser-based ap­p; I’d have to bud­get an even high­er pro­por­tion of the time stay­ing on top of this week’s funki­est new JS libraries and scram­bling to have Wave ef­fects be­fore ev­ery­one has them and they’re bor­ing."

He also links to Ed Finkler’s "The Developer's Dystopi­an Fu­ture" [2] which was on HN a while ago and addresses the same topic.

[1] https://www.tbray.org/ongoing/When/201x/2014/07/17/Discourag...

[2] https://the-pastry-box-project.net/ed-finkler/2014-july-6

[1] http://en.wikipedia.org/wiki/Billion_laughs

The vast majority of tools exists to optimize and scale your time. Very few tools beyond a compiler/linker are required for software development. Depending on the size of your project, taking the time to learn a tool or set it up may not be worth it. Setting up build scripts and CI systems may be totally stupid for one project, and essential for another.

The trick is to know when it makes sense to optimize your workflow and manual tasks with tools.

I dunno...The significant overhead is mostly because we attempt to latch on and leverage existing platforms and useful technologies...and so to complain about it would be like Isaac Newton, instead of appreciating standing on the shoulders of giants, complained how in the good ol days, pi was just 22/7.

Awhile ago, I tried to make a simple Chrome plugin that would let me filter Reddit IAMA's by dynamically hiding all threads that didn't involve the IAMA-host...simple enough to conceive it as a jQuery snippet, but I had to spend an hour learning how Chrome plugins worked, all of its conventions...and then about three hours digging up why inline click handlers were unaffected by my jQuery code (Chrome recently considered manipulating existing onclick events to be a security risk).

A total pain in the ass, considering that the code to solve the problem was "easy"...but I understand the tradeoff here...I didn't have to code my own web browser, and when playing with other people's browser environment, security can't be ignored. If I wanted to avoid these hours of learning about the Chrome ecosystem, there's nothing stopping me coming up with my own bespoke way (such as querying the Reddit API programmatically and re-constructing the iAMA as I wish on my own webpage), but that has its own tradeoffs.

I do think, though, that for novice programmers...the overhead must seem immense. It drives me a little crazy to see bootcamps attempt to teach non-programmers Rails. Yes, Rails is in demand, but for a long time, these novice coders think that running "rails new" is a prerequisite for every web project.

Agreed. This is why I recommend sites like Codecademy, Khan academy, etc, to just get started and see if coding is for you. Purists will argue that they're teaching you their way to code, but it at least gets your foot in the door in two important ways: getting over the hurdle of environment, and getting the syntax of the language. In my personal experience, teaching someone(very interested but with zero experience) to code without some sort of boilerplate already in place was very frustrating indeed. Only after several hours and lengthy explanations of what things are and why they are used later could the actual coding begin.

After completing enough of one of those options to grasp the syntax and language constructs, you can slowly introduce things like terminals, version management, environments, scripts, etc. As they wrap their head around each piece such that it's not in their way, they can get back to the coding that they're trying to focus on.

Everyone also has their own preferences. The author was stating how much harder a web app is vs. a mobile app, but I find exactly the opposite to be true.

Just pick your tools, learn them, get good at them, and then code for a long time before changing. Don't get caught in the trap of always needing to try the newest thing. Focus on your core purpose of delivering a product, and you'll find that even a non-ideal toolkit still gets the job done, and you can stick with it for quite a while.

http://www.thoughtworks.com/radar/#/

The assumption in this article is that you always have to be using the latest whiz bang tools and platforms, but that's up to you -- the "fashion" aspect of software development is the problem, not the tools per se.

SCM,Frameworks and such are part of the price we pay to be able to build larger and larger projects.

In any non trivial pursuit along those two vectors, complexity typically creeps in because more people are involved. Since more people are involved, this becomes a human organization. A human organization is not concerned with only the primitive activity to be done, but also what are the right approaches, methods, measurement, priorities, politics, scaling, learning, etc. Therefore, one cannot just be doing the primitive activity and ignore all of these higher level goals.

I am going to use an analogy: let's say coding is brick layering + painting + wall building + carpet + etc. and we are going to build a building. The worker says he just "wants to do work" but if we let her do that the building would be a disaster, unless you are just building a dog house. In which case the risks are low and a single person can do the work.

At the beginning (startup), one can just "do coding" because the problem is ill defined and an organization has not been established to manage the higher level work.

I wonder to what extent this mentality of "just want to code" is related to the (stereotypical) aversion of the developer as anti-social and introvert.

I'm curious if software development (in large organisations) will ever reach that level of specialization, where a coder will be able to 'just code', because others workers will be employed to handle everything else.

Unfortunately, the world of software development seems to have been pushed away from specialisation and each person knowing certian topics well, into 'everyone is just a resource - anyone can code' mindset.

Those environments have totally sucked, because to pigeonhole people into those roles in the first place requires a non-flexible, non-creative culture.

There is a proper balance to everything, but few organizations succeed in finding it.

I guess most people would only like to be the "head surgeon" because of the implied status (and not really knowing what it is like to be e.g. Linus Torvalds). But personally, I wouldn't mind doing a specialized job like the tools programmer or language lawyer because these are still interesting jobs allowing good forward progress to be made.

If the load of tedious work like build systems is too much, and the best we can do is either load-balance it across the team or dump it on some schmuck, maybe that just means we should try harder to break up projects into smaller units so that process doesn't completely dominate them.

What do you mean a source control person, just someone who manages the source control when it goes wrong? The programmers are still doing the committing, pushing, pulling, branching themselves

She hated that job, BTW. :)

Before any carpet or brick is placed, a foundation needs to be poured, but before that, a hole must be made, but before that, a machine must be purchased. Then, someone is going to ask: "how big should the hole be?" And the answer would be, "Whatever, I am just going to put these bricks on it."

and the whole thing just falls apart because nobody can just lay bricks.

Bear in mind that Brooks was mostly talking about his work on OS/360 at IBM. OS/360 wasn't a doghouse. IBM wasn't a small organization. His interest in reducing meetings wasn't caused by being anti-social, or having some antipathy toward management or PMs. It was caused by an interest in shipping products on time, which programmers are held accountable to do. (Consider that the next time you feel like accusing developers of being anti-social for wanting to get work done.)

Of course Brooks was discussing an idealized version of the problem, aimed at the essentials. But reality includes a lot of kinds of organizational bloat which really aren't necessary to software production goals, they're just hard to avoid in large organizations.

Say you are building a big house, and you can't wait for one person to finish it by herself, so you have to hire and manage and pay n workers and keep the pipelines full; so you need funding up front; long story short, you make a construction company.

Everything you're doing to scale up the organization encourages "leaks."

With more funding, more self-interested contention over where it goes, more fighting over who got it for the company, etc.

With more hiring, more competition among hiring managers to build empires underneath themselves.

With more management structure, more regulation and enforcement to justify and expand the management structure.

With more decisions, more attempts to influence or take credit for those decisions, and endless arguments down to useless bikeshedding. ('what are the right approaches, methods ...')

With more people, more internal social dynamics that become ends in themselves and change how the organization is steered and how resources are allocated in ways that often are actively harmful to the organization's stated goals.

Now relative to these real-world phenomena, does it make sense for software-producing organizations to see their chief risk as letting the programmers who know about code write the requested code as they know best how to do? Or to solve that "problem" with micromanagement, creating more and more barriers and distractions (and morale drains, and reasons to leave) for programmers?

Being anti-social is not really a developer stereotype. Being a pedant is, though. ;)

Whoah, waitaminnit...

At least some of those decisions can be deferred if you like.

You've decided on Git or some other SCM you're more familiar with. OK, fine. Nothing stops you from using it locally and deferring your decision on where to put a shared repo until later. Same goes for ticket tracking, continuous integration, testing, and so on. And if you want, just skip them for now. Heck, if you really want to, you can even defer using an SCM.

Nothing is stopping you from starting your project, building it privately, sideloading it into your personal device, and deferring almost everything else infrastructure-wise until later.

Yes, if you are building for iOS, you need XCode. If you are building for Android, you probably want Eclipse. But that's about it in terms of required infrastructure.

You almost certainly can 'just start coding' if you want to.

In fact, given that it is smart to 'build one to throw away' anyway, starting out by avoiding the initial overhead isn't necessarily a bad idea.

I didn't use any of those things while learning web/server programming. Just a laptop with Debian and Apache installed.

So the other day I wanted to learn a JavaScript client-side MVC framework. For various reasons I picked Ember. Suddenly, I had to spend a day playing with... Node.js (hey, I was trying to do client-side work!). Hundreds of megabytes of tools and libraries; package managers, web servers, a half of an operating system, just to generate a Hello World example in the way Ember documentation says is right (I also skipped the Ruby on Rails part). An example that, generated, had literally tens of thousands files and directories.

Now the question is, why on Earth do I need to install Node to play with client-side JS (that is supposed to work, like, in browser)? Why do I need to subscribe to a particular TDD-ish development regime? Why every project nowdays uses a random build tool written in/for completely unrelated programming language? I've recently seen C++ code for AVR being compiled and loaded by Scala build toolchain.

I get that some of this may be useful in large multi-team projects. But for small code written by one or few programmers? I feel it's only a distraction. I smell cargo cult.

It gets an enormous pass because programmers love programmer culture, and it's open. (Exactly like the lackluster Linux of the nineties being immune to criticism due to openness).

You know what a great workflow is? Vim, C, and a Makefile. C offers a far more conceptually complete model that isn't forced client/server. The C compiler does basic checks on my code (revelatory, for sure), and the Makefile, as horrible as the syntax is, can be added later.

If I'm teaching someone, they can open something like gedit, type some code in, and run gcc manually. Boom! A program to run!

Perhaps this is the authors problem in general: the trick to productivity is being able to quickly reach functional understanding of a tool/library you've decided to use. Enough to 1) evaluate the tool/library itself and 2) use it in a way that's at least somewhat conformant to how the authors intended. Obviously doing these two things requires good authors and good client programmers. However, if being a large body of work kept developers away from things you certainly wouldn't have a zillion apps on the iOS app store.

This is one reason I started to fall in love with javascript. I've been a longtime critic of the language, but I'll be damned if there is not an easier way to build, test, debug, and distribute code.

Growing up, I learned from MS QBASIC - which was an incredibly easy portal into coding. It is a shame no such things are commonly available today.

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.

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?

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.

No automated testing, no CI, no reasonable way of deploying code and certainly no rollback, who has time for such frippery? I left.

It's wholly unsuitable for anything professional, and it's wholly a joy.

I don't think these tools are all the same, at least as traditionally used. And you don't have to (ab)use all their features. Also, you don't have to use these tools at all.

But the original author more or less claims that you have to use git to get any community involvement.

And whatever community you ascribe to, you'll have to learn how to operate within it to get community contributions.

They're just tools. I shouldn't need to ascribe to "vim community" hosted on "vimhub" even if I wrote my software using vim (I don't).

Add'l note: Other hosts, BitBucket, Google Code, etc. also offer Git hosting. So, yes, choose whatever host you want, but choose and SCM that will make it easy for folks to contribute.

Now? This is not a new sentiment. In fact, it's older than I am. That may qualify it as a cliché.

What we need is a simple solution. I recommend bottle or flask. Documentation is available. Easy to start. A good community to work with for learners.

Will it scale? To Hell with that. No beginner should have to worry about that. They need to worry about first principles. Then work their way up.

Most people I've talked to at this level, they are so far away from being "technical" that HTML/CSS is already a huge (unavoidable) hurdle and the simplest thing I can imagine is PHP + FTP. If they get on an FTP client that mimics the GUI of a folder system, people get it real quick - they are copying this local file to another folder on the server. To me, the quicker you can get them to deploy something the better. because the first steps are to understand how information is sent to your app, understand that it's your apps job to make sense of that information and return a response.

I also tell them to get a cheap standard shared host, so most of the apache is transparent to them anyways. When they get to the point of needing to customize apache, that's an incremental step from where they have already gotten

"IDE support is immature." Response: well, true, but you don't need an IDE. Java makes IDEs mandatory because it's a crappy, verbose language. Scala doesn't. Clojure especially doesn't. Haskell doesn't (although convincing that company to move off the JVM would have been impossible).

"Where are the refactoring tools?" Response: when you have good static typing, the compiler is far better at enforcing refactoring safety than any tools on the market. (Java itself combines the worst of static and dynamic typing.)

People-- especially non-programming managers-- have become dependent on the trappings of productivity that they've forgotten what actual work looks like. Java culture is full of this nonsense. The business becomes so dependent on a convoluted toolchain that it doesn't need for most purposes.

Then there is the myth of the "full stack developer". It's a good idea in theory, but no one knows what it means. It's just management "at the end of the day, it's all about leveraging our core synergies" bullshit. What's really going on is that execs and professional managers can't evaluate the work in most specialties, so they've decided to pretend that specialties don't exist. All types of programming get thrown together into "it's all code; just make the thingy work" and what that means is that programmers get stuck cleaning up any kind of technical mess they have the bad fortune of having thrown to them. The result is that a good number of programmers (those who aren't savvy enough to play the game and be selective in what work they do) end up learning a bunch of crappy, parochial, non-transferrable "how we do things here" details but (a) never get a coherent career or develop the ability to protect a specialty, and (b) are constantly learning "new" but ill-thought-out and incoherent things.

For what it's worth, I used to think that this was a "new" problem, or a symptom of the industry getting worse. I'm not so sure that it's very new. Maintenance programming, 20 years ago, was the same slog that it is today. If anything, the situation is getting better. I agree that Git is not user friendly at all, but the damn thing works, and it's far better than other VC tools (e.g. Perforce).

Clojure is in a different situation though, but that's because its type system, or lack thereof. Just like in Javascript, people end up falling back to REPLs and other such primitive tools, because the IDE just can't tell you very much about your code. Code is data is not a strength, but a double edge sword.

As for Git's usability, yes, it's not very good, which interestingly seems to be a key reason of why it has so many advocates: it forces you to understand a whole lot of internals to be proficient at it, and while git's command line interface is pretty ugly, its internals are elegant. It's kind of the opposite of what happens with Mercurial: It's easier to start working with it, so people don't look into it long enough to fall in love and start advocating.

What I really find interesting about this whole 'let me code' thing is that, while I really don't want to spend valuable mental space dealing with a complex environment, I do not want to use it instead on code, but on figuring out what is the right code to write. We obsess over the mechanics of coding, over our tooling, but what really matters is that we are actually solving the right problem.

I spent some time this month with some code written by my predecessor at this job: A well known library designer and speaker. He had looked at a hard problem, wrote a proof of how to solve it, and wrote a mathematically correct implementation matching his paper. The problem is that his premises were incorrect: He failed to account for some unavoidable issues. That made his last 4 months of work here a waste because he was just solving the wrong problem.

I want to spend less time coding, and more time making sure that the coding is actually solving the real problem at hand, not an incorrect idea of the problem.

Web programming is now, too. Look around at job postings for frontend dev positions and you'll see basically just lists of fashionable tools, e.g. "Grunt, Bower, Angular, Phantom, Karma, Jasmine..."

(To those used to such things, you will find something tremendously freeing if you drop down to using no language specific tools but the compiler/interpreter).

And that's what most of people bashing IDE's don't get: it's the ease debugging that's important, not typing code!

Which wasn't my original point really.