What's it all about, Alfie?

Over the course of the last probably 8 years the number of pieces of paper I've printed out are few and far between. I have to print out two pages a week for my time and billing, and when I go someplace that I need directions to, I map it and print that out. It's a very little bit of paper.

I buy books electronically now. I get PDFs of manuals when I can. All in all, I'd like to be as paper-free as possible. And I've been doing a good job... until recently.

Part of my current assignment is a ton of paper-pushing. Read this spec, write this spec, what's the status of this spec? It's what I thought I was walking away from 12 years ago when I left my own company. I left management behind, and wanted to just do.

But every time I think I'm out, they find a way to pull me back in (excuses to Michael C.)

If I felt it was going to really be something then I'd be a lot more excited about it. But it's just paper because business feels like it's accomplishing something when it goes through fifty reams of paper a day through a printer. After all, what's getting printed has to be useful, right?

I've told them I'm not the guy for this job, but I've been told I am. Funny... I thought I'd have known that by now. Silly me. So I push paper. What a state.

I've spent a lot of time today working with a good guy in the ticker infrastructure team to get bugs in his group's code worked out. It's not been easy on him, that's for sure. Today I showed him no less than 4 bugs, each requiring new libraries be built - or in the case of one, the infrastructure itself had to be patched and upgraded.

I gotta hand it to him, it's a massive change, but I'm amazed that his developers didn't find any of these bugs in their testing. I'd have thought they'd have seen these as I did upon first inspection. I guess this is what he's going through to get his guys to get the bugs fixed.

In the end, I know it'll work, but I just feel really bad for him when I keep pointing out bugs less than 5 mins after a new release that he's thinking fixed the very last bug. Nope. There's a few more.

At least he's taking off for the weekend and getting some rest. I'll email him the next set of bugs in the morning and he can get to them on Monday. He deserves a break. It's close, but it still needs work.

I've used a lot of different source control systems in my days. Some have seemed to be really nice, only to be replaced by others that are even nicer. Some were replaced by worse systems, but for the most part, it's about the integrity of the development process. Period. Some make it easier to work in teams, some make it easier to work in a distributed manner, but all should have the same key feature: it allows you to version your files so you don't loose anything.

Which is why I was stunned to be in the middle of a discussion about the "one" source control system we should be using. Why? We've used ClearCase, and it worked OK, but then they didn't like supporting it and told us to move to a different system. We've used CVS for ages and it's never failed us. You can use Subversion now, and it's fine. I'm not sure, but I'm willing to bet that just about any reliable SCM is going to work. Just pick one, make sure it's safe, backed-up, and then get on with the job.

To say a group needs to use one at the exclusion of another is silly. You don't use one development environment at the exclusion of another - use Eclipse if you want... use Emacs, use Vi... just get the job done. Why would a group of professional developers even consider making rules like this?

OK, maybe some places feel it's important to have a single tool for each category so that people can get used to it and not have to change. Fine. Then by that logic, if someone is using a tool, don't make them change. If it's working, then it's solved. If it's not, then fix it. But making rules like this when nothing's broken is just plain silly.

When I've used projects that are in Subversion, I used subversion. When they were in ClearCase, I used that. What's the big deal? There is no one tool that's so vastly superior to the others that it can't be made to work, just pick one for a project and stick with it. Seems pretty clear to me.

But I'm in the minority here, it seems. They want to say all new development needs to be in one system. Until they don't like that and move to another, as they did when they moved to this one they are favoring now. It's crazy, but that's corporate life, I guess.

I was talking to a friend that recently left a position as to the reasons for leaving the position, and he said something that was remarkably insightful: I shouldn't know that my COO hates me. It's sad that he does, but what's really just plain bad management is that this upper management makes it known publicly that he doesn't like developers.

