Showing posts with label work. Show all posts
Showing posts with label work. Show all posts

Thursday, August 19, 2010

Windows Server 2008 R2 and COM Objects

So we just went through a huge ordeal while trying to decommission an old server and move a legacy website onto a new one. The old server was a 32 bit Windows Server 2003 machine, the new one is 64 bit Windows Server 2008 R2. The website is classic ASP that uses Dimac's JMail control and SoftArtisan's FileUp control, which are both 32 bit.

The result was several HTTP 500 errors and a relatively generic set of log messages. Actually we weren't always seeing anything in the logs. It was fairly perplexing. When we did get error messages they were like this:


800a01ad|ActiveX_component_can't_create_object

8000ffff|Enque:_Error__no_pickupdirectory_found.

80004005|[Microsoft][ODBC_Driver_Manager]_Data_source_name_not_found_and_no_default_driver_specified

The first part of the solution was to set the application pool for that website to 32 bit. You do this by opening IIS Manager, select Application Pools, select the application pool you're modifying, in the Actions pane click Advanced Settings..., then set Enable 32-Bit Applications to True. After you've done that, reset IIS and try your site. If the site still isn't working, reboot your machine. Apparently Windows isn't all that keen on switching between 64 and 32 bit, so sometimes a reboot is in order. [We had to.]

Maybe that will fix your problems, it didn't for us. In fact, the ODBC error seems to stem from this action. Apparently when you create an ODBC DSN it's only available to 64 bit processes. You have to create the DSN in the 32 bit space by using the 32 bit Data Source Administrator from the SysWOW64 directory [odbcad32.exe].

We still had those pesky JMail errors. The object was created successfully but we were getting File I/O errors. We followed advice that suggested we should copy the DLL to the SysWOW64 directory and register it there. No change. We modified the permissions on the DLL to allow everyone to read and execute it. No change.

What we hadn't thought of yet was to modify permissions on the SMTP pickup folder. We didn't think of this because the test page we'd created had everything but the instantiation commented. Still, this simple change made all the difference. For whatever reason, giving write permission to the IUSR didn't fix this. We tried a few other users before we gave up and just gave all local users write permission to the pickup folder. This did the trick.

Overall this was a royal pain. That's why I stopped to do this quick write up. I hope it helps.

Thursday, April 15, 2010

Feature Creep: The Enemy of an In-House Developer

If you do in-house development then you probably have first-hand knowledge of feature creep. If you don't know what that is, or you haven't seen it happen, then I envy you. It's an ugly monster and the bane of my work. The problem is not limited to in-house developers; it is particularly acute in that environment, though.

This is because development cost is a taboo topic in most in-house development environments. The developers and their immediate management don't want to talk about it because they don't want to remind senior management that in-house development is expensive. Senior management is happy to ignore it because they crave the finite control, costs be damned. So a game is played to balance the quality of the product with costs, where the quality is generally lower than a prepackaged system and the cost is generally higher. In general, this works fine. It helps keep developers employed and management happy.

The real problems start as the customization culture trickles down the management chain. Depending on how vertical the structure of your company is, you may have dozens of management steps between the top and the developers. Typically, when software is not a primary focus of the company, your developers and their managers will be quite low on the org chart. This puts them at a disadvantage when dealing with almost any manager and makes saying no quite difficult.

Therein you have the perfect storm: A situation where discussion about cost is a taboo, but the number of powerful voices calling for increased cost is huge. It's worse yet, though. When management's focus is not on software but instead specifically on how to make software work for them (as in, each manager personally) there is often little to no concern about the cost of feature creep to usability. In fact, usability is typically not in a non-technical manager's vocabulary. Outside of the developer group no one cares about usability, and often inside the developer group it is neglected because of the notion that client doesn't care.

Unfortunately, even if the user thinks they don't care about usability they really do. The difference between great software and passable software is often usability. The difference between a truly happy client and a client who is merely happy that development is done is usually usability. Software is supposed to solve a problem, to help a user achieve a goal. If it is too difficult to use it creates more problems than it solves, or it hinders the users from achieving their goals. At that point it should be considered a failure, though reality shows that this rarely happens.

