Wednesday, December 06, 2006

Versatile programmers

I work as a programmer for a small consultingware ISV. Since we're small, everyone has to be flexible and take on roles outside their primary area from time to time.

Programmers tend to be higher up the skills chain than some others in an ISV. As a result we have the ability to be reassigned to a number of non-programming roles at the same skill level or lower. These tasks could include in no particular order

QA testing
creating product documentation
creating online help files
sales engineering
professional services
producing training materials
delivering live training sessions
level 1 and 2 tech support
consulting
providing a reassuring presence on a customer site
creating content to demonstrate at trade shows
attending trade shows


In general there is little to no transferrance the other way into the core programming team. This is because it is generally difficult to impossible to quickly reposition someone up the skills chain instead of down it. For example it would not be realistic to try to cold reassign a tech writer or level 1 tech support rep from their usual role into the programming group for a couple of weeks to help the product team meet an end of month deadline. They don't have the required skills and experience to function effectively as programmers. So the standing programming team can only lose resources, and never gains them.

In larger companies, it should be possible to properly separate the programmers from the other roles. The other teams are big enough to be properly staffed and are expected to fill in their own shortfalls using their own means. In a smaller company we have to be more flexible and cannot just isolate the programmers from having to occasionally do non-programming tasks. Especially in consultingware, which is about smaller numbers of big sales, we have to be responsive to sales opportunities. When you're close to a big sale you do what you have to to make that sale. The success of the products and the company depends on it. Sometimes the distinction between the core product and a customization can be somewhat blurry. If the programmers can help make the difference in a short term big opportunity then that's worth doing.

In general it's not economical to reassign programmers to other roles since programmers tend to cost more than the roles they are taking on. So assigning a programmer who averages a loaded $100K a year to do tech writing or level 1 tech support than can be adequately staffed at a loaded $50K a year isn't cost effective in the long term.

There is a hidden cost to reassigning programmers. The cost is that the programmers cannot advance the core products when they are doing other tasks. At Microsoft there is a really good saying among the programmers: "If you're not writing code then what are you doing?" That really focuses the mind on what the programmers are there for. What's more important that a programmer should be doing than creating source code. Every day a programmer spends not writing code is a loss for the products he would otherwise be advancing. This cost is not immediately apparent, and may seem negligible in the short term. However over time it can be extremely costly if the core product becomes uncompetitive in the marketplace.

So the programmers immediate manager, product management and the company in general must be educated to understand the potential costs of reassigning programmers. In general requests for programmer reassignment should be carefully reviewed and challenged, and rejected if a compelling business case cannot be made for it.

In a dysfunctional environment, the programming team would be like a buffet table where any other group can help themselves at any time to a warm body or two to cover over a local shortfall. If you have a small programming team to begin with and you've got one person doing phone/email tech support, another one out of town at a trade show, another on another continent holding hands on a customer site, another helping set up a sales demo, two others over helping out with a QA cycle, and someone else conducting training sessions then you basically have nobody working on the actual products which will then be at risk of becoming uncompetitive. That's an extreme example but you have to be vigilant to keep the programmers writing code.

Tuesday, December 05, 2006

A use for Internet Explorer (XML viewer)

Normally I have little use for Internet Explorer, except at annoying sites that only work with IE. I switched to Firefox years ago and have never regretted it. Hello tabs!

However a smart guy at work showed me a handy thing that IE is actually useful for. IE does a pretty good job of rendering raw XML. It shows it in a nicely formatted, color coded way where you can open and close the branches to narrow focus to a specific area.

This is useful for me because I deal with SOAP a lot at work on the server side. Clients visiting the internal web service tend to be shaky and get themselves into a bad state, and do strange things that cause problems. We necessarily log all of the SOAP/XML that we send and receive. When a problem occurs it is very useful to see the exact SOAP content that was sent or received on the wire.

Now viewing SOAP content can be a pain. On our side we use Tomcat and Xerces. While this is robust and reliable, it also generates the XML all on one line. This is fine for a computer to process but hard for a human to read. Previously I had to copy and paste from the log file into a text editor and insert line breaks manually to see the actual valid XML/SOAP we sent that the client was having problems with.

Using IE, there's a much faster, easier and better way.

Create a document on your desktop called t.xml.
Make sure your settings have IE as the default application for .xml files.
Right click on t.xml and open using a text editor.
Replace the existing t.xml content with the XML copied from the log file.
Save t.xml and close.

Then just double click t.xml on your desktop and it comes up nicely formatted in IE with all the attributes and namespaces and everything right there. This is very handy and a real time saver.

Wednesday, November 08, 2006

HP

So HP has had some negative publicity lately. What an idiot that board member was to make those leaks and cause all that trouble. That was good of Patricia to take one for the team.

