Build all the things! (and wait for it to fail)

Continuous integration is a great concept.  Within a few minutes of making a change, you can get quick feedback about potential problems with your change.  You can run unit tests, which helps spot problems internal to your module.  You can run integration tests, which helps find problems between your module and any modules you depend on.  You can run static code analysis to attempt to find bugs in your code.  How about code complexity analysis, or dependency analysis, or a build violations checker.  Well, as long as those run fast, I guess, maybe.  How about installing your war file into Tomcat, starting up a browser and running a browser automation tool to validate that it still works.  Hmm....this is starting to be a lot.  What ever happened to quick feedback?

Oh, you want quick feedback?  Then we can just at a time limit to your Jenkins job, so if it runs more than 9 minutes, then your job fails?  How about that for quick feedback!  Well, if my jobs are going to fail because too much is running during the builds, I can just reduce what runs in those builds.  Brilliant!  What....I don't actually have access to reduce the number of things that occur during the build?  The team that mandated that builds fail after 9 minutes is the same team that mandates that all those build steps must be done?  The same team that gives us a Jenkins instance that 10 executors and a backlog of 60+ items at all times?

When you try to measure everything, you end up measuring nothing.  This is my life.