Gradle Review

Gradle

Gradle is a build tool, I personally use it to build some old java projects but it can do other things.

I've given it a chance now so feel I can blog about it.

I like, no I love the idea of Gradle, however the implementation isn't good enough :(

It's not that it lacks features, quite the opposite there are so many that the basic set have been neglected in favour of the more fun stuff.

Essentially there needs to be another layer to add simplicity, you need to know too much about the internal workings of the system for it to be all that useful to build systems that already exist.

It probably works well on basic systems, and if starting a new system you can adhere to all the rules it'd probably rock, but for making existing builds better it becomes an uphill struggle where the benefits are sadly overshadowed by the difficulties in getting there.

If there was more IDE support then it would probably be far easier and I would be writing a totally different blog but until it is my opinion stands.

Specifics on whats wrong

I have a legacy system that I am trying to move away from using Ant, as is always the case the build has become incredibly over-complex which means an incredibly verbose xml build file and many workarounds for the immutable nature of ant.

I like the idea of being able to use actual proper code in the build when some conditional stuff is required, ant wholey fails on this count by forcing you to make custom tasks e.t.c. for very obscure conditions rather than allowing quick in line code.

I create a set of jar files from a particular project, I am using the 'java' plugin which gives me some handy stuff, but goes too far!!  It gives me a default jar of all of my code which I don't want and using what seems obvious to switch it off 'jar.enabled =false' seems to have no affect.  The suggested alternative was
configurations.runtime.with{
  artifacts.remove artifacts.find { it.archiveTask.is jar }
}
YUK! this is forcing me to know about the internal workings of the thing I want to use, which is wrong.  I don't want to spend ages learning about a damn build tool I just want my source to go in one end of a black box and have my compiled jars pop out the other end.  I mean I use my car and tv to perform the tasks I want adequately yet I don't need to know what's going on inside in order to do so.  To me this is where the design of the api starts to fall down.

I used another plugin 'ear' which helpfully created a packaged ear file, I needed an exploded one but there seems to be no simple way to stop the ear being zipped up, yes I could add a doLast() to unzip the ear but come on seriously why would I waste time zipping to begin with!

UP-TO-DATE
The idea of an up to date check sounded like the best thing ever, you have a task tell it what the inputs will be, what the outputs will be and when there has been a change the task is run, yet if the system hasn't changed the task isn't run thus saving tons of unneeded build work.


Yes it does sound like a good idea but it simply doesn't work.  I currently have a jar that is part of an ivy repository that is downloaded and unzipped.  Therefore the task to do this has the zip as an input and the output dir as an output.  This task never runs as it is ALWAYS up-to-date, I've created the output dir and put stuff in it, I've altered the source zip, I've even added an upToDateWhen closure and this is never triggered Gradle simply responds that the task is up-to-date.

More overengineering

Another thing that simply wound me up about Gradle but I was prepared to deal with on the assumption that the rest of the sales rhetoric was at least vaguely truthful was the dependency mechanism.  There are already tried and tested dependency mechanisms, my project used to use Ivy so why can't Gradle just use Ivy?  As far as I have discovered there is No benefit of gradle dependecy management over ivy!

Conclusion

I really like the idea of Gradle and when I went through the typical hello, world tutorials it all seemed nice.  It's only when you want to deviate from the path of what the originator of Gradle deemed to be the route to take that you realise just how hard it is to use.

There is a lot of documentation, there is a host of helpful people (and unhelpful) that are willing to offer assistance.  This is all brilliant and I commend those that are involved with it.  This article does sound like a bit of a downer on Gradle which I don't want it to be because I believe it'll be fantastic one day, however it isn't yet and it would appear that more features are being added rather than sorting out the current failings which could end up turning Gradle into unmanageable bloatware like so many tools (maven) that have come before it.

For me the ideal build tool would be nothing like what has gone before, no fancy convention over configuration none of that just a set of libraries for dealing with typical build-like tasks (file copying, dependency resolution, compilation...) and let whomever needs the build use it however they want rather than attempt to steer them in what I believe to be the right direction because with legacy there is no standard way these things have been done and the time to convert them cannot be justified, it's just a build tool!

Random Thoughts on deadlines

I've worked in several places where deadlines are tight, who hasn't. Management can help, but they can also hinder so I thought I'd sketch out my ideas of what helps the most and what destroys any chance you may have had in producing a deliverable.

