Working on Convergence Issues

June 26th, 2007

shark.png

Today I took out a few minutes to check on the convergence issues that I remembered were in shark, the simulator that I had originally written as part of the Ph.D. thesis while at Purdue. The big problem originally was that there wasn't a machine fast enough to give me real, solid, answers to the questions of the physics of the problem. At least not in 1988. Now, it's a little different story and yet I remembered that I was still troubled by some convergence issues, so I wanted to take a look and see if there was an easy solution to the convergence issues.

The code tries to 'step' the bias on the device from the initial equilibrium state to the requested bias point. This is a classic problem in modeling - if you can't get a reasonable initial guess to the solution, then back-off on the initial state and see if you can get that guy solved. If you can, then use that as the initial guess for the next 'step' in the bias ramp-up. Seems reasonable, and it works pretty well.

One clever trick is to look at the difference between the values at each node from one bias point to the next, and then scale that for a better initial guess at the next bias point. In theory, it should get you closer to the next bias point than the last state, and therefore get you to the solution even faster. Problem is that if you don't get the "jump" right you can make the situation worse for yourself. And that's what was happening in the code. I was overshooting the change, which is not really surprising as this is a massively non-linear system and I was trying to assume for the bias changes it was linear. Not good. When I took that out of the code, it got to the right values fast enough and a lot more controllable.

The right solution might be to look at the last two points and allow the change to be second-order. It's better than linear, but I have a feeling that even that isn't going to be good enough at predicting the solution to warrant the cost, and uncertainty, of using the "jumps" in the biasing of the device. But if I wanted to try something else, I'm guessing an a logarithmic scale is probably closer to 'right' than even a second-order approximation.

At this point, all the tests check out and it looks pretty good. The next thing to do is to put in the input deck for the drifting packet that was the problem that couldn't get solved in 1988. It'll be interesting to see how long it's going to take with modern desktop computer hardware. My guess is it'll work, and be on the order of days, but it'll generate answers.

Slowly Making Headway

June 25th, 2007

Today I think I'm turning the corner with the Rock Star developer that joined recently. Today he came over to say that there's a problem in a class collection that I had put together. Basically, there's a general interface to a table and both the table and views into tables implement this interface. That means that they can be "stacked" and one view can be placed on another to make a rather advanced view on the base data table. The key is that the tables are like database tables, and the views are like database views, so in some cases - like an aggregated view, it's impossible to set a value of the underlying data because it's aggregated. Same with database views.

Anyway, Rock Star wanted to say that the setValue() method worked in some cases and threw an exception in others and that was dependent on the implementation of the general table interface. He was saying that this was a bad design. I told him that there were methods in the interface to see if you could set values on this instance, and that if the method returned false, then not try to set them as it was going to throw an exception.

He tried to say that this was an inconsistency. "Not at all", I said. It may not have been how he would have one it, but there's nothing inconsistent about it. He then spent about 15 minutes trying to say how he'd do it - with multiple interfaces inherited from each other to make it clear what one instance was capable of having done to it. I pointed out that this idea would then lead to a ton of interfaces and then you're going to have a ton of methods returning the values cast into the right interface, or a bunch of if-then logic with instanceof tests to see what interface it was.

In the end he agreed that it was his inexperience with the classes that lead him to believe there was a problem. I felt as if we might have turned the corner. It would be nice if he learned that before he comes over to tell me how badly something is done he does the legwork to make sure it's not going to come back and bit him in the rump - just like today. I think he's got talent, he just needs to adjust his attitude to the rest of us and the development/deployment environment we have in place here.

Complaining about the iPhone

June 25th, 2007

It's still 5 days from launch, but it seems that there's a ton of folks that are talking about how wonderful, and horrible, it's going to be. I have to say it makes me giggle to see so many people talk as if from a position of fact on how good (or bad) something will be when they haven't even touched it. I know that the Apple fans are saying what a wonderful device it is, and how it will revolutionize the cell phone industry, and that's to be expected. It's standard cheerleading. Vista, Windows, OS X, Linux, editors, religions - it's all about point of view and opinion. But what's interesting is the negative press as well. It's as if it's the Crusades and there's the catholics and the heathen. It's not enough to allow them their cheerleading, they must actively be put down.

