Slashdot Mirror
CIOs Say New Talent and Old Tech Don't Mix
StewBeans writes: Usually when an article references "what keeps IT leaders up at night," it's a chance to talk about "shadow IT," losing control of tech spending, hackers, or some other overly-hyped concept. Adam Dennison, publisher at IDG Enterprise, opposes this interview tactic and says that "reports of pain are greatly exaggerated." IT leaders don't mind shadow IT or sharing control of the IT budget (in fact, they want others in the business to have some skin in the game), and they understand that they are probably being hacked. What they DO care about is talent. Dennison points out gaps in data, security, and app development, based on IDG's recent survey, and he says CIOs tell him that finding the right IT talent that is also able to articulate what the business needs to succeed with technology is very difficult. He says, "They worry that they can't move fast enough to adopt the technology they need because the new IT talent doesn't want to work on the old stuff, and the old talent doesn't understand the new stuff."
I'm one ofthe old dogs. I have to admit that App development and such is not my kind of things. But I do have experience. LOADS of it. When I see the fundamental mistakes by young "talented" programmers, it makes me cringe.
Just a few days ago, there was a kickoff meeting for a new project. This project needs multi-user support on the long run - everyone in the team admits that. And access control, with all its implications like "how to I check a password", "how do I store a password", "which kind of permission do I need to call this function". Which they never ever did before. None of them had ever heard of books like "Applied Cryprography". There is a copy here, on my shelf. Actually, it is my second book, the first was worn down due to heavy use. All they cared for was "Licence Management", but I'm not sure if they understand how this works properly. I offered them to ride piggyback on the existing licence management scheme I've implemented in my part of the system, but this was probably too unsexy, because it cannot add licences on the fly over the web, at least not "just so".
My experience tells me (and anyone who has been around for long enough) that any software that will need this kind of multiuser support needs to have this built-in from the very beginning. The very concepts of the software must be aware of the possibility that e.g. a call might fail for lack of permissions. Communication protocols must be designed in a way that they guarantee to a sufficient degree that one side has proper identification presented to the other side to be permitted to do this, and don't that. This is nothing that can be added lateron without SERIOUS headaches, problems, and, worst of all, risks. Windows9x was the living prrof of such a mistake.
Reply from the "young talent": Implementing multi-user is too time consuming at the moment, we will add it later. *FACEDESK*
You got by 30+ years doing the job you liked, but they also failed to think ahead and hoped to ride out the lifespan of the technology with the lifespan of their careers.
The "old" system offered people retirement and pension after 20 years, meaning many people could "retire" around age 40 with a modest pension. Not quite enough to live on, but definitely enough to support a dramatic change of career. And you could retire from your second career around age 60.
Turns out, a lot of people get bored, frustrated, or otherwise useless at their job in their 40s. Call it the mid-life crisis, if you like. Failure to adapt, if you like. It can be pretty useful to both the employee and the employer to have people change careers at that point, but it's pretty intimidating to do that if all you've got is a 401k that you're not allowed to touch until you're 59
1) Implemented a new automated web testing framework. Next year, I'll do the same thing for Android and Apple phones.
2) Migrated some of my control system apps to C#. Three months ago, I didn't know C#.
3) Migrated more system control software than I care to think about from VBScript (awful) to Powershell (slightly less awful).
Four years ago, I didn't know what virtualization was. Today, I'm in charge of the VMWare servers and couldn't do without it.
I have no idea why I can still do this. Like the other commenters here, however, I do regularly cringe at the latest business/software/process fad. They're inevitably retreads of something older and few add any actual improvement. Powershell, for example, although it packs more functionality into fewer characters than VBScript, made the skill set of thousands of system administrators obsolete. No thought was given to the human side of the system. A more useful solution would have been a rewrite of VBScript and the addition of useful function libraries and easier access to the net framework. It was yet another typically wrong Microsoft decision, but it says something about an industry that doesn't have enough of a balanced view to consider the cold, hard neurological facts of their user base.
Please do not read this sig. Thank you.
I have an older person right now cleaning up an unbelievable mess that two younger people made because they didn't know what they were doing, and the people managing them didn't catch it because they assumed young people are always talented and get everything.
Somewhat related CSB. 15 years ago I was working at a startup writing Linux device drivers for our product. Things were going well, I was on schedule, no issues whatsoever. One day my boss' boss shows up with a consultant who was supposed to help me with my work, he was very experienced, I could learn from him, yadda yadda yadda. Ok. At the time I was writing a PCI driver and was hip deep in the read part, so I gave him the write part. A week or so later I got his first cut, he was using an ioctl() to write data to the board. Hmmm, thinks I. This is different. But he's an expert, maybe he knows something I don't. Another week later I get more code from him that just doesn't make sense. I take him to lunch to talk to him a bit. Turns out:
1) He's never used Linux before
2) He's never written a device driver before
3) He's never talked to hardware before
4) He's only been programming for a year
5) In his interview he never claimed to know Linux, hardware, nor device drivers.
6) I never saw him because not only was he on a different floor, but he spent his lunch breaks in his car studying up on Linux
I went to my boss with a WTF, the guy was gone the next day. I felt bad about that, the guy was actually nice and once the blinders were removed from my eyes I realized he was very trainable. I never did hear why he was brought in, who interviewed him, nor how he became a Linux device driver expert.
That company was full of management problems, one of the biggies was at the CXX level they were all snakes in the grass who stabbed people in the back on a regular basis.