I still think well of Hewlett Packard. I've always thought well of HP. Back when I was in high school, they were considered a very prestigious company. They made the engineers calculators and the ultrasound machines and the testing equipment. I once read this article that HP had resorts around the world for their employees and that it was great to work there. Back then I hoped I could work at HP some day.

The PC I'm writing this from is an HP pavilion. If I ever get a digital camera I'll be looking for an HP one. Back at PRIOR Data Sciences, they had HP laser printers. I got talking to a sysadmin one time about laser printers and problems I'd seen with printers at other sites. What he said was this: the thing about printers is, go with HP. Don't fool around with anything else, you'll regret it.

Alas, times changed. They got out of calculators. They spun off the medical and test equipment into Agilent so that HP, a decades old company, could try to present itself to the late 90s stock market as some kind of dot com startup. D'oh, so much for that plan. Then Carly Fiorina dismantled the "HP Way." Nice one Carly.

A friend of mine who's an engineer had an interview with Agilent a couple of years ago. I was excited when he told me. We both recalled the old HP reputation, and agreed that Agilent was the good HP, the original HP. I recall he ended up landing another job before things progressed very far, so it goes.

Sunday, October 29, 2006

Reference update

Here's another update on my former colleague who has been looking for work in high tech. I heard from him this week. He gave me a heads up that I might be hearing from a company he has interviewed with. That was considerate and smart of him to tell me in advance who I might be hearing from.

The company is a large, well known IT firm. I haven't heard from them yet. I kind of thought I would have heard from them by now. Maybe he's dropped out of the running.

Fortunately for him, it turns out that he does currently have a job. He caught on with the startup company he'd interviewed with. He said he's still looking because the pay isn't quite what he wants and the work is a bit light on the skills he's most interested in. I'd say go for it if something better appears. There is little loyalty in high tech, it's every man and every company for himself in this industry.

But its good for him. Having a job gives him credibility with other companies that he's desirable and employable. Plus if you don't land something better then he still has something which is good enough and many times better than being out of work on the outside and worrying about how long his severance and unemployment will hold out.

Sunday, October 22, 2006

Sneaky Network Magic

I was getting some weird printing errors on the Dell laptop last week. Visual C++ runtime error, followed by program termination. That's weird, it was all working OK and nothing had been changed.

I went to the printers console in the laptop, and it said stuff like spooler service not running on the main HP PC where the printer was shared from. Hmmm. I opened the printer in the HP. Indeed the share had been turned off. That's strange, I didn't turn it off.

So I clicked the Network Magic console. It showed a message indicating that the free trial had expired and I had to upgrade to enable printer sharing. Their GUI implied that there was no way around this to turn printer sharing back on. Luckily I knew better and just turned on the share manually. After that I went back to the Dell and did the printer discovery wizard again and it all worked.

That was pretty dirty and deceptive of Network Magic. First they "helpfully" set up a shared printer, then they go and turn it off without my consent. Then their GUI is extremely deceptive, acting like they were holding my shared printer hostage until I gave them some ransom money to release the shared printer lock they had put on.

I'm glad I don't work for them. This to me is very unethical, basically Network Magic is acting like a trojan. That must have sucked for the programmer who had to write that feature to turn off printer sharing and then try to dupe unsophisticated users into thinking they had to pay off the Network Magic shakedown to get their printer share back up.

Make no mistake: the printer share is not created or owned by Network Magic. It is part of Windows itself. It is owned by the PC user. The user is free to manually turn on printer sharing with no assistance at all required from Network Magic. That's true for all of the other Network Magic features too, file sharing, wireless security and access lists, all of it is part of Windows and the user can easily set up all that stuff himself using the GUI in Windows.

If you want to pay for their nice, intuitive GUI for the above features, then fine, that's your choice. But their guerilla bait and switch marketing is very bad.

Tuesday, October 10, 2006

Documentation

We're nearing the end of the testing cycle for a product release. There aren't any high priority bugs around so I was told to just grab some lower priority issues. Given a choice I decided to tackle some documentation that had become a little bit out of date.

I find I've enjoyed doing the documentation. There's a certain Zen to documentation that makes it satisfying. Maybe it's because, like code, it can be verified to be correct. Plus I'd been involved in this documentation in earlier releases so it was something that I'd been involved with in the past that I wanted to see maintained at a high level of quality.

Documentation, especially API documentation, unlike code, can generate feedback from external users. Nobody ever sees the code you write, especially outside the programming group. But with documentation you are presenting yourself and your department for external valuation. Do a good job and you'll look good and be praised. Do a shoddy job and probably nobody will say anything directly, but the bad vibe will come back around in some way.

