Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

10/15/2013
01:23 PM
Gunter Ollmann
Gunter Ollmann
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

The Reality Of Freshly Minted Software Engineers

Why do recent computer science graduates need to be retrained when they hit the commercial world?

Universities and colleges are pumping out more and more software engineers each year. Yet it would seem to many in the industry that the quality of these freshly minted graduates is decreasing. Perhaps "quality" is too harsh a word -- "immediate usefulness" would likely be more appropriate. What's the problem?

During my career I've been lucky enough to work with and manage several of the world's most renowned security engineering and research teams. In some cases, it may have been the pedigree of the development teams that made it inappropriate to recruit new graduates or anyone with less than five years of experience, but in other cases, with tight deadlines and demanding schedules, the development teams themselves weren't prepared to expend the energy and time retraining a newbie.

That problem of "retraining" has always gnawed at me and, during the past year or so as I've worked with a growing number of universities and computer science professors around the world, I think I have a better understanding and articulation of the root cause to the "usefulness" problem when it comes to new software engineering graduates.

At its crux, the delta between university and commercial development can largely be attributed to two missed opportunities in the computer science:

 

  • 1. Individual project development.Through various courses and projects, students predominantly work on individual study assignments. It is the exception rather than the norm that they engage in group or collaborative development projects. I've been told about a common perception among students of university "honor code" infringement when it comes to discussing assignments or collaborative work.

    The problem with this in the commercial world is that, unless you're a phenomenal and well-known uber-engineer (or working for a dinky never-heard-of start-up), you're almost never going to be working on a project or product as a sole contributor. At every stage of a project, you'll be working within a collective of software engineers, QA engineers, product managers, and project managers. Group communication and collaboration skills are mandatory -- so, too, is maturity.

    Very rarely is an engineer born with these key group skills; they're skills that must be practiced and reinforced through hands-on experience. This should be occurring daily within the university and college education program, but it's not.

 

 

  • 2. Creating fresh applications.Most curriculums place an emphasis on learning the dynamics and advantages of a montage of programming languages and styles. The vast majority of projects and assignments students will participate in will revolve around writing new applications or modules from scratch. Very rarely will students have to face code written by others, or, if they do, it'll be to find some kind of logic flaw or bug.

    The reality of commercial software development is that the vast majority of time a software engineer will be editing someone else's code. More than likely the code will be several years old, passed through the hands of a dozen or more developers over that time, and only rudimentarily documented, and the engineer will be tasked with extending some existing functionality. Refactoring existing code to make it more efficient or reflect new standards is a timely and costly task, and no product manager will allow that to happen without a great deal of fuss that'll be well above a freshly minted engineer's pay grade.

 

I suspect that many of the old-hands charged with running engineering organizations or leading development teams are nodding to themselves right this moment -- wishing, too, that the next batch of newbie engineers pouring out of the college and university gates were better prepared for the careers they have chosen.

The disparity between the skills newly minted software engineers arrive with and the operational needs of the engineering teams they eventually join are felt acutely within the security industry. It takes a special and finely honed engineering skill set to make legacy applications and the code they're written from more secure. Merely sitting through a course covering the secure development life cycle (SDL) isn't enough to make a difference -- new engineers need the communication skills to negotiate and socialize ideas with their colleagues, and the ability to tweak existing code snippets and routines if they're to be useful within the first few months of on-boarding.

Gunter Ollmann, CTO, IOActive Inc.

Gunter Ollmann serves as CTO for security and helps drive the cross-pillar strategy for the cloud and AI security groups at Microsoft. He has over three decades of information security experience in an array of cyber security consulting and research roles. Before to joining ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Becca Lipman
50%
50%
Becca Lipman,
User Rank: Apprentice
11/25/2013 | 9:44:03 PM
re: The Reality Of Freshly Minted Software Engineers
Excellent points, I see the same frustrations coming from the
software engineers who start at new companies, desperately trying to
reshape their thinking for their new role. The same can be said for other professions.