A quick word on methodologies, Agile is great it is fantastic to never lose sight of the actual goal and having weekly sprints whereby a result is actually seen by the major project stakeholder is ideal...however there is a tendency for management types to see a product with the bits they liked that week and can't make the intuitive leap that although those features work the product as a whole is incomplete and so it gets sold.

Also there does have to be buy-in from the ground level all the way up when going agile, if the guys up top are still requesting requirement documentation and things they've missed the point and many of the benefits of agile will be lost.

So back to the issue of deadlines, number 1 is where the deadlines come from, if it's a sale date then how was it decided. More than likely it has been decided by a salesman whom has no clear knowledge of what the solution entails let alone how much work is involved or the resources that will be available, with so many unknowns it's no wonder that the deadlines are incredibly unrealistic.

A clever manager when faced with a, lets say it, stupid deadline, will gather his troops garner opinion from the experienced developers that will after all be sweating buckets to meet the deadline, then and only then will they be able to judge the loading of the team members and produce a realistic, yet usually very tight deadline. If an adjusted deadline from someone with more knowledge is ignored you can pretty safely say it won't be met. Not only will the deadline not be met but because of it's unrealistic nature the psychology of the developers will reach a point of "it's not possible so why bother" this causes projects to actually go slower than if the deadline had been set more reasonably to begin with.

The Carrot or the stick.

Software developers are a lucky breed in that their skills are 100% transferable this means when pissed off they simply jump ship. Too much pressure they jump, not enough money they jump, no respect they jump and bored they jump. Keep the good guys happy and a good supportive team is created. If developers want to do well then they will, if they feel forced or coerced into doing something they feel less inclined to do they won't do well and once again are likely to jump ship.

The same goes for managers to be honest, barking orders makes developers dig their heels in, yet if a developer doesn't want to let the manager down they work harder, this level of respect isn't automatic nor is it bought with bonuses it is developed over time and yes it takes work. Shouting or berating the very people that are doing the actual work is never going to work, trying to pile on more pressure is also never going to work. "what you mean the developers won't work harder for this crust of bread!" it is sad that even to this day there is a falsehood touted that people work harder when they feel their jobs are under threat, that just makes them dislike the job and guess what they leave!

Now the carrot, I've seen bonuses work in the past, usually bonuses on a sliding scale make the damn near impossible to reach deadline have a high bonus then give a far smaller one for meeting the previously thought of unattainable one. Lets face it salesmen get bonuses for landing big sales that sometimes are a result of them enjoying a visit to the pub with the right people. I am not saying sales isn't hard and that the tough ones should be rewarded but they all agree some accounts are easier than others, to the point of not being work at all.

Now the reason that neither of these should be used anyway is that once the stick is used developers bugger off and once the carrot is used too often developers come to expect it and when they don't get it they bugger off! Plus there is of course the product and the customer to think about. At the end of the day the only way an unrealistic deadline is going to be met is if corners are cut. The first thing to go will be the documentation, then the level of testing then the standard of features, then the number of features until eventually a pile of crap the customers didn't want is given to them they complain and either the whole lot needs to be re-worked thus taking us to a point beyond an original realistic estimate or the customer throws toys from pram refuses to pay and maybe sues. This is scary but true.

Estimates

It all starts to go wrong from the moment an uninformed guesstimate of a deadline is given and the recipient believes it.

So how are the estimates made and how can they be so wrong?

It's all to do with the number of unknowns, or variables when estimating, the simpler the item being created the fewer variables and hence the more accurate the estimate can be. Most large sales have countless variables, not only that but they also have unexplored avenues. What I mean by this is that if nothing similar has been created by the team there will be a certain amount of trial and error with their solutions this is perfectly valid and by taking the software through this sort of evolution means that the best solution should be arrived at. The trouble is you don't know that one avenue of development is necessarily better than another for your particular problem given that you've never seen anything similar and the number of avenues can almost exponentially increase the number of unknowns of development.

To explain lets take a chess game as an example, the solution we seek is to checkmate the opponent we start with 20 possible moves at the beginning, that's 2 for every pawn and 2 for each knight. Depending on which move or avenue we investigate next determines the number of possibilities we have next and at this point we're not sure that the one we take is going to help us reach our goal we take an educated guess but we may well need to backtrack to this point before a solution is achieved.