I had to subjects for this journal entry. The first one was 'When Developer becomes Customer and vice versa' and the one I finally picked, I started thinking about writing this journal entry after some heated e-mail discussion back and forth over some API definitions.
I am writing the specification of the modification of some existing online services with a client and we are going to enable online payments in these at the same time we one to migrate all payment services to a new a common payment system.
I entered the project before the summer because I thought the project was too unstable, my company have been given the assignment and I had allocated a freelancer to do the task - he really wanted the task, so it was natural to go this way.
Anyway we received the technical design and everything was crap, I have journalled about this before, so it is not because I keep running into these sort of projects.
Well anyway as a response to the technical design document, I wrote up a specification for the online part which was almost totally left out. I examined the requirements and mapped these onto my specification.
I cooked up some different implementation scenarios. I presented these to the online technical lead and the freelancer and after some discussion we agreed on one of the proposals.
It surfaced that an existing payment method had been totally ignored in the technical design document and other small things had not been examined.
Following the scenario from my specification everything looked good and based on my input, we found out what the new user interfaces should look like, we got the product manager and a marketing responsible to create some new mock-ups.
Throughout all this we where discussing the APIs to call on the backend, I came up with a proposals, which we would require in order to meet the requirements.
So after much heated discussion both at meetings and via e-mail we seemed to be getting somewhere - so today I received a new proposal for some APIs and they where taken in a whole new direction, I mailed my feedback and simply asked what the motivation was for introducing these new APIs. The response did not provide much clarification.
So the project manager called a meeting.
At the meeting they all of a sudden informed us that we where supposed to call another external clearing house instead of the one we had been aiming at for some of the payment types, this put the APIs in a whole new light and they actually made sense.
So to bring me back to the subject, 'How to make your consultants look really stupid' - this was exactly what happended, I reacted positively and informed the project manager, developer of the APIs and the technical architecht that they should just have said so, then there was no reason for us to discuss these things so intensely since we where still basing our specification and design on the requirement of reusing as much as possible and other assumptions.
So our assumptions where plain wrong and all due to lack of information.
When leaving the meeting I was happy that we where finally getting somewhere. But giving the whole information some though I got really angry. This lack of information had made us look completely stupid and our response to the provided APIs seemed so unproffesional and out of order since nobody had informed us of the change in integration scope.
man, I really really want to tell these people a few things on working as a project team, I hope for them they forget to invite me to the project evaluation.
I actually wanted to write a journal entry on inter-department/division communication. Since my experience it that when attempting to integrate diverse systems the APIs are extremely important, these must be clear and concise and be specified as early as possible.
This is when one developer becomes the customer on another system and therefore should be treated as such. In this case the APIs are forming the base for our complete control-flow and application implementation. We are the sole users and our requirements should be taken seriously - I do not feel this is the case in this project.
We are required to deliver input and estimates etc. but we are not provided with a complete picture or level of information to do so - so we assume and sometimes we assume wrong based on wrongful or lack of information.