Around 10 years ago my younger sister was finishing up high school and considering her options heading into university. I encouraged her then to get into technical writing. She can write, and could learn the technical jargon easily enough. There were about a million tech jobs open at that time. It's much easier to teach natural writers the technical stuff than to try to teach people how to write well. You either can or you can't write.

She ended up going to law school and has had a good career. If I wasn't programming, then maybe I would have got into technical writing. I probably would have enjoyed it enough as a vocation.

Thursday, September 28, 2006

How to share HP deskjet 3650 printer with a Dell laptop

We now have a Dell laptop computer in addition to the HP Pavilion we already had. My wife will be using the laptop. She wanted to be able to print from the laptop to the hp deskjet 3650 using the wireless router.

The laptop is connected to the Internet through a D-Link wireless router which works great. The D-Link included Network Magic which set up the home network. It also set up the printer as a shared device.

So it would seem straightforward to add the HP printer to the Dell and get printing remotely. Well it almost worked. The wizard came up and was able to find the shared printer off the HP PC. However after the dialog about downloading drivers off the HP, there was an error message that it didn't have the right driver version.

Uh Oh. I brought up the printer properties. It had an additional drivers section. That looked promising. But when I clicked to add new drivers it prompted me for a drive letter. There's no CD as all the software on the HP was pre-installed.

I thought to get the drivers from HP. So from hp.com I was able to easily click through a couple of screens to find the download for deskjet 3650 drivers. First I thought to put it on the HP. Then I decided to leave the HP unchanged as it has always worked fine so I didn't want to risk changing it. So I downloaded the drivers to the Dell instead.

When I installed them on the Dell the dialogs came up and then one said to plug in the printer. I just clicked Cancel, hoping it would work. But clicking Cancel aborts the driver install. So I ran the wizard again. This time when it said to plug the printer into the USB port I moved the laptop next to the PC. Then I unplugged the printer from the PC USB port and into the Dell USB port. Then happily the driver install completed and I was able to print a test page from the Dell onto the HP printer.

The last step was to plug the printer back into the PC USB port. Then I went back to the add printer wizard on the Dell. It found the shared printer as usual. This time it was able to add it successfully as it now had all the drivers from my earlier trickery. Then I set the shared printer as the default and deleted the physical printer definition that the driver installed. And that was that.

Thursday, September 21, 2006

Reference update

I didn't hear back anything from my former colleague's first interview. However I did hear from recruiters twice in the past week doing reference checks on him.

The first one was from a large well known tech firm. The second was from a startup company.

The woman from the large firm seemed to be looking for an overall feel for what my colleague was like. She asked me how long I'd known him; how long we worked together on projects; what specific technologies did he work with; what was his biggest strength; what was his biggest weakness; did he get along well with others. We talked for around 15 minutes.

The end of the discussion was interesting. The recruiter started asking me about my skill set. I told here we're a Java shop and I'd been working on basically the same stuff as my former co-worker. She said they are interested in J2EE and Oracle and asked me if I would interested in applying to her company. I told her I'm not presently looking. She suggested she'd e-mail me and I could reply with a resume to get on each others rader screens in case things change in the future. I said sure - Why not? Strangely she hasn't followed up on that e-mail. Oh well she must have forgot after she hung up.


The second company wanted to talk to me during the daytime. I had said when I agreed to give a reference that a phone chat was available in the evening hours. The fellow e-mailed me back and said he'd try to call me that evening.

I haven't heard from him since though. He must have had to go out of town or had some unimaginably high priority thing. After all, in a small startup with a very small programming team, what's more important than getting in great developers. A bad hire could cause the company to fail, and a great hire could be a difference maker. So like Google you'd expect he'd make the effort to do the follow up to get as much data as he could on this potential hire to be sure he was getting someone very good. What's more important to the success of a software startup than hiring outstanding programmers? Not much.

He feels he might get offers from both companies. He may be favoring the startup because it is closer to his house. I reminded him in the chat that the hours can get long at startups, but he's done the startup thing at least twice now so he knows what to expect.

Wednesday, September 20, 2006

Test team

We're a small team, around a dozen developers and a handful of testers. Two or three times a year the developers have to temporarily join the test team to help complete a test cycle for a product release. Myself and around three other programmers have been with the test team the last week or so. Hopefully we'll be finished up by the end of this week.

Testing is an interesting experience. I don't mind doing it once in a while. I always test my own code of course, but testing other people's work is interesting. You get to try to think like a customer.

With testing, my take on it is that the name of the game is automation. I think our test team should work on ways to increase use of automated testing. There's some, but not as much as there could be. I was testing three APIs. One internal API is my own API; and two other APIs developed by others. For my own API, after I tested it out OK, there was a gap between candidate releases. The test team lead said OK to my request to use the time to create an automated test suite for the my own API.

