It’s very easy to get in your own way. You have the vision, you know what you need to execute on that vision. However, it’s too much work for you to handle alone, so it’s up to your team to deliver on that. You’re going to be quite frustrated at times and believe that you’re better placed to deliver certain aspects of it. So you opt to get involved at the coal-face and handle certain parts of the deliverable yourself. Is it because you want something interesting to do, want to retain your technical edge or is it because you don’t trust your team.
You have a vision that is pretty clear to the technical team and you’re all working towards that goal. The business has bought into the vision previously and they’ve given you the mandate to work on the vision and goal. The next thing that is bound to happen is that the market direction changes or market research shows some different problems that need solving.
These days we’re consumed with the new; always looking to get rid of the old in favour of something that’s newer, brighter and shinier. It’s very obvious with consumer electronics and the built in obsolescence that comes with almost every single product on the market. The pace of change, Moore’s law, all support this kind of behaviour; my watch has more computing power in it, most likely, than the ZX Spectrum that was my first computer.
Are Maven’s opinionated conventions all that useful for any semi-complex build environment?
We use Apache Ivy as our dependency management tool of choice; backed by an installation of Sonatype Nexus. Recently, due to a restructure of some internal projects we’re using Maven to publish (some) snapshot artefacts into our nexus repository and then referencing them when the time comes to generate our nightly downloads. You’d think this would be a relatively simple thing to do, but it was really much harder than it should have been.
The cost of a new integration is outweighed by the cost of maintainence
When we first started building Interlok we had a very clear design goal; it’s about the lowering the cost of maintenance as opposed to lowering the cost of new development. It’s simply a happy by-product of our design goals that the cost of integrating a new system is lowered as well. When faced with a classic integration problem; whether or not it’s customer facing or just integrating various back-end systems; once you have the process up, running and in production; the maintenance of that integration is going to be the major cost factor.