It's hard to knock
universities, they teach the skills they can in a relatively short
period. Perhaps they need more time, extra courses, or a mandatory
internship for the students to learn this group-think and refactoring.
IMO, too many group projects run the risk of pigeonholing skill sets when
students get comfortable taking on the same aspect of the project again and again.
tarnold282
50%
50%
tarnold282,
User Rank: Apprentice
10/21/2013 | 6:15:01 PM
re: The Reality Of Freshly Minted Software Engineers
It's not only newly-graduated people - I've found that it also applies to ANYONE who writes software, but not for "real products". In particular, I've seen this a lot from people who work in Research organizations - corporate ones, not academics. Like the student projects you describe, they tend to write everything from scratch without needing to consider things like maintainability or figuring out someone else's old code.
BrianY331
50%
50%
BrianY331,
User Rank: Strategist
10/17/2013 | 7:05:28 PM
re: The Reality Of Freshly Minted Software Engineers
Great article. I think there is an additional factor regarding the mile-wide gulf separating academia from the business world is that there is very little communication or similarity between what happens in the business world and what academia thinks goes on there. I find that vanishingly few computer science professors have ever actually worked in the industry, and many (most?) have never even met anybody who has. Their world of academic publications, tenure, and focus on mathematical theory rarely has anything at all to do with the actual practice of developing software. I have met many of them who believe that the papers they publish in ACM journals are eagerly being read by practicing engineers and used to build systems in the real world. While you can point to a tiny number of examples of this happening in a few areas (like graphics for example) it is uncommon even there and entirely absent everywhere else. While medical schools have active connections to real doctors and real hospitals, new CS grads have likely never even talked to an actual software engineer and may never have even talked to someone who has.

Ponder this, if you could hire one of two people for the same amount of money and one was a fresh CS grad and the other was someone with no formal education in software development but with 20 years of hands-on experience you would clearly hire the second guy, right? What if he only had ten? Likely you would still hire the experienced guy, right? What about 5 years? or 2 years? Comparing someone with a 4 year degree with someone with 4 years of hands on experience, I think I would still rather take the guy with 4 years of experience, all other things being equal. If that's the case, a 4 year degree is a waste of time regarding one's software development skills. It might well do you some good to read Shakespeare, learn calculus, and learn a second language, but when it comes to software development skills? It's not a good investment in time and money for most people.
Don Gray
50%
50%
Don Gray,
User Rank: Apprentice
10/15/2013 | 7:19:23 PM
re: The Reality Of Freshly Minted Software Engineers
Gunter,

Excellent article and I believe you have hit the nail on the head!

I am on an advisory board for my alma mater and the first few meetings I attended I tried to use my position to highlight these exact issues. I proposed that the university adopt a multi-year project approach creating 3 credit 100,200,300,and 400 level classes that would revolve around a 2 semester project that was designed by the Year 4 students.

Year 1 students would act as the Quality Assurance team, Year 2 students the Technical Analysts writing the specifications, Year 3 as the Infrastructure & Development team, and Year 4 as the Architects and Project Managers.

In my mind such a program would serve several purposes:

1) Create interaction amongst the students in different years allowing mutual learning and teaching large group project dynamics and fundamentals
2) Force every student through the 4 year program to see the many sides of a software project and the different roles involved
3) Create "ready-to-hit-the-ground-running" graduates that could actually be of some use

I was told that such a program was not feasible and unrealistic, even more strongly I was instructed that this was university not a trade school, the mission was to teach the fundamentals and theory not the application of it.

I should have known better, I tried 20ish years ago to get a 1 credit course approved to teach JCL, since the FIRST thing I was trained on when leaving college was JCL!

I think by adding in your concept of modifying existing code, you could have the Year 4 project by enhancements to the prior years project, giving the teams a 4 year exposure to the same codebase.
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
DevSecOps: The Answer to the Cloud Security Skills Gap
Lamont Orange, Chief Information Security Officer at Netskope,  11/15/2019
Unreasonable Security Best Practices vs. Good Risk Management
Jack Freund, Director, Risk Science at RiskLens,  11/13/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19012
PUBLISHED: 2019-11-17
An integer overflow in the search_in_range function in regexec.c in Oniguruma 6.x before 6.9.4_rc2 leads to an out-of-bounds read, in which the offset of this read is under the control of an attacker. (This only affects the 32-bit compiled version). Remote attackers can cause a denial-of-service or ...
CVE-2019-19022
PUBLISHED: 2019-11-17
iTerm2 through 3.3.6 has potentially insufficient documentation about the presence of search history in com.googlecode.iterm2.plist, which might allow remote attackers to obtain sensitive information, as demonstrated by searching for the NoSyncSearchHistory string in .plist files within public Git r...
CVE-2019-19035
PUBLISHED: 2019-11-17
jhead 3.03 is affected by: heap-based buffer over-read. The impact is: Denial of service. The component is: ReadJpegSections and process_SOFn in jpgfile.c. The attack vector is: Open a specially crafted JPEG file.
CVE-2019-19011
PUBLISHED: 2019-11-17
MiniUPnP ngiflib 0.4 has a NULL pointer dereference in GifIndexToTrueColor in ngiflib.c via a file that lacks a palette.
CVE-2019-19010
PUBLISHED: 2019-11-16
Eval injection in the Math plugin of Limnoria (before 2019.11.09) and Supybot (through 2018-05-09) allows remote unprivileged attackers to disclose information or possibly have unspecified other impact via the calc and icalc IRC commands.