maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <>
Subject Re: evangelising maven from the business benefits point of view
Date Sun, 08 Apr 2007 13:22:13 GMT
Jerome Lacoste on 18/03/07 19:13, wrote:
> On 3/18/07, Adam Hardy <> wrote:
>> I want the software house where I work to go to the next level with maven 
>> from where we are at the moment, which is a case of gross 
>> under-utilisation. We use maven as a glorified ant script to run tests and
>> build jars.
>> There are several other projects in-house which have not been mavenised
>> but could be, there is a great opportunity to implement maven's release
>> cycle management, and the need for configuration, filtering and profiles is
>>  huge.
>> No-one on the project management side though has much interest in all the 
>> reports, the QA, test coverage, continuous integration or release 
>> management. I have a meeting with a chief PM lined up and I have to present
>> hard data in terms of developer-days saved if we put maven into place.
>> What is the best way to nail down potential future gains from mavenization 
>> into easily grasped cost savings? Are there any good stories out there on
>> this sort of stuff? Does anyone have some experiences they would like to
>> share in this area?
> Introducing a new technology will always incur a cost. And resistance to
> change. So focus on the maven benefits and on the strategy to make these
> changes happen.
> Maybe can you start moving all projects to maven then improve your use of
> maven. Or maybe you should start. Probably a mix of both.
> * on projects not using maven. Compare them to those using maven. If maven
> is already helping, and people in the team already recognize the benefits,
> then this case is easier to argue. Further, you reduce the amount of
> technology used across projects making it easier to move people around (or
> when you take in new employees), or have site technology champions. Try to
> first migrate the projects which are related to the ones that already use
> maven (maybe because they use similar, or they share a pool of developers,
> or are on the same network and share the same development server).
> * on projects already using maven, you identify the gap doing 2 things:
> ** for each plugin listed under and, see
> if you're using it. If not, estimate what would be the cost of introducing
> it, how often you would use it and what it would bring. Select the 4-5 most
> relevant plugins. I guess the release one should happen there.
> ** look at your process, and identify areas where automation/uniformisation
> would help. The plugin might exist, but it may not. Where do people make
> recurrent costly errors (during development/deployment/maintainance/...)?
> Can those be detected ? Think how you could make this part of the build.
> * identify one project and start adding the things yourself. Don't start
> with a too big of a project. Do this on your own time if you don't get
> approval. Make it in a branch if necessary. After some weeks, compare the
> before & after states. Be objective. Still for each costs look if these
> costs would go down if you were to share them across projects. If the boss
> is not happy for you to taking initiative, consider that you at least
> improved your own knowledge.
> * Look at indirect savings. Do they have problem to hire the right people ?
> Do people leave because they feel they don't learn new things? Is the
> motivation low because of problems that this change could address (at least
> in part)? Etc...
> 3 last things:
> * identify the right people to convince. Sometime to convince your boss you
> have to convince the right coworker. Or a respected person in your company
> * know the person you are talking to and identify the words he wants to
> hear.
> * be patient.
> Hope that helped. And come back with a summary of how it went !

Just a quick note as a follow-up to the discussion above. I put together a 
presentation detailing where I thought maven would be useful and why, putting 
forward many of the points above, illustrated by rough estimates of time and 
resources involved or saved, and management benefits.

On the whole all points were well understood and the dept will definitely 
implement a couple of the proposals immediately, but the majority of the 
mavenisation is something that may or may not happen over the long run, 
depending on the ability of the managers to devote time to developing the maven 
/ agile environment.

What would have been very useful and what I didn't have because I'm a consultant 
who has only worked there for a few months, is a few examples of set-backs in 
the company that maven would have prevented.

The managers are IMHO far too accepting of the seat-of-your-pants approach. The 
additional start-up effort of mavenisation, learning the code quality statistics 
and imposing the paradigm all seem a bit too much work, on top of the everyday 
fire-fighting that they are involved in. I think the fire-fighting will have to 
get more painful before any wholesale changes are made, but perhaps being 
optimistic there may be a gradual implementation of more and more mavenisation 
over the coming months.

Thanks for the initial advice,


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message