Signs of Trouble

I came home from work Thursday afternoon. It had been a tough week. So I took a nap. When I woke up later Thursday night, I had voice mail messages from work. They were requests for help with the software being delivered next Monday. I was working on a different task. But people wanted me to come in at the last minute to assist with this other effort. One request came from an executive high up in the company. So of course my answer would be yes.

My charter was to come in and fix some bugs detected by the customer. That sounded reasonable. I am an expert at speedy bug resolution. The first sign of doom was that my team leader said he did not know what bugs I should fix. He said he did not have the time to go through the massive list of defects and assign them to people. So my first task was to identify some reported defects that I could correct.

I spent some time reviewing all the open defects against our system. There were quite a few of them. I then let my team lead know which ones I could work. He agreed and I got down to business. Then there was another developer who “needed help”. I agreed to look at their problems. It was plain and clear. Their SQL was defective. I guess they did not understand what they were trying to query. I got their query fixed soon enough.

Then the next big bomb was dropped. They were trying to code some new functionality. This was being done on the Friday before a Monday delivery. Oh oh. My team lead called me up and asked me what I thought about the design. I told him it was one way to do the task, but it would break a number of other functionality in the application. I pitched a different design. Then I got assigned the task of running forward with the design. Oh oh again.

Of course there is a lot more drama associated with this diversion on this troubled task. I will save that for a future post. One thing to look forward to are developers too tired to build their software. Another is the never ending “we need another hour to make some more changes”. Stay tuned.

Rise of the Duct Tape Programmer

I have been hearing a lot of noise in the blogosphere about opinions on The Duct Tape Programmer. This is a phrase coined by Joel Spolsky, of Joel on Software fame. He writes about his respect of such a programmer. Let's first define what such a programmer is.

These programmers roll up their sleeves and just do it. They do not get weird bugs in their code. Their work is completed quickly. These programmers skip unit tests. They also avoid "complex" techniques such as templates, multiple inheritance, multi-threading, COM, CORBA, and C++.

This list really isn't a list of difficult tech. Those are just areas where an Astronaut Architect might get tripped up and not be able to deliver working software quickly. There has been a backlash against the love of such a programmer. Many have come to the defense of unit tests. And developers should be willing to learn new technologies.

I think that a duct tape programmer can use C++. They just might not need to use templates for implementing every solution. I also agree that multiple inheritance is not needed. However there comes a time when you need to start a background thread to do some work and not hang up the user interface. It is all about moderation. More thought is needed on this topic as it often depends on the situation.

Killer Bugs

For a while now I have been taken on my main task at work to help with other emergencies. Just yesterday I wrapped up the last piece of extra work. Today I was happy. I finally got back to writing new code for my main project.

The piece I was adding was pretty simple. It was a dialog with choices initialized from a database table. I was integrating this with an old application. So I followed the pattern I found there. There is a C API to get to the database. Behind the API is Oracle Pro*C code that retrieves a big chunk of memory with the database data.

Here is the funny thing. I kept getting an empty dialog. No problem. I decided to step through the code. Something was wrong with my initial count of the records. I fixed a variable initialization and got the correct count. Still no data in the dialog. Stepping through again showed that my cursor was retrieving all the data correctly. Ooops. I was not passing back the structure properly. Doh. I got to keep up with my C programming, especially when dealing with multiple levels of indirection in pointers.

Requirements and Analysis

The customer on our project has their own software acceptance team. Recently they have been finding a lot of problems with our applications. A few recent problems got a lot of visibility. Some VIP from our company said we needed to fix these problems. My team lead called me up and asked if I had any extra time in my schedule. I just laughed.

In the end, my manager informed me I had to drop what I was doing and fix the problems. The first one was easy. I disregarded some of the information that had been collected so far on the problem. I honed into the specific facts that pointed to a certain module not working. There were some protests until I demonstrated that previous information about the problem was incorrect. Next I went to another problem. This second one had a lot of parts to it. The first two parts were easy. They were coding errors. I fixed them with little trouble. The last part was difficult.

Requirements were gathered on some changes to the system. A technical customer helped specify the requirements. Unfortunately he started getting into the design of the solution, and those specifics were documented as part of the design. We subsequently ignored this external design when we actually designed the system. The came back to bite us. The customer's test team validated our implementation based on the letter of the documented requirements (as they should be doing). The problem was that the system did not match those requirements. I thought this was no problem. We could just change the requirements to match the implemented design. This proved a lot harder than it sounds. More on that later.

How Does Google Do It?