I was talking to another friend today that went for an interview and he was talking to the CTo of the small-ish shop that he was interviewing with and the CTO told my friend that he was overpaid. He went on to say that his advice was to have my friend talk to a recruiter and see if he wasn't telling him the truth. The conversation he had with this CTO as part of the interviewing process was just not at all what you'd expect from a CTO.

It was almost like he didn't want my friend to take the job, but didn't want to say "No" to him. Very odd story to hear.

I'm sure there's more to this from the CTO's point of view - who knows how well my friend did on the technical side, and if his personality was a good match with the people. Lots of things can factor into an interview. Heck, back at Port-to-Port, my old company, we had a saying: Sometimes good people don't fit. It was the recognition that good, talented people might not fit into every organization well. It was no reflection on them as a talented person, it was a statement on the fit.

So I look at these two things and think there's a big difference between a good interview and a bad one. And a good manager and a bad one. And it's got nothing to do with skill or talent. It's about personality. If you're someone that likes to poke at people, then you might be a great coach or trainer. But you're not likely to make a great manager as you need to motivate differently in the long haul to be a real success. You also either like talking to people and have a good sense of how to make people feel good about themselves, or you don't. If you don't, your interviews might seem very odd.

It's all about knowing what you're good at. Focusing on the positives and trying to best deal with the negatives. It's not easy, and we all need to do more of it.

I'm sitting in my cube - like a million other office workers in the world, and I'm listening to the chatter of my co-workers. Now I'm the first to admit that I'm a little more driven that the average worker, and have been called work-aholic more than a few times. But working hard just feels good to me. I like having a challenge to overcome. Yet clearly, mine is not the only work ethic. Far from it.

To hear about the game... or about this contractor, or about that bid for the new kitchen... you'd think that this was a part-time job. Yet I suppose that as long as their managers are happy, I can't complain... only wonder. Wonder at how much might get done if people stopped focusing on their personal needs and started focusing on the business' needs. If their work tasks took priority over their personal tasks.

I chat with my kids when they are online and I'm not busy... but it's never at the expense of work that I'm supposed to do for the Shop. I'm sure there are a lot of people that do personal errands, or call about bills, or such - that's just the nature of people trying to get their non-work life stuff done in the only time that other people are open and available.

I suppose then it's more a level and priority thing. If you're talking about the Cubs for 15 mins. that's OK... but if it's 3 hrs - or you're watching the game while at work, then it's possibly a bit excessive. If you're working out a complete remodel of your house and only get to spend 2 hrs a day on work tasks, then you might have a priority issue.

I just look around and wonder... How much could we really get done if everyone really tried?

This morning I was able to restart the last of my servers that had a re-configuration with the MindAlign system to disable it. These were the 10 authentications per minute that were spamming the authentication server... well... the last of them are finally disabled and things seem to be going swimmingly. Good for me. I wrote up the documentation on how to re-enable them once MindAlign decides to allow bots once again - whenever that is. I just wanted to make sure that if I got hit by a truck, someone could read the docs and get things going again.

I know from experience that this is not going to make any difference in the MindAlign stability, but they have been rather insistent that we shut down these spamming bots and so I have done it as quickly as is prudent. We'll see if they are as quick to restore complete MindAlign service.

I'm not holding my breath.

Over the last several days we've had significant issues with what appears is non-ASCII data entering the MindAlign servers and bring them all down. Since data like that is very unlikely to be entered by a human, it's thought it had to be a bot. Fair enough.

I've been sent messages by the MindAlign support group that I needed to shut down all the MindAlign bots I had because I was spamming the authentication server with connection requests. I've checked, and we're talking about approximately 10 requests a minute. Hardly excessive, and certainly not the source of continued instability in the system.

Yet I get messages to shut them down.

But to do so is to update/patch several production systems - not the thing you want to do quickly or in haste, and since I've never run these production apps without chatting, it is going to be easy to miss one or two places where the chatting is done. So it's a significant production support risk - all for 10 hits a minute. Hardly seems worth it, so I haven't done anything about it.

