Re: Interview

Dave Searles wrote:
Arved Sandstrom wrote:
Dave Searles wrote:
Lew wrote:
[ SNIP ]

A good programmer with solid fundamentals can seem like an outright
genius and coding machine by comparison. Just don't piss the peons
off or they'll sabotage you politically.

Politics is another skill that should not be demanded of an engineer.

You'd best have some skill at politics if you wish to enjoy a successful career.

Is that a threat?

No, it's an English expression using the extremely common indefinite or general "you". As for the sentiments expressed, it's an observation as to the facts of life, idealistic thinking aside.

[ SNIP ]

In all of these cases there were nuances as well. In the first case the vendor officially supported over three-quarters of our installed software. If we had replaced the small piece that was flawed with an open-source implementation, the argument was that the vendor would have refused to deal with any problems related to the entire stack. Not inconceivable. That's political, but it's also a decent argument.

The correct way to deal with that is to tell the vendor all about the flaws in the small piece, and if the vendor wouldn't do anything about that, go with the open source replacement for that component. And of course what the vendor doesn't know won't hurt it; no need to specify that that component was replaced. Just tell the vendor if some other component has problems what the inputs to it were and what the incorrect output was. If the output was clearly not what should have resulted from the inputs, the vendor can't very well argue, regardless of where those inputs actually came from.

Depends on the vendor involved. This particular vendor happens to be in the Top 5 of global IT companies by annual revenue, so if they intimate that support for problems with your installation of their software stack is contingent on not screwing around with that installation, including swapping out pieces for third-party software, it's probably a good idea to listen to 'em.

Unless the vendor is irrational, of course, in which case the vendor is going to turn into an anchor tied to your foot and drag you down sooner or later. Get one that isn't crazy, ASAP, or go open source for the whole stack, and then you can fix things yourself using in-house expertise or using a company like Red Hat that sells support services for open source systems.

As to the latter, a vendor like Red Hat sells support for _their_ systems, OSS or otherwise. You'll get no further with them if you start monkeying around with what they recommend as stable configurations.

As to using in-house expertise for fixing problems with your OSS, most organizations hire developers to tackle their business problems, not to spend time fixing defects in other peoples' programs. If it's a superficial problem, sure, go ahead and fix it. But if it's serious, how much time do you want one of your developers to divert from what they are really paid to do? IOW, you don't generally select a piece of third-party software because it's open-source, you select it because it's the best software for the job.

In the other two cases I mention there were actually larger project issues involved - possible retraining of internal staff, or hiring more external people, extending deadlines etc.

That seems to me to depend on what was being done. For example, with retraining of internal staff, the problem would be that some user interface was being changed. If the product being contemplated was well designed, the UI and the engine would be decoupled enough that the UI could be replaced or reconfigured so retraining wouldn't be needed (except maybe all those workarounds for annoying known bugs could be happily forgotten about). If the product being contemplated was not well designed, then it fails on the merits anyway.

[ SNIP ]

In this case there would have been technology changes involved. The internal staff would have been programmers and operations support. You don't lightly propose changing technologies, even if the target technology is a much better solution for the problem, without taking those kinds of resource issues into account.

This is all political stuff. And unless you're a software developer on the bottom rung (and maybe not even then) you'll have a happier career if you learn how to take it into account. You certainly don't have to, but you'll end up frustrated and bitter if you don't.

If you don't, AND work for the wrong sorts of people, perhaps.

You'll never work for a company that has no politics.

AHS
.

Relevant Pages

  • Re: Interview
    ... If we had replaced the small piece that was flawed with an open-source implementation, the argument was that the vendor would have refused to deal with any problems related to the entire stack. ... The correct way to deal with that is to tell the vendor all about the flaws in the small piece, and if the vendor wouldn't do anything about that, go with the open source replacement for that component. ... This particular vendor happens to be in the Top 5 of global IT companies by annual revenue, so if they intimate that support for problems with your installation of their software stack is contingent on not screwing around with that installation, including swapping out pieces for third-party software, it's probably a good idea to listen to 'em. ...
    (comp.lang.java.programmer)
  • Re: Electronic prescribing: No panacea
    ... The human interface of your software package is defective. ... the administration and the doctors. ... If at all possible get the IT people on your side against the vendor. ... I've always had problems with politics in large ...
    (sci.med)
  • Re: Interview
    ... You'd best have some skill at politics if you wish to enjoy a successful career. ... Stupid businessmen, on the other hand, might be susceptible to political tricks and other such nonsense, but which would you rather work for, a smart businessman that lets you do your job to the best of your ability, or a stupid one who wastes your time with this political nonsense, will screw you over if you are bad at it, and will eventually screw you over anyway because his stupid decisions will kill your project, bollix up the whole department, and ultimately sink the entire company? ... If we had replaced the small piece that was flawed with an open-source implementation, the argument was that the vendor would have refused to deal with any problems related to the entire stack. ...
    (comp.lang.java.programmer)
  • Re: Interview
    ... You'd best have some skill at politics if you wish to enjoy a successful career. ... In one case an influential approver was antagonistic to open-source software (and we also couldn't be seen to piss off a vendor). ...
    (comp.lang.java.programmer)
  • RE: Vendor wants remote control of our Servers and Workstations
    ... Of course the age-old problem with security is that ... Vendor has significant access to your internal ... this vendor uses the same method to support a number ... customer and makes significant changes ... ...
    (Security-Basics)