I hope you’re all aware of my book The Software IP Detective’s Handbook: Measurement, Comparison, and Infringement Detection. It’s the first book on Software Forensics, a field that I pioneered at Software Analysis and Forensic Engineering and Zeidman Consulting. Whereas Digital Forensics deals with bits and files, without any detailed knowledge of the meaning of the data, Software Forensics deals with analysis of software using detailed knowledge of its syntax and functionality to perform analysis to find stolen code and stolen trade secrets. The algorithms described in the book have been used in many court cases. The book also describes algorithms for measuring software evolution, particularly as it relates to IP changes.
If you are a teacher, this is a great time to incorporate the materials in the book into your courses on software development, intellectual property law, business management, and computer science. There’s something for everyone in the various chapters of the book. Your students and you will be at the forefront of an important and very new field of study.
If you’re interested, please contact me.
In the past few years I’ve been interviewing students for job openings at my companies. Some students came from large, well-known universities while other came from small colleges. Some students had bachelor’s degrees in computer science while others had master’s degrees. One thing that many of these recent graduates had in common was that they couldn’t program competently.
I found that these graduating students were adept at finding code on the Internet. When I gave assignments to code a particular algorithm, I was seriously impressed with how quickly they were able to find the code online. When I asked them to modify the algorithm, they struggled. Also, testing and debugging code often seemed beyond their abilities. Many of them were unaware of debugging techniques that allow them to focus in on the problem, such as using breakpoints to isolate chunks of code or forcing conditions that cause certain code paths to be executed.
The art of commenting also seems to have been ignored in most computer science education programs as well as in many companies. In my companies, our coding standard requires that every routine, no matter how small, must have a header comment that describes the functionality of the routine, all input parameters, the output of the routine, and any other information that someone using the routine would need. Yet most programmers out of school, and many working in the industry, produce uncommented code that is difficult to understand, difficult to debug, and very difficult to maintain.
Can you imagine a medical program that didn’t teach how to stitch up a patient after surgery or use the latest CT scanner? University computer science departments need to take a serious look at the skills they’re teaching. At my companies, I now require prospective employees to sit down at a computer and write a program that works correctly according to a written specification, is fully commented, and is completely their own code. I hope that the percentage of graduates passing this test increases in future years.