How to practice diplomacy: Playing on the nature of truth
So today I practiced diplomacy. We need to integrate with an application that has reached its end of life. It was suggested that since both applications are written with .NET, we can just take the code and build on top of it.
I said that I would need to see the code. They sent me the documentation and a link to the current site. I read it, I thought about all the things that I am not going to say.
Here is what I did not say:
I found three SQL Injection attacks just by reading the documentation, I looked at the code and had to go and wash my hands. I am going to put that in the WWTT* folder, to look at dark moments, when I am frustrated and need the relief of: "At least I not working on that."
What I did say was:
I do not believe that we can reconcile the architecture of the existing application into our own applications, there are significant and unbridgeable gaps between the two. What we are going to do is to rebuild it using our own architecture and harvest the existing code base to the best of our ability.
That is diplomacy.
Being polite is another matter, in which you tell someone you hate their guts, but you smile when you do it, and say "if you please" at the end.
* As in What were they thinking?
Comments
You only "practiced diplomacy" up to the point where you went and spread the thing all over the internet.
From there on, you only practiced - quite successfully, if your prospective clients get to read your post - "not being very smart".
So we should never use our real world experiences as source material for blog posts? No names were mentioned and it's highly likely that anyone who did work with this code and actively watched this blog would probably be in agreement with his comments. So in all likely hood no harm.. no foul..
Grigore,
I never name names in this blog, unless they are already public or they have expressly given me permission to do so.
This particular client is unlikely to read this blog, and if he will, I am more than willing to sit down and explain it. That is not a consideration that I would usually take.
But I have also publish much worse about work I have done to clients, when I knew full well that the lead developer whose design I ranted about is a subscriber to this blog.
It seems that rebuilding stuff in your existing architecture is a recurring issue. I'm not saying this is necessarily a bad thing, but what are the costs? How do you control your NIH tick? How do you get away with that (management-wise)?
Avish,
It has to do about responsibility, and TCO.
If I am responsible for something, I have to consider costs. I tend to look over the lifetime of the application rather than the immediate moment, and as such, I consider maintainability concerns over immediate concerns.
From experience, trying to tangle with a bad architecture is something to avoid. If it is small, I would prefer writing it again, if it is big, anti corruption layers.
Comment preview