Business Case

I recently had the need to hand out some business cards. However I have not received any from my company. You apparently have to order them. I thought this would not be a problem. I went to the online order form. After filling out most of the required information, I chose a custom title of “Rock Star Programmer”.

A message was generated that stated my order was cancelled. The reason was that you can only use your official company title on business cards. Otherwise you have to submit a business case to the anonymous Program Administrator. At first I was taken aback. Why do I have to go through the motions of justifying a minimal purchase such as business cards?

I decided to go online myself and pay for my own business cards. There are some sites which will print them for you for free. You just have to pay the postage which amounts to 6 bucks. I did so, and added some extra customization, bringing the total to ten dollars. This is a crock. I made sure the business cards I paid for did not have my company name on them. Hey. If I am paying for the darn things, they are going to only have my name.

In the end, I went back and composed a business case for the company to approve a custom title on my business cards. I figured I would give the company one last chance. Besides, I determined I would expense the company anyway for the ten bucks for my own cards if they would not approve my business case. The anonymous Program Administrator eventually gave me an approval for the custom title of Rock Star Programmer.

That was a good decision. I would hate for my opening line when handing out my cool new business cards to be, “I work for a big company. They would not let me choose my own title. So I had to buy my own cards.” The company has already made the decision to hire me. They should not scrutinize me for a $10 business card order. I am going to make the best decision for the business. If not, you should not have hired me in the first place. We are not in kindergarten any more.

Training Days

My company provides mandatory training for all new employees. As soon as I joined the company, I got busy on my project. I was able to delay the mandatory training. However last week it caught up with me. Human Resources informed me that I must attend this training. So I reported to the training facility. It is only 40 miles away from my house. However due to city traffic gridlock, I had to leave very early for there to be any chance of arriving on time.

The company provides breakfast and lunch. This is to make sure you eat and get back to training quickly. The food is ok. We learned about the history of the firm. I got a nice coffee table book describing the company over the years. The training was geared around how we market ourselves as a company to clients.

There were some funny harassment videos. I saw my vice president being interviewed in another video clip. It seemed that the table I sat at lost all the competitions with other new employees. So I walked out of the 2 day training class without any SWAG. There were a lot of retired military new hires in my firm. I also met some new people that work in the same building that I do.

I ran into an interesting fellow developer at the training session. He was in another class, but I spoke with him during one of our networking sessions. He is currently doing Linux and C development. However he was positioning himself to get into Microsoft Sharepoint development. This guy seemed to have a very broad background. This is in sharp contrast with my own specialization in one or two technical areas and one particular client. I did notice that this guy was a level below me in the organization.

Even though I have been with the company for almost half a year, I never got any business cards. This was a real disadvantage at the training. An important component of our company is making contacts through networking. I felt a little funny having to jot down my contact info on blank pieces of paper to hand out. I was impressed that most of the new hires seemed like top notch people. Perhaps this is because we are a management consulting company. And that draws a certain kind of individual to the firm.

Getting Trained

My company has a mandatory training class for new hires. However the training is done on the other side of the city. The heavy traffic in my city means the commute to training is painful. So I tried to put off the training. Last week I got a message from Human Resources stating that I must attend the training.

I get up in the wee hours of the morning. And I drive out to the training facility. I get there so early it is still dark outside. I keep driving around but can't find the place. Eventually the sun rises and I locate the facility.

We learned about our company and its values in training. It is tough to stay away. I am not a morning person. And I have been up since who knows when. There were some fun games where they gave you a clicker, and you had to answer multiple choice questions competing against other employees. But this was not fun enough to outweigh the equally painful drive back home. Note to self - get out of the rest of this training. I know I have better things to do with my time.

Dialog Box Woes

Development got a requirement to display some data in the application. In addition, the user required the ability for some users to change that data. This is simple stuff. I figured this would be perfect for a Windows dialog box to handle. The only point of interest would be how the data gets saved. I figured that the system could enable a Save button when the user change the data. Then they could press this button to actually store the changed value. I figured this was a simple enough design.

A developer took this design and ran with it. However he figured we needed a little more details in the design. So he wrote down the flow for the scenario where the user changes the value, but then tries to close the dialog box without saving. At that point there were a few options that this developer wanted to handle: (1) user wants to save the data and continue closing the dialog, (2) user wants to close the dialog box without saving, and (3) user does not want to close the dialog box. To tell the truth, this confused one of the acceptance testers in the customer organization. So I explained how these scenarios would work.