Honestly, I like Apple stuff, and I'd love it if Steve had another hit. But I'm not going to buy one anytime soon. I have a laptop and a phone and with these two I don't need to have a small-screen phone/computer. If I didn't have the laptop, I might consider it, but I can't imagine being without the laptop, so that's a long ways off.

Likewise, I don't care if the Zune sold as many or more units than the iPod. If it's better, then the market will decide and that will make Apple's products better. But I can see that the cell phone companies like Motorola, Nokia, etc. are much more interested in the iPhone than another iPod - this is their game, and if it takes off they are going to have to respond to it or be left behind on the high-end.

It'll be interesting who turns out to be right and will they eventually accept their mistakes. It'll be fun to watch.

Digging for Locking Problems

June 22nd, 2007

Once again I got the wake-up call and needed to deal with a problem on the server. During the night there had been a problem with deadlocks and it stopped the server. What a drag.

Thank goodness for the extra logging I had put into the server. This time it was the reloading of the missing marks after they had been received. The code evaluated the stock families for those with new prices from the loading of the missing marks. The problem was that in some conditions a tick coming in for the instrument that's getting revalued from the loading of the missing marks was locking from the stock down, and the revalue method was only locking the options. That's certainly a source of potential deadlock.

These deadlocks have been very hard to eliminate. I know that if I used the exclusive locks and not try to be cute with the read/write mutexes it'd be a lot easier. But I think it's important to the server that I try very hard to make these read/write mutexes work. I'm close, I can feel it.

The State of FORTRAN on Mac OS X

June 21st, 2007

I've got my old thesis work that I was looking at yesterday. It's primarily f77 code, with a few of the critical methods converted to C with f2c and hand-tuned by me to get the best performance possible out of the code. It's nothing exceptional, but it's something I'm proud of, and I like to go back to it every so often and test it on new hardware that I get. Well, yesterday I was thinking about testing it on my MacBook Pro because the last time I tested it was on my G5 iMac, and it was very fast there, and I expect it to be even faster on my MacBook. It's got a faster processor, and if the compiler is capable of using multiple cores, then this will be even faster. So I was looking forward to it.

In the past, I've gone to the HPC Mac OS X page and they have had tarballs of g77, g95, gfortran that are built with the Developer Tools so that they work well with Xcode, which I am a big believer in. So I go there and get the latest Intel binaries for gfortran. Problem is, they don't compile the code. There's a problem in newton.F that causes an internal compiler segfault, and while they say "send in a bug report", I looked at the site and I think it's probably safe to assume that someone else has done this. There are a ton of rules to follow to submit the bug. So I missed there.

I tried the g95 compiler on SourceForge as it is supposed to be a different fork on the code, and while it compiled a little test program, it was spewing some errors that didn't look good, and in the end, didn't compile as much of the codebase as gfortran did. Strike two.

While I suppose I could buy a FORTRAN compiler, I really don't want to. I like the GCC tools, and I know that right now the gfortran snapshot (4.3.0) in the HPC download is 'experimental', it'll get better, and when it does, I'll get the next version. Until then, I'll have to wait. Not the worst thing in the world. It would be nice if Apple put it in Xcode, though. Face it, they're using gcc, so how hard could it really be?


UPDATE: I chatted with the maintainer of the HPC Mac OS X site and he said that he'd be updating the gfortran code in a few weeks due to the updates, but that the g77 code should work and it can be installed alongside the gfortran package. So I got it and it worked! The code compiles in less than a minute, and the tests run faster than any other machine I've ever run the code on. Amazing! Great guy.

As the hardware gets better, the times drop. I may have to come up with different tests. The latest tests show the MacBook Pro beats the G5 iMac. Nice.

Some Days are Harder than Others

June 20th, 2007

