Please create an account to participate in the Slashdot moderation system


Forgot your password?
Note: You can take 10% off all Slashdot Deals with coupon code "slashdot10off." ×

Comment It's too late (Score 1) 187

What you describe is a political issue, not a technological one. Unless you've already made strong friends with the IT staff, and _earned_ their respect and trust, expect them to resist you at every step. In particular, expect their middle management layers to disagree with every move and sabotage them behind your back. And I'm afraid you're starting out with a basic confusion: "3000 employees" is not a medium sized, company, it's a _big_ company. I'm also afraid that if you think of it as a medium size company, you'll be tempted to micromanage individual employees and pet projects. You're not going to have time for this, really.

Earning the respect and trust of the existing staff is going to be awkward. You're going to need that: they're going to need questions answered, clear decisions made with clear justification, and a clear set of technology and social practices so they know what is expected. Documentation, backup, and standard practices for network and environment configuration are all going to come from or be signed off on by you. If they disagree with a practice, they need to be safe to express it safely, work with you to iron out the differences, and if it turns out one of you were dead wrong, to get the other's insight credited and the other person educated on why the right practice is just that.

And I'm afraid many practices aren't that clear-cut: flexibility versus recoverability, reliability versus expense, growth over repair are all going to require decisions coming from you, as an architect. And even when you make the "right" decision, sometimes things are going to break that the "wrong" decision would have avoided. Some of them are going to be _large_.

That's partly why the existing staff are afraid of handing over admin access. Another possibility is that they're _embarrassed_ and you'll have immediate visibility into what they're embarrassed about. I've had tremendous difficulty with staff leaving in unannounced backdoors "to get their jobs done" and not wanting me to know about them. I've even been booted right off a project because I kept going to the manager with "your technical leader is putting in backdoors for his telecommuting here, here, and here, in direct violation of SOX guidelines: I can't sign off on this".

Anecdotes aside, you're going to have to establish trust with these people. From your short description, it sounds like they've been thinking of you as the enemy. If they're unhappy and can't work with your vision, check if your vision is confused and you can accommodate their ideals and goals. If you can't incorporate their goals, or if they're just plain wrong, show them the door gracefully. And let them know what your "vision" is, so they can be sure if you'll like their plans or if they're going to have trouble convincing you something is workable.

The best way to show them the door is to help them get hired somewhere else better suited to their neds as well as yours. I've had good success with staff who'd outgrown our environments, or our environments had moved to new practices they didn't care for, helping them find work with partners and other companies who appreciated their approach. I've even done a few flat-out exchanges: "You need a new security expert, we need a new backup expert", we've swapped staff, and we both came out better for it.

Comment Re:In other news... (Score 1) 122

> 20% of Healthcare CIOs are idiots or liars.

Or both., I'm afraid. Or the survey was badly constructed. I've seen a number of security compliance surveys, especially now with HIPAA laws affecting health care security, that were designed to allow hospital IT departments to claim more or less security with subtle interpretation. The result is that for medical IT staff who needed more security funding, and wanted to justify the work, they'd answer the surveys one way and say "we have a problem, we need to spend money". And if they wanted to report success the next year, despite no genuine oerall change, they'd choose other similarly "interpritive" answers and point to the improvement in security.

Comment Re:Focus on his current skills (Score 1) 87

The stroke he suffered while writing "Number of the Beast" affected Robert Heinlein a great deal. I'm afraid having so many adoring fans, and editors who grew up with his earlier work, gave him enough influence that editors didn't dare to rein in his works with the plot unification and cutting of excess themes that a good editor would apply to a less successful author. It's a common problem for successful authors, and coupled with his age and the stroke, I'm afraid Heinlein's work suffered.

The "Heinlein juveniles" were exciting and inspirational work for many people, especially engineers. His characters were humans, many were engineers by nature if not by trade, and they bothered to do the work to master their crafts and to use the available tools to their full extent. The Lazarus Long anecdotes were filled with the lessons of an old man who's learned tremendous wisdom and tries to share it, and the Moon is a Harsh Mistress explored family life and guerrilla warfare and space-based warfare and the moral ramifications of AI and shortsighted politcal thinking, all in the same story. Stranger in a Strange Land explored the idea that language shapes thinking, and that to fully understand something is to love and cherish it as it exists, but does _not_ mean accepting that it should continue to exist.

I recommend Heinlein's older work to youngsters today in much the same way I recommend Terry Pratchett's fantasy work. They're entertaining, they pay attention to the consequences of technology and technological shifts, and they carry interesting moral lessons.

Comment Re:Account should not try to "get knowledgeable" (Score 1) 87

> Account should not try to "get knowledgeable" in HTML and JavaScript. He will only seem more of an idiot.

Unless he learns a bare minimum, he will be _owned_ by the technical people, who will exploit his lack of knowledge to make irrelevant work seem more important. I've seen this a great deal, with pointless code churn and endless "meetings" used to justify the size of a group that is accomplishing very little, for group members to take on irrelevant projects, and to leave only a few core people doing any real work.

It's also not normally the job of an accountant to "make the work profitable", any more than it is the role of security to make the product usable. There are critical exchanges of power for speed, of cost for usability and scalability, that an accountant _can_ help with.

Comment Re:i think it shows trends in GitHub's demographic (Score 2) 132

> Might be because the systems I was involved in where not supposed to run on washing machines.

Then you don't look at Linux device drivers, and apparently don't look at highly performance optimized daemons. That's fine: you may not have needed to do this.

> That is a non sense sentence. What exactly is an unreliable compilation?

"Unreliable compilaton" could mean many things. Code that is likely to give different results based on subtle compilaton option differences, such as optimization levels, due to assuming default population of uninitialized variables is my current favorite. Code that produces different binary functions dependent on compiler assumed architecture is another, such as using "int" versus "uint_32", is another older favorite from when I did more porting of 32-bit code to 64-bit environments. Code that relies on replacing system libraries with its own particular "tuned" versions of libraries or standard OS functions is another, since it becomes vulnerable to inconsistencies in the compiler flags and a developer who fails to set them correctly can get surprisingly inconsistent behavior.

Other features do not so much prevent compiler inconsistency, but help with programmer consistency. Following the local style guide, using consistent naming schemes for variables, keeping memory handling in one consistent area of code so "free" and "malloc" are easily tracked, and sanitizing I/O before relying on it are all aids to consistent behavior.

Comment Re:i think it shows trends in GitHub's demographic (Score 3, Interesting) 132

A great deal of professional code is published: it's key to the Apache foundation and the Free Software Foundation. And a great deal of the more straightforward being published as "C++" for lightweight applications is standards compliant C. I just went through a similar issue with a job applicant who wrote backend website processing: That person's code had _no_ C++ elements in it, written for the simplest and most reliable compilation. It was very lightweight, the libraries it required were very stable, and it had _no_ dependency confusion common to the "overloading" of C++ functions. I was quite pleased with their code.

Comment Re:Installed in a VM (Score 1, Informative) 282

> Gotta tell you - you sound like a real classy professional.

That seems confusing. Please, re-read what I said. I said that making multiple concealed copies of licensed software hidden by virtualization to violate their licensing would be illegal. Where, exactly did I say "but we do it anyway"? I don't, myself do it, and I would have a long professional talk with any of my colleagues I caught doing it.

Comment Re:Installed in a VM (Score 4, Interesting) 282

I do that a great deal. Not with Windows 95 for some time now, but for node-locked licenses for some _very_ expensive software that companies are unwilling to upgrade. And it would be quite illegal of me or my people to explain to the customer, in detail, how to run the locked node inside a virtualized network, and run other copies of the same VM inside other virtualized private networks only connected via NAT to the outside world. No, that would be a license violation.

I've also done similar setups for numerous UNIX and Linux distributions as well.

Comment Re:Programming? (Score 2) 132

Because they are both used with API compliant software to accomplish specific computer behavior, including I/O, programmed operations, and back end integration with style guides, QA verification, and clear functional success of the computer application if misused or if ocrrectly implemented. They may not be Turing complete and able to compile their own interpreters written in their own language as source code, but they're certainly "languages" as far as listing them on a resume or planning training are concerned.

Also, they're quite a _lot_ of the hosted code on github: it's certainly reasonable to acknowledge their roles in open source.

Comment Re:Its a dumb feature (Score 1) 89

As soon as you put "removable" BIOS chips back, you have to provide physical access to that chip, you have to provide board space to mount it, it increases the price of the motherboard, and most important to security, it provides the possibility of corrupt vendor replacement of the BIOS chip with their _own_ socket replaced chip with only poweroff physical access, not console access to run the drivers or work with attached boot media.

I'm not saying this is a greater attack vector: but it's one that has to be considered for high security systems.

Comment Re:I forgot... (Score 2) 380

Servants to reduce their physical workload? Yes.
Cooks to prepare food with little effort? Yes.
One day's labor or income providing more than 10 days of food? Yes.
Plenty of food all winter? Yes.
Children somewhere else for much of the day? Yes.

Sugar is a _result_ of wealth and modern industry supported by that wealth. I'm afraid it's hardly the only factor modern obese people share with historically obese people.

Comment Re:Guess what? (Score 1) 301

> I'm pretty sure most dashslot readers have not even been accused of "molesting five children, including his own sisters",

Given the accusations and abuse heaped on various software project leaders or contributors, it's more common than you may realize.

Also, I'm afraid that the standards for what constitutes "molesting children" vary from culture to culture, and even from state to state. There are cultures where clitorectomy, which I would certainly classify as sexual abuse of children, is considered part of proper upbringing. Looking at for rape statutes, the first state listed considers it a felony for an 18 year old to have sex with a 15 year old.

Even marriage among siblings has occurred in small communities, and among royalty, throughout history. And sexual play among siblings is surprisingly common among humans and other mammals. This doesn't mean that I, for one, recommend it. But by itself, without violence or threats or other harassment, it should not turn the recipient of sexual molestation into an automatic object of lifelong pity.

Comment Re:Offsite backups (Score 0) 141

Administered by a skilled storage, hardware, and network team. Training up such a team and keeping them employed, without managerial or technical errors destroying the whole system, for years, is far beyond the skills of most IT departments.

I've built such offsite storage: I've helped people recover from the _inevitable_ sitewide disasters that overwhelm reasonable protections. Much like running your own mail server, Google has consistently outperformed and outlasted single company systems. Bulk data storage and handling is one of their core technologies, and this was a genuinely exceptional failure which very, very few home brew systems would have survived.

Comment Re: Cannot be trusted (Score 1) 141

I'm afraid that had nothing to do with write speed for storage. It had a great deal to do with deliberately keeping the design very light, using very effective proxies for the very light and consistent images, and keeping tight reins on web designers who might want to front load the Google pages with exciting content that had no relationship to the service.

I'm confused why you mention it, unless you think that the wise practices and designs that led to such effective and quick interfaces affected their storage designs, as well.

There are three kinds of people: men, women, and unix.