Quality is Job 1

We got a manager on our project who is relatively new. This is the first release his is responsible for. As usual, we have had a heck of a time documenting good requirements for the release. The manager has stated that next time developers will be required to write the system level requirements.

Now that sounds good to me. Except developers are always busy. As the requirements gathering for the next round is taking place, we are busy designing, coding, and testing the previous release. Oh well. We will make it one way or another.

I was pleasantly surprised to find that Karl Wiegers has a lot of great advice on Writing Quality Requirements. If we get to the point where developers are writing system requirements in the future, I will have all the developers study his advice.

Uninstall

I got a call late one night on the weekend. We were planning a rollout of a few software releases on the weekend. One of the system administration team found problems with our install. The install came up with an error stating Uninstallshield was already running. Nobody else could duplicate the problem, even when they tried to replicate the sys admin’s environment. The good thing was that the sys admin was using a virtual environment. He could restore back to the state where he could replicate the problem at will.

A second attempt at installation makes the problem go away for the sys admin. An uninstall prior to the first install also makes the problem go away. My recommendation was for them to just rollout an uninstall plus install. The sys admin team stated that they were not in a position to do that at this late stage in the game. Then there was a lot of discussion how similar problems happened in previous rollouts.

At this point the discussions went on tangents about whether the prior problems were the same as the current ones. I tried to get everyone to stick to verifiable facts. Theories would only put us in danger of talking a lot and accomplishing little. If sys admin could not do an uninstall first, I just recommended that they go through with the install. The worst that could happen was that some installs would not work.

The sys admin guy who found the problem thought the issue might be with the .NET framework. We do install version 2 of the .NET framework during our install. This was for legacy purposes and was not required by any of the apps installed. If we have time to work this issue, I would first have the install be modified to remove installation of .NET. I would also remove any piece that attempts to first automatically do an uninstall of the previous version during the install.

Company Support

My company is supposed to have a standard. When you get to my level, you get to share an office with another employee. I am talking about a real office with a door. That sounds like a good perk.

There is one problem with this model. They don't seem to have enough offices. At first I got put in an office. Then I got kicked out. I am now in my second office. It started out fine. Then they ran out of room.

What was the company's solution? Well they added extra desks to the offices. You might think that was smart. Nope. The rooms are sized for two desks. They could not fit a third desk in my room. So they took a desk and hoisted one side of it up on my desk. The other side prevents the door from opening. I kid you not.

The unlucky third person does not get a phone. LOL. I am glad I was not the last one in. The third person also does not have any network jacks. Some genius decided they would add hubs to break out the ports. Just today that solution failed as the company initiated some network security. All the connections through the hubs are toast. This is starting to look like a typical body shop.

Modernization

There are a lot of legacy systems out there. They continue to be an asset to businesses. However it is hard for these systems to be modified to meet changing business requirements. Most of the budget for these systems is for maintenance. One option to deal with such high costs and limited flexibility is to modernize the system.

Modernization is a term that could mean replacing the legacy system entirely. A smaller scope effort would be to supplement the old system. Either way, you are going want to use some type of open standards as opposed to the usual proprietary ones in the legacy system.

The key to any modernization project is proper planning. You want to keep the old functionality. Costs can be cut by using COTS products in the rewrite. You are also probably going to be doing a lot of rearchitecture during the modernization process.

Modernization can typically require multiple vendors. These include a system integrator and technical vendor. I have seen a lot of money spent and wasted in such modernization projects. Most of the big ones I have witnessed were failures. The large scope and lack of subject matter knowledge often doom such projects. The legacy developers do not have a vested interest in a replacement system succeeding unless they are the ones coding the new system. I myself have been marginally involved in some big redesigns that were to eliminate the system I maintained. For better or for worse, those projects have all failed and I continue to support an old legacy system for my customer.

Training

I have been rethinking my training options. This is because the class I signed up for this semester got cancelled. In general you need to be smart about your training development plan. It is always good to learn some more technology. There is just a lot to learn.

One method is to just buy some books. The cost is low. And you might spend a lot of time to really learn a subject. However I am thinking more and more that hands on self learning is the best. You cannot replace being able to try things out yourself. Seeing what works and what fails is priceless.

Another technique is to attend a conference. This is similar to attending a short one week course on a topic. This usually costs a good deal of money. The costs get higher if the training is not local. The benefit is that you can learn much quicker. Unfortunately you will also lose the knowledge quicker if you do not put it to use right away.

Finally you can teach others. This can be at a local level such as presenting info to your team. Or you can step up and try to present at a conference. Either way you can learn more yourself by listening to feedback from the audience. The good news about presenting at conferences is that you usually get in for free.

Dev Skills for Jobs

We are still recovering from a very weak economy. Most software engineers got a small salary increase last year. What is a developer to do to stay alive?

The good news is that the software engineering market is not that bad. Software engineers make an average of 91k at their jobs. This compares favorably to the 78k average for all technical positions. The unemployment level for technical people is only 4.5%. Compare that to the 10% unemployment for all professions.

Here is some common advice. Don’t just beef up on your programming skills. Develop communication skills. Be able to pitch your ideas to normal users. If you combine this ability with strong technical skills, you will be very valuable. That means high salaries.

This is not to say that you should ignore the technical side. Try to broaden your skills set. Learn a new language or framework or methodology. You got to work hard to stay ahead of the game in these tough times.

Teaming

I get first hand experience with the difficulty of running a team. Today I run the application dev team. This will only last until the team lead returns from a massively long vacation. However I see how frustrating and difficult it is. You need to track who is working which trouble tickets. Then you need to track their status.

This is an example of a bigger struggle in software development. Another example is the productivity of the waterfall method. You get big releases once every two years using that methodology. Not good.

How do you combat such challenges? Some say use good processes and great tools. The latest process fad seems to be something agile like Scrum. And the latest tool buzzword is ALM, or application life cycle management. I am not sure that I buy the hype.

One such ALM tool is TeamForge by CollabNet. Here is some guidance on how to choose and use such a tool. Make sure things are kept simple. Get input from your dev team leads. That will give you developer credibility. You might get the alleged 4x productivity gains. Personally I would settle for a 2x gain across my dev team.