Today has been one of those days that seemed to start off bad and get worse as the day went on. Looking back on it, I suppose it started decently, but that's really only in relation to how it ended. I just want to go to bed and have the day end and put it in the history of my life.

Once of the developers moved to a cube close to me and even before he did, he said to me: "We'll fight over the blinds, Bob, and you'll give up." My cube backs to a set of windows and as such, to keep the glare on my monitors down, I've kept the blinds closed for more than three years - ever since we moved into this building. The developer knew this and he still seemed to want an argument. Odd. Anyway, today started with two of the blinds pulled up and while neither caused any glare at the time, it was 5:30 am, and the sun was just coming up. My rule had been: if it's causing glare, then they get shut. Well, I left one of the two open, but a few hours later, the other one was causing too much glare and had to be shut.

Now we get into the "up-down-up-down", Keystone Cops phase of the program. What's funny to me is that he had the choice of where to move and he could have moved to a cube that's got a real view of the windows on the other side of the building, but he didn't want to walk the extra 20 feet to talk to some people. Guess he really wanted to fight about it... or was just plain lazy. Or both.

Finally, the one blind closed, the other open, which is acceptable for me, we get into the it just keeps getting better portion of the day.

One of the new developers, the Rock Star I've mentioned in previous posts wanted me to look at his code and tell him what I thought of it. I said I would, and he wanted to do it right then. OK, I guess so. What I saw was something that I would have scrapped right away: no constructor, inconsistent use of the imports, virtually no comments, completely optimistic coding... in general, an example of what not to do for a production system. I started going through what I'd have done differently, and he wanted to argue about it.

I said "Hey, you asked me, I'm not interested in arguing about this."

"We're not arguing, we're discussing differences of opinion."

"Well... I don't want to discuss it. You asked me for my opinion, remember?"

So I continued. We talked more about his refusal to write code that was more robust, better commented, etc. In general, I came to realize that he really was committed to this way of writing code even-though he knew better.

At the end of the review he asked: "So, now are you going to let me code on BKit?"

"You've got to be kidding." I said, and went on to say that I can accept that this is the kind of job that he's going to do, but that I don't have to have him work on the projects I'm responsible for. I suspect that this is really what he was after by showing me his code, but it didn't turn out that way.

Then things got ratcheted up another notch when one of the Data Team guys was editing a price of an instrument while another was reloading it in the server. This ended up causing a deadlock - yeah, my mistake for not thinking of the possibility, but then the server had to be restarted. This was at 2:40 pm, and the restart takes 20 mins. The traders were not happy. I can completely understand, but I do wish they'd lay off the verbal abuse when things aren't going their way. It's not like I purposefully took down the server... it was a logic hole, and I've got it fixed up, but there was a lot of verbal abuse about missing the last 20 mins of the market. I hate it when that happens.

After things were up, I had about 30 mins to try and fix the bug so it'd be in development for tomorrow, and then Rock Star decides to ask me questions like: What java library is most used? and then Do you believe that java collections are widely used? I was in the middle of fixing this bug and so I answered him as quickly as I could, only to really find out what he was after a bit later.

He had looked up the source for Vector in the Java source and had seen that it didn't use one of my top-three code standards: single-entry/single-exit. He was using this as an example to say that if I thought Vector was "good", then I should think his code was "good" when he didn't code any differently than the Vector code.

What amazes me is that he was still on this kick of me liking his code. I finally got fed up with him and said "Well... when I need you to write code for me, I'll have to accept the best you can do. But for now, I don't need you to write code for me." And I can't imagine that I ever will.

I had to leave early for my daughter's birthday, and the commute was horrible, only to get home and find that work had called. Again, it seems like it kept getting worse and worse as time went on. I just wanted to go to bed.

Complaining about Comcast

June 19th, 2007

I was reading a story on Slashdot today about a blogger that was mad at Comcast for essentially rolling back features, in this case, HD channels, on her service. She could always upgrade her service to pay more to get them back and get others, but she was mad about what Comcast had done. I agree with her that it's a raw deal by Comcast, but honestly, what do any of us expect from the likes of Comcast, AT&T, and the large cable/telco companies? Honesty? A good deal? Please.

