Said reply amounted to:
- I'm the only SQL advocate (really, RM advocate, let's be honest) in this part of the world
- unless the C-suite types enforce it, the coders will obstruct, obstruct, obstruct (kind of like Republicans)
- my experience is that SQL advocates, in orgs run by either pure coders or business analysts, end up with RDBMS as passive filestore
- does your client really, really understand the implications of having a person who's going to be at odds with most of the staff
- what, exactly, does the client want to accomplish; what change is desired
The database wasn't named, but I'll guess SQL Server.
Much to my surprise, I got a message back from her. And it confirmed my concerns; she didn't know what the client wants to do, and doesn't think the client knows. I was shocked, shocked I say!! May be not so much. The recruiter showed a Boston area address, which means there could be some form of intelligent life. Her client, turns out, is not far from West Redneck, but not Hartford or New Haven. Not that either necessarily means a SQL advocate would be warmly welcomed. I took a position at CSC in Hartford a while back, mostly on the assertion (from the hiring person, no less) that "we're going to be doing heavyweight database development". Turns out, all they did was map COPYBOOKS into tables (that link is about a decade after I weathered the nonsense at CSC, the Dark Ages continue). Moreover, mainframe DB2 allows existing COBOL code to be executed as a stored proc. A yukky time for all, but past.
So, then comes a simple-talk piece on where to check the data. Naturally, I didn't keep my mouth shut. But I remain amazed that it's still necessary to slay such octogenarian dragons. Them dragons do endure.
And, it turns out that there are a few coders who recognize that having centralized control is generally a good thing. Allen Holub has been my favorite java guy since the late 90s. He seems to have fallen off the map, largely. I think I know why. Here's a bit from his Bank of Allen series:
The only recourse is to change the ROMs in every ATM in the world (since there's no telling which one Bill will use), to use 64-bit doubles instead of 32-bit floats to hold account balances, and to 32-bit longs to hold five-digit PINs. That's an enormous maintenance problem, of course.
Changing the clients is a waste of time and effort. Bad design, but good for billable hours. Do it his way, and you don't need quite so many coders, don't ya know?
No comments:
Post a Comment