Failed development projects, whether they are recognized or not, are dangerous. They put developers on shaky ground. They cause managers to think of the taboo of their in-house development: cost. If they aren't thrilled with the product then they will be far more likely to consider whether it is worth the money. The only thing that keeps this from happening is that they are often too egotistical to admit failures, but eventually if feature creep continues they will come around. When they do they will externalize the failure to the development group, after all it is their job to make this software and if it's so much more expensive then it should be better, right?

Wrong. There is little connection between cost and quality in software. Devs don't dare tell a manager this, except maybe as a last resort. Lest he add things together and realize that he could put company resources to better use.

Of course, most developers actually do want to put resources to better use. With less pet projects on their plate most developers will try to automate processes to save the company money. They'll refine existing systems to make them more efficient. In this aspect, in-house developers yearn to be more like system and network administrators; if you can't tell I'm there then that means I'm doing my job. Occasionally they might venture off course to test some new technology or try to solve a particularly complex problem, but for the most part a dedicated in-house developer is happy with the sense of accomplishment that comes when he or she knows that their product made a truly positive impact.

Developers have a responsibility to fight against feature creep. Don't buy into the false mantra that your job is to do as you're told. Your job, at any level of any company, is to act in the company's interest. That means to be truthful about costs and try to help management make the right decisions. There is no room for complacency in this. Feature creep is the developer's enemy and it is our duty to fight.

Friday, November 20, 2009

Monitoring Internet Usage

This is part of a series of reprints from my classes. Once the class is over, I will lose these if I don't save them elsewhere. I've decided to post them here as they may be of some interest. This is from my Introduction to Information Systems class, which I was too lazy to test out of.

I'm not against monitoring internet usage in the workplace. I am against ham-handed management of people's communication. Often I find that this argument is oversimplified: You're at work to work, and you can't possibly be working if you're online on an outside instant messenger or checking your email. This argument ignores all other factors, such as lengthened work-weeks and jobs where productivity is held at a higher value. I think that a situational approach and proper management are required, no monitoring technology can replace these.

This boils down to metrics: Is someone's productivity and worth to an organization measured in how much time they spend online? I posit that it is not. You are not paid to not use the Internet, you're paid to perform certain tasks. Depending on the type of tasks and the expectations of your employer, this may preclude using the Internet, but it likely does not. Instead we should judge employees based on their ability to get their job done, only when they fall short of that should we question how they use their time.

Work/life balance is another issue to consider. When employers ask increasingly more time out of their workers’ lives they should expect a compulsion to bring the home life back into the mix to find a better balance. This is especially true when it comes to IM where that communication can be vital to maintaining healthy home relationships. It can also be said that the workplace continually creeps into home life. How is IM unacceptable at work when BlackBerries are required to be on at home? Again, this is about balance and it will vary individually. The employee who works minimal hours has less claim to this than the one who works dozens of hours overtime and some employees allow their home lives to affect their work. Managers should deal with these employees individually and realize that their Internet usage may not be a particularly useful metric to fixing the problem.

Lastly, I will side with employers from a Human Resources perspective. I think this is where monitoring, and even filtering, is important. Employees should know they are being monitored and they should have a few clear usage guidelines for the Internet. It may be acceptable to communicate with your family and friends, but not everything is acceptable to do from work. Companies need to take a zero tolerance stance on pornography, discriminatory practices (take for instance the Human Rights Watch worker that was recently found to post on Nazi bulletin boards), harassment, industry secrets, etc.. Such offenses should be taken extremely seriously and should be actively monitored. Employees that cross the line should be dealt with immediately. Policies like this should be clearly stated, though.

Schools are somewhat similar. I think there, since you’re likely not dealing with adults, you should be a little more proactive in monitoring and stopping abuse of technology. I see most of this as twenty first century note passing. Other content should be filtered, though pretty much any filter can be broken. This is still a situation where filtering and monitoring will not take the place of parenting and teaching. If a child is struggling you might look at abuse of technology as a contributing factor, but it is dangerous to assume that it is the definitive factor and even more dangerous to act on such an assumption without considering how it may effect the child.