It took me around two days to assemble the individual loose tests for each API function into a one pass driver that calls all of them. I suspect I've already saved in the subsequent baselines close to the amount of time I spent creating the automated test driver.


For the other APIs, we have a GUI driver that will set up and call each API function with data the GUI user enters interactively. This is OK for a programmer to test individual APIs as they are added, modified or debugged. However it doesn't scale well and is labour intensive and isn't well suited to rigorous regression testing.

So after this cycle I'm going to push to get some time to create a driver for the other two APIs as well. That may save me truckloads of weekend time in the future.

Saturday, August 05, 2006

Reference

I former co-worker who got caught up in the recent RIF got in touch with me recently. Luckily for him he's already lined up a couple of interviews. Hopefully he'll be back working in high tech soon.

He contacted me to ask if he could use me as a reference. I said OK. He's a pretty good guy. This is the first time someone asked me to be a reference. Maybe I'm getting somewhere in high tech after over nine years doing it, if someone asks if they can use me as a reference. I kind of hope his potential employer contacts me. I'm curious what kind of questions reference checkers ask. I'll post what happens if they do get in touch.

I don't think employers are generally too keen on their people being references for former co-workers. The problem is that once their people talk to recruiters at all, the recruiters know who they are and could start to target them to jump. This is especially bad after a downsizing since you'll be short staffed anyway and hiring someone new to fill for someone quitting is just not very likely to happen. So you'll just be even weaker. I think one of the last things an employer wants after a RIF is for any of the survivors to voluntarily leave.

Tuesday, August 01, 2006

Job search tips

I e-mailed a former co-worker who got caught up in the RIF last week. I wanted to wish him well in his search for a new job. We'd worked together on a number of projects over the last five years. I was his team leader on projects for around 2 years. I sent him these tips that I had picked up over the years.

* update your online resume on monster, workopolis, hotjobs, etc at least once a week. Many searchers look for active job seekers and they use the last update time of the resume as a guide. The "update" can be as simple as adding and deleting a trailing space at the end of a paragraph, or reordering some information in a sentence. So the content stays the same but your "last update time" always indicates an active job seeker.

* when a job is posted online, the company generally gets a crush of applications. They often will just look at the first 50 or so to get a shortlist to interview. One thing that I've heard works is to be in the first 20 respondents. This can be done by getting up quite early, say 4-5 AM. Log in to the job sites. If there is a job you match then send your saved resume. That should get you in the top 20 of repliers. That could give you an edge. If there's nothing that's fine, just go back to bed and it should only take around 5-15 minutes total.

Sunday, July 30, 2006

RIF

We downsized again recently, 10%, as part of the quarterly announcement. A few people in our office were affected. This included some good people who had made valuable contributions. Luckily for me I managed to survive this cut, like the previous layoffs. It's not real surprising just because tech companies rarely just do one round of layoffs. There's usually at least a second round. Hopefully this will be the last. I'm not sure how many more I could get through.

So there's a new acronym I hadn't heard before for it. Reduction In Force (RIF). That's scary, it's just too close to RIP, which it is the same as on some levels.

So you don't want to get RIF'ed.

Sunday, July 23, 2006

Yahoo

I use Yahoo. I like it, it's pretty good. I've never given them any money directly but I've used their games, finance, e-mail (until I switched to GMail). I still use Yahoo as my start page. The recent changes in the personal Yahoo pages with the Ajax and moving the blocks around are really impressive. Very smooth and slick. Nice job Yahoo.

Sometimes I find Yahoo comes across as deceptively simple. A lot of what they do is actually quite sophisticated. The programmers there are working on and solving some extremely difficult problems. Plus they manage to portray themselves with this favorable underdog image against Microsoft and Google.

When I use Yahoo I sometimes think it would be pretty interesting and challenging to work there as a programmer. If I was an elite CS major coming out of a top ranked school like Stanford, then I could pick where I wanted to join among Microsoft, Google, Apple or Yahoo. In that enviable situation I'd give very strong consideration to picking Yahoo. I'd give them an at least an equal chance going in.

Saturday, June 24, 2006

The cost of enterprise software

I work for a consultingware ISV. That means we tend to sell to large companies. We have base products that we customize to the customer's requirements to do the deal. Pretty standard stuff.

One thing I've noticed is that the overheads of what we do are very high. The amount spent on travel and lodging for each sale is a lot. Also for each sale made, an ISV also spends on deals that they bid on but don't win.

The costs of research and development are part of the equation. Having programmers who create the base products and their costs such as office space. Also not every product developed is for sale. Sometimes products can be started and then killed before completion, leaving behind sunk costs. Some products make it to market but then don't sell as well as hoped, and do not cover their development costs.

Then there's general overhead costs such as finance and administration, legal, SOX compliance, costs of being a public company, etc.