The big day came when we were supposed to walk through the design with the customer. Hardly anybody from my team showed up on time. So my boss told me to take it away. I went through the design. It was easy because I did most of the design for all the requested changes. When I got to the part where the tester did not understand, I thought I would explain once again the different scenarios on closing. This erupted into a lengthy discussion on all of the paths through the logic. It felt like we had missed the point. The user wanted to view and save changes to some data. We got derailed and were discussing all kind of user interface design.

In retrospect, I think we should have stuck to a simpler method for dealing with this dialog box. If the user makes a change, we should save that change on exit. That’s the original intent of dialog boxes. I think developers have made things more complicated than they should be. This is, in essence, a user interface design issue. The best designs are simple and easy to understand. Following simple designs will keep us focused on the business of the applications.

Upgrade Broke the Build

This year my team upgraded a number of software development tools we use. This included some third party libraries such as Objective Toolkit from Rogue Wave. We specifically use the Object Grid from that toolkit. We initially received a trial version of this toolkit while our customer worked on the lengthy process of software procurement. Our team worked to get this trial version to work with our code. There were a bunch of changes since it had been a long time since we last made a toolkit upgrade. However we persevered in the end.

Then we finally received the real software from Rogue Wave. However there was a slight problem. The trial version we initially received was version 11. The purchased version was version 12. Our team lead thought this would be no problem. He assigned the task of upgraded to the latest version to a junior developer. That is where the real problems started happening.

The junior developer never seemed to clearly understand what we needed to do. In essence, we needed to build the DLLs using the latest code. Then we needed to use the newest version of the include files in our code. Finally our build process needed to deploy the new version of the DLLs. That sounds simple on paper. However like most things in this world, nothing is ever simple to the newbies.

Our junior developer needed a lot of help to get the new libraries built. Then this developer just checked a lot of things into source code control. Some of the files checked in were the new libraries we needed. However other files checked in were files that get built during compilation time. It also did not help that the developer did not update our projects to use the new libraries. I get the feeling that this developer needs a lot of mentoring. Unfortunately, the majority of the development team works out of a different location than this developer. What’s a team like ours to do?

Got It Wrong

Previously our requirements analysis team interviewed the customers to figure out the changes they wanted implemented next year. They wrote down the customer’s business requirements. Then they developed system level requirements. I read one of these system requirements and could not figure out what they wanted. It was just vague. So I asked the requirements team what this was all about. They could only repeat the requirements verbatim. It seems they did not know what we were supposed to do. That did not help. So I scheduled a meeting with the customer. I asked them what we were doing for this requirement. I got an answer that I could understand. With that I ran and designed a solution. Then a developer took this design and implemented it.

Today we finally got around to formally presenting our design to the customer. I reviewed the design for the requirement that I previously found vague. Immediately the customer piped up that this was not what they needed. They said that they initially sat down and explained their needs clear to our team. I confessed that I was not at that initial meeting. However I reminded customer that I received clarifications at a further meeting. The customer was adamant that the initial meeting explained all the things they needed. And this was not what we had implemented. Oh no. We are in trouble here.

So far we have tabled the discussions for another time. We need to get back with the customer to find out exactly what they need here. I am not sure if the customer is changing their mind a lot for this topic. Or perhaps they are getting tired of talking to different people at different times from our project. We need to get this right. I am going to propose that we write down exactly what the customer says they want. Then we need to verify that this is what they meant. Normally we delegate this customer interaction to the requirements team. However I am wondering if that is going to be a good idea this time around. We might need to send in somebody who is more familiar with the system.

Requirements Debacle

We have a separate requirements analysis team on our project. Their mission is to interface with customers. They capture business requirements from them. They also perform analysis, and create system requirements. Developers such as myself are supposed to design and implement code changes based on the system requirements. You can imagine that I am a very interested party in understanding the system requirements then. You could say I depend on them.

I was reading a new requirement for next year. It was a bit vague. I say a couple ways it could go. So I picked up the phone and called the author of the system requirement. I got clarification, and I ran with it. I documented the details in my design document. And it has since been implemented by another developer.

The requirements team asked for some help from development. A new customer was going to be using our system. So they wanted to talk with somebody who really understands the current system. That somebody was me. I went down to the customer site with one requirements analyst. The customer wanted to know how our system would look next year based on the new business requirements they provided to our requirements analysis team. I detailed the changes. The one change I had previously inquired about caused some commotion. Apparently it was not implemented the way the client wanted it to be. I told the requirements analysis person what the client said, and asked that they deal with this further change.