Legend has it that Google employees get 20% of their time to work on personal projects. This is 20% of your 40 hours week. Awesome. I always figured that Google engineers would be writing games, working on cool utilities, or doing computer science research.

Old Cringely shed some light on what Google people do with that 20%. You have to first understand the culture at Google. They peer review everything. And the result is very clean high quality code. Developers don't go to meetings. They let the managers do that.

Of course peer review has a cost. Many companies skip this step because of the time it takes to perform. Well get this. Google developers do the peer review during their 20% personal project time. Go figure. It does not take away from their normal duties. But it does steal from their creative development time. In the end it is for a good cause. They are working to improve the quality of their code.

Resume Writing

A buddy of mine may be looking for work pretty soon. Things move fast in the world of government contracting. So what's a fellow to do? Well I have read some advice from people who are doing the hiring. There are changes you can make to your resume to make sure it does not immediately get discarded.

Make sure you list the things in your experience section that you actually did. Nobody cares what your team or company did. What did you do specifically. This also applies to the technology section. Don't listen random tech buzzwords. List specific versions of technologies, and tie in how exactly you used them.

Have an introduction at the top. Also try to quantify your experience with numbers. How many years did you use the technology? How much money did you make your company. Here is another hint. Match you skill set to the ones they need to the current opening.

Now I have heard somebody recommend some sample code. I have done some hiring. Sample code did not impress me. If you wrong something really great, maybe that might be a factor. I am Oracle certified. You should list certifications like this. It counts more if you were certified by the vendor instead of some arbitrary training company.

Finally don't say you are an expert unless you truly are. Good luck job hunters.

Finding Good Jobs

I read an interesting discussion on a message board today. The topic was how to find a good programming job. A number of people said that you need to create your own company to ensure that. This seems a bit extreme. There must be some good employers out there in the software development world.

There were also some cynics in on the discussion. They came out and said that good programming jobs just do not exist. But these people were in the minority. You want to figure out how good a company is before you start working there. After you are committed, it is too late. You could try to get a feel for the corporate culture during your interview. This might be tough as they don't want to scare you away.

Employees are the best way to find out what working at the company is really like. You can try to get in touch with actual company employees via social networking sites like Facebook. This angle really boils down to doing your networking. You can even talk with people you have worked with in the past and trust. They will give you the low down on a company.

Sometimes you just need to be willing to relocate to get the best job possible. That does not sound fun to me. I am too connected to the local area. Finally here is an interesting perspective. The lower paying jobs are usually the better ones. I can somewhat vouch for this. When I made low pay, I hardly ever put in any overtime. And when I did, I was actually paid extra. Unfortunately I don't want to go back to low pay. This might not be an option.

Employee Retention

How do you keep your top employees happy so they don't jump ship? It is not my job to answer this question for my company. But I still want the good guys to stick around on my project.

Consulting magazine has some ideas. Give your workers a better work/life balance. Yes I know that is easier said than done. But you will benefit in the long run. I read that the average big dog in a company works over 55 hours a week. That's just the average. Not too fun. I thought my weeks were bad at 48 to 50 hours worked average.

Workers on the front lines do not feel appreciated. You combine that with overwork, and you have disgruntled employees. They will go elsewhere if they can find jobs. A new trend is that workers in the trenches feel that their companies are cutting back on training. Luckily my company does not seem to be following that trend. I honestly worry that I spend too much of my company's training budget. If I leave, the policy is that I have to pay back any recent training. I guess they got me now.

Overwork and Outsourcing

I read a couple blog posts about overwork and also outsourcing. Then I put the two ideas together because they are related. This is very relevant stuff.

We somehow got committed to too much work on our project. They are trying to get us some more resources. That is, we want to hire more programmers. But that task has a very long lead time. We have deadlines now.

Management continues to have the same short term answer for our problems. Work late on weekdays, and work weekends. Of course this is leading to burn out of the whole development team. This is part of a general trend of customers wanted more for less money.

Is a possible answer to our problems a little bit of outsourcing? I am not talking about moving the whole project overseas. But how about we augment our existing staff. We could only outsource to experts in the domain or technology. They would not come cheaply. But it would mean I get to go home at quitting time. Sounds good to me.

The Winner is C

A company that make open source tools did a survey of open source code. The result was amazing. The majority of code in open source projects is written in C. This was very strange indeed.

You need to look into what this company was measuring. They counted lines of code. Now that makes more sense. If you are just counting the number of open source projects themselves, then Java and Perl come out on top.

This does give me some more faith in the good old C programming language. With all the new hot technologies and programming languages, you would have thought C would be falling behind.