I spend more than $200/month to Comcast for cable and internet. I'm never going to get VOIP service until they change the regulations on 911 service, but given that I get all the channels, an HD PVR, 8Mbps (down) Internet, I'm not surprised that I pay a nearly insane amount of money to Comcast. But what's the option? AT&T? Not likely... they use a Dish service in Chicagoland, and their best DSL is still slower than the cable modem speed I'm getting. It's just what the market is willing to bear.

I can remember paying $750/mo for a 56kbps leased line through Sprint to the internet for my company. It was early 1990s, but still... $750/mo? The 56kbps line was no different copper than a standard phone line, and the service was something they already had in the CO (central office). I know this because my company was a computer/telco consulting company. But if you wanted to have something other than a modem connection in the early 1990s, that's what you had to pay. Comcast, while a different company, is doing the same thing - charging what the market will bear.

Unfortunately, there isn't enough competition to really drive prices down. Verizon's FiOS isn't in Chicagoland, and I can understand why - Comcast has incredible market penetration, and to put all the infrastructure in-place to 'steal' customers from Comcast is a dodgy proposition. Better to go to someplace that's not served by Comcast nearly as well and get much better market share right off the bat. So they go to other places first. Even if they did come in, they'd hardly undercut Comcast by much... maybe a few dollars, or provide features (like speed) that Comcast doesn't. Again, doing what Comcast did with their cable modem to AT&T's DSL.

So it's business... nothing more, nothing less. While I don't like it, I can't very well blame Comcast for doing it. I can vote with my dollars, and if I really don't like what Comcast is doing, I can go somewhere else. But in this area, the choices are limited, and it's not like AT&T is a corporate angel, either. It's business. What surprises me is that she was supposedly an industry insider, and she's still surprised. Now that's amazing.

Gotta Leave it on the Track

June 18th, 2007

Interesting thing happened on Friday, and I'm just now getting around to writing about it. One of the new developers here asked me about my opinion on the checked versus unchecked exceptions - otherwise known as the runtime versus typed exceptions. So I talked to this guy for a while about where we use one versus another and why we try to stick to a scheme given that Java itself makes this pretty hard to do. For example, Java has runtime exceptions and typed exceptions in it's code, so when you try to write code like Java's you are stuck trying to make it look like Java, but since there are really no hard and fast rules as to when to use one versus the other, it's a bit tough, and you have of make a lot of judgement calls. Nothing horrible, but something you have to be aware of.

So as we're talking about this, the guy tries to show me that I'm inconsistent in the use of these in the code I've written. I understand exactly what he's trying to do (though he denies it) - he's trying to show me how smart he is in an effort to gain my respect. Missed the boat entirely.

This kind of "See how smart I am?" crud does the exact opposite for me. Sure, you look at the Vector class and there are a lot of exceptions that are unchecked - ArrayIndexOutOfBoundsException is one. In JDBC this would be a checked exception for sure, but here, it's not. Why? Who knows. More importantly, who cares? When you're writing JDBC-based classes and extending them, you have to live in that little sub-universe of Java, and stick to their pseudo-standards. In the case of the Vector, you have to stay in the world of JDK 1.1 and realize that in the beginning they weren't using a lot of checked exceptions, so you have to make you code look a lot more like that - certainly if you're subclassing Vector (which was the case in this instance). Then he asked me to look at his code and what would I do in this specific case.

I looked at the code and said that he should check the input parameters, check all returned values, and single-entry/single-exit all methods. These are the three most basic coding standards that I have and believe in them without question - regardless of the language. He then said that this code didn't need that. A light then went off in my mind and I knew exactly who this guy was. By the way, he was the Rock Star of the previous few day's posts. This guy was a lazy Rock Star coder.

