Good Estimates

Producing accurate software development estimates is an art. These days they mostly seem to be wrong. How can we correct this pattern? Start by defining your project scope. Without that you are doomed to fail. Period. When the requirements change, so does the scope. You then need to estimate again.

Once you have the documented requirements, locate all the unknowns. Overestimate these items. Put together a list of deliverables to manage expectations. Remember to cost in security the first time around. There may also need to be time factored in for developer training.

This might be obvious, but you need a lot of time for testing. The current fix I am doing requires double the amount of time testing as it does coding. This should be the norm and not the exception. Get your developers to agree to the estimate, and more importantly the deadlines.

Add some slack in, no matter how well you think your estimate is. The estimation phase is the toughest one. Don't cave in to pressure to reduce the estimate. That will only lead to disaster.

H1-B Visa Pay

People brought into the company under an H1-B visa make less money than US citizens, right? This is another ploy like outsourcing to bring the salary of US citizens down lower. Here is something interesting. Recent research from the University of Maryland shows that the opposite may be true. H1-B visa workers make more money than their US citizen counterparts in the IT industry.

The study took education and experience into account. It found that H1-B visa holders made about 9% more in pay than US citizens. This is the inverse of the situation with green card holders making 13% less than US citizens. The UMD findings contradict other studies and information previously available. Back in the early 2000's, they found H1-B visa holders making $75k average salaries.

Why is this so? One theory is that companies are getting specialized skills from outside the country, and they need to pay to attract the talent. The H1-B visa holders are also temporary workers. Temp workers in general make more than long term employees. More than half of all H1-B visas are for IT work. Maybe their presence is not all that bad for the locals.

More on Jobs

Software development is a field that is easy to get started in. You can download some free tools. And most of them will work on a normal PC. Get busy working on a product. If you don't think you are ready for that, try helping out on an open source project.

You don't even need to start out coding. I would recommend it. However you can do some testing or documentation work first. There are some technical tasks that are not hard core coding. For example, you could develop a web site.

Learn to program to an API. Become proficient at developing mobile applications. These are good skills to have. If you cannot get a first job as a developer, try working for a non-profit organization or a small business. Alternatively you can get a regular job, then look for ways to move into your company's tech side.

Doing some hand-on work can help make your resume stand out. This is crucial for getting that first real development job. I wish somebody had told me about this when I was in school. Luckily I did end up at an internship which gave me a great resume upon graduation from college. These days you need all the help you can get to enter the job market.

Getting a Job

So you want to be a computer programmer. How do you go about doing this? The job market right now is tough. You got to stand out somehow. I just read this blog entry on how one guy successfully got hired.

You need to have a goal of becoming a great programmer. Go to college. However don't have a goal to get good grades. Get good skills instead. Make sure you do go to college. It can be a community college. But don't cop out and go to some institute like Devry. You will end up doing documentation or help desk work.

Here is another surprising misconception. Your major does not matter that much. Choose a technical degree. But it does not have to be computer science or computer engineering. Do join user groups and attend conferences. Get your social media on. When you apply for jobs, have a personalized cover letter. It would also help to customize the resume to address the job requirements as well. Good luck

Software as a Service

Software as a service is a hot topic these days. The main selling point is that you can quickly get high quality products developed. The only problem is that it is hard to find developers with the necessary skill sets to do the work. Such developers need integration skills.

Outsourcing in general is a difficult task. Like many software development efforts, IT often fails in their outsourcing implementation. Know that software as a service is a kind of outsourcing in itself. Security is important in the software as a service world. Normal DoD security audits may not be sufficient to ensure your security is tight. You must test the security of the vendors you choose.

Software as a service depends on the Internet. So by definition there will be downtime. You need to prepare for this in advance. Make sure incoming mail also gets routed to an alternate system. And the outgoing mail backup should always be ready to go. Test your data recovery plans. And it would be best if you were in control of your own DNS entries.

Code Done Right

I have this task to complete. The goal is to correct a lot of data corrupted in production by some bugs. The actual SQL is not too difficult. Understanding the business logic is most tricky. We had a meeting with the customer to confirm the requirements. Based on the first meeting I banged out a script in no time.

Now I made sure I did my script right. The main routine just makes a lot of calls to other functions. Those functions are ones that I wrote myself. They are in the script as well. However the main routine just implements the logic calling other routines. All the routines trap exceptions and deal with them to ensure the script will run on.

Later we found out that there were some additional requirements for the script. Now the tough business logic became even tougher. However the way I set up the script helped make these new changes a breeze. There was a need for a new function or two. But the main script just needed a line or two tweaked. I had set myself up for success. With the time saved I assisted some other developers who were swamped with their full work loads. That's smart.

Dedicated Administrators

For the past 10 years or so, we have had a dedicated system administrator at our computing center. They were responsible for our specific system. It was easy. If we needed something done on the back end, we would contact this person.

I got a disturbing email from the person today. They are now being taken off the job. It is part of a enterprise wide shift in how work gets done. Instead of specific people being responsible for each system, the whole system administration staff if going to be responsible for all the systems.