I was a bit taken aback when I saw the requirements analyst contact our internal test team. Requirements directed the test team to fail our software because we hard coded the implementation, and made some wrong assumptions. I called up this analyst and said we needed to stop this train. I explained how I received clarification for their vague system requirement. Apparently their team had forgotten about that. Now they say that they had other ideas on what the requirement should be. I said that was fine. However I would not make any changes based on some back door method like the test team directing how the requirement should be implemented. I was very firm on this.

The next day I was in touch with the management that the requirements team reports to. I carefully explained what had happened. And I said their team needed to contact the customer to find out what they want. We needed to stop the nonsense that was going on. It turns out that the manager I talked to handled the situation personally. I was required to provide additional information. However the way I implemented the code was going to be the way it is required. Sometimes you need to stand up and call some weak actions for what they are – BS.

Adobe Complaints

I came across a web site that listed the top 100 complaints users had against Adobe Corporation. It was quite comical. However there was good information in there. A lot of the issues impacted me in the past when I used Adobe software. I thought I would go over some of these, in an effect to make sure we do not make the same mistakes with the software on our project.

One frequent complaint was the time it takes for Adobe applications to launch. Users want to quickly view a PDF file. They don’t want some updater to run first. There seems to be a bunch of unnecessary helper applications being launched in the background. They take up a lot of memory. Many people are begging for a lightweight PDF reader that is not bundled with other software.

Another common complaint is the application updates. It seems Adobe tries to get you to update their application all the time. When you choose this option, the updater takes over the whole CPU. People complain that the installer is totally bloated. And it automatically associates PDF files with their software without asking the user. The install requires the user to closer their web browser, which the users hate. It also requires a reboot which is unfortunate.

A final theme in the complaints is that the price for the software is just too high. For example, Photoshop might run around $1000. People overseas have loudly complained that Adobe does not use the correct exchange rate with foreign currency. So they get the foreign tax on their purchase.

There were a many more individual complaints. All the applications produced by Adobe do not work the same. Some require an Internet connection to run for some reason. And some hold on to memory even when the application exits. Patches to bugs are only offered in new versions. And the updater automatically steals the focus from other applications.

Many people have requested that Adobe stop adding new features, and start addressing some of the critical problems. I thought I would go over these items with respect to my own team’s project. However a lot of the complaints are loud and clear. Don’t make the same mistakes that Adobe has made. You will only end up with irate users, myself included.

Security Install

I work on my project out of my company’s building. This is nice because it is convenient to my home. My work requires me to access the client’s networks all day long. Therefore I always VPN into the client’s network. Recently the client informed me that they were upgrading their VPN software. This could not be done while I was on a VPN. So I had to go visit the client’s site to have a physical access to their network during the upgrade.

The install program was written by the sys admin staff of the client organization. These guys seem to know their stuff. I was a little apprehensive when their install program asked for my password. It needed it because the install requires a number of reboots of my machine. The install program wants to be able to control the reboot and re-login. Another thing that disturbed me was that the install was able to reboot and bypass the laptop disk encryption. I thought that was not possible.

The install took a long time. It required 4 reboots on my machine. Many of these reboots seemed to be related to uninstalling the old VPN software client from my machine. I did get an error message stating that an MSI file could not be accessed. My boss warned me that such a message would come up. I was advised to just ignore it. The install program tested itself. This required an additional reboot. It seemed strange because the test showed a dialog on the screen that seemed to count something.

Overall the install was quite impressive. The program locked out keyboard and mouse input so I could not mess up the install. It also did not require any human interaction at all. The install worked the first time around. I have not gone home yet to verify that I can still VPN into the client’s network. However I have a good feeling about it.

C Programming Commandments

I read a nice blog entry by Henry Spencer entitled “Commandments For C Programmers”. Some of them did not seem to be as important as others. However I took note because even though I am a C++ programmer, my style is more of a C programmer using a C++ compiler. I thought I would review some of the finer points of the commandments.

Henry recommends all C programmers run lint. Well that sounds like great theory. However I think I have maybe ran lint once or twice in my life. Maybe that is why we get array out of bounds errors now and then. And we also have some dark memory leaks in our code. Lint just sounds like a UNIX or command line type of thing. If I had a Windows GUI version, I bet I would make use of the tool more.

Another commandment is to check for NULL. Now this is one that I heed pretty closely. It is no fun when you try to de-reference a NULL pointer. Most code I write checks for NULL. In fact, I like to validate input parameters first in each function. And that means checking if any input pointers are NULL first.