With parenting, I think that young children should be monitored closely. This isn’t to say that I’m afraid of what they might see or who they might talk to. It is that they are far more likely not to understand, to take things wrong, and to make poor assumptions about what they’re seeing. I don’t want my child reading a hate website unattended, lest they believe such foolishness is true. I don’t want them to use social networking sites unattended, more because of cruelty like that of the Lori Drew case than worry over someone appearing on To Catch a Predator. The younger the child the more help they need with interpreting the situation Eventually they grow older at which time I would scale back monitoring only to avoid more serious problems such as lawsuits over infringement. Though such things may be a little easier to block than to monitor.

Tuesday, March 3, 2009

The Benefit of Consistent Naming

In late 2007 I started a project that required a pass-through database to allow for auditing and change approval to occur between our CRM product and Outlook. I was, and am, acting as the database administrator (DBA) on this project. I was fortunate enough to be able to create the database almost single-handedly.

Doing everything yourself is tedious work. It can also go very wrong if you assume that you're not just doing it alone, but doing it for yourself. I stuck to some best practices to create cleanly formatted, self-documenting, and commented SQL code. This has allowed me to have exchanges like this:

Coworker: "What is the procedure to get a contact's information?"
Me: "getContact"
Coworker: "Oh."
Coworker: "What if I want to add this user as a subscriber?"
Me: "Use the addSubscriber procedure, pass it the contact ID and the user name."
Coworker: "Oh."

Eventually they stop asking because almost everything is so predictable. These exchanges may make them feel ridiculous but that's the point. If you stick to a well defined naming scheme then your code should do a lot of self-documentation. If the code is documented then it will normally be equally convenient to simply reference the code. This is a benefit to everyone. There is less need to bother me. The code is more readily available to the other developers than I am anyway.

Another benefit became apparent to me a few times recently: It helps you find when you are about to do the same thing twice. This is a big database that my team has been working on for the last year. There are almost 200 stored procedures and functions. Unfortunately, I was not able to create them all. I did create the vast majority, though, sticking to my same naming conventions each time. Now we are actively developing parts of this project again, so I need to put new functionality in the database. At least twice in recent weeks, a procedure I was prepared to create already existed, was named exactly what I intended to name it and did exactly what I wanted.

The lesson here is the power of doing things the right way for the sake of it truly being the right way. I could have probably done things faster if I didn't take the time to properly indent my SQL queries or if I used the query designer every now and then. Yet, I would cost myself and the company time in the long run because it would be far more difficult to decipher those queries to troubleshoot or change them. I could have used procedure names that were less descriptive to save some typing time or avoid names such as "getAcceptedCompanyMinorityStatusValues" but then I couldn't tell you exactly what the procedure does without looking at the code, and if I needed that later I might use a different naming scheme and do the same work twice. It is usually quicker to do it right once than it is to do it half right twice, especially when twice is likely to grow exponentially.

Thursday, February 26, 2009

Solution for My Time Sheet Problem

I have to fill out a time sheet at the end of every week. It's due by Monday at noon. Each week I find myself filling in 40 hours to the main project that I worked on, then wondering to myself, "Okay, what did I do this week that took away that time, kept me late, and made me miss lunch?"

It's a perplexing question. Even with my attention draining habits, I still feel that I am putting in over 40 hours of real work per week. Yet I rarely feel that all 40 of those hours were spent working on my current primary objective.

I've found that the times I keep detailed logs of how I use my time that I have dozens of interruptions during the day. These are interruptions for various business reasons, not my own attention wandering off to the realms of the Internet, I tend to simply discount those times from my time sheet. I feel that it is a disservice to myself not to somehow indicate that these interruptions occur.

The problem is that it is another attention draining task to stop and note each interruption. It also magnifies the impact of small interruptions, which I can sometimes regain my focus immediately after. So I resort to keeping clues around by way of emails, notes, and phone logs. Then my time sheet exercise is to find all of these notes, combine them with other events that I remember but did not note, and rebuild my week in an honest fashion.

Doing this on a weekly basis is hard. It also doesn't mix very well with the whole Inbox Zero thing. It's too much work to get this information all into a single store, and if I immediately process and file it then it is that much harder to reference it by date.

With Outlook 2007, I think I've finally found a workable solution, at least for my email. I created a category "For Time Sheet" and assigned that to the category quick click event. This allows me to quickly mark the items that are interesting for my time sheet. Next, I file these items in my personal archive. On my personal archive I have created a For Time Sheet search folder that lists all of these items. I added this folder to my favorite folders list.

