interview with randy cox

randy is the engineering manager at pukoa scientific. and he was one of my first managers at another company. he actually was the one that convinced me to come work for that company. he is a great guy. he was very supportive of my ideas and i could tell that he really cared. thats very important to me. to be honest, randy's sincerity is really one of the reasons why i chose to come work for him. did i mention he is a great guy; no really he is a great guy.


What inspired me to get back into programming?

My drive to get back into programming was my attempt to improve myself. It could be a mid-life crisis thing :). I am bored of management, and wanted to excel in something new. Personally, I am happiest when I am coding. I think good programming skills make you a better manager, and managerial experience make you a better programmer. So I was very excited to take this class.

What are some of the lessons I learned about myself from taking the class?

First, I learned what I have forgotten, that I really enjoy coding and really enjoyed learning. I also received training in patience. It was difficult working in teams when procrastination is so prevalent. In addition, although my background is in Electrical Engineering and I was intending to study Signal Processing, I have learned that Computer Science is what really makes me excited.

What insights additional insights did you gain from the class, because you were a manager?

I believe, ICS 613 Software Engineering's core teachings is managerial . During my 18 year managerial career, I have been in constant battle with software depreciation (and losing). I actually resigned to the fact the software depreciation was inevitable in large companies. Everyone had there own way of coding, people who did not understand the overall architecture created their own designs within subsystems, or people just coding things arbitrarily more complex then needed. The task of controlling and enforcing was too difficult or unfeasible to keep the code base "clean". Once the legacy code base reaches the point of no return = "spaghetti", your staff end up living in purgatory, you fight fire after fire, you build band-aids, the quality of your work diminishes and your brightness engineers start walking. You never get the chance to "rewrite" the application because it can never compete with nifty new marketing features. Look at any of the big companies out there and you will see large legacy applications maintained by legacy experts in archaic languages (COBOL, BASIC, etc.).

Enter Aaron and other alumni from ICS. I got a taste of the set of QA tools now available. I learned the principles of continuous re-factoring. I found that today's software engineering methods may actually eliminate this age old nemesis of mine. I think today's students don't really understand the value of this. I can see how students who understand the principles of this class may become disillusioned working for bigger companies that do things old-school.

What lessons have you adopted from class into your work?

I pretty much would like to adopt the entire software process from this class at work. We are slowly implementing these processes, but there are a few challenges to overcome. Finding the balance between improving the process from my point of view versus micromanaging the software manager takes some finesse. Also, things need to be staged (instructions, tools, etc.) in a systematic way to avoid chaos.

You mentioned, "I think today's students don't really understand the value of this." I'm not sure today's students learn that much about that. Let's dig deeper into this area.

I've said for years that the classes that Dr. Johnson teaches should be mandatory in the ICS curriculum. Learning the tools and processes he teaches in his class are mandatory in any software development. Do you think the core teachings of Software Engineering should be required in the ICS curriculum?

Definitely, I really think that this separates the “professional programmer” from the “amateur programmer”. It’s so easy to pick up a language and have fun programming something. It takes hard work and discipline to make that code “industrial strength”. Unit tests, constant refactoring, javadoc, etc. can be tedious for the lazy programmer, but critical in achieving quality.

[end interview and some of aaron's thoughts]
randy is a hacker. that is so obvious. i'm totally stoked that he has found his way back to hacking! i totally see what he's saying with

Finding the balance between improving the process from my point of view versus micromanaging the software manager takes some finesse. Also, things need to be staged (instructions, tools, etc.) in a systematic way to avoid chaos.

thats really good insight. i just wonder what that finesse is.


i want to revisit my last question about requiring software engineering in the ics curriculum. Here are some of my (aaron's) thoughts about that. A professor could give a presentation about the state of the art software development tools. And even give the students an assignment to download, install, and play with them. But, I think that would almost be useless. Learning doesn't work that way. You need constant interaction with the subject matter to gain experience and insights. Thus, its rare that classroom assignments does the trick. Class projects are a lot better, because it allows the student to work on something, refactor it, be evaluated, and try again. Yet, class projects has its limitations too. So, it seems that students really need to to theses, work in research labs, dissertations, etc to get the experience they need to really learn. That's reality i guess, but seems like a shame. In regards to software engineering principles, I'm tired of the software being ignored in "other classes". (i'm not picking on any professor here) For example, lets say we have a programming class project in a database class. Would the professor require the class to use a configuration management tool? Or have a continuous build? I doubt it. The problem that I see is that the core principles of Software Engineering are only important some times. that works vice versa too. when in a software engineering class we should be aware of the "right" thing to do for, lets say, data structures and algorithms.

I remember when I was taking a multimedia for the web programming class, the professor asked us a Big-O Notation question. We all looked around confused, saying to our selves "um excuse me but we are supposed to be learning about web programming". No one answered the question. In fact, I'm not even sure any one knew the answer. I had no clue. The professor was astonished, because he obviously thought that was an easy question. Looking back at that event and knowing that I still suck at Big-O questions, I realize that I'm not good at that because we were forced to only care during one or two classes. And we are indirectly forced by all the other classes to not to care about Big-O.

anyway, i guess i'm making a plea for more synergy across disciplines in the classroom.

update
i just remembered that randy gave a great talk at the ics dual-use-industry internship presentation. actually, a few students came up to me and asked if 413/613 was a required class to work at our companies. i said no, but it certainly helps A LOT. :)