A tough commandment to follow is to check return error codes. Yes I know this is crucial. However I normally code the case when functions do not return error codes first. Then if I have time, I got back and code in the paths for errors. You know how it goes. There is often not enough time to come back and do things like this.

Here is a commandment I have not heard about before. Thou shalt make external identifiers unique. Or you should at least make the first characters of long identifiers unique. Normally I figure that if the linker can resolve the externals, you are good to go. But that might get wack when you are writing a lot of code. I imagine you could get confused if there were different externals with the same name. Point is taken.

Obviously there were 10 original commandments. I have only reviewed a couple here. But I think it would be best to start small. If I tried to implement all 10 at once, I would give up too soon. Obey the commandments.

Coupon Savings

Late one night this week, my manager told me to go meet with the customer. They wanted to review some of their long range goals for new features in our application suite. Normally the requirements analysis team performs this function. However our requirements people are new and do not know the existing system.

So I take the train down to our customer's site. I have never been to this location. I wander around the city a bit. After asking for some direction, I arrive at the building. I show them my badge, which was issued by the customer's organization. That badge is good enough for the guards to not give me the shake down. However I still cannot get through any doors in the meeting.

I was pleased to meet the customers. They all seemed very knowledgeable about their business. And they had a lot of ideas about how they wanted some new programming done. I tried to keep them focused on their business requirements. So I assured them, that given a clear set of business requirements, we could design anything they want given enough time. In the contracting business, time equals money. Unfortunately, this customer said they did not have a lot of money right now. But they would work on getting whatever was needed to make the changes happen.

Here was the funny part about the meeting. Once I started giving them some rough estimates on how much some of these rewrites of the existing system would cost, they started looking for ways to save. They thought that if there were some parts of the system that were similar to their needs, they could get a discount. The top customer there said this was just like shopping with coupons. That comment was good for quite a few laughs.

Shared Components

We have a suite of applications on my project at work. There are a number of components which are shared among the different applications in the suite. Some components are shared via a DLL. Others are wrapped in COM components. And a few are exposed through an OCX. This is standard fare for legacy Visual C++ development. The tricky part comes during installation of any one of the given applications. How should you do a build which installs a common component? We have chosen a way that seems to trip up developers.

A quick a dirty method for sharing components which do not change often is to just check in the binary release version of the component. That way, when an application that depends on that shared component needs to be installed, you just register the binary copy you have in source control. This makes the default case of a build easy. However there is some extra work when you fix bugs or add features to the shared component. You have to manually update the binary copy you stored for build purposes.

Another technique we use for code that we think will change often is to include the code in the project of the application that needs the shared code. Then the build can get the latest copy of the code every time. This does add some complexity to the project. And it adds some time when you are trying to do a full build. However you don’t need to know any tricks.

Here is the dilemma. When we perform maintenance year after year on our product suite, it seems the sharing of common components seems to break down during build time. Some developers say we just need to redo the build scripts. However I think this is a sort of design issue. Or maybe it is more of a configuration issue. How do you best store common components in your system for easy maintenance and install?

Taken Care Of

My company bought me a daytime planner. I did not have to ask for it. It showed up along with a big box of supplies one day. The thing probably only cost the company 20 or 30 bucks. But it is the thought that counts here. The planner itself is pretty nice. So I put it to good use. Now the company has got some good will for a very cheap price.

I find this behavior unlike most of the other companies I have worked for in the past. There was maybe only one other small company that went the extra mile to take care of its employees. This is more impressive in my company since it has around 20k employees. As far as I know, they treat all employees just as well as me.

This makes sense for my company, more so since it is a services company. The thing that is valuable to this company is its people. Now I have worked for other services companies that were stingy with their employees (including myself). I always had to fight for every little thing there. That meant I could not spend all my energy solving problems for the company’s clients. It also meant that when things were suspicious, the company did not get the benefit of the doubt. Not so with my own company.

Now all of this does not mean that my company is the best in the world. But it is pretty damn good. They have made some capital investments in me. That is what goes through my head every time things get tough. And in the work world things are always going to be tough. The benefits do not comprise of just supplies. I got a brand new laptop on day one from the company. They also provide me with a budget and time off from work for training.

Here is the real funny thing about all of this. The other day I went to the printer and saw an invoice for another laptop they bought for a new hire. It seems my company buys in bulk so they get a really good deal. Here I thought my laptop cost a couple grand. Not so. This does not lower my appreciation for the company. It just confirms the fact that the company is not spending a lot of its employees, but is gaining a fortune.

Free Python Book

