6 ms·

Flexibility is not something I want in a build system. I want predictability and simplicity. "Flexibility" just means that the dumbest guy on the project will

by bborud 9y ago

Flexibility is not something I want in a build system. I want predictability and simplicity. "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later. That being said, "flexibility" is not special to Gradle. As long as there have been build systems there have been people who are too lazy to learn them and get "bright ideas". For instance I have no idea how many shellscript-infested build setups I've seen for C programs that could easily have been built using entirely standard Makefiles. If the author had bothered learning to use Makefiles.

kodablah 9y ago
> Flexibility is not something I want in a build system. [...] "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later. We're on opposite sides here. I can control my team wrt rope and what not. But it's very hard to wrangle a build system to perform some advanced task you need without flexibility. I'd way rather have problems with the build system users than the build system authors. One is more easily fixable.
- freedomben 9y ago
  I agree. With an inflexible build system we still end up with the nasty shell script but it's worse because it wraps the build system.
  - Pxtl 9y ago
    Maybe combine a generic non-language specific build system (some variant of Make without the C obsession?) as the outer wrapper around a very language-oriented and inflexible/opinionated build system?
    - flukus 9y ago
      > some variant of Make without the C obsession Make doesn't have a C obsession (although the docs do), make works anywhere you have a dependency graph that can be expressed as a file timestamp. Here's an example compiling a c# project: http://flukus.github.io/rediscovering-make.html http://flukus.github.io/rediscovering-make.html . It's much simpler than any .net build tool (and I've tried them all).
      - tigershark 9y ago
        Either you have a very strange concept of simplicity or you never tried Fake.
        flukus 9y ago
        That's one I haven't looked at much, but can you show me a fake script that does the equivalent of my example? That means a fully incremental build, generating version files, etc. Even things like the version file tend to turn out more complicated in most build systems because they come with a half assed reimplimentation of unix tools From a quick look t looks like it's task based instead of output based as well, so an incremental build doesn't look simple. Correct me me if I'm wrong, but it looks like it's trying to be a better nant, not a better make.
- madmax96 9y ago
  I've experienced this myself in a number of different environments. But I'm still not satisfied with the results with the more flexible tooling, usually. I think it's because they commonly lack scaffolding that I want a majority of the time. The older I get, the more I realize that the lisp DSL approach is probably best: provide a simple, declarative walled garden. If I want to change something for my project using the full language, let me, and may the PR reviewers determine my fate. Ruby also seems to adhere to this philosophy, although I don't have a lot of experience with it.
  - kodablah 9y ago
    > may the PR reviewers determine my fate Confused here. I can't really stop progress waiting on build system features. Extensibility is required like a programming language. Otherwise, you must stop using the build system or build wrappers around it or outside of it making your build even more bespoke than if you used a more flexible system.
    - bonesss 9y ago
      That's my issue: missing build system capabilities leaves me writing console apps to make builds sane. If I'm writing code anyways in MyLanguage to compensate for MyBuildScript, why aren't my build scripts written in MyLanguage?
  - bonesss 9y ago
    > I'm still not satisfied with ... more flexible tooling ... they commonly lack scaffolding that I want a majority of the time. I think this dichotomy, flexibility vs maintainability, reflects build complexity. Not only do I think the same-language-DSL (a la LISP, as you pointed out), is the 'least bad' choice, I think if we raise our gaze a little the answer here is painfully obvious: how do we handle those issues everywhere else? In other cases if you need to move files, call some sys commands, structure some data, and express some logic? What if you have to call a webservice with some throttling logic, where is your "build language"? Plop something in a DB? Not to mention that complex builds often have specialized command line apps called by their specialized build langauge.... why? Complex logic we use programming languages for. Why sacrifice power, components, libraries, compiler-time-checking, and all the rest to use a lesser tool? Full language power, it's The Right Thing.
- Yeroc 9y ago
  You're assuming that you're around when the team is building out said system. What if you have the misfortune of inheriting a system where there was plenty of rope to go around?
  - kodablah 9y ago
    Still better than having to abandon the build system altogether because it can't do what I want (or work around it which is often worse than leveraging flexible environments in the first place).
- andrewaylett 9y ago
  At least in Maven, the answer here is simple: write your own plugin. You can do whatever you want, but you're still operating within the confines of the build system so you've not lost the ability to see what's going on. It's not all that common that I see an "advanced task" that actually belongs in the build, though -- more often I see people who have decided to fight against their tooling rather than working with it.