Until today.

Today I got a call from one of the MindAlign support folks and he told me what his email had said. I then pointed out the risk to production systems and he actually started to laugh. Clearly, he knew this was a much a fool's folly as I. I even said so. We shared a little giggle and I told him that he had done his job and I'd look into it.

After all, 10 requests a minute is certainly reason enough to cause global chat instability. Hmmm... he didn't think so either, but confessed that he was just 'under orders' to pass the word. I told him his duty was done and he laughed at that as well.

In the end, I put in the changes as best I could, tested them as best I could, and will get the final few restarted this evening/tomorrow morning so as to shut off this spamming. But the problem will remain, won't it? Certainly, because these bots that are so important have been tested and re-tested so many times under so many conditions that they are so unlikely to be the cause of the problem it should be an acceptable risk to leave them on.

It's the bots that are new in the last few days, or those that might chat binary data. Not these that have been working fine for years. It's just silly.

But we're putting production services at risk for this. All for 10 requests a minute. And no one but myself and the guy that called and laughed about it seems to see how incredibly thoughtless this is. But that's how some things go - no one stands up to the Emperor who has no clothes.

Today has been the first day of really hammering on the new ticker infrastructure for any issues. There were several, and over the course of the day the Team Lead and I have figured them out. Currently, there are only a handful of differences, and those might be related to the timing of the configuration changes as they were done throughout the day. We'll have to wait and see what data tomorrow has. If I'm right, all these remaining differences will vanish and we'll be left with a clean set.

It's nice to make progress on something like this. It turns out a better product for our group and well as getting the global support group to have a better product for everyone.

I've been working a lot with MindAlign lately, and specifically with the case where the login credentials are not valid and the server returns 'ERROR:504' as opposed to the package that the protocol indicates. Since I hadn't seen anything like this in their spec, I have just been assuming that it's a protocol error and throwing it up the exception chain as a general error in the code I'd written for MindAlign in BKit and CKit.

Well... that's no good. So I took the few minutes to clean that up and create a generally more informative exception message saying that the authentication server didn't like the login. This isn't going to revolutionize anything, but it might save someone 5 mins debugging, and that's good enough.

Again today we're having problems with a key infrastructural communication system. Whose fault it is is really unimportant... we're not changing this component out anytime soon - it's a key component in a company that literally spans the globe. It's here.

That being said, it is interesting that today I get a mail from them saying it's going to be running in a restricted mode for the next week. This places a non-trivial squeeze on most of my applications. I use this in every app to communicate with it - control it... monitor it... check health... lots of stuff. So to be without it for another week is non-trivial and more than a little annoying.

Sa as I was saying, they are asking us if we can migrate to a less-secure version that we used to all be on about a year or so ago. It was a multi-year effort to get everyone migrated to the new secure product, but they want to know if we can move back in a few days. What? Oh... yeah, that's right... when you can't fix your own stuff, the best ploy is to ask the users to change and hope that they can change fast enough not to get sick of the outage and decide to move off your product for good. I mean, can these guys be sincere about this?

For me, it's less than a dozen applications, and in some cases the changes are simple configuration changes and some are more structural. But if we change to the old system it's going to mean a ton of logistics... new login credentials for each of the 120 connections I have... new names of channels... lots of chances to get something messed up in the change.

That's why it took more than a year to get the move up right. It had to be sure not to break anything. I don't know what the problem is with their system - it could be really tough to figure out. But to get hundreds of applications reconfigured only to reverse it when they got it all cleared is a little more than a simple exercise. It's silly.

They need to find and fix the problem. If they have to call in smarter people, then do it. If they have to get in new servers, do it. I can think of any of a number of ways to hack the system to work in a pinch, but they aren't asking me and I'm not offering unsolicited advice. But the mere idea that we can easily manage the risk of a global change like this in a few days is absurd. It'd take weeks, and they had better be able to fix this problem faster than that.