Previously I had written about Defect Injection. That post described a tool called Jester written by Al Sweigart. Recently I stumbled upon a free book written by Al entitled “Invest Your Own Computer Games with Python”. He provides a free PDF download of this book on his web site. He also has a free online version. This seemed like quite a contribution to the programming community.

The book had a number of interesting chapters such as Hello World, Tic Tac Toe, Caesar Cipher, and AI Simulation. Right now I am not a Python developer. But I have heard the buzz about the language. Sometime in the future I may be interested in picking it up. I thought maybe I would sign up for a community college class on it to get me to learn it. However it sounds fun to go through Al’s book since the application is computer games. You can’t beat the price.

From his bio, Al lives in San Francisco. He seems to have many assorted interests. Some of them include volunteering and making useful software. That seems to match what I’ve seen. He has a blog which he “tries to keep terse”.

I too have written some software on the side of my day job. And I distribute it free of charge. Maybe I need to write a useful book as well. But who has the time? I spend a good deal of time publishing some blogs of different subjects. Now if I did have the time, I wonder what the topic of my book would be? Perhaps Software Maintenance.

Junior Developer Help

Our application suite uses a third party grid to display all our spreadsheet. Recently we decided to upgrade to the latest version of this product. So our team lead got us an evaluation copy of the product. I installed it on my computer, used the third party’s make file, and built the libraries we need for our project. It took a while to modify our code to use the conventions from the latest version. But we got everything working and sent our application suite to internal testing.

It took forever for our customer to procure the real version of the grid we use. Now our team had an action item to make sure our software works with the official copy of the software the client bought. I think the real copy is the same version of the product. However we needed to use the code from the real version to be sure. So a junior developer on our team got assigned this task. There was just one problem. She had no idea on what to do.

My team lead told her to get help from me. So I explained how our application uses the header, library, and DLL files from the third party tool. I gave her some pointers on what to look for in the product documentation on how to build the libraries. I suggested the newbie first ensure she could be our existing application. Even that task proved to be too much. I felt sorry for this girl. She started off as a tester. Then she got into a little back end database programming. But she is not a C++ developer. Thus there is a lot of pain for her with this task.

I can recall back when I started working straight out of school. Even though I knew enough to obtain a college degree, I really did not know anything about software development. I had to have people hold my hand until I learned how to walk. So I figure I should give back and do the same. The problem here is that I have a lot of tasks on my plate. And the work the junior developer needs to get done also needs to be completed soon. What is a good way to strike a balance here? It might be time to talk with the management here.

This is one of the reasons why I insist we always hire seasoned developers for our project that have specific experience in the technologies we use. It is hard enough to learn the complicated business rules of our customer. If you also need to learn the technology, you are not going to be able to pull your weight on the team. Sorry young bucks. We are not going to be able to train you this time around.

Keep Quiet About Problems

I have noticed a disturbing pattern on the project that I work on. It seems that if you bring up an issue, you get assigned the task to resolve it. This is problematic. There are a number of things wrong in the project. You reward for bringing them to light is extra work. This might be fine if you were sitting around twiddling your thumbs. But most people are very busy on our project. So the tendency is to just keep quiet about problems. That way you will not get tasked with extra chores at work.

Yes I know that when you come forward with a problem, you should also have thought about a solution to pitch to management. However that does not mean that you need to go implement that solution too. That is crazy. I am not sure why this is the case. We might be suffering from poor team leadership or resource allocation. Whatever the cause, something should be done about it. However it is a vicious cycle. I would bring this up. But I worry that I will be tasked with investigating and implementing a solution to the problem. I am already behind on my major tasks. And I do not want to be part of any action that requires me to start working weekends.

The only time I step up and volunteer that we have problems is if I know the work will come my way anyway. And I also speak up when I see that the problem is going to directly impact my ability to do my job. Other than that, I just keep quiet. Now that I think about it, the people who have kept quiet all along are the ones who are not heavily tasked. It must be nice. I like earning a good day’s pay. I also do not mind working hard. However I have been burned in the past where I used up a lot of my life at work because everything was falling apart. So I guess I am quite paranoid about project mismanagement.

These types of issues at work remind me of a time when a huge project was promised in a short amount of time. The result was a death march. I tried to make some sense about the outrageous demands on my time. At first I would try to get management to identify some concrete milestones that I needed to get done by a certain date. The only response I got was that I needed to work long and hard. If I got lucky or finished a task, I had to stick around because they had a whole bunch of other tasks they could assign me ad infinitum. Now I am sensing a déjà vu with the number of problems that are surfacing, along with the way that problem resolution is dealt with.