- bborud 9y ago
  Perhaps you can control a team, but how many people do you think you can "control"? Could you control every developer in a division? A company? And how do you onboard new people if any past experience with build systems is worthless because they have to learn how you do your particular build? And if you find yourself consistently not being able to build a piece of software with a relatively simple build process, perhaps you are trying to do too many weird things?
deleted 9y ago
[deleted]
acdha 9y ago
> "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later. In my experience, it's not dumb but clever which you should worry about — those are the ones who'll spend two weeks making something completely unmaintainable after reading someone's post about how some esoteric mathematically pure style delivered a 7% performance increase on an edge case.
- bborud 9y ago
  "Clever" is just a polite way of saying "dumb" :-)
  - acdha 9y ago
    It's a different concept — closer to the difference between intelligence and wisdom. Someone who is cleverer than they are wise can go a long way before recognizing that the approach they're taking isn't cost-effective, especially if it gives them some point to feel proud about doing something which (correctly or not) they feel most other people couldn't.
lmilcin 9y ago
Lack of flexibility means that it will only work for xx% of projects (supply an arbitrary value for xx but other than 100, by definition). Then what it means, is that 100-xx percent of projects are going to be screwed up. Not everybody lives in a nice world when the project is a single web application with 4 microservices and a shared library maintanied by a team of 5.
- bborud 9y ago
  Out of those xx% of projects, how many really need the flexibility? Based on the last 30 years or so of being a developer, I would be tempted to believe that it would be in the low single digits. It is sometimes worth it to spend a little extra time as you set up the build process, and as you make decisions on how to organise things so they can conform to a build process other people will understand. Quite often "clever" builds on long-lived projects, or projects with many developers, have a higher cost in terms of effort than what you save on "clever" shortcuts.
pleasecalllater 9y ago
Well, if you will allow such a guy to operate alone without any code review, then I'm sure you have much more serious problems in the code, than a build system.
- bborud 9y ago
  Most complex build setups I've seen in the wild the last 5 years were made by teams that have mandatory code reviews of all code. This isn't so much about review or not as it is about not establishing a culture where you always take the easy way out. It is tempting to think that "this will be solved through the magic of code reviews", but if you are in charge of several teams and you have to face the reality of projects living on for years with people joining and leaving the team. It is important to have empathy with developers and your future self. Much build complexity and annoyance is due to people taking the easy way out, for instance, by scripting things that should either be adapted to make use of an existing build process, or develop a proper plugin that is documented and helps newcomers to the project understand what is going on. If you make it easy to make ad-hoc solutions, people will build ad-hoc solutions.

by bborud 9y ago

kodablah 9y ago

> Flexibility is not something I want in a build system. [...] "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later. We're on opposite sides here. I can control my team wrt rope and what not. But it's very hard to wrangle a build system to perform some advanced task you need without flexibility. I'd way rather have problems with the build system users than the build system authors. One is more easily fixable.

freedomben 9y ago
I agree. With an inflexible build system we still end up with the nasty shell script but it's worse because it wraps the build system.
- Pxtl 9y ago
  Maybe combine a generic non-language specific build system (some variant of Make without the C obsession?) as the outer wrapper around a very language-oriented and inflexible/opinionated build system?
  - flukus 9y ago
    > some variant of Make without the C obsession Make doesn't have a C obsession (although the docs do), make works anywhere you have a dependency graph that can be expressed as a file timestamp. Here's an example compiling a c# project: http://flukus.github.io/rediscovering-make.html http://flukus.github.io/rediscovering-make.html . It's much simpler than any .net build tool (and I've tried them all).
    - tigershark 9y ago
      Either you have a very strange concept of simplicity or you never tried Fake.
      - flukus 9y ago
        That's one I haven't looked at much, but can you show me a fake script that does the equivalent of my example? That means a fully incremental build, generating version files, etc. Even things like the version file tend to turn out more complicated in most build systems because they come with a half assed reimplimentation of unix tools From a quick look t looks like it's task based instead of output based as well, so an incremental build doesn't look simple. Correct me me if I'm wrong, but it looks like it's trying to be a better nant, not a better make.