So when the ISV quotes you a price in say the hundreds of thousands for some software, you have to realize what that price is paying for. It is paying for the software itself, then all of the other overheads the ISV absorbs to get that software to market. And then the ISV of course wants to make a net profit. So the gross margins need to be very high of course to cover the costs of doing business as an ISV.

The consultingware ISV is also at a disadvantage compared to mass market shrink wrap software like say Quicken. The consultingware ISV can only sell their products to a small market. For example there are only around 100 big telcos in the world. So a product catering to ILECs has a limited market to sell into. That means they have far fewer potential sales they can make to cover off their development costs. The shrinkwrap software company can amortize their development costs over millions of unit sales.


So I was thinking, from the customer's perspective, why buy enterprise software if it is expensive and the GUI may not be especially slick, and it is basically not a lot more than some big CRUD database application. Why not just get the IT people to clip something together for far less. Now I'm not a salesman so I don't have the stock answer to that question.

However the consultingware ISV offering does have some good points. Our software tends to be stable, and it scales well to enterprise level number of users. The internal IT people tend to be good at putting together quick small departmental level stuff quickly but are not as successful at larger scale, more complex integrated developments.

Plus there is far less risk and potential liability going with the consultingware ISV. If the ISV salesman can demo something that works and does 70% of what you want, with a quoted price and schedule to do a customization to get it to a good enough 90% then that is a low risk for the customer. The IT department might say they can do something at least as good for half the cost in 6 monts, however those are just estimates which you may not be confident in.

The nice thing about purchasing software is that the software vendor continues to be responsible for the maintenance of the source code. That motivates the vendor to create clean maintainable code for their own sake.

With internal IT projects, they might not have the same level of discipline in throwing something together faster and cheaper than the consultingware ISV quote. You could be left with an undocumented, unmaintainable, unstable code base with the original developers long gone and nobody capable of taking it over. It is very desirable to avoid that type of situation, even if it means spending more up front to purchase the software.

Tuesday, May 30, 2006

muon.html

The weekend started so well. Through a series of circumstances I went to see Evita at the Neptune Theatre. That was a very enjoyable show.

I got home around 11 PM. I was going to do a quick login and check my e-mail and get to bed by 12.

Unfortunately when I logged in the computer was in a bad state. The screen was covered in popups that kept appearing on their own. The popups were for stupid sites that all seemed to end in muon.html. Even Firefox was popping up extra tabs when I tried to do anything. I couldn't open a command prompt or the task manager. After a couple of minutes Windows defender put up a screen saying it was going to reboot the computer to protect it. Big trouble.

It was difficult to get the computer working well again. I ended up running numerous scans and fixes with windows defender, ad-aware, spybot and hijack this. That cleaned up all kinds of stuff. Finally after I cleared out that bunch of other crud, I followed these instructions to get rid of muon.html. The instructions worked great and now the computer seems to be working properly. As a bonus I got rid of a lot of junk from auto startup that was making it take way to long to start up.

Where did it come from? That's a good question. I noticed that the trouble appeared shortly after my wife downloaded limewire. As part of the work to get rid of the popups I zapped limewire. I hope I never see it again. I noticed that of course limewire is as stubborn as the viruses to get rid of. After the first attempt I got this dumb java message every five minutes about some missing gnutella class. So limewire seems to be built on gnutella - wonderful.

It's annoying because this has happened before. Months ago my wife started using Kazaa. For about a week she got some files she liked. Then the popups, weird error messages, IE start page change, and Google hijacks showed up. That was a lot of work on me to clean up. After Kazaa vanished the popups went away too. I don't know why she thought it would be any different with limewire which is just kazaa by a new name as far as I'm concerned.

I have to use the computer too to log in remotely to work and to just use. If I had the money I'd get a wireless router and my own computer and just use that; let my wife clean up the viruses while enjoying her downloaded stuff.

I don't see the point of downloading music from unknown sources when iTunes is something like $0.99 a song, and Yahoo music is $7 a month.

It's troubling that Firefox was affected by the trouble. In the past stories of trouble in Internet Explorer were like hearing about strife in the Solomon Islands, Sudan or Nepal. Trouble in a faraway land that didn't really affect me. I guess Firefox is popular enough now that the black hats are disrupting it too, which sucks.

I know of people who have suffered with random popups for like months. I was thinking of setting up a removal service to try to make some money off this.

Thursday, May 18, 2006

+1 for JProbe

We were doing some performance analysis recently of our application. The application is distributed across a central J2EE AS component, with satellite nodes running under Tomcat connecting to the central J2EE server.

We used JProbe to collect the baseline performance data and locate the hot spots. I have all positive to say about this product. I was focused on the Tomcat part, but the people who used it on the J2EE side also spoke well of it.

