Ethical vs Policy Crisis

This past Christmas I read a lot of posts from my friends about their kid's love of Harry Potter and their Harry Potter themed Christmas gifts. It is pretty awesome that they were able to have this shared interest. So when I read this past Penny Arcade comic, https://www.penny-arcade.com/comic/2018/04/30/hogwash, I was shocked and angered. This hits close to home: My friends might be experiencing this extortion. If the comic doesn't provide enough information (it didn't for me) then read (or skim) https://www.eurogamer.net/articles/2018-04-27-harry-potter-hogwarts-mystery-is-ruined-by-its-in-game-payments.

Summary: There is a scene in the game where the player (your child) is getting choked by a vine. They can either pay real money in order to stop it or wait for their energy to recharge (many minutes of watching their avatar get choked). And there are many other things like that.

This comic strip is so spot on; panel 2, especially so. I've read several articles in the last few months calling for Computer Science to include ethics in more classes instead of the traditional capstone course on ethics. In the Jan 2019 issue of CACM, Moshe Vardi pointed out that more ethics in classes will be nice but that it won't change anything. The only thing that will force these companies to change is public policy -- regulation that bans these practices that target children. (Sorry, I have to say it for the sake of completeness.) If this stuff* matters to you then you need to write to your state representatives.

* stuff being any unethical practice being carried out via a computing device.

Computer Science Areas and Their Journals/Venues

A summary of Computer Science areas, abbreviations, and their corresponding journals and venues.

I started to link each of the journals/venues to each Computer Science area then found that I kept going to Microsoft Academic Search to look them up.

Artificial Intelligence (AI)

• AIJ, JAIR, JAR, AAAI, IJCAI

Bioinformatics (BIO)

• BMC Bioinf, Bioinformatics, JCB, RECOMB, TCBB

Communications and Networking (COMM)

• TON, TCOM, Mobicom, Sigcomm, Infocom

Compilers and Programming Languages (C+PL)

• OOPSLA, POPL, PLDI, TOPLAS, CGO

Computer Architecture (ARCH)

• ISCA, MICRO, DAC, ASPLOS, TCAD, SC

Computer Graphics (GRAPH)

• TOG, CGA, TVCG, SIGGRAPH

Database (DB)

• TODS, VLDB, Sigmod

Distributed Computing (DC)

• TPDS, JPDC, ICDCS, ICPP

Human-Computer Interaction (HCI)

• TOCHI, IJMMs, UMUAI, CHI, CSCW

Image Processing and Computer Vision (IPCV)

• IJCV, TIP, CVPR, ICIP

Machine Learning (ML)

• JMLR, ML, NECO, NIPS, ICML

Management Information Systems (MIS)

• ISR, MANSCI, JMIS, EJIS, MISQ

Multimedia (MM)

• MMS, TMM, IEEEMM, MM, ICMCS

Operational Research and Optimization (OR)

• Math Prog, SIOPT, C&OR, Disc Appl Math

Security (SEC)

• TISSEC, JCS, IEEESP, SP, USS, CSS

Software Engineering (SE)

• TOSEM, ICSE, TACAS, ESE

Theory (TH)

• JACM, SICOMP, STOC, FOCS, SODA

Pair Programming

I'm a big fan of pair programming. I have used it many times and almost everytime the result was better code that was developed faster. Pair programming is like having continuous code review.

Sadly, there is a lot of controversy with this particular agile/XP practice. Seeing two valuable resources sitting down at one computer makes most managers nervous. They think their team's productivity has just been halved. The worst thing about this mentality is that it makes it clear that the manager thinks programming is just typing.

Mere typing, programming is not. A good idea or a bug caught early on in the process can save a team a lot of work and rework later. By pairing you share valuable knowledge and practices throughout the team, catching more bugs early, and increasing code quality.

Merciless Refactoring

Many people are afraid to make code changes out of fear that they will break the code. To ensure you can safely make code changes you should change it often. I'm not talking about pointless changes but solid improvements. Run FindBugs against your code and fix the issues. If you disagree with FindBugs then use PMD or any static analysis tool. However, if static analysis suggests that your code looks like a bug then consider changing it to look less dangerous.

Anyway, the point of merciless refactoring is to always be improving your code. To make changes and ensure that it was easy to make those changes. If it isn't fast and easy then you need to make changes to make it fast and easy. Write unit tests, delete unused code, optimize loops, automate tests; everything you can do to make it possible to complete your next project in record time.

Merciless refactoring can also be described as following the boy scouts rule of always leaving a place cleaner than when you found it. If you add a method to a class then add some JavaDocs to the other methods while you're there. If you change a single line of code in a method, take a look at the entire class and fix it up if you can.

Donald Knuth

Dr. Dobb's Journal published an Interview with Donald Knuth in April of 1996. It was a very good read.

Knuth discusses what distinguishes a "computer scientist" from a "computer programmer" but neatly side steps actually separating the two terms. Choosing to instead explain how computer science is about thinking about problems in a different way. (You'll have to ready the article to see what I mean.)

There is some discussion about Knuth's The Art of Computer Programming. Which Charles Moss tells me is a wonderful read. I'm not sure I believe that but the MSU library has volumes 1-3 in case I want to check them out.

I must quote this because one of my coworkers is just fanitical about C++. To him, everything that is not C++ is crap with the exception of javascript and ruby.

DDJ: You've mentioned Edsgar Dijkstra. What do you think of his work? DK: His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.

Kunth followed that quote up with some very reassuring comments about trying to find the middle ground between very specific control of code and allowing a library to be used without knowing how it was implemented.

[W]hen you write a program, think of it primarily as a work of literature. You're trying to write something that human beings are going to read. Don't think of it primarily as something a computer is going to follow. The more effective you are at making your program readable, the more effective it's going to be: You'll understand it today, you'll understand it next week, and your successors who are going to maintain and modify it will understand it.