madmax96 9y ago
I've experienced this myself in a number of different environments. But I'm still not satisfied with the results with the more flexible tooling, usually. I think it's because they commonly lack scaffolding that I want a majority of the time. The older I get, the more I realize that the lisp DSL approach is probably best: provide a simple, declarative walled garden. If I want to change something for my project using the full language, let me, and may the PR reviewers determine my fate. Ruby also seems to adhere to this philosophy, although I don't have a lot of experience with it.
- kodablah 9y ago
  > may the PR reviewers determine my fate Confused here. I can't really stop progress waiting on build system features. Extensibility is required like a programming language. Otherwise, you must stop using the build system or build wrappers around it or outside of it making your build even more bespoke than if you used a more flexible system.
  - bonesss 9y ago
    That's my issue: missing build system capabilities leaves me writing console apps to make builds sane. If I'm writing code anyways in MyLanguage to compensate for MyBuildScript, why aren't my build scripts written in MyLanguage?
- bonesss 9y ago
  > I'm still not satisfied with ... more flexible tooling ... they commonly lack scaffolding that I want a majority of the time. I think this dichotomy, flexibility vs maintainability, reflects build complexity. Not only do I think the same-language-DSL (a la LISP, as you pointed out), is the 'least bad' choice, I think if we raise our gaze a little the answer here is painfully obvious: how do we handle those issues everywhere else? In other cases if you need to move files, call some sys commands, structure some data, and express some logic? What if you have to call a webservice with some throttling logic, where is your "build language"? Plop something in a DB? Not to mention that complex builds often have specialized command line apps called by their specialized build langauge.... why? Complex logic we use programming languages for. Why sacrifice power, components, libraries, compiler-time-checking, and all the rest to use a lesser tool? Full language power, it's The Right Thing.
Yeroc 9y ago
You're assuming that you're around when the team is building out said system. What if you have the misfortune of inheriting a system where there was plenty of rope to go around?
- kodablah 9y ago
  Still better than having to abandon the build system altogether because it can't do what I want (or work around it which is often worse than leveraging flexible environments in the first place).
andrewaylett 9y ago
At least in Maven, the answer here is simple: write your own plugin. You can do whatever you want, but you're still operating within the confines of the build system so you've not lost the ability to see what's going on. It's not all that common that I see an "advanced task" that actually belongs in the build, though -- more often I see people who have decided to fight against their tooling rather than working with it.
bborud 9y ago
Perhaps you can control a team, but how many people do you think you can "control"? Could you control every developer in a division? A company? And how do you onboard new people if any past experience with build systems is worthless because they have to learn how you do your particular build? And if you find yourself consistently not being able to build a piece of software with a relatively simple build process, perhaps you are trying to do too many weird things?

deleted 9y ago

[deleted]

acdha 9y ago

> "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later. In my experience, it's not dumb but clever which you should worry about — those are the ones who'll spend two weeks making something completely unmaintainable after reading someone's post about how some esoteric mathematically pure style delivered a 7% performance increase on an edge case.

bborud 9y ago
"Clever" is just a polite way of saying "dumb" :-)
- acdha 9y ago
  It's a different concept — closer to the difference between intelligence and wisdom. Someone who is cleverer than they are wise can go a long way before recognizing that the approach they're taking isn't cost-effective, especially if it gives them some point to feel proud about doing something which (correctly or not) they feel most other people couldn't.

lmilcin 9y ago

Lack of flexibility means that it will only work for xx% of projects (supply an arbitrary value for xx but other than 100, by definition). Then what it means, is that 100-xx percent of projects are going to be screwed up. Not everybody lives in a nice world when the project is a single web application with 4 microservices and a shared library maintanied by a team of 5.

bborud 9y ago
Out of those xx% of projects, how many really need the flexibility? Based on the last 30 years or so of being a developer, I would be tempted to believe that it would be in the low single digits. It is sometimes worth it to spend a little extra time as you set up the build process, and as you make decisions on how to organise things so they can conform to a build process other people will understand. Quite often "clever" builds on long-lived projects, or projects with many developers, have a higher cost in terms of effort than what you save on "clever" shortcuts.

pleasecalllater 9y ago

Well, if you will allow such a guy to operate alone without any code review, then I'm sure you have much more serious problems in the code, than a build system.

bborud 9y ago
Most complex build setups I've seen in the wild the last 5 years were made by teams that have mandatory code reviews of all code. This isn't so much about review or not as it is about not establishing a culture where you always take the easy way out. It is tempting to think that "this will be solved through the magic of code reviews", but if you are in charge of several teams and you have to face the reality of projects living on for years with people joining and leaving the team. It is important to have empathy with developers and your future self. Much build complexity and annoyance is due to people taking the easy way out, for instance, by scripting things that should either be adapted to make use of an existing build process, or develop a proper plugin that is documented and helps newcomers to the project understand what is going on. If you make it easy to make ad-hoc solutions, people will build ad-hoc solutions.