For Tomcat, setup was a breeze. It was all simple click through wizards. JProbe has a built in Tomcat module and it works great for Tomcat 5. The setup worked properly the first time I ran it.

The stats it collected were right on. They provided all the data I was looking for. The results were presented in a useful way that allowed me to see the key summary parts while also being able to drill down to the level of detail I needed.

At one point I wanted to focus on CPU utilization in the remote Tomcat servers. I was able to easily reconfigure my JProbe session to measure CPU usage instead of default clock time. It worked just great and quickly isolated some key areas. The areas it found were not the sections we thought were problematic. So JProbe saved us a lot of effort.

Wednesday, May 10, 2006

Remote control

It's just so impressive what you can do remotely these days. The software is great and the CPUs and networks are now fast enough to make it work quite well. Here are a couple of examples.

Sitting at my home on a weekend I get a call about a support issue.
- from my home PC I connect to a VPN at the Halifax office
- from the VPN I'm able to remote desktop to my work PC. The GUI and everything comes up properly. It is responsive. Close enough to the real thing that I'm able to work without really noticing I'm logged in remotely. Remote desktop is just an awesome piece of work.
- from the remote desktop session I use Funk to connect to another server on a different continent. Again everything is responsive. The mouse works the way you expect. I can copy and paste from computer to computer and it all works easily
- after I Funk'ed into the computer on the other continent I was able to see what they had and do the fix
- the chain is home PC -> office VPN -> office PC -> server on a different continent


Here's another example
- sitting from my home PC I connect to the office VPN
- from the VPN I remote desktop into my work PC
- from remote desktop off my work PC I launch an xterm to a UNIX server in the office
- from the xterm window I ssh into a different UNIX server in the office
- the chain is home PC -> office VPN -> office PC -> virtual xterm session -> virtual ssh session


I just find it remarkable all the layers of indirection, all the encryption, all the network traffic. And it comes up great and is nearly as crisp and responsive as being there.

Remote desktop provides other advantages. Before RDP, when it was busy at the office, I had to be physically in the office to put in the extra hours. This meant I sometimes had to arrive at work horribly early. Or it was disruptive staying late or going in on a weekend. Now I can usually put in the extra time from home and still be able to do other stuff around.

The thing you have to be careful about with RPP is you can get a bit too attached to the office. Like just extending your office day from home after supper every night. It can be a bit "addictive".

It's OK in non-peak times to log in for a few minutes in the evenings and check your late in the day e-mail. Or pick off some small thing that was nearly done when you left. But keep it balanced. Your time away from the office is just that.

Wednesday, May 03, 2006

EJB is not portable

Remember when Java bragged about being "write once, run anywhere"? Well in EJB land that does not seem to apply.

We did a port of a J2EE application to a new application server. We were able to finish it. I'd say that about 70% of the porting effort was spent on EJB. Around 15% was the GUI servlets. Around 15% was other stuff like documentation and the ant scripts and some J2SE clients.

The servlet stuff went well. There were just a few small things we were doing that were against the servlet spec that the first application server allowed, but the new one didn't. Easily identified and fixed.

EJB was a much different story. So much of it is vendor specific with designed lock in that porting is so much more effort and complicated. It just shows how painful everything is in EJB. It's painful just getting stuff to work on the original application server, let alone porting it to another one.

That's just not the Java way. Originally people liked it and used it because it was portable. When something is painful to port and requires code changes to port like EJB then that is not in the spirit of Java. It may be short term advantageous to application server vendors to discourage porting or make it expensive. But long term it's a bad thing. It undermines the cross platform spirit of Java and comes across as bait and switch.

I've grumbled about EJB before. I just don't get EJB or why people would choose it. It is painful to do anything in. It is so verbose with all the endless and non standard XML files. There are all these code restrictions that annoy and frustrate the programmers. Weird and tedious concepts and terminology in the EJB spec. Bewildering arrays of modes and options. Good luck connecting from an external J2SE program.

At every turn EJB comes across as developer hostile. Without developer support it will have a tough go of it long term. It's no surprise that new competing technologies have emerged and have gained support.

If I was the decision maker and was starting something brand new in Java with no legacy code base then I would not choose EJB. Just stay clear of it entirely and everyone will be happier and better off without it.

Saturday, April 15, 2006

Get Ethereal

At work we were having some interop problems between our server and some DSL devices. I wanted to get some packet traces to see what was going across the wire in both directions.

Needing some software for this, I Googled around a bit. There were some commercial products. Most of the commercial products were big elaborate network management suites. I just wanted to sniff some traffic between my PC and a device. Looking around a bit, I found Ethereal.

Ethereal is free to download. It did what I wanted, allowing me to analyze the traffic and get a nice detailed view of what was going on. I recommend Ethereal for packet sniffing analysis. Pretty good for free. The commercial products were starting around $995.

