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."
For Microsoft OSes, I was fine with XP. I didn't care for some of the UI changes that were done following Windows 2000, but it seemed quite stable.
You might be fine with win xp on at home (although you shouldn't) but it should have no place in proffessional environment. Windows 7 fixed some gaping security issues with XP. Here are some examples:
- in XP If something is started by a user with administrator rights, it automatically runs in administrator context, Win 7 has a much better structured User Access Control (though still not as good as even 80's era Unix)
- in XP the memory space for programs is alloted in sequential address spaces, which greatly helps when cracking a program, in Win 7 memory is alloted in random spaces
- win 7 fixes the Structured Exception Handler exploit of XP
- win 7 has integrated hdd encryption - win 7 includes moder crypto tools (though even those should be replaced with stronger ones soon)
Running your stuff on Win XP is just not feasible - not because of the superficial UI differences, but the deeply engrained unsecure mechanisms it employs.
I don't think of it as much a young vs old per say. But Baby Boomer logic vs. Gen XY logic.
The Baby Boomers have 80's culture stuck in their head. So their focus is on maintaining whatever power they have, so if that means they are the only one who know that old system and its years of undocumented workarounds, they will keep it, and make it theirs. It isn't that the new guys are unwilling to learn from them, many do, and find this older tech fassinating. But the old guys keep the secrets to themselves in fear if they let the whipper snappers know. Then their job will be useless. Until management realizes the risk of such an application controlled by one person is too high, that they will upgrade off of it, and if that Baby Boomer guys is too resistant and unable to learn the new one, his job is gone.
Gen XY culture knows some stuff too. They come in with knowledge of the new stuff and how to implement them. They can see why XML (Bah I am showing my age here) err. JSON is much better method of sharing data then flat text files, for a lot of cases, and how it can lead to less errors in the code, and allow for programs to expand. As well their sensibilities are different. Storage is cheap, CPUs are fast, they know the real bottleneck is the person. So they may implement "wasteful" code, as it can mean easier management. Vs the older method of highly optimized code where in the days Storage was expensive and CPU were slow, and the human cost was low.
Now they are a lot of older developers who keep on top of this stuff and are not afraid of change. They just need to learn to dump their old bagages and legacy systems and get onto the new ones, embrace the new kids on the job, learn from them, and you can also pass down experience too. They are a lot of unwritten rules, such as the appropriate amount of information to share with the client or other departments. How to anticipate specifications issues, and plan your code with hooks to make the code work as expected and not as stated. Avoiding the pitfalls of a program that will get you a good grade in computer science, that will get in the way of you making a good program. When to OO and when not too, heck there are times you realize those XML and JSON files are way too much overhead, and we should just give them a flat file. Knowledge on when to optimize, How to collaborate with other developers, were in college that would be called cheating. Explain the business decisions on why things are where they are at, even if you don't fully agree.
Older and younger developers are actually quite compatible. Just as long they are not in the mind set that they are competing for the same job.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.