Working on a Java project for the past year has taught me some things about projects in general. This point is important because I think we tend to become too comfortable with a single development stack and its set of best practices, that when we switch over to a different stack with different, or incomplete, best practices we get lost and do things in mysterious ways.
Be an expert in the field
Going into a new project with unfamiliar tools and libraries, you need to find out who is the expert or become the expert yourself. Justify your recommendations but be prepared to accomodate with your open mind. Regardless of the project timelines there is always a chance to change things up, especially for internal servers and applications.
Don't fight the system
Most tools have their own ways of doing things, so do it the way it wants to do it. On Ensemble, Faran spent the best years of his life trying to get it to do things in the way he thought was great (and to be fair it was a great way to do it). Unfortunately Maven thought otherwise and it gave him gray hairs that he has since dyed back to black. Once he discovered how Maven does things he easily got the projects set up and working as he had imagined it.
Get it right the first time
Easier said than done, especially when almost every technology choice is driven by the client. Even with this restraint, we should be able to make good choices about things such as project (code) structuring and team goals. Things like continuous integration and automatic deployments should be considered up front and made a part of everyone's responsibility, not just that of the DevOps representative.
Having been in a DevOps role for the first time in my career, I can say that it has been both the most interesting and frustrating role so far. It's surprising to me that this type of role is only starting to be developed now, after having so much time wasted communicating with an IT department that doesn't know exactly what a development team needs. I'm not saying that IT is incompetent (ours is great), but there can often be wildly different needs even between development teams within the same project. We should spend just a bit more time defining the DevOps role, and while not every project needs one, every developer team should go into a project with this mindset.
After all, more and more time is being spent configuring an existing system or application framework than coding one. Ensemble just happens to be an exception.
I wear my gray hairs with pride :-)
ReplyDeleteJon is correct that fighting maven was a bad idea.
Manny asserts that my grievances are not isolated and that many people have moved to Gradle due to similar circumstances.
I have since learned, from people more knowledgeable about the Java development universe, how to utilize maven plugins to achieve my ends. These extension points are available for you once you learn the lay of the land.
The thing about Java and it's ecosystem is that there's no one best way to do something and no arbiter like Microsoft picking the best practices. Much suffering has gone into what we see today and all we can do is make our own mistakes towards an unknown end.
It's the journey that matters.