This means staff unfamiliar with our system will be matrixed in to do the work. While this might work for stable systems with straight forward standard operating procedures, I bet this will not work well with our system. There is a lot that the administrators pick up over the years. And it is hard to train this instinct. I think we are going to have to suffer for a while until they realize that the new plan is not working. Great.

A Work of Beauty

The customer wanted some data in our system fixed. A prior bug fix did not resolve the underlying data corruption caused by the bug. They were demanding this be resolve as our top priority.

I got called in because I know the system well. We had a meeting where the customer told us the requirements. People get nervous when things like this are just rattled off. So a manager recommended we document the requirements as we heard them.

After a while I called up the manager to ask who was going to write up that documentation, and whether it was going to be a team effort. Good thing I called. He said he wanted me to do it. Better to hear about this when I called than as a surprise at the last minute.

Luckily I was fully engaged with the customer when we went through the requirements clarification. I put together the flow of how our data correction script would run. I added all the details so that somebody familiar with the system would know exactly what we were doing. Got a tech guy to peer review the work. Then a manager added section titles. This document was becoming a good looking thing.

Today we had our first set of meetings with the customer. This one was only with our sponsor to get the game plan for discussing the document with the end user. Our sponsor was very pleased with the document. It read easily. And it captured all the details of what we talked about during our requirements gathering. I was very proud of this document.

Happy Camper

It is Friday afternoon, and I am loving life. Sure it is nice that the weekend is upon us. However I am smiling for a different reason. I got assigned to a high priority problem. No. That alone is not cause for joy. However the fix involves some interesting logic. And I get to code the whole thing myself.

I started with an empty text file. Well I actually started with a small template. But it had no functionality in it. Then I started coding away at the requirements. Yes. I actually had documented requirements. I wrote them. Spoke to the customer. Got assigned to document what I heard. Now I can code to spec.

Here I am, writing nice tight routines. They call subroutines. And guess what? I get to code the subroutines as well. There is actually enough time in the schedule to get all the work done. There is time to adequately test the functionality. I think they got a sense of the complexity when I spoke to the customer about their requirements. I kept going through significant scenarios until I understood what they wanted. There are a lot of combinations, and therefore many scenarios. Those will all be turned into unit test cases.

I just like writing code. It is nice if it is new development. It also helps that the customer desperately needs this code to be correct for them to do their jobs. People are counting on me to deliver. I actually have a reasonable schedule to do my work. You bet I am happy. This is such an unusual situation for most software maintenance work. So I am here on a Friday afternoon. I am writing code and not looking at the clock. Why go anywhere else when I am having so much fun?

Conference Call

I saw a new high priority customer trouble ticket come in. It got assigned to a junior developer. Our team lead said he would help out as well. Then the test team shared some of their findings. I was hoping all was going well. Then I got the dreaded invite to the conference call.

Reluctantly I dialed in. The boss asked whether this problem was related to any other fixes we recently deployed. I tried to stay out of this. People were trying to recall what changes went in to fix what problems. They were also trying to determine whether any of those changes were incomplete.

Finally I could not take it any more. I said we really needed to get back on track. Somebody should find out whether what the customer is reporting is actually happening. Then they should find out why and fix it. After all that we can then investigate how such a problem slipped by. Eventually the boss and the team lead agreed. Then all the developers started saying they were unable to work this weekend. That's when I knew our conference call had become broke down again. Luckily I was able to switch to a higher priority task before conference call number 2 started up on this problem.

Maintenance is not really that hard. You talk with users to find out what they are experiencing. Then find out what they are expecting. Determine if their expectations are valid. See if you can make the problem happen. Then code a fix to make the problem go away. If you are mature, go a little further to find out how the problem can be resolved. Anything beyond these simple steps are going to be a waste of time. Seriously.

Middle of the Function

A coworker has been struggling to resolve a bug in our system for about 5 days. Part of the problem is that he keeps getting distracted by other work. However he made a goal of knocking this thing out by the end of the week.

Three were strange things happening. Perusing the code made it look like those things should never happen. So this developer put a bunch of breakpoints in the code. Actually he inserted a bunch of message boxes to slow things down and alert him to what was happening.

He traced the code down into one particular call to a funciton. The function looked simple. It was supposed to retrieve a string from the registry. However it was coming back with the wrong string. So he traced in with the debugger. That's when he saw what was going on. In the middle of the function, somebody put some code to return a constant string. All the other code below it was not getting executed.

You would think that the compiler would warn you about the unreachable code. It probably was. However that was getting lost in the million other warnings that race by in the build. Your eyes can deceive you when you trace code. However the debugger does not lie, not usually at least.

Desktop Environment

I have been working on a high priority problem for the customer. The behavior is strange. The software just does not work on some workstation. It generates an unknown exception. My boss told me to look into the version of Microsoft Office.

We use Office to run the reports. Everybody has Office 2003. I drilled down to the DLL from Office that we use. Everybody has the exact same version. But some people's stuff works, others does not.

After a while the customer got frustrated. Luckily they wanted us to stop researching this problem. They have other teams that manage the configuration of all workstations. Now I am only going to assist the workstation folks to figure out the delta between the workstations.