Now with a single click I have access to all of the items that are interesting for my time sheet, regardless of what folder they reside in. I can remove the category as I record the time I spent working on these items, allowing me to limit the list to only the current time sheet. Since I try to use email as much as possible for correspondence this unobtrusive process does most of the work for me.

Saturday, February 21, 2009

My RSS Reader has a "Productivity" Category

I put it there. Nevertheless, it's there. This post is about the irony of that.

Recently, one of the feeds that I have categorized under the Productivity folder, Lifehacker, posted about ManicTime. ManicTime is an application that somewhat unobtrusively monitors your application usage and provides a report. You can tag time spans and use it to help figure out how you're using your time. It's great for someone like me that has to fill out a detaile time sheet at the end of the week.

Here's where the irony comes in. I installed this app on Tuesday. Since then, only one day (the first day) was Firefox not the top application by sheer volume of usage. I used Firefox for almost 30% of the time I was on my computer. The most time consuming thing I do in Firefox? Read articles fed to me via my RSS reader.

Fortunately I don't live in a fantasy land where average people are 100% attentive. If I did then I would think that something was seriously wrong with me. However, I do live in the real world and I think that 30% might be a little high. Sure, I do read trade-specific articles part of the time. I do have a business reason to have Firefox. Still, the primary reasons I go there are personal.

Now I have to figure out what to do, or if I should do anything. I'm not too worried about my productivity. I even amaze myself with my ability to meet or beat deadlines occasionally. I do wonder if lowering the noise might boost my productivity, at least in a way that would result in less overtime and more family time. Then again, if I take away my distractions during the day I may realize how boring and tedious my job is. I may stagnate and stifle my creativity. What to do? What to do?


I'm going to try to cut back. I think I need to push myself to improve this ratio. I at least owe it to myself to experiment and see if an extra 10% of my attention is worth the price.

Tuesday, December 9, 2008

Free Trade: Why Don't You Get a Job?

A coworker sent my department one of those junk emails with crappy jokes today. This one was about a guy looking for a job. It went down a list and mentioned all of the things he was wearing and using and where they were supposedly "made." The punchline was that everything was foreign and he wondered why he couldn't find work.

Welcome to global economics with free, but not fair, trade.

The problem I have with sentiments like those insinuated in the email is that they blame the wrong thing. They blame everyone else, but especially the foreign workers for having the audacity to import their goods.

There is a distinct failure to blame the politicians for opening up free trade without ever imposing the slightest bit of human rights, workers rights, or environmental regulation. More importantly, there is the failure of our mindless consumerism to ever think of the consequence of blind shopping for the lowest price in a category with little actual understanding of how that price is achieved. In short, the reason we don't have manufacturing is because we exported it willingly and then refused to buy local.

So, if its the jobless man's fault that he can't find a manufacturing job, or his father's or his neighbor's, where's the joke? I'll rewrite it for you: All he needs to do is wait for the economy to collapse to the point where he can't afford any of those things and the capitalists will gladly pay him $0.12 per hour to make them instead.

Friday, July 25, 2008

A Quick BlackBerry Post-Mortem

I recently carried and returned a BlackBerry 8820 for my job. I did this on a temporary basis as a stipulation of my vacation, since not enough notice was given I had to be on-call for at least two of the five days. My experience overall was a positive one, I was able to be responsive and somewhat productive what out of the office.

I never finished this one. Long story short, I found myself checking my mail too often. I felt slightly leashed to work. The 8820 was too big for my liking, and the keys too small. Yet, through all that I was able to be away from work without worrying too much that I'd miss out on things. I could communicate still, and I was able to make a big contribution with only a small amount of my day.

I decided not to press for a BB through work, but to get one for personal use. Last weekend I did just that. I chose the Pearl because it's more phone-like yet it has larger buttons that are easier for me to use. I'm trying to work something out where I can get my work email on this phone without the attached expectations of having a work BB. That way I can use my free time to help my productivity without my boss (or her boss, more importantly) feeling that they command 24 hours per day of my time. We'll see how that goes.

More Chain Mail Lunacy

In retrospect, I should have posted this one as-is back in November...

