Skip to content

Instantly share code, notes, and snippets.

@mikey179
Last active December 30, 2015 03:39
Show Gist options
  • Save mikey179/7770854 to your computer and use it in GitHub Desktop.
Save mikey179/7770854 to your computer and use it in GitHub Desktop.
Some thoughts on build tools and application builds

If your application requires a build tool, there's something wrong with your application or the runtime environment of the application. For some that might be quite a controversial statement. What do I mean with it? In order to be able to run an application, the list of steps to fulfill should include just three steps. The first step is to get a checkout of the application from your source code management system (or download it to a local folder, this should require a single command line instruction only as well), and the last step is to start the application.

Now there is a single step left only. And this step should not be running a build tool which does hundreds of things in order to get a running application. Your application should be runnable right after checkout, the only thing that is allowed to miss are any dependencies the application is build on. So the second step should be fetching the dependencies. Nothing more. You don't need a build tool for that. A simple dependency manager is just enough to accomplish that.

Now you might say this sounds like a nice idea from someone who has never created big projects. In fact, I was and am part of different big projects and experience those and their hassle in my work environment on a daily basis. Actually that's one of the reasons that led me to this conclusion. Another view on that is the natural evolution of mastering programming skills:

  1. Can I do this?
  2. Can I do this more easily?
  3. Can I do this more elegantly?
  4. Can I not do this?

In our current programming environments we are mostly somewhere between stage 2 and 3 regarding builds, but I like to look forward. We will find ways not to require a build. In some languages I think we are on our way to get to stage 4, these are mostly dynamic languages. Sure, it is much harder to have no build when you need to compile your source code before being able to run it, but I count this as a deficiency of the environment where the build is a workaround for this deficiency.

Actually I think there's a similarity to design patterns. In some of the more recent languages the implementation of a design pattern is not particularly useful, as the feature is already build into the language and you just use it instead of building it yourself first. So the evolutation shows that we are heading towards stage 4 with design patterns. Having a build could be considered as some kind of a design pattern. We need to find ways that we don't have to do it any more.

Additionally, there's another point why we need to get rid of build tools and application builds. They just consume so much resources, resources that we could better spend for solving business problems. Actually, that's what application developers are supposed to do: solving business problems. Administrating a build normally doesn't solve a business problem, it just solves a problem of our technical environment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment