So I’m engaged in an email dialogue with a developer who wants to integrate some new systems with some of the systems that I administer. I have (reasonably) asked for information about what they’re actually building and how it will interact with my systems, so I can figure out (a) if I’m going to allow this and (b) what will be required to make it work.
The first time I asked for diagrams of the solution, I got a two-page Powerpoint presentation. The first page was the business benefit of the solution (“customers will be able to get data!”) and the second was about five boxes with labels like “Amazon Web Services” and “OurNewPortal.”
I got back a six-page Powerpoint presentation that included the original first page, a modified version of the second page, a new diagram helpfully labelel “Logical Diagram” (which is a good fucking thing since that’s the ONLY way I could tell that’s what it was supposed to be) with some boxes, lots of bidirectional arrows, and some numbers on the arrows.
And three new pages labeled “Data Flow Diagrams” which were actually business process diagrams featuring gratuitous misuse of standard diagram shapes and a carefree disregard for nitpicky details like “what systems are actually named” and “what’s actually going on in this step.”
At what point did this seem like a good idea?* “Hm, I don’t understand what he’s asking for, so I’ll just make some shit up. Maybe he won’t be able to tell.”* Of *course *I can tell, you jackass. I’m the one asking the question.
Are you sure you’re dealing with a developer? I don’t think I have ever yet met one that when asked for details would respond with a business case (they’d all be damn quick to tell me that is my job not there’s, there’s is to tell me how it could be done or, if they don’t want to do it, return an estimate of 40k hours to fix a typo).
Not 100% sure, but pretty close. Although I suppose it depends on what you mean by “developer” - he’s certainly not one that would pass my team’s interviewing process.
Are those 4 + 1 things actually useful? From the Wiki article they look like the sort of thing… well, that you’d expect to see in a Powerpoint presentation.
I wouldn’t be surprised at all if a random coder knew nothing about UML. I’m in a graduate level IS program, and we spent about a week on it in the modeling class, and the rest of the term on basic DFD’s and BPMN. The data modeling class was all ERD.
There’s a very good chance that the typical Devry dude has never so much as seen a sequence diagram.
This sounds SO much like the group I used to work with. If so, the slides you got were manufactured by a yahoo on a power-trip and sent under the developer’s name. Cuz the yahoo doesn’t let anyone in his group communicate with the outside world. They might, you know, learn stuff if they did.
I’m not surprised that he can’t answer my questions. I’m surprised at his methodology for dealing with the fact that he can’t. Seriously, at what point do you figure “ah hell, I’m just throw some shit on a slide, that’ll probably do”?
Bear in mind this is the second request I’ve made for specific technical details of the design, with an explanation of why and reference links to the sort of thing I’m expecting to see back.
The author of the slides is basking in superiority. They should explain everything. The fact that the slides don’t answer all your questions means you are, as he suspected, intellectually inferior. If he gets well-entrenched he’ll try to get you fired and replaced with his own people. His own people don’t understand the slides either, but they pretend they do.
Heh. I’ve seen that pattern before - I don’t think that’s what’s going on this time. He’s a consultant, and I’ve outlasted far, far better people than him.
It’s not that he didn’t create “diagrams” in response to my request, it’s that what he created bears almost no resemblance to what I asked for. Which means it’s not a methodology thing, it’s an inability to communicate thing.
And the Agile teams you have worked with make me sad, because Agile done right produces plenty of written artifacts, just not before the work gets done.