Last time, I was complaining because a coworker used me as a source rather than doing a simple two second search to verify the validity of a piece of chain mail, and I commented on how the email actually linked to the snopes.com article that invalidates it. This time it's far worse. This time the CIO actually forwarded one of these messages, claiming a new computer virus is spreading, to the IT Department.

Wednesday, April 16, 2008

Difficult Choices

This is an email I wrote to the users of one of our applications. I realized that none of the users want to hear all of it, so I decided not to send it. Still, I think it's an interesting look into what I do, and the little details that I toil over.

Recurrence, recurrence, recurrence…

One of the most requested features for the new Corporate Events Calendar is now implemented, sort of. We have partially implemented the feature, and plan to finish it soon.

Recurrence is one of those things that are easy to describe, but hard to get right. We had a very crude implementation done by release date. We realized that it was not right and so it was removed from the calendar. In its place was a message [I considered it a promise] that it would come soon. Since then we have spent much time in planning and development to strike a balance between easy to use and powerful, functional and sane.

We believe we have achieved those goals, but you are our ultimate judges. Read on to learn how it works.

Recurrence can be broken into a few questions: How often, how many, and what gets copied.

How often can you schedule a recurring event; daily, weekly, monthly, yearly? We chose the middle two. You can either schedule a weekly or monthly event. Daily and yearly events rarely recur in such a pattern, and we do not want a lot of wasted reservations being created, we are going to handle those differently. I will cover that later. As for the weekly recurrence, you can set what day of the week to start and how many weeks between occurrences. The monthly scheduling is done by selecting the day again and which week of the month the event should be held.

How many events can you schedule at once? This was a particularly challenging question. We would love to allow for infinite scheduling, but that is not very manageable. We chose to limit you to 24 monthly occurrences and 52 weekly occurrences. You will have to revisit your events to create a new schedule each year, which will allow you to make the necessary adjustments and will self-clean any abandoned event schedules.

What gets copied? Again, there were no easy answers. We could copy everything, from basic information to each invitation sent, but only certain values apply to every event. We chose to copy: Event Information, Rooms/Equipment, Scheduling, Capabilities, Facilitators, and Sign Up settings (not the attendees). We have left off the Invitations and Menu, because those tend to change from event to event. Obviously, while the schedule is copied, it is also modified to start as of the new date.

One last feature is that you will see a list of all scheduled occurrences after you have added recurrence. This will allow you to quickly jump to other occurrences. You can also use this list to cancel future occurrences, just select one or more and press the Cancel Selected Occurrences button, then confirm your action.

Now that I have covered what is implemented, I need to discuss what is still missing. The biggest feature that is missing is the ability to modify all of your occurrences at once. After you schedule multiple occurrences of an event you will have to manage each one separately. We will implement a way to push changes to all occurrences and plan to release it in the near future.

Another feature that is missing is the ability to add an individual occurrence. This will allow easy scheduling of yearly events or quick copying of an event with two instances. We think this could be of great benefit and plan to release it shortly.

I cut it off there, realizing that I need no conclusion to an email that I will never send.

I love to be open with my clients about what I do. Sharing information is important to me. I find that when people know what goes into every decision that we make then they're more likely to appreciate what we get right and positively contribute when we get things wrong. The problem here is that most people don't care about the decisions, especially not until they believe it effects them. So, I'll hold this one back.

Wednesday, April 2, 2008

The Problem with Integration

The more you integrate products the more that product A's operation relies on how well product B works. A bug in product A can cripple product B.

That's pretty obvious, but what's less obvious is that you have to be able to trust everyone involved in the integrated products. If you can't trust the developer, or the code, of product B then product A may be doomed. If you're integrating products so that they use the same data then you not only have to worry about the developers, but the operators as well.

On Monday an application stopped working. It's part of our Intranet, but it displays human resources data, and it ties into our accounting system. It turns out that the accounting department had not opened a new period in the system, which broke everything.

Tuesday, April 1, 2008

I Want My H1B

Well, not for me. I'd like one for my coworker. He's a great guy whose been here on a student visa and began interning for us a few years ago. I believe we're hoping to get him one of these visas and I really worry what will happen if we don't. He wants to stay and work with us, but he has to do that legally. This whole situation is a mess.

