Teaching engineers

What do we want our Universities to teach computer science and computer engineering students? I've lamented that teachings are sort of bipolar: flip-flopping between minutiae associated with implementation (and attendant lack of attention to design), and interesting but in the long run nearly useless theory. This week's New York Times Magazine describes a new university, Olin, which graduated it's first class last December. The article says they focus on teaching engineers to do the right thing, not just do the thing right. The description would have sounded way too artsy for me when I went to school, but from my current perspective, I think it would be a refreshing change. Engineers have a strong bias towards saying "yes" - they are taught to solve problems within given constraints. What I haven't seen as much of, is identification of which constraints are unreasonable and creative thinking about how to get better solutions by changing the constraints. We need more of those engineers.

Moral Hazard

It's fascinating to me to read about whether lower fed discount rates cause inflation, and even whether it's good for the stock market. I wish I'd blogged on it last week, because there was great article that basically said we have no idea how the economy really works. We understand some things, for example, a smaller discount rate immediately increases the value of stocks. When the discount rate was lowered, the NPV of all stocks immediately rose, if you assume that the value of a stock is actually correlated to the company's ability to generate free cash flow (if it isn't, then the stock market must be a form of gambling). But we don't understand the long term effects of such changes. There is no shortage of experts willing to write about whether this is good or bad. But I really enjoyed this one: http://online.wsj.com/article/SB119025102955233333.html, which has some great quotes and concerns. If indeed, past irresponsible behavior could lead to pain for millions of people, the discount rate simply had to be cut. The question is, how do we know that is the case? We may very well have increased our risk.

Another negotiating tool: WIFM

You may have heard WIFM in the context of managing others. WIFM stands for "Whats In it For Me?". Sometimes you'll hear it as "WIFM radio". (Ironically, there is at least one real WIFM radio station). WIFM doesn't mean look out for yourself - rather it's a reminder that others will be looking out for themselves. So put yourself in the other's perspective, and then answer the question of what's in it for them, without them having to ask. You can use this in managing others, but it is essential in negotiation. I finished my little negotiation yesterday, and we are both happy. This is at least partly because I looked at it from her perspective, and thought about how both our needs could be met. I structured a deal which lets her get what she wants if I get what I want. Conversely, if I don't get what I want, she doesn't either. It's fair, and it puts us both on the same team with the same objectives.

Negotiating

I'm currently doing a little negotiating, so it was timely that this month's HBR has an article in it about negotiation. Entitled Investigative Negotiation, it resonates with me because it is loaded with examples and techniques about understanding the motives of the people you are negotiating with, rather than trying to "win". It somewhat reminds me of advice on selling by Jeffrey Gitomer, and consulting by Jay Conrad Levin and Michael W. McLaughlin. They all advise: quit talking and start listening. People may not be forthright in telling you what their needs are; that's your job, to learn those needs. The HBR article even gives examples of how you can make simultaneous multiple offers and use the response to learn about their motivation. One of the techniques is to offer information first, but make sure the other party knows you want them to provide information in return. I think this article helps define negotiation as a cooperative and even fun undertaking, as opposed to a competition. Good stuff.

Measurement Constructs

I've been learning about the methods used by the PSM group, which is detailed in their reference book here. One of the concepts is what they term a Measurement Construct. It's a graphical structure that shows how you go from an Attribute to an Information Product. At first the whole thing seemed very intuitive, but the structure helps you consider all the aspects of metrics. What are we trying to learn, how should we present what we know, how we should gather the data, and in what ways can combine data for more information.

The relevant terms are:

Attribute: a property or characteristic
Base Measure: a single independent measure of an attribute
Derived Measure: a function of two or more base or derived measures
Indicator: a measure for presentation which enables evaluation of an attribute

It's kind of a dry read but I think most software and system organizations I have worked with would benefit from some of its discipline.

Geeking out

My excuse for not blogging recently is that I have been totally geeking out on the technical details of my startup. We're using windows, mac and ubuntu, NetBeans 5.5.1 with the visual webpack and the mobility pack, Sun's Java Application Server, asterisk (via asterisk-java), a third party routing library and SAS, mySQL, some Apache Commons stuff, svn and a bunch of free tools. We share our code via svn's tunnel through ssh using public key cryptography, making it very secure, and low maintenance.

The NetBeans environment is impressive and occasionally oppressive. One thing that is amazing is that this is all free, and you can find help on all these components, although it can take you a while to sort it out sometimes. I had a lot of trouble trying to test J2EE services on my Mac - the behavior was very inconsistent. Eventually I gave up and am using Ubuntu.

The use case the NetBeans team really missed big time is the use of third party libraries. If you do this the natural way, it ends up being part of the user's environment instead of what gets put back with your source code to your repository. There is this nice hack which works, assuming you don't have erroneous dependencies in your hierarchy (if you do, it totally tanks NetBeans and the working copy - you have to start over! Total disaster).

Anyway it's been fun and I made a lot of progress. We now have a prototype of a voice client to our service, built using some of the patterns I learned about a few weeks ago (notably the command pattern - I used it to structure the menu system). Now I can get back to more management stuff.