We got to have a stable workstation. Our documentation lists the required software and versions that we expect be configured on the workstation. It is tough when the customer manages the workstations. That means there is a variable outside of our control. But I guess that is life.

More Build Woes

Our team is about to release a new version of our system to the customer. Another developer is leading that effort. He found the latest version of our code had a lot of bugs. Not sure how it got this way. But the developer went in and fixed them. He then wanted another developer to go in and verify that his changes work.

Here is the problem. Nobody on the development team seems capable of building the whole system. That's a big problem. I know some of the people are newer. But come on people. I was not ready to help because I had been assigned a high priority problem the production users are encountering.

My team lead gave me a call. He said he tried to help verify the code changes. But he too could not build. Criminal. The he was "out of the office sick" today. Figure. He asked me to step in and assist. I told him I would need a reprieve from my current task. When he gave me the go ahead, I jumped on the verification.

This is when I saw what the pain was about. One of our apps refused to build. Our C: drives are out of space. So developers build from the D: drive now. But this one app was not having it. I modified the environment to build from D:. Then I ran into additional problems. I hacked through that. The next two apps were easy to build. The hard part was writing a custom script that would set up the Windows registry for these apps to run. Something is just not right here. I was able to do the verification, but there should not be this much pain. Time to solve this problem.

Architect Skills

In the good old days, the big dog used to get the title of senior developer. Now the king is the architect. What kind of skills to you need to achieve such a job? One would think that you need a lot of experience. And you got to know how to design. However a real key skill to possess is above average communication skills.

The architect needs to express ideas to people other than developers. They need to be able to figure out what decision makers in the project needs. Then they must explain things to these non tech folks. It is almost like the architect needs more business skills.

Now that I think about it some more, perhaps architecture is not the lofty position it is trumped up to being. If you do decide to go that route, try to get in front of people. It is easier to make a connection when you are face to face with your audience. That's what the architects say at least.

Tools to the Rescue

I got assigned to work on this high priority problem for the customer. Could not replicate the problem in development. So I decided to steal some data from the production environment. I used a SQL tool to generate scripts from the data. However when I tried to run the scripts, they bombed out.

Turns out I need to massage the scripts before they will run in a development environment. This was a painful task for just a couple records. To replicate the problem, I need to get a couple hundred records into our development database. That would take forever. Then it hit me. It was time to get productive and have fun at the same time. I was going to roll my own custom tool.

This was some good times. I love writing small useful tools. So I did some rapid application development. At first I thought I would code these up in Java to help with my Java education. But I needed to be quick. So I decided to use C++ programming. The first couple things I needed to do could be knocked out in a couple hours. The rest were a little more tricky. Therefore I have decided to put the changes I need in database triggers.

No Code Review

I have a confession to make. For the code changes I make, I often skip the code review. It looks like I am not alone. And we do not have a formal written process which requires it. When somebody asks to review my important changes, I do not fight it. However I don't volunteer either.

Sure I am down with finding bugs early in the process. However who has the time for a peer review? There is no slot in the schedule for code reviews. But let's say we do make time for reviews. It would be good to schedule time for them.

Here is an idea I just recently heard about. Why not invite quality assurance to the reviews? A lot of time we talk about the deep technical things in the review. Only a software developer might appreciate this. I am not sure how I feel about this idea. Perhaps I should ask a tester.

Duped by Customer

Last week I worked on this high priority customer problem. There was a lot of excitement over it. I was required to dial into a lot of conference calls to discuss the problem. In the end I proposed some fixes. The customer chose one and I implemented it.

After this monster problem, I was ready to call it a week. My team leader and my boss told me another problem came it. I let them know it would have to wait until this week. A developer can only take so many emergencies in one week.

I talked to the customer who submitter the problem. They gave me a bunch of information. Then I went off to the races to try to duplicate the problem. I could not make the problem happen. Then I inspected the problem data. Something was not right. The problem was not as the submitter described. I called some other customers and found that the information I got at the beginning was not accurate. I should have listened to Fox Mulder of the X-Files. Trust no one.

Now I am back to square one. This time I am a bit smarter. I am questioning every fact that somebody gives me. I am also not too worried about fixing this problem ASAP. The customer led me astray.

Frozen Application

Last week a developer on the team released a fix to a big problem in production. The users were anxious to experience the fix. As soon as the fixed was implemented, they got on and tried the application. Something was not right. The customer called my manager. My manager put a bunch of us on the problem.

The first guy to respond said he had no idea what the customer was talking about. The second guy was silent. So I jumped in. That was the beginning of a nightmare. Here is a fine point from the story. The user complained that the application just froze. Ouch.

I got our DBA team on this problem. The user said the app froze. That must mean that there was a performance problem. The DBA could not see anything wrong. There were no locks or anything. We got some conference calls going with the user. I reverted back to asking the users exactly what they were doing, what they were seeing, and what they expected to see.

Then it because obvious. There was no performance problem. The user was expecting some control to be enabled. They were not getting enabled. The customer calls this "frozen". I call it controls not acting correctly. They are disabled. They will never get enabled unless we fix the problem. This is different from a database call being blocked by another transaction. We eventually developed a fix for the customer. But that is a story for a different post.