Source of Failure

I just read an article in Software Development Times. It talked about the continual failure of big software projects. This article had some authority as it included quotes from Grady Booch. It called attention to the fact that despite all kinds of new technologies, projects continue to fail at a critical rate.

Failure is defined broadly. The project may be late. It may cost more than anticipated. Or it may not contain everything that was needed. Given this definition, most software projects are probably failures.

What are the causes of such failures? It might be requirements problems. Specifically teams are not validating requirements. There may be programmers who do not follow the designated architecture. Or there might be poor contingency planning. We continue to fail, and don’t learn from our mistakes. There is a lack of best practices being used in the industry.

Here is a pattern for disaster. Keep adding requirements piecemeal. Then try to deliver a system that implements them all. Fail. The overall source of software project failure is human communication errors. Here is how you tell whether your software project has high quality. Check whether the software does the job it was required to do. Furthermore, test whether it does this correctly. If not, you can add you software project to the list of failures.

Microsoft Tech

My customer has paid for some type of Microsoft membership. I think it might be an MSDN subscription. I have been so busy at work that I forget what I got. One of the benefits of this program is that I get a subscription to the print edition of MSDN magazine from Microsoft. My first issue came this week.

I have not been keeping up with Microsoft technologies for a number of years. Instead I am focusing on the business needs of my current customer. So it was tough to get through a lot of articles in the MSDN magazine. There were a boatload of acronyms – WCF, WPF, and WF. All I could say was WTF.

WCF stands for Windows Communication Foundation. This is a piece of the .NET framework. It is used for building SOA applications. WCF defines the communication of web apps. It uses XML as the protocol.

WPF stands for Windows Presentation Foundation. It is the graphics subsystem of Windows apps. This initially was shipped as part of the .NET framework. It is based on DirectX technology. Developers employ the XAML markup language to describe the UI.

WF stands for Windows Workflow Foundation. Like WPF, WF was first released as part of the .NET framework. It helps developers define how long running programs operate and store their state. Another similarity with WPF is that workflows in WF are defined in XAML.

If I want to get back to staying current with Microsoft technologies, it looks like I got a lot to learn. This is difficult as Microsoft is continually coming up with new technologies to learn. It will be like chasing a moving target.

Bitmap Filtering

Today I got a call from my team lead. He needed help. We have functionality in one of our apps to filter out spreadsheet rows based on values in the columns. He added a new column. But he could not get the filter working.

I got a couple files that were changed. However I could not get the software to build. There were additional files missing. I kept iterating between getting the new file changes, compiling, running, and finding I was lacking more files.

Isn't this what source control is for? By the end of the day I got the latest code. This was partly an exercise in assuring that all the file changes got checked in. The filtering was still not working.

I started to make some code changes to try to get it to work. No luck so far. After putting in a couple extra hours, I decided to give up. Normally I am focused on solving problems. But this task seemed boring. Some dude coded some stuff that did not work. It got reassigned to me. If we were not in such a hurry, I would have thrown out the broken code and started from scratch myself.

Bad Design

We are a little behind schedule on our latest software delivery at work. I told the management that we will not make the dates unless we get more help. It took a while for that to sink in. The managers kept coming back asking me how we could make the dates. I kept repeating that we needed more people or it was absolutely impossible. Finally we got another resource.

The extra guy is a proficient one. The team gave him some changes to an application he designed and built years ago. We figured he would be happy to work on his little baby. Today he called me up because he was confused about how to add some spreadsheet filtering. I reminded him that this was his creation. He remembered part of the crazy filter design. However he could not recall how the filter GUI worked.

Now if the designer cannot come in and figure out how the UI works, we have some big problems. He tried to check out the resources for the dialogs. They were missing. I guess he had implemented some kind on non-standard dialog generation on the fly. Well he has to eat his own dog food now. He is stressing due to the time lines. I told him I gave him plenty of time in the schedule to get the work done. Nobody figured that his own design would be tripping him up.

Out of Control

On Friday afternoon I had wrapped up my development tasks for the week. It was looking to be a good weekend. Then I got that dreaded call. Another developer was stuck on a customer problem. The customer said a new report implementation was not working. The customer had said the report did not match the application. Our developer needed help. I had no choice but to assist.

I told the developer it would take around 20 minutes to compare what the application and report were doing. She told me they needed to ship the software in an hour. I dove in, and found some discrepancies. So I called the developer back. She asked me to conference in a lot of people with that call. So I did. Then I explained what I found, and gave some recommendations.

The manager on the call said he thought the new report was not correct. Then he asked if the old and new reports were equivalent. The developer answered yes. He wanted a second opinion. All the other developers took a step back, leaving me holding the bag again. So I quickly printed out pages and pages of the old and new report queries. Wouldn't you know it? I found a subtle but important difference in the SQL.

We held another conference call. By the we were right at the point where we needed to ship the software. I provided my findings and helped everyone understand the implications. Our manager had more questions. I told him he should assign someone to go research the answers to those questions, and I told him it needed to be somebody other than me. He said he needed me to do it. Then I told him no. We later had a private conversation where I reiterated my position. He then got a VIP from our company to call us up. I told him no as well.

I don't mind working on customer problems. In fact, I enjoy them. However I don't like coming in at the last minute and cleaning up other peoples messes. If I keep doing that, I set a bad precedent. This just encourages sloppy work, bypassing processes, and making me stay late due to other people's incompetence. I figured it was time to take a stand. Perhaps some nice article I read about saying no helped me grow the courage to do so. Let us see how this turns out. So far I have not been fired. But it is still early in the weekend.

Order of Importance

I had a week to implement the latest new feature in our system. The coding got done in 4 days leaving one extra day. On that day I performed a number of tasks to make the code complete. It is interesting how I ranked the remaining tasks to be done. I made sure the most important things were done first.

The number one item on my agenda was to ensure the program was functionally correct. That is the main thing the customer cares about. Next I made sure my unit tests were documented. This is to meet CMMi standards.

I then went back to my code to ensure it was modular. This meant breaking up some bigger functions into smaller ones, and combining like functions together. In other words I refactored. Then I beefed up the user interface, making sure I put in controls that did not allow the user to make entry errors.

Next I went back and deleted any obsolete code that was still there but commented out or unused. Finally I did a round trip and updated the design documentation. I did not have time to do any performance tweaks. This task fell off the list due to time constraints. Get the most important things done first. You will not have time to come back later and fix things.

Interview Wrap Up

This time I wrap up the lessons learned by reading Programming Interviews Exposed. Although I have never personally be asked any drawing questions in an interview, I suppose you might get some if you are trying to get a game developer position. I can't go into a lot of details of computer drawing. But it is good to know that high performance drawing relies on using integer math.

I do know you will get asked about SQL in interviews. Most questions revolve around the INSERT or SELECT statements. Know them well. If you are faced with a brainteaser, try to solve a sub problems first. You may get the insight you require.

A general rule is to make sure you can talk deeply about every technology listed on your resume. This is basic. Finally don't paint yourself into a corner when answering to what your favorite programming language is. The chances are that the interviewer does not share your choice, and may count it against you. Provide a general answer to such a question.

Next time I am going to get back to some real life stories and intuition I have gained on the job as a software engineer.