Ethereal is just one of many free and open source products I use all the time. Here are some others I use now or have used heavily in the past.

  • Eclipse, plus a number of quality free plugins
  • Python
  • JBoss
  • Emacs
  • SgMibSpy
  • PHP
  • Tomcat
  • Apache Web server
  • All kinds of Apache Jakarta Commons Java libraries
  • MySQL
  • Ant
  • Java JDK
  • Linux
  • Firefox
That's just off the top of my head.

What does it mean? Well in those areas above, it would be tough to sell me something when there is a quality alternative that I can download and use for free. Why pay $995 to sniff traffic when Ethereal is free? Why pay for a Java IDE when Eclipse is outstanding and free.

That's kind of the thing about open source. The stuff is great for a programmer as it makes your life so much easier and more productive. However, developing commercial software, you can see a potential threat to your company's area if a strong open source alternative was available. Where I'm at in consultingware, we tend to be industry specific, with services work with each sale. Since were not mass use general purpose we're probably not too threatened by open source at this time.

Sunday, April 09, 2006

New CEO

We've hired a new CEO at work. Since I joined Core Networks in the summer of 2001, this is the fifth CEO I've had. We also preannounced this quarter. This is the third time in the last seven quarters we've preannounced. I don't think many people are expecting the new leader to just maintain the status quo.

In the nine years I've been in software, there's been some interesting times. I've been acquired three times. I've survived eight downsizings. I left a job on my own. I've been fortunate to not yet been downsized. I've also not yet been in an office or company that was shut down. So far so good.

As always I'm grateful to on the inside working in high tech. The pay and benefits are good. The coffee is free. The work can be challenging and interesting at times. The cubicles are comfortable. The office is climate controlled. The PC is fast and the monitor big.

The change is a fact of life in high tech. I sometimes miss the stability and continuity of PRIOR Data Sciences back on Spring Garden Road. It was civilized, things were done a certain way. Spring Garden Road was happening and downtown. Alas, PRIOR is no more.

Monday, April 03, 2006

I'm LinkedIn

I heard from a former coworker last week. She invited me to join her network on LinkedIn. It looked interesting and I respect her, so I joined. So now I'm LinkedIn, yay for me.

My network only contains the one person, so I should try to increase it I guess. I'm not sure who I should ask to join. It would be a good time to try to find some of my old TUNS (now DalTech) fellow students and find out how they are doing. Back then around 1/2 the TUNS CS Class of 1997 joined Nortel, who I'm sure would have hired the other half too if we'd wanted to join. I wonder what became of them. At least of some of them are likely still there, but certainly not all of them.


My friend's network was interesting. She has around 12 people. Some of the names I recognized as people I'd worked with before. One guy I knew from St. Mary's and TUNS. Some of the others were well known players in the local startup scene. It was pretty good company to be in, so it's nice to be remembered positively after we'd worked together in the past.

One time there was this insane Core Networks project where she was team lead and everyone was working really hard on it. There was a key integration testing weekend before the first baseline went to the test team, and she said that everyone was on call and had to come in if problems were found in their area. I had a quiet weekend. On the Monday after she told me she'd phoned everyone else in the department over the weekend except me with code issues. No problems were found in my code. That's kind of a party trick I have of writing all kinds of features and lines of code with very low defect rate, something I take pride in. I take bugs in my code personally, but in my career I've noticed that few others do. Most people I've ever worked with are indifferent to bugs in their code.

It has made me realize I've been part of the Halifax software startup scene for nearly five years now. In my own modest way I've contributed to building a new company, and to building the Halifax software industry. I think it will be interesting to see what directions my career takes in the next five years.

Monday, March 06, 2006

Hammer that keyboard

Here's a tip if you spend most of your work day working at a computer, like most programmers do. It is a lot faster to use the keyboard than the mouse. The mouse slows you down. You have to interrupt yourself to reach over and it is slow and imprecise to use. Then you have to interrupt yourself again to get back to the keyboard.

You will be more productive if you learn the keyboard accelerator shortcuts for the programs you use heavily during the day. Any professionally written application has them. Many good applications allow them to be customized so you can create a binding for a command you use a lot that takes three menu clicks to invoke with the mouse. The keyboard shortcuts will just save you tons of time if you learn and master them. It is a small investment in time that will pay off many times over.

I find it surprising at work how few people realize the benefit to using the keyboard over the mouse. As programmers we write the applications so should want to make them fast and easy to work with to test, yet a lot of people don't.