I asked him my one of my favorite questions about self-image and human nature: If you were driving on a road at 2:00 am and came upon a stop light that was red, and could see far in all directions, far enough to see that no one was coming, would you run the red light? His answer was "Yes", as I knew it would be. I pointed out to him that this tells me he believes himself above the "rules" made by others. After all, the stop light is just supposed to keep us safe, or is it the law to obey them? Yes, it's a law, but many people think it's really optional, and so feel that it's their life, and they can decide what's important and what's not, and they decide that this light isn't worth stopping for.

So we look at his code. We talk more and it comes out that he's built server-side code that has all these checks in it, but he hasn't put them in this particular code because he thinks it's not worth it. I ask him: "Why isn't this section of ten lines of code worth your very best efforts?" He has no answer, and wants to change the subject - which means he knows that I'm right, and that well documented, error-checking code is really better than code that's totally optimistic and undocumented. But he was trying to show me how smart he was, and this is really spoiling his plans. Sad day.

This goes into every aspect of a person's life - you either run it out to first base, or you pull up if you think you might not make it. You either go all out every time, or you sluff it off. You play at your level, or you sandbag. It's personal honesty and integrity. As Yoda said: Do or do not. There is no try. and he wasn't talking about giving your best effort and failing, he was talking about giving it everything you have all the time, believing that this is the last time you'll ever get a chance to do this, or you hold back, take it easy, realize this isn't a playoff game, etc.

I have no interest in living my life the latter of those two. I have to give it everything I have every minute of every day, or I'm just not going to feel like I can look myself in the mirror in the morning. And when I give it everything I have, I can look myself in the mirror - win or loose, and know that the only thing I can do is practice, because there's nothing I could have done to change the outcome - there's only what I can do to change it the next time.

Introspection is Painful

June 15th, 2007

Several things have happened in the last few days that have caused me to look back on things, times, places, and look within to see if I'm really the person I think I am, or if I'm just kidding myself. It's not a fun process. Never is. Never has been.

The first incident was an old friend from grad school emailed me about some pictures that Purdue had up on it's site for the graduates. Some were clearly professionally done, others were very clearly not. What sort of stung was the fact that I spent 9 yrs. there and there was no picture of me. It's like I was a ghost. Invisible. But I wasn't. I taught classes, did research, did a lot of stuff, but in the end, I'm only a footnote, it seems. Now I know that I didn't take the time, effort, or money to get a professionally done photo for the school, and I didn't go out of my way to put in an amateur one. But I am willing to guess that my friend that sent me the links didn't go out of his way to get an amateur picture of him there, either.

I'm surprised at myself, a little. I didn't think it would bother me, but it does. Just a bit. I look back and think What difference am I making? and I'm stuck thinking that about the only thing I'm really doing of any permanence is raising great kids. No one really seems to care too much about the work I'm doing. And in all honesty, if I weren't doing it, they'd survive. Maybe have to have more people, or do with less, but they'd still keep rolling.

Which brings me to the second thing that recently happened that caused me to take stock. Yesterday, I wrote about the Rock Star programmer, and today I talked to his manager - simple saying that one of my concerns before we hired him was that he might turn out to be just like this - Do what I want, or I'll do it anyway. And the feedback I got from his manager was a little surprising, and at the same time not: he was happy with the guy. He hadn't had any experiences like I had with the guy and was producing a lot of stuff - comparable to the others in the group. Again, I hate to say it, but it's classic Rock Star programmer - gets lots done, but don't cross him.

I didn't push it, and didn't want the manager to do anything at this point, I really just wanted to express my concerns and see how his dealings with 'Mick' had been going. I know in my bones that this guy is going to be more hassle than he's worth. But I'm not about to make it an issue. But it got me to thinking: Am I a Rock Star programmer?

I suppose that anyone that's really productive can think that maybe there's a little element of the Rock Star programmer in them. Being a Rock Star is, after all, about getting a ton of work done in a very short time. But very soon after that, the similarities end and a good, senior, developer is entirely different from a Rock Star. So I was looking within and trying to see if I was really who I thought I was.

