Share via

Computer Science and Software Engineering

  • Article

This is an opinion piece, and my opinion at that, not of my employer.  

I was watching a debate on one of the internal support email lists for debugger related things last year when an interesting event occured.  There is currently a limitation in the Windows OS that prevents ModuleLoad events being sent after ~500 of those events have been sent.  The conversation wandered into why you get some gains from performance if you keep the number of dlls down, and ensure they have their base adresses set.  To which there was a reply of (paraphrase):

 "I don't want to think about that, the operating system should keep all that from me, if I want to have thousands of dlls I should be able to"

Which set off alarm bells for me.  The hyperbolae of this statement is of course "don't bother me with constraints".  It also surfaces in how people treat memory allocation and usage in managed code ("Hey - there's a garbage collector - there are no leaks.  Um - why am I running out of memory - it must be a CLR bug").  Complete ignorance of the constraints of systems is a dangerous place to be.

I self identify as an engineer.  But of course many of us who are in professional software development came through Computer Science courses as their degrees.  Looking back on my own education, there were very few courses that armed me with the engineering skills I grew in my first few years as a developer.  I learned (the hard way in many cases) what it takes to engineer solutions that work within the constraints of the systems my customers expected.  I'm in no way bashing Computer Science.  Where would our industry be without the deep thinking and experimentation that carries on to this very day.  But when onboarding software developers, I think we need to do more to make them aware of engineering practices and principles in a more structured way.  In our own team we do this through a combination of mentoring and training, but by no means do we have it down pat (who does).  Different situations may call for different solutions. Until recently I never thought of how much that science vs. engineering discipline is actually implicitly demonstrated as opposed to being explicitly stated, but now I think on it, it's a useful conversation to have with those new hires.

Something to ponder as the next wave of scientist/engineers walk through the doors into industry from university.  Please discuss through the comments section!

 John

Comments