One time a couple of years ago a co-worker was struggling and using his mouse awkwardly with his left hand. I said to him, "I thought you were right handed." He said he was, but he was having carpal tunnel problems in his right hand so was trying to start using the mouse left handed to lessen strain on his right hand. I suggested to him that he should learn to use keyboard shortcuts and avoid using the mouse at all as much as possible. He gave me a kind of "nnnyaa, I don't really want to do that" look. What can you do? Even with a career threatening condition he still wasn't eager to consider the potential of the keyboard. It's kind of funny because he was a GUI developer so he had the ability to put in all the hot keys and get the default focus and tab indexes right to make it easy on himself.

Pulling it together with this post, and my previous posts on leveraging your IDE, and Google desktop search, there is a theme. My point is that there is a lot you can do to be more productive without working any longer or harder. Optimize your work environment to make things easier for yourself.

Friday, February 24, 2006

Skateboarder NYC v1.0 game

I've released another game that I wrote.

Skateboarder NYC v1.0 is now available for download over on my free games site.

It's freeware and the Python source code is available.

Enjoy!

Monday, February 06, 2006

All nighter

Last week I pulled an all nighter at work. I hadn't done one since the death march project last year.

A problem was found in some code that was to be used for an imminent customer demo. It turned out to be a newly discovered bug in the same troublesome code from the project last year. Fortunately I was able to find and fix the problem, and the demo went more smoothly.

It was a long night. I was finished up some other stuff and putting on my jacket to leave at around 8 PM when my director comes running out of his office to tell me there was a problem and could I look at it. So I wasn't really prepared for it. Fortunately we have a coffee machine at the office with Starbucks coffee. I put on a brew. I ended up drinking most of it through the night - yuck!

I'm glad things turned out pretty well. People seemed appreciative of it. The next morning one of the product managers said he'd go to McDonald's and get me whatever I wanted for breakfast. I got a sausage McMuffin and coffee. McDonald's coffee is pretty good. That was a nice gesture by him. The grease hit the spot.

Hopefully this will be the last all nighter due to that troublesome code base. Am I confident we've found and fixed all of the bugs? Hardly! In the next product release most of that problematic code is now rewritten. Going forward I expect things will work much more smoothly. Also I can actually really understand what the code is doing now. So if there is an issue with either my code, or the external systems that interact with my code, it will be significantly faster to isolate problems and fix.

Generally I prefer to avoid rewriting existing code. It is generally difficult to justify the effort to spent developer time revisiting code that seems to work. In this case we wanted to improve product performance, so we had to revisit the inherited code. Plus we will save maintenance headaches going forward by avoiding situations like the one described above.

I don't have an equation for when to rewrite. It's a decision you make based on your experience, judgement and instincts. I'm generally skeptical of the value of rewriting code that seems to work and whether you'll truly be better off for doing it.

Sometimes there can be political pressure against rewrite. There may be a large sunk cost in the existing code base. Also a rewrite could be seen as a knock against the reputation of the original developers, so that may not be popular.

Still, when you know that rewrite is the best solution then you need to push ahead and do it.

Tuesday, January 03, 2006

Welcome RIM

Recenty Research in Motion has announced they are coming to Nova Scotia, with 1200 tech support jobs. This is great news for the high tech industry here in Nova Scotia.

I notice RIM has posted some Halifax jobs on Workopolis. I subscribe to Monster and Workopolis alerts, even though I'm not looking to switch jobs. I just like to know what's going on. People in tech seem to be pretty gossipy about what companies are doing well or poorly, and what the hot skills are. If you just listen to the chatter around your cubicle you can pick up a lot.

The tech scene in Halifax has been very weak the last few years. The period of 2001-2003 was very tough, with hardly any jobs posted. I think there were more New Brunswick tech jobs posted in the Saturday Chronicle Herald than Halifax jobs. A lot of people who had jobs in high tech had to move on to other industries. A lot of new grads weren't able to break into tech during this time and had to find work elsewhere. I was fortunate myself to be able to stay employed the whole time.

Things stabilized through 2004-2005. Hopefully it will continue to improve through 2006 and beyond. It's strange why it was so tough in high tech in Halifax the last few years. Like everywhere, we grew in the late 90s. However we didn't have a huge Internet startup scene so the bust itself didn't really cause any spectacular job losses.

It's interesting that RIM will be locating in Burnside park. In the early 2000s there was a move to establish Bayers Lake park as a tech "cluster". Although xwave and Core Networks moved there, few others did and the cluster didn't get off the ground. The RIM decision pretty much kills any hopes for a cluster in Bayers Lake.

There is a huge cluster of furniture stores in Bayers Lake though. I understand a top big ticket item salesman can pull down very good compensation. That's not quite the cluster the city planners hoped for, but still a good living for a fair number of people.

The thing about the other clusters in Canada like Waterloo, Ottawa and Vancouver is they have a strong hardware presence as well as a big software scene. For whatever reason you need a big hardware presence to have a tech cluster in Canada. Software alone just won't do it.