I guess the thing I look at are those things that I see that are clearly not the qualities of a Rock Star in myself. Like the middle of the night phone calls. Never lost my cool, always explained everything, walked them through the problem, or if they wanted, I just fixed it myself and then sent out an email explaining the problem. Existing code - I stick with what is as opposed to what I'd like it to be. I might not code this class a certain way, but if it's there and working, I'm not going to spend the time to recode it just because I don't like the way it looks, or how it's structured. Now, if I have to re-write big sections of it, I'll probably clean up the indentation, add a bunch of comments, and such. When I write new, I try to stick with the 'tone' of the rest of the library/package/project. It's just easier on the next guy that might have to pick this up. There's no need to make it look like it's been written by multiple folks, even though it clearly has.

So I guess I'm comfortable with where I sit in the spectrum. I'm certainly not a wallflower, but I'm pretty confident that I'm not a Rock Star either.

Rock Star Programmers

June 14th, 2007

There's been a lot of talk about the Rock Star programmer on the web these days. Several very interesting articles about it. Today I had a run-in with a new guy at work, and I have to say, while not a Rock Star, he's certainly got several of the worst qualities of a Rock Star, and I'm trying very nicely to point out to him that they really aren't very useful here.

I try to ask people in interviews what they think their most important job is when first coming to a new place. There are a lot of different answers, most of them very political or very technical, but every so often I find someone who understands what it means to be a good developer, and they give me the answer: learn.

That's when I know I have a 'keeper'.

If the smartest person in the industry came into a shop and started changing things, or building things, it would only be by the greatest feat of luck that it actually worked and worked well - with the existing systems. Anyone can build an app. OK, almost anyone. It takes a skilled developer to see the right way to buld the app so that it fits in nicely with the existing apps and services in the organization.

For instance, if a new app is built that needs to make a copy of the accounting data in order to function as built, then it's bound to fail. Or worse, cost excessive manpower to make sure that it's always kept in sync with the real repository of the accounting data. Making copies of critical data is almost always a mistake. But if you don't know how it's stored (because you're new and don't take the time to learn) then you'll build something that has to have lots of scripts for copying, checking, back-filling, etc. all because you didn't learn before you built.

So today I had a visit from a new developer - been here a few weeks. We'll call him Skippy. Skippy wanted to have a new method put on a Java table object that is widely used in the organization: renameColumn(String, String). I pointed out that there already exists the method setColumnHeaders(int, String) that can rename the column header, but he pointed out that if he didn't know the column number, the setter wouldn't really help. Agreed, then use the method getColumnForHeader(String) to get the numerical column and then use that in the setter. Still no good, says Skippy. It's too long.

Too long? I pointed out that it was one line:

  setColumnHeaders(getColumnForHeader("old"), "new");

and he said that even that was not as clear and concise as the rename method he proposed. I agreed that the 20 (or so) extra characters make the existing method invocation technically longer than the other, the point was really is this the best thing to be spending time on right now?

We are, after all, understaffed for the workload, which means that things are always getting rearranged on the priority list, and many are just not getting done. This means that we need to be very efficient with our time. While I don't disagree that adding convenience methods to classes makes them easier to use, my question is does this addition benefit the users in a material way? And to that question, I am fairly confident, the answer is 'No'.

Now I'm trying to put this in as non-confrontational a manner as possible, but Skippy is still being quite insistent that this change is significant and warranted. I'm trying to tell him that it's not an issue of the individual change, it's about a balance of the workload and the cost/benefits of each thing that we do. I can see his eyes glaze over... his head turns away... and I know I've lost him. I say as much and we're done.

Later, as I try to use an example of something I had done for him the day before to show him that I'm not against his ideas just because they aren't mine, he told me that he was adding the method in his project. As further evidence of his thoroughness, the feature I added for him wasn't going to be used because he hadn't checked with the Team Lead beforehand, and when he told the Team Lead about it, he directed him to do it another way entirely. Effectively wasting my time the day before because he hadn't learned what was needed. He acted on what he thought was needed.

Rock Stars - more hassle than they are ever worth.