The federal government on Tuesday begins accepting H-1B visa applications. The government grants 65,000 visas by a lottery system — mostly to tech companies so they can hire highly skilled workers from outside the U.S. Last year, it received more than double that number in applications — on the first day.

The funny thing is, we're not just looking for cheap labor or to replace all of our programmers. [At least I really hope not, because that would include me.] What we want to do is keep a good worker around. He's someone who positively contributes to the company and, I'm sure, the community. We think he's worth the effort to try to obtain a visa, so our HR people have been working on it.

Interestingly, he is not displacing American workers. Last year he took a four month hiatus from the company due to a lapse in his work visa. We tried to hire during this time, not to replace him, but to augment our team and to help fill the gap during his leave. After hundreds of resumes and dozens of interviews, we found no one who wanted the job and fit our needs. It isn't for lack of trying, we just need our guy.

He's far from the best programmer, and I've done everything in my power to ensure he's not the cheapest. The crux is that he's part of our team. I'd hate to see the team suffer because of stupid immigration laws and greedy, abusive companies. I'd hate to see my coworker suffer, too.

Monday, September 17, 2007

Implement Fair and Equal Holidays

I don't know why I never posted this one. Interestingly, since I wrote this my company has reinstated Comp Time for the few employees that can take advantage of it. It wasn't the easiest task, but I had to do all of the programming to make that happen. I still think that workers would be better served by making a fair holiday schedule, or perhaps unlimited vacation like Netflix does. Originally this post was going to make a point about increasing productivity. I'm not going to make that point, but the concept of fair holidays seems reasonably argued...

The current corporate culture regarding employee holidays, in the U.S., is wrong and largely discriminatory. The prevailing thinking regarding holidays has not caught up with the progressive, inclusive, worker-oriented thinking of the modern office. The good news is that it can be changed. Read on to find out why and how.

What's wrong? I'm fine with the federal holidays.

I think that it can be safely assumed that everyone, shy of management, is a fan of paid holidays. The key word of that statement, though, is everyone. The current system of holidays that most companies employ is to give employees a popular set of federal holidays off as well as a few religious holidays.

Unfortunately, federal holidays don't hold the same value to every citizen, nor do religious holidays. Often one religions holiday schedule is fairly divergent to the next. Some religions have many important holidays that employees would like to spend with their family. Some holidays require the devout to observe a practice that conflicts with their ability to attend work or function in full capacity.

Can't they just take vacation? What about Comp Days?

Vacation is often the solution employees are forced to implement. How is that fair to them, though? That creates an inequality based on religion. Someone of a faith that aligns well with federal holidays and any others that the company chooses effectively gets all of their holidays paid as well as any vacation time. This means that they can vacation as they please and still spend important holidays with their friends and family. Workers who are forced to take paid holidays that do not match their religion must use vacation to compensate, which lessens their effective vacation time and limits their schedule.

Another solution has been to use compensatory, or "comp," time, to allow workers to pick which holidays they adhere to. There are a few problems with this, some new and some old.

To start with the old, we can look at the "closed office" phenomenon. Basically, each of these company holidays also designate a day when the offices of the company are closed, retail aside. This means that on these holidays everyone is expected to be away from the office. There are limited facilities on these days. The secretary won't be in, the HVAC may be off, and the doors may be locked. These things provide a challenge to an employee who wishes to work on these days. This likely leads to that person feeling that this is unwanted behavior, and often it is, which can make them choose not to work those days instead of going against the status quo.

The newer problem is that straight hour for hour compensatory time is, for most workers, illegal. It's difficult to properly implement. There's undue effort required of the company's HR department to track it. Worst of all, it still doesn't allow the required flexibility. At best you can offer this to any employees who fit into the narrow category of straight overtime pay. If you're feeling especially generous you can give this benefit to employees who are salaried, but at that point you're actually going well beyond your responsibilities and you still have the headache of tracking all of this.

For example, last Thursday marked the beginning of the Jewish holiday, Rosh HaShana, and the Muslim holiday, Ramadan. While I must admit to a lack of knowledge regarding Ramadan, I know enough about Rosh HaShana to say that most practicing Jewish people took the 13th and 14th off.

I work with a few of these people. I didn't ask what they did but we can assume that they either worked on Labor Day and Independence Day, the last two company holidays before these, or they took vacation time.