The idea that the business should learn IT is typical of technical people and completely misguided

Some time ago I wrote the following:

“The idea that the business should learn IT is typical of technical people and completely misguided” (Ron Palmer)

Yes, but then please don’t complain. Go away. You are talking about stuff you do not understand and I can’t take you seriously.
There is a Dilbert cartoon where the Pointy Haired Boss is doing a project estimation; claims that everything he doesn’t understand is simple and goes on: ‘Creating a multi-tier architecture for multiple channels … that will be three minutes’.

Do you listen to your IT department when they tell you, that doing this project in the given time frame will make maintenance difficult? No you won’t, you say that “they stifle the creative entrepreneurialism that is critical to advancing the state of the business”.
But would you skip maintenance on your car knowing that the risk of losing a tire will increase every month?

You do not listen … and then you complain. You create christmas wishlists and then you complain about not getting everything and especially not getting the thing that wasn’t on your list. But that was obviously needed by you.

So don’t learn about IT but make it your responsibility that they understand your needs. Would you have an architect build your house without checking the plans making sure that he understood your needs, without regularly checking the progress?

It was written, when I was involved in a project where the business side (again) complained that our software did not do what they expected. And it was (again) a misunderstanding about a sentence in their specification, that to us had a complete different meaning than what they expected (and vice versa). So perhaps you can forgive me the angry style. Instead of whining, let me try to improve on the situation.

Let’s draft a contract: It is our responsibility to understand your needs and translate them into software. We do that in the best way we know of. And “best” here means, as fast and cheap as possible (“cheap” in the long or short run: you choose). Because if you need something now, and know the trade off of getting it ASAP, we will do it. If we (think we) see a better way to support your business, it is our obligation to propose such a solution. But to be able to do that you must help us in any way you can. So that we are enabled to learn, what is important to you and what is not. And this does not end with you handing over a “specification”. It involves you, to write the specification (with us) in the best way you know of. It involves you, when we have questions and need clarifications. It involves you listening to us, when we explain trade offs for various solutions. It involves you, when we have a prototype or even a first version ready, to thoroughly try and test it. Anything that has been in that first version, that you would like to change later, will become more expensive to change over time. Adding a basement after the roof has been set is kind of difficult.

Does anyone read the Ivy documentation?

I know there are write-only-programming-languages, but isn’t there write-only documentation as well? Case at hand: The Apache Ivy documentation.

Some years ago I stumbled upon Ivy and we tried to use it to replace our home grown Ant solution. But after some weeks we simply gave up, nobody but our in-house build guru could understand it and he refrained from supporting the build, if it used Ivy. Some month later, we/he gave in. I am not sure this was a wise move.

Now, searching again for something less convoluted than Maven, I am looking into Gradle and Buildr (interestingly all but Gradle are part of Apache).

Since Gradle uses Ivy, I took another look at it, i.e at its documentation:

<project xmlns:ivy="antlib:org.apache.ivy.ant" name="hello-ivy" default="run">
     ...
     <target name="resolve" description="--> retrieve dependencies with ivy">
        <ivy:retrieve />
     </target>
  </project>

“[...] Note that in this case we define a “resolve” target and call the retrieve task. This may sound confusing, actually the retrieve task performs a resolve (which resolves dependencies and downloads them to a cache) followed by a retrieve (a copy of those file in a local project directory)”

Yes, it sounds confusing. I had to read that twice, just to be sure I haven’t simply garbled the sentence in my head. We have a resolve target and a retrieve task that performs a resolve. Why isn’t the “resolve” target simply called “retrieve”? But directly after that sentence, there is the rescue: “Check the How does it work ? page for details about that.” Let’s move on.

First, we see a great looking image:

and then (explaining “resolve”):

“The resolve time is the moment when ivy actually resolve the dependencies of one module. It first needs to access the ivy file of the module for which it resolves the dependencies.



Then, for each dependency declared in this file, it asks the appropriate resolver (according to configuration) to find the module (i.e. either an ivy file for it, or its artifacts if no ivy file can be found). It also uses a filesystem based cache to avoid asking for a dependency if it is already in cache (at least if possible, which is not the case with latest revisions).”

I am not a native speaker, so I won’t try to fix this gobbledegook, but please could someone review this text. I think it is nearly unchanged (or even more complicated) than some years ago. But if i understand it correctly, “resolve” does retrieve the files from the enterprise repository to the cache. “retrieve” then copies them to the project workspace:

“What is called retrieve in ivy is the fact to copy artifacts from the cache to another directory structure. This is done using a pattern, which indicates to ivy where the files should be copied.

For this, ivy uses the xml report in cache corresponding to the module it should retrieve to know which artifacts should be copied.”

Ok, I give up.