Slashdot Mirror
Ask Slashdot: What Are Some Hard Truths IT Must Learn To Accept? (cio.com)
snydeq writes: "The rise of shadow IT, shortcomings in the cloud, security breaches -- IT leadership is all about navigating hurdles and deficiencies, and learning to adapt to inevitable setbacks," writes Dan Tynan in an article on six hard truths IT must learn to accept. "It can be hard to admit that you've lost control over how your organization deploys technology, or that your network is porous and your code poorly written. Or no matter how much bandwidth you've budgeted for, it never quite seems to be enough, and that despite its bright promise, the cloud isn't the best solution for everything." What are some hard truths your organization has been dealing with? Tynan writes about how the idea of engineering teams sticking a server in a closet and using it to run their own skunkworks has become more open; how an organization can't do everything in the cloud, contrasting the 40 percent of CIOs surveyed by Gartner six years ago who believed they'd be running most of their IT operations in the cloud by now; and how your organization should assume from the get-go that your environment has already been compromised and design a security plan around that. Can you think of any other hard truths IT must learn to accept?
Your gravestone will read 'He never scored'. Just like Beavis.
suckers haha
The Cloud is your enemy. Fire anyone who offers a "cloud" solution before offering an in-house solution, because I can guarantee you that "cloud" services are only half as efficient as running the hardware in-house. The question really is where do you want your data to be.
If you have privacy concerns (eg credit cards), then machines dealing with credit cards should be co-located in a high-security data center that you know who has physical access to it. If you are simply serving cat videos, then cloud-away, because nobody is going to care if a cat video is slow due to bad provisioning.
But every time, it seems like I have to fight someone as to why it's cheaper to own or lease the hardware in-house rather than "cloud it", because cloud services are not as scalable as you believe it to be. The "cloud" only scales two things efficiently. CPU "TIME" and "Storage Capacity". If your IT is not concerned about these, then it doesn't belong in the cloud. If you are concerned about security or latency, those must never go into the cloud.
If you are crunching numbers, it is cheaper to borrow the CPU power of 500 computers for one day than it is to buy two computers and have them take one year. That is where "cloud" computing is supposed to be used.
Instead we have the morons of IT management trying to put everything into the cloud so they can eliminate IT staff, and the cost of doing this is that when mistakes are made (eg equifax) , nobody knows how to fix it, and it costs substantially more to fix by hiring new staff just to solve one problem.
>> What Are Some Hard Truths IT Must Learn To Accept? ...that IT is not engineering, and that engineering is not IT.
in HTML. There. I said it.
If you want to be a sysadmin these days, do the devops thing. Which basically means you are a sysadmin who knows how to write deploy scripts for AWS. Pays a lot, though.
"First they came for the slanderers and i said nothing."
Then don't fix it. Seriously if something has been working fine for years, don't meddle with it.
Only the State obtains its revenue by coercion. - Murray Rothbard
The single biggest predictor of project success/failure is the quality of the people involved.
However, most firms are bad at recruiting and maintaining top-quality people. Often, they chase the best ones away, resulting in the Dead Sea Effect.
Finally, "In starting a new software program, all the important mistakes are made on the first day." (The Art of Systems Architecting, Maier & Rechtin). ..bruce..
Bruce F. Webster (brucefwebster.com)
You're overpaying programmers for the shitty code they produce.
With each iteration, operating systems become less usable and user friendly.
The "cloud" is only as good as your connection or the bad software behind it (see above).
Overpriced hardware cannot compensate for poor software (see above).
Voice recognition is not the be all and end all.
Broadband speeds and pricing in the U.S. will always be behind the rest of the industrialized nations until there is competition.
Your definition of 24/7 uptime is vastly exaggerated.
I used to be an IT person, but have spent time in the humanities too. From that experience, I'd say the biggest lesson of all is that often more technology is not the solution. And that as much as we nerds like to think we are rational, we often fall into the trap of being religious about our belief that all a situation needs is more tech. The humanities - ethnography, sociology, philosophy - have valuable insights to offer into the complexities of human society.
Now when I see thing like the blockchain I see projections of ideology, and very little real understanding of the complexities of politics, ethics and social norms. To a nerd, all of that is noise, something that ideally shouldn't be there.
To learn more about this, search for the 'technological determinism vs social contructivism' debate.
slashdot = stagnated
We can outsource your job to anyone. Don't go into IT.
IT going forward doesn't need a dozen people with BS degrees. When you're building a house you only need so many civil engineers and architects. At some point you need a fleet of plumbers, electricians and general contractors. Some people insist that a BS is required so management finds the cheapest BS they can. For 10% of my job I would love to hire a 17-18 year old apprentice and just train them in the hands on tools.
I don't need a BS. I don't need an Indian. I just need someone thirsty and willing to learn. I was lucky enough to have an engineering 'apprenticeship' at 16 and it influenced the rest of my career. It was hands on "do this" style learning, exactly how you see journeymen training apprentices.
There will always be a need for advanced degrees but the ratio of degreed:apprenticed needs to change. Doctors have moved to train physician assistants, RNs, and a host of other positions to do most of their job so they can concentrate on what they were trained to do.
If you're a manager looking for 'cheap labor' start talking to the local voctech high schools. Factor in rework and communication 'costs' and pay them well for their age. You'll come out loads ahead. They'll have relevant job experience for the future and you'll have cheap labor. If you have someone set to retire in 5 years just have the 16 year olds shadow them and do any work that they can.
You'll have 'cheap' labor that knows your system inside and out and you can pick the best to hire after HS. It's how all of the CNC and tool and die shops in my area do it. Kids wrap up highschool and get hands on training in something they're interested in. After HS the CNC shops have 18-19 year olds that are getting paid well for their age with no debt.
Software engineering cannot be squeezed into formulas for plugging and chugging.
The ship is sinking. The captain lied.
You have a very narrow technical training and you are being used to enslave and/or destroy everything you know and love and you're too damn stupid to see it because you inundate yourself with material pleasure.
The most banal, junior school/Jeopardy linguistic construct ever.
E.g. "What are some hard truths your organization has been dealing with?"
You could say
"What hard truths has your organization been dealing with?"
Or, imagining the set of hard truths being finite, you could even say "Which...".
Executive summary of the six "truths":
1. The other departments are already using cloud services without asking IT.
2. ~90% of companies will be using cloud services by 2020 according to Gartner.
3. Your IT is so incompetent that it's already been hacked; using cloud solutions may help to mitigate risks.
4. Your IT is incompetent(bis): your software is outdated and/or crap (no mention of the cloud, but I guess they're supposed to keep their stuff better updated).
5. Have lots of bandwidth (no mention of the cloud again, but then how are the users going to use cloud services if the network connection isn't fast enough?).
6. If IT bends over and let cloud services take their rightful place, they may get to keep their jobs.
In short, the whole things reads like an a clever advertisement, where instead of saying quotes like (...)cloud infrastructure comes with security designed in, they instead claim that the IT department is incompetent and useless.
all hail
While there are a lot of problems with the way IT is done in companies today, my experience has been that the companies who pay the least for IT (as in smallest IT staff to general staff ratio) are those companies that encourage honesty, thoughtfulness, and long-term planning. I've worked for a few - at one place, a handful of staff supported 4,000 workers and had time to blab at the watercooler. But they could do this because the company was remarkably consistent about resisting IT fads, and instead looked at IT purchases from the standpoint of, "Yes, but what am I going to get out of it?!" They paid their employees, the vendors, not so much.
Those companies which view IT as a cost center, in my observation:
pay far more than they need for what they get
follow the latest fads in IT
are continually under the gun to cut costs
constantly overwork their employees,
deliver much worse service overall,
and suffer from seemingly constant IT failures of one sort or another.
For some reason, those companies which view IT as a cost center rather than a strategic asset always seem to be falling short of their goals.
The society for a thought-free internet welcomes you.
Fire them all.
Anyone who reads trade rags and thinks the ideas they get from them are good, should be decapitated, the oxygen they are wasting could be put to better use by people who actually use their brains.
You lone wolf, cowboy types are losing the war with your NIMBY ways. There is no spoon.
If you don't work for a tech company, you are a blue collar worker not a white collar worker.
Even if you do work for a tech company, if you are not a manager or a high level designer, you are a blue collar worker.
Basically, we are more like plumbers than doctors.
We really should unionize.
excitingthingstodo.blogspot.com
"Employees can quickly stand up whole IT solutions, from applications to storage, with a few button clicks, and then access these platforms from their mobile devices"
If you have employees doing this without authorization, you don't have an IT problem - you have a huge administrative/leadership/management problem.
As per my subject title. This is something that has never changed. The changing face of IT over the ages is probably worse than being a medical doctor. You have to learn new tech constantly, and now you need cloud & devops, which isn't that hard really unless you are a lazy windows muppet admin. Every new job involves you learning new disciplines, even if what you do the majority of the time basically stays the same. At least users these days are a tiny bit more tech savvy (but not amazingly better - computer education has seriously failed a generation) than 20 years ago. These are the hard truths a sysadmin must learn.
The hard truths IT must learn is yep, people want stuff in the cloud, and a bunch of crappy services from third party providers to supplement them (that they change every couple of years, going from "wowomg awesome" to "sucks" in this period, when the new and shiny thing comes out next. User management of the metric fucktonne of third party crap is a nightmare, going through all these stupid services. Oh yes, and finally the last thing especially in europe is data protection/compliance/etc stuff that you have to run, the current favourite flap being GDPR. Love it or leave it, people.
1) Agile is bullshit
2) You do not need to have meetings every day
3) Standing up for a meeting is utterly ridiculous
4) Iteration Managers are a very poor replacement for Project Managers
5) Scrum Masters are a crock. You should not hire these people
6) Kanban is a bullshit methodology
7) Hotdesking sucks. Treat your staff well and give them their own desk.
You can outsource tasks, but not responsibility.
That people outside the company care as much as you do (should) about the success of your project just because your pay them exhorbitant fees.
That people only work hard because you give them quarterly rah-rah speeches, praising some niche project that nobody outside the C-ranks have even heard of.
Apple hating Android users always have these insane paranoid scenarios where the CIA picks them up and tortures them until they unlock their phone with FaceID, meanwhile they have an Android phone in their pocket filled with months old vulnerabilities that will never be patched.
Don't take Android people seriously, they are not smart.
Your codebase's primary job is to attract and retain top talent. Whatever the fuck you want to sell or buy or disrupt or facilitate is secondary, if you can't get people to write and maintain your code.
You could have a hideous frankensystem that grants golden penis wishes and you will go bankrupt trying to maintain it if you don't let those two skinny guys and that fat guy convert it to Rails, then Angular, then React every 6 months.
The toner cartridge in the LJ up on 4th Floor East isn't going to change itself!
Systemd is a perfect example of this lesson in action.
In my case, I'd been using Linux for about two decades. During this time I'd used all sorts of distros, in all sorts of environments, but ended up mainly using Debian. And in all of this time, I think I had maybe one or two incidents where a Linux system wouldn't boot due to an init-related software problem. Yet within my first couple of months of using systemd I experienced numerous incidents where systemd broke the boot process, often in remarkably stupid ways.
I wish that Debian had never switched to systemd. Debian was so reliable and predictable and stable before the switch. I could feel confident thinking that any Debian server I had to reboot would very likely come back up just fine. But systemd changed all of that. It took away the predictability, the reliability, and the stability. It got to the point where I just couldn't trust a Debian server using systemd to reboot properly. This is a really serious problem when dealing with critical systems where unexpected downtime is not acceptable.
Thanks to the totally unwanted introduction of systemd into Debian, and the numerous problems it caused me, I had to move on. I chose FreeBSD, because it seemed to me to be the most sane OS out there, while exhibiting many of the values that made traditional Debian such a pleasure to work with. It took some time, but eventually I migrated all of the Debian systems I was responsible for over to FreeBSD. I couldn't have made a better decision! I haven't had even a single incident where a FreeBSD system wouldn't boot properly.
I can't emphasize how important this lesson is. I think that Debian would still be usable today if only it hadn't made the unnecessary switch to systemd.
Throw it away, Reboot it, Buy that software, Replace that finicky ___. Don't be the "hero" who spends 3 days debugging something which can be replaced for $500.
Because there's always going to be someway in and the only way to build a near bullet proof system is to throw necessary funds at it required to do so. Shareholders like profits today, not 10 years down the road when they're too crusty to screw anyone over.
You mean convert all your API's into JSON calls and spin up gajillion web services? Why? That increases complexity. Native-app-language-to-native-app-language is much easier than app-language-to-JSON-back-to-native-app-language.
Can't cloud do monolith? If not, what's stopping it? The performance bottleneck usually is and should be the database anyhow for must CRUD apps. Kajillion web services won't solve that. The CAP Theorem (Eric Brewer) limits your options and probably shouldn't be an app-side concern anyhow, but mostly a database side issue.
This kind of hype created a bloated stack in our org that requires dealing with 4x more code than a normal stack would. Nobody can give practical examples of the use of such splitting: they just spit out vague buzzwords stolen from Dilbert's boss, or dreamy shit like "what if we grow to Amazon.com size"? -- Yeah Right. We are more likely to get hit by a meteor while buying a lottery ticket on a unicycle.
Plus, these extra web layers seem a security risk: more doors for hackers to pick the locks of. Who is spreading this microservice rumor/hype? Russians? Microsoft marketers? Wrox? Knock-it-off!
Martin Fowler said:
As far as general IT advice:
1. Data tends to outlive application software, so focus on good data.
2. Be wary of wasteful hype. Let somebody else be the guinea pig. When that somebody else has it running well, THEN borrow the idea.
3. Books are judged by the cover for good or bad, so throw the executives a pretty bone for a few high-visibility parts of a system, but keep most of the regular stuff (grunt screens) in something easy to create and maintain. Don't drag down the entire system chasing eye-candy and UI fads. By the time you're finished, it'll be obsolete anyhow.
4. "Separation of Concerns" is a myth. Most non-trivial concerns inherently inter-weave among each other. You want to manage concerns well, not outright separate them with thick Trump Walls.
Table-ized A.I.
......
Everything in the summary seems to be more along the lines of things Executives need to accept about IT, but i'll add to it.
That you should trust your IT department over salesmen looking to make a buck at your expense.
That cloud tech is and always was harder to secure than your own hardware.
That when IT says "We have to upgrade this", its not a wish or a want, but a need.
That when IT says "we must patch this" it means NOW, not in 6 months. Losing a few days work now is much better than losing half your clients later after a massive breach that at this point everyone should realize WILL HAPPEN.
I could go on and on but the lack of overlap between IT folks and C-level folks means i'm just pissing in the wind, and so was this article.
Russian trolls and neonazi white nationalist capitalists will delete or mod down any insightful comments that go against their right wing nut boss Trumpkin all the while claiming leftists censor their free Confederate speech.
Equifax has learned the hard way that a woman with a music degree as CIO didn't keep their company secure.
Face the facts, women are not cut out for the long hours required to be good at an IT job. Maybe you can find an exception for an androgynous blob with purple hair who identifies as a woman. But really, those fatties have a litany of problems of their own. Those loudmouth cunts have more to do with driving normal attractive women out of IT more than any nerdy guys.
1. The whipped cream in the bathroom is not whipped cream.
2. We cannot escape ourselves.
3. And sometimes, the cat door... is closed.
-Forrest Cameranesi, Geek of all Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
1. State actors never have your own best interests at heart.
2. Frat tech boys will always get their feelings hurt. And whine whenever they aren't winning massively.
3. Comment your code. Always. And stick to naming conventions, it saves a lot of time - for you, and for others.
4. Low cost index mutual funds and ETFs will always outperform actively managed stock and bond funds. Property will always outperform all of these in areas of high population and job growth. You can't take it with you, so don't buy a house you don't need until you actually need it, and never look back.
5. Lists are for people who have problems. Which is, quite frankly, everyone.
6. Take showers and brush teeth/hair. Don't wear shirts or underwear more than one day. Keep spares at work or a gym if that's hard to do.
-- Tigger warning: This post may contain tiggers! --
Jeremy 'wannabe' Reimer, known failure in computers, is such a fool (scrum master, lol) & a known loser from arstechnica. Parent poster to you hit you on the head, didn't he, bullshitter Reimer? Yes, he did, and you can't stand it! A dunce like you that for decades has been 1 fail after another in dozens of "odd jobs" wouldn't know the first thing about what keeps projects on time and under budget, you total jerkoff - hahahahaha.
IT management should, frankly, become boring. The key to success, for the vast majority of companies, is no longer to seek advantage aggressively but to manage costs and risks meticulously
If you are in a technical position and you aren't describing your job in terms of risk and costs - you are doing it wrong.
Plain and simple -- IT costs money. The people who operate and implement IT cost money. Every bit of IT that gets implemented, from email to that fancy CRM system require money to do right. Even if you move stuff to the cloud, outsource or push it out to front-line staff to do it themselves will always cost money.
The trick is to make that money you are putting toward IT to good use. You will spend it regardless if you make it your competitive advantage or not. So, the smart companies use technology as their competitive advantage rather than just as a cost center. Making IT a competitive advantage costs a bit more, but ultimately it will put more money into other parts of the business.
You can't fix stupid.
IT departments need to understand that they have more in common with facilities management than with any other department. It's their job to make sure that the tools that people use to do work, work. Nobody cares about how migrating to the latest greatest Cloud 3.0 platform will make licence management easier, or exactly WHY the wifi keeps going down. They just want to get on with their jobs. This applies if you're a software house, a widget factory or a coffee shop: IT is just another thing that needs to work in order to get shit done.
A good IT department is a huge asset, but the best IT dept is one you only hear from when you have a business need that needs a solution. We don't have time to play with your latest toy, not the patience to set up yet another thing you think will be helpful, or worst of all redo something we've already done because you've pushed out a breaking change that requires users to do work to fix.
The disconnect between what IT thinks they do and what the rest of the business wants them to do is the reason why IT is often viewed as disposable and underpaid. To us, you're digital janitors; HVAC maintenance guys at best. Except those guys unionised and need access to the premises, so we can't just fire them all and employ people in developing nations for 1/3 the cost. Demanding stellar salaries for keeping the virtual lights on and keeping out of the way of revenue generating departments is a one way ticket to downsizing.
I'm 42, so I'm officially an old fart when it comes to my IT job. I'm in a senior engineering/systems architect job and one of my favorite aspects of it is my unofficial duty to impart wisdom on the newbies. My "hard truth" about IT that surprisingly few people truly grasp is that you can't get comfortable being the expert at one particular thing and coast. Even 10 years ago you could do that...I know so many people who make more than I do jumping from contract to contract doing CCNP-level router work or being the "EMC/HPE/IBM storage wizard." The formula for success used to be to pick a vendor, steep yourself in the technology, then get and keep certifications while learning what's new every few years. This is rapidly going away...regardless of what you think of cloud, CIOs hear the magic word "OpEx" and suddenly all that on-premises hardware and knowledge is out the window. For years, I did a combination of Windows Server, Citrix XenApp and System Center as my core skills, while trying to learn as much as I could about other areas. Even that has changed so much in the past couple of years...desktop apps are being replaced with web apps, containers, APIs, anything that abstracts the client layer and makes it look and act like a smartphone.
These days, one of my jobs is to do the systems design for a huge project in Azure. Anyone thinking they can just pick up a cloud provider's stack of tools overnight is in for a bit of a shock. Couple that with the fact that all the cloud vendors are releasing whole new features every week and existing features change almost as often. Part of my job has been trying to get as many of our engineering staff on board for learning cloud stuff, and it's been a challenge with a couple of people.
Keeping up with all the knowledge needed to be the guy they keep on staff when all the routine work is offshore is hard. I have had to dedicate a lot of off-work time to it, because no company trains their staff anymore...one of the things I hate about IT not being recognized as a real profession. The reward for doing this is a very interesting job and, not surprisingly, a higher-pressure firehose to learn from. :-) Being a dad on top of this is tough also...it requires lots of time management, late night reading and watching videos at 2x speed to do this and be a functioning parent.
So yeah...if you want to keep an IT job, especially as things get more and more abstract, broaden your skill set and learn as much as you can get your brain around.
San Francisco tech startups have a serious problem with gender equality nearly as bad as the one in Hollywood, but the rest of the United States doesn't, so they can shut the hell up with their hypocritical political garbage.
Design your network and code assuming you are working in a permanent state of compromise.
If you don't get third party audit for your work, you're stagnating and weak.
Your manager is stealing from you and your family. Make or join a union.
Your coworkers don't respect code elegance or network up time. They care how you make them feel.
Certs are important. Get them. They mean money for you.
There's someone who can do the job cheaper. There may not be someone who can do the job better. Management frequently prefers cheap to good, but if they like you, you'll stay around.
Management will fire you to bring their kids on in your place.
Conferences are useful.
Your job should be your hobby. Your new hobby should be something else.
If you become a manager, some of the people working for you will resent you. You can't do anything about this.
Kids will interfer with your job. Wait to have them until you are an expert at IT and managing your coworkers.
Don't be afraid to be the biggest nerd in the room. It's your job. A CIO who avoids technical matters won't last long.
If you have regulators, they know who is good and who isn't. Ask them and they might tell you.
Don't use mb5, rc4, or des.
Linux is more expensive than Windows.
You are a red line on the budget. You are nothing but an expense Your department just beg and grovel to justify its existence at every turn.
When something breaks, and you fix it, the value of fixing it will not be seen by the company. They will only see this red line on the budget fucked up and expanded that red line even further.
IT is information technology. So information is a main part of this.
In order for 7 billion plus to succeed technologically though we some wisdom as well.
That's the REAL meaning of DevOps.
DevOps does not just mean writing deploy scripts.
Every upgrade cycle you skip makes the next one that much harder...
Let that insight educate you as to why so many critical business applications end up using products that change infrequently (aka 'are stable').
DevSecOps is where the industry is headed.
100 REM PISS OFF CODE FASCISTS 200 GOTO 100
No one cares about it unless it's off.
I've worked on IT problems for a very long time.. coming up on 30 years here soon. In all sorts of contexts, academic, government/miltary, ISPs, ASPs, cloud providers, SaaS entities, traditional IT departments, telcos.. you name it. Ever work at a company that has 64 different billers and no plans to ever consolidate? Ever work on an awesome tool only to have it replaced by index cards because the guy in charge was afraid of computers? Ever build a perfectly capable monitoring/management platform only to have it replaced by an entirely substandard version because yours 'wasn't invented here'? Ever watch as a vendor takes big chunks of a companies money every 3 years because no one remembers the last time said vendor couldn't deliver even though it was only 3 years ago? Ever watch project after project fail because anytime any modicum of project management is applied or development methodology attempted all progress comes to a screeching halt? I have and I can go on endlessly... with examples of IT failures and very rarely, IT's successes. To sum it all up, to me, all forward progress in IT is made by people who actually know what is going on ( both from a technical and from a business/political/social perspective) .. and generally, all hard problems associated with IT are caused by the poseurs and the leeches ( in either domain ). 2 examples of poseurs.. execs that use vendors to do everything for them, including thinking for them .. or the 'X specialist' that refuses to learn the 'Y domain' because of the 'religion/supposed magic/history/tradition around X' .. 2 examples of the leeches.. the person that blocks any attempt to introduce something new or fix lingering issues because they want to protect their job.. or generally 'project managers/scrum masters/etc.' For me, the team/module is too big if you can't run it or extend it with 8-12 people .. beyond that the overhead causes everything to cave in ( not a new concept .. see MMM's surgical team concept from 1976) .. I can go on endlessly.
The low point of the poseur/leech problem is this recent love affair people have with 'imposter syndrome'... it's as if the poseurs and leeches are wanting desperately to rationalize their reason for hanging around and have created this sad justification. Let's rather focus on the 'burden of the expert'.. having to constantly claw your way thru all the artifice and detritus stood up by the imposters and instead find a way to clear these folks out, make IT into a real engineering profession, and then finally automate and converge IT away as was promised long ago .. and not have IT itself leech off the system forever with teams re-developing every possible thing over and over again in the next new fad methodology or language. Sorry for the rant.. IT could go on forever. :-)
A June 2017 survey of 300 IT pros found that 80 percent said the cloud wasn't meeting their expectations due to problems with security, compliance, complexity and cost. According to a January 2017 survey by cloud management firm RightScale, from 30 to 45 percent of enterprise cloud spend is wasted.
No shit, Captain Obvious. The whole, "Giving The Keys to The Kingdom to Someone Else" idea (otherwise known as Cloud Computing) was idiotic from the start. Of course it was, is, and always will be, costly and inefficient. It boggles the mind that otherwise (presumably) smart people would be so stupid as to buy into that particular brand of snake oil.
The only surprising thing in this section is that RightScale stopped at 30 to 45 percent. In my experience, the waste (meaning absolutely no benefit for the dollars spent) is closer to 85 to 90 percent.
Software is crucial for every business, regardless of industry. If the VPs and CEO don't understand software, the business is doomed.
You are constrained by your circumstances only as much as you are willing to go out on a limb and risk failing.
And web management GUIs are a sickening fad of instability.and inconsistency.
-
Windows, Mac, Linux, you name it... it's not secure, by design. None of them implement the principle of least access (POLA). All of them are default permissive environments which makes it impossible to specify at run time the extent of side-effects allowable from a given process.
My running estimate is 10 more years before people wake up and start re-engineering things to shift paradigms. Until then, chaos will continue.
Know absolutely nothing.
Congrats buddy. Your post is the first time I've ever seen the word "OpEx" used in a sentence that does not also include the word "CapEx"!
Do not mingle "Shadow IT" with BYOD. They are only tangentially related.
Shadow IT is a symptom of a seriously shitty IT department. The
customers will only waste their time if they think they can get something
better out of doing it themselves. If your IT department isn't total shit then
you don't have a problem with competition here.
I do not block ads. I do block third party scripts.
Unless you are in some kind of Internet business, you are not a line department. You are a support department. just like the janitorial service. You are being paid, not to pursue your own ambitions, but to make other peoples' ambitions come true. Maybe you get to do some professionally interesting things along the way, but to be a professional you can't let that affect your decision-making.
Perhaps a better analogy than the janitors would be the organization's lawyers. Corporate counsel a highly skilled position, but as a lawyer your job is to look after the interest of your client. If you decided to take a particular legal course because it involved a new and interesting legal theory that would be legal malpractice, but IT people do that sort of shit all the time.
I have found working in the staff role very rewarding; you can even have a transformative effect on an organization. But if you're not interested in what the organization does and helping the people who do those things you'll never be good at your job.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I always wondered why the government moved managers around every two years. The reason is to avoid the possibility of ever holding someone accountable for fraud, waste, and abuse on mismanaged IT projects. As long as there is a culture of âoeIt was the previous management who let the contract go to hell there will never be any changes.â
The following is the fact that everyone should realize. âoeThe IT Department - delivering you yesterdayâ(TM)s technology tomorrowâ
IT's Glory Days have come and gone.
But actual experts are expensive. Stay away from IT "security experts" that cannot code, that cannot configure a network or a firewall, that cannot administrate a system, mailserver, DNS server or webserver and that do not understand how crypto works and what it can and cannot do. I have seen far to many of these people and they universally make things worse in the long run instead of better.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Security is an illusion and you're the mage.
Hardware fails, keep stock of hardware replacements.
Power fails, keep some generators.
Oracle auditings asking for more money so keep track of licenses and re-read every 15 days license agreement changes (never trust them and keep them recorded on video): http://www.businessinsider.com/oracle-customer-explains-audit-threats-2015-9
You will have to keep reading constantly about new possible problems in the IT field and news.
Keep near the legal and accounting department.
Management will never give you the resources you need to do the project right. They will skimp on security, architecture, or the right hardware because they can't see it benefiting the bottom line directly. But if anything goes wrong (hacked, crashes, etc.) they will always have plenty of blame on hand to pass around.
I was working contract at the HQ for a x86 processor maker (yes, you can probably guess who) a couple years back and IT had banned any program which attempted to even READ from the Windows registry...which I found out when Visual Studio batch file (to setup its environment) complained about being able to find some of its installation paths
Rather than talking to IT to fix the problem, my boss pointed me to a network location which had a .exe to enable all registry writing...and a set of recursive directories for each OS going back to the 90's when it was a simple VBScript with the company's logo.
Hacking a solution to bypass IT had literally become the de facto design pattern for over 20 years.
(FWIW, I don't even blame IT...every I talked to was both nice and knowledgeable, but it was clear they were being handled like a commodity and had almost zero free time to help with anything that wasn't in an explicit ticket.)
-- Political fascism requires a Fuhrer.
The days of you being able to be condescending, or rude, or throw tantrums because your technology or architecture was not the chosen one just because you're "just in IT, ignore him/her" are long, long gone.
Executive teams don't care if you're the only person who knows some obscure system anymore. They don't care how clever you think you are or how your CV for sure proves that you're "in the top x% of all developers". Software systems are not so much voodoo to them now as they used to be and they are perfectly comfortable canning your a** if you don't play well with others.
At the very least, your career projection will end if you think behaving like Dilbert is cool (if you just think Dilbert is cool you have a whole bank of other issues which may or may not be career threatening).
I taught grads for a few years and was asked over and over for one piece of advice to help with their career...most were expecting "learn java" or "learn python" or "learn X" but it was always the same...don't be a d*ck and your career will be just fine.
1. CIOs are fags.
2. k0d3rz are fags.
3. clouds are fags.
Depends what sector of IT, but it's an ungrateful job.
You have to constantly learn and improve. ... and treated that way too.
Companies tend to hire younger people they can exploit more.
Companies tend to hire cheap barely skilled labor over investing in quality people.
Management has no idea what they're doing, as most of them don't understand IT at all.. they just know buzzwords such as Agile, Cloud, whatever.
If you're in some kind of NOC, you're basically a plumber.. and treated that way too.
If you're programmer you're basically just a drone
Etc. Etc.
I've been in IT since 2001, it's getting worse and worse (at least for me) to the point where now at 32, I'm trying to make something of my own (product/service) so I at least I don't have to deal with bosses, management, agile standup bullshit meetings, or discussing cloud providers.
Hopefully I will, otherwise I might commit suicide.
IT is a support function - it's job is to keep the rest of the company moving.
All the security in the world is pointless if the actual task at hand can no longer be performed.
For example, my corporate IT policy forbids me sending "files" to customers. It enforces this by not allowing FTP access, and not allowing binaries, archives, etc. to be transmitted in email messages.
This is kinda funny, because my job is writing software. I'm literally being paid to create binaries and send them to customers - something I'm no longer allowed to do. So what are my alternatives? If I'm remote-debugging an application in another country, should I just send them USB sticks or CDs every time I have an update? Or should I just fly out and stay in a hotel a couple of days each time?
Oh, and if someone sends me a binary or an archive (or an SVG drawing - very dangerous, those), the mail is simply disappeared by the corporate email system, with neither a message to me that this has happened, nor to the customer that their message wasn't delivered. About the only thing I can think of that is even more secure is to just abolish email altogether.
Since we switched to Skype for Business we haven't been able to make phonecalls either, so if they removed email, in any practical sense I could just stay at home. Nobody would notice the difference anymore...
Anyone thinking they can just pick up a cloud provider's stack of tools overnight is in for a bit of a shock. Couple that with the fact that all the cloud vendors are releasing whole new features every week and existing features change almost as often.
The key is to keep things simple. You really don't need features like AWS Lambda, even though they are really fun. If you treat the cloud as a plain vanilla way to spin up and down servers, then you can build a robust, portable architecture that won't need to be rewritten at the whim of a vendor.
"First they came for the slanderers and i said nothing."
Fanboys are the and tech evangelists are mind rot incarnate. Nothing is black and white and tech is a tool. Many tools can do the job. Some better than others but there is no perfect tool for all job nor one that will do the job the best. No coding style or language is superior. Just because something is popular does not it good. Black jewish transgender Vagina is not the magic bullet to diversity..
Look out Broham! There's a Nazi under your bed, and Vladimir Putin is hiding in your closet!
Here is my some so far unlisted experiences from me, after 16 years in IT in various roles - right now as IT Strategist in a large organization.
1) All IT solutions are more or less temporary and constantly evolving. Continous evolution of the systems environment is generally less risky than big projects that aim to replace several systems. Often, sticking with your old systems and adding, replacing and removing functions works best.
2) Getting new systems is easy compared to migration from old systems and decommisioning.
3) Collecting requirements from users are generally very hard and often fails. The best requirements specifications is a current systems or sometimes an advanced excel sheet that has outlived itself. These can be seen as prototypes.
4) Large scale IT operations can save money but it also adds maintenance complexity, which costs money. The IT cost is not what matters. What matters is the total effect on business.
5) Technical arguments to replace a application should be vetted carefully. If someone proposes that a new system is required because the old system is based on legacy COM+ or some other obsolete framework, this is often incorrect. It is very often much cheaper to replace different modules in applications.
6) Measure as much as possible. Website uptime, usage statistics, server usage, response times, firewall rule hits, database requests, etc. Users and system administrators are very ofter clueless on how much their application is used or if it works properly or not. The IT department should set up a good measuring framework. Only the experts even know what can be measured.
7) Don't overdo ITIL or similar frameworks. If you have more people on managerial roles than technical roles, you have problems.
... time and time again, for all of us in IT:
The world doesn't revolve around you.
IT may be a cornerstone, but it's very often not the actual business. If IT falls, personnel will switch to pen and paper. If everything else fails, the best IT is pointless.
Don't over-estimate your own importance.
We suffer more in our imagination than in reality. - Seneca
By outsourcing the credit cart portion, do you mean the good ol' pay pal solution?
1. Management doesn't understand shit about IT
2. Management is always right
Slashdot, fix the reply notifications... You won't get away with it...
The cloud is secure.
That men and women, on average, differ in their interests, and therefore without setting different standards for one over the other in any given field, you will not achieve an equity outcome.
I think this is right, but choosing a vendor/technology to beef yourself up on, especially on your own time, feels like playing roulette -- you have to put it all on 23 red, essentially, to develop anything remotely like "expertise" and then *hope* that whatever you've invested in is "the thing" that your management, industry to even employment region, decides is the thing they will invest in.
It used to be a higher-percentage bet that whatever you invested in would have a good chance of paying off. But I've seen too many people buying into something only to find out it doesn't pay off because it turns out to be marketing BS or winds up in reality being not the economic choice people with money want to make (or, you seldom lose betting that management is cheap).
The other thing is that I mostly reject the notion that self-investment in most technologies produces anything like expertise, with the possible exception of software languages where there's a lot more opportunity for in-depth implementation. I run into plenty of people who are certification/video/example experts but who really have zero grasp of the logic/rationale of operational choices and real-world applications. And in many cases, it's not their fault but the reality of extremely expensive equipment, restrictive software licenses, and the hard reality of separating hype from fact in real-world implementations.
For a lot of IT technology you need a lot of time and an awfully big sandbox to think you've developed any "expertise" in a particular technology. I'm increasingly convinced that only real-world production experience counts as actual expertise.
In fact, most of the time it is worse. This latest massive security breach in WPA2 is directly because of some shitty amateur developers put down the bong one day and wrote a wireless subsystem for linux. IT must learn that using open source wont solve your problems, and statistically speaking is likely to make it MUCH worse for you. We need less Linux and more Windows in the datacenter.
Hosts protect where addons can't (or as well):
Bad sites (past ads)
Botnet C&Cs
DNS down or poisoned
Trackers (dns logs/ads/transparent ISP proxy)
Dns blocks
Spam/phish payload
Slowdown 2 ways: adblocks & hardcodes
Hosts = Ez edit.
AB+ 151mb https://www.google.com/search?q=Adblock+memory+consumption&btnG=Search&hl=en&gbv=1/
UBlock 64MB https://www.google.com/search?q=UBlock+memory+consumption&btnG=Search&hl=en&gbv=1/
Hosts~16mb
Addons = ClarityRay defeatable & crippled http://www.businessinsider.com/google-microsoft-amazon-taboola-pay-adblock-plus-to-stop-blocking-their-ads-2015-2/
NoScript tag parses. Hosts block script prior to it!
No 1 addon does as much.
Stacked addons slowup.
ADDONS = EXPLOITABLE https://news.slashdot.org/comments.pl?sid=11166303&cid=55266729/
APK
P.S.=> APK Hosts File Engine https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/
The whole point of this thread was that some jobs unnecessarily have advanced degrees as prerequisites.
If employers do not want broad-based knowledge and education, why do many IT jobs require college degrees?
Yes, employers do list jobs with very specific requirements - many times after listing a broad based college degree requirement. This tells me they want a formally educated individual with specific work experience.
The trades have similar requirements. I know many certified technicians (HVAC, Automotive, and Industrial) who have either two-year engineering educations or VocTech and their employers still require job-specific experience along with the broad education.
Are there some employers who only want one very specific particular skill? Yep - and I'll bet your "career" at those employers will not last long - as soon as that technology is gone - so are you.
The original Slashdot poster took the article out of context. What the article said was most companies will be taking a hybrid approach to the cloud. The article also said that a great deal of cloud spend is wasted due to lack of cloud expertise and experience. The article never said the cloud was an absolute failure as the Slashdot poster did.
As a cloud architect I spend a lot of my time optimizing systems that were shifted to the cloud without proper planning. The cloud is not the answer to all problems and it utilizes different programming patterns that most developers are unfamiliar with. A lot of the time code was not written to be scalable or resilient which can be fixed. I think many developers hate the cloud because they don't want to change. Perhaps a better reason for them to hate the cloud would be that a few well placed PaaS components (available from all 3 major cloud vendors) could eliminate 50% to 75% of the code needed to write an application. If that seems unbelievable you should see how many applications get thrown away during an application audit prior to a cloud move because they were found to be nothing but a report that Excel could do just as easily.
In a large organization, non-IT employees will outnumber IT members 100:1. IT members will be focusing on a billion different things throughout the day... but Janine in Accounting is freaking out because her monitor is flickering and Allen, her assistant, knows how to troubleshoot but got his head bit off the last time he unplugged a cable. So IT has to send someone over to give a once over and hear the bullshit from Janine about how this has completely ruined her day, etc.
Get to know Allen. Allen knows shit. He just doesn't code. Use Allen, don't hate on him.
Bring Allen in to meetings when discussing the new procurement system you're building for Accounting because he knows enough of the Accounting side and enough of the IT side to bridge the gap for both groups.
... there are no 'musts.'
Requiem for the American Dream
Windows is a virus.
Don't have a lot of Agile experience, managers seem to love the "latest" (it isn't all that new) buzzword. I've found a lot of the principles are done anyway with a good back and forth relationship with the developers. However... I've noticed that doing rapid Agile type development exacerbates some of the existing challenges in testing, namely regression testing. Basically you have to be testing ALL the time. I'd have to block off essentially all my time for testing, whereas in less iterative approaches, you test for a specific release, go do other stuff you have to do for your job, then when the time comes, do some more testing on a release.
One of the PITA of testing that everyone will understand is regression testing where whatever it is that is being worked on, breaks something else, many times with no seeming connect (at least at the time). Anyway with more discrete releases I think it is easier to nail this down. However when there are constantly releases, of which any of them could break anything else, you just end up testing ad infinitum for the duration of the project. Which is fine if you have one project you work on. If you have a dozen projects all on the go, it becomes untenable. So I guess it is more of a resources issue that management might not understand. Also some of those principles of Agile basically box up failures into critical or not, which one would do normally anyway, but again due to the numbers involved, some of those non-critical can snowball into major issues, to which at that point it's too late. There seems to be a lot of, well with Agile, you just got to live with mistakes and move on and do more Agile, etc... Doesn't make for a very stable release ever.
All the meetings are supposed to facilitate better communication that is needed in such short intervals/iterations, however I've found wasted time where you're testing a function in the test environment, only to find out later you wasted your afternoon because the developers had already fixed it in the development environment, but it wasn't ready for deployment yet, etc...
Anyway not supposed to be a condemnation of Agile, but it has its issues, and is certainly not infallible or the fix that management might think it is. A flexible waterfall is just as good if not better in many situations. I don't know too many that do a strict waterfall anyway in reality, which is indeed somewhat cumbersome. Agile is the other end of the spectrum and at least in my opinion, just as cumbersome as it's opposite. I think much of these methodologies are a way for management to try to idiot proof or reduce the amount of skill required for any particular project. However reality is, if you get good developers, and good project management, business engagement and documentation, and testers that know what it is they are looking at you will always have better outcomes than less skilled, but following a strict methodology. Bottom line from a management perspective and project costs, methodology is free, and skill costs. However at the end of the day when looking at TCO it might not be, but then again, that might be another project and another manager, call it a success, put it on your resume "AGILE" and move on...
If we take "IT" to mean a general IT department, not just any use of computers in a company (i.e., we leave out embedded processors in products, software development where the software is the company's product, etc.) then a few hard truths might be:
There is rarely if ever an easy "one size fits all" answer for corporate IT strategy. If you don't have a senior IT staff that first understands their company's business, second understands the IT strategy in support of the company's business, and third understands how a particular new technology (such as a cloud service) may play a role and can talk about the pros and cons, then you may be doomed to have a chaotic "strategy" where personal power drives decisions and the company's IT solutions depend upon the powerful regardless of whether they are knowledgeable. You may also be doomed to weak and ineffectual management by committees and decisions by default because no one dares to take a stand in favor of what they think is right (and few would understand a cogent argument even if laid out in comic book form).
Everyone in your company can do "IT" (they don't need you to do it for them). Ever since DEC started selling Peripheral Data Processors, then the first "departmental minicomputers" (Data General Nova, DEC PDP 11/70s, VAXen, etc. etc.) emerged on the scene, corporate IT departments have been locked in a tug-of-war over who does "IT". If the corporate IT department wants to be in charge of IT, they have to demonstrate their leadership and competence at delivering IT solutions that the business likes and can use effectively (at least effectively enough that they don't decide to go off and do it on their own).
Change in IT is constant. Just when you think you are done and can rest a bit, something new comes along and you have to figure out what its value is now, what its value will be in a year or two, and how to control the adoption/integration of this new thing into your every changing set of IT solutions.
Although change in IT is a constant, at a high level many things remain the same. The business needs tools that help them do their job (whatever that is). It takes time to achieve new capabilities, but if it takes too long to get the new thing working, the need has changed by the time that you do. Business needs to trust IT, and IT has to respect and support the business. Users are *not* a "test load" on the system, they are the reason why you got to spend a bunch of money on the system in the first place; if you piss them off, you will eventually be in a bad place. Not every bright and shiny new thing will find a place in your environment, but you will have to be able to communicate well with the advocates of each and every one of those bright and shiny new things.
There are probably more "hard truths," but that is a start.
I totally agree, and this is the eternal problem. Employers want instant drop-in replacements for job candidates, and it's totally impossible to do it all anymore. You have to have a focus -- mine has been on systems and end user stuff, and I've been shifting as needed over to Azure stuff, mainly focusing on IaaS. The problem, like you said, is making a wrong bet. My solution has been to learn a lot in my core field and sample from others, being ready to learn as much as needed. You have to choose how you use your valuable time for learning and how far down each rabbit hole you need or want to go.
My real-world example is as follows...I've shifted from end user computing to systems engineering, and a couple years back I started hearing more and more "web developer-y" talk. Web dev is something I just haven't been involved in -- beyond standing up the odd Apache server or putting an app into IIS and tweaking a web.config file. But with the "API economy," and cloud providers using RESTful interfaces to manage resources, I had to get semi-skilled. I had to learn enough about certificates to be dangerous, scripting and PowerShell imprvement, how REST works, some provider-specific syntax stuff, etc...all while keeping my feet in the day to day stuff I was working on. When it came time to start working with Azure, I had to ramp up extremely fast but having at least some clue about "how to learn" everything really helped me out. AWS and Azure and GCP have documentation aimed squarely at "dudebro developers" cranking out JavaScript apps at startups. Coming at it from an infrastructure side means having to learn a few new skills, new vocabulary, etc. before you're truly productive.
I'm not saying it's an easy problem to solve. What I am saying is that keeping your eyes open is important. Learning to spot what's a fad, what's a rehash and what's going to require massive time investment to keep up is important. There's tons of "fear of missing out" especially now that people are starting to call 4 year old technology "legacy". If you let yourself become too narrow-focused an expert on one particular field, it can leave you in a bad position if you miss a key shift.
Stay down in the sewer you filthy clown!
Some settling may occur during posting.
IT is no longer a magic pill that makes everything cheaper and faster. It's now considered a fixed cost that needs to be cut like anything else to increase profits. Your job is to make IT cheaper, efficient, and require less people. End of story. Doing your job well means that people will lose their job, and be forced to find work elsewhere.
1. This is old, and therefore good.
2. This is new, and therefore better.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Tynan writes about how the idea of engineering teams sticking a server in a closet and using it to run their own skunkworks has become more open; ... Can you think of any other hard truths IT must learn to accept?
FFS Shadow IT is the number two security threat for any company. The number one threat are the active hackers/spies, but shadow IT are like the dummies in a vampire story who despite all warnings invite the vampires in the house.
If your processes depend on humans never making a mistake, then they are doomed to failure!
Humans are not infallible beings, they will make mistakes. Your processes need to anticipate those mistakes and be able to recover gracefully from them.
Hard truth for the vast majority of IT people iâ(TM)m afraid- they donâ(TM)t view what they do as a service to the organization, and therefore do not do enough to understand their customer. Itâ(TM)s the same problem I saw when I started in IT in the early nineties, and NOTHING in ITâ(TM)s perspective has truly changed. The only difference now is that the business has more pervasive services and shadow IT tech available to them at a reasonable cost, and for many of us, our jobs are going out the door as these services come in. There are a lot of reasons for this, not all ITâ(TM)s fault, but ironic that itâ(TM)s the technology departmentâ(TM)s need for centralized control and resistance to change that is bringing about the commoditization of internal IT. Sad but true... sorry.
Years ago my (former) company switched from local, in-house file servers to ones 2/3 of a continent away. With all the security verification, file opening times increased from well under one minute to 3-5 minutes. Thousands of employees spent more than 15 minutes per day waiting for files to open. (So let's call this $15,000 per day lost productivity - using the company's internal cost numbers - an invisible cost.)
To avoid the file opening hassle, many employees tended to leave the files open all day, even when on breaks, at meetings, or out to lunch. So security wasn't enhanced either.
But IT management could tout that they could lay off a half dozen staff and avoid server upgrade. So, a small visible savings versus a large invisible cost. Promotions were inevitable.
Employers want instant drop-in replacements for job candidates, and it's totally impossible to do it all anymore.
I feel like this is the real crux of the problem. Employers simultaneously want someone with broad enough experience across disciplines to be useful in all of them, but *also* expect deep-dive expertise in all of them at the same time or any one of them at any time.
I think this was mostly possible 15 years ago -- you were kind of worthless not understanding switching, networking, server hardware and OS all at the same time to some fairly deep level, and all of it was mostly obtainable.
Now? I only see a couple of those things being understood at deep, expert levels at the same time. I think you can functional in all of them, but not really in expert in any of them.
What's funny is when you get exposed to some of the heavily silo'd people from a place like EMC. Once they start talking about *anything* outside their silo, it's like talking to my dad about technology. I didn't know it was *possible* to be a certified expert in storage systems, yet retain a 1995 level of knowledge about switched networking.
Ever.
Windows is not secure.
You still have to secure your cloud presence. It's just someone else's computer.
You need to backup your data offsite.
Consultants are not a replacement for people who know your business and can implement solutions tailored to your business.