So I’m supposed to be maintaining an application- only problem is that the source and executable don't match- the source we do have (created over a year ago by a previous developer) doesn't work properly. Even worse than all this is that the documentation is sketchy and there are no regression tests to determine what functionality may have changed between the source code we have and the executable. The developers apparently used version control, but the source I'm using has a lable telling me it's the version in production- it isn't though. Cool hunh?

I already tried decompiling the two executables (the one in production and the one I can generate with the source I have) but there are simply too many differences for me to catch them all in assembler and translate that back into code. I guess the plan is to spend a couple months doing full regression testing (creating the scripts as we go) to figure out how the application is broken. I just hope I’m not the one who’s tapped to do this testing. Any suggestions?

Your project has just become a leg-work and research project.

You cannot continue without the most recent source code. It is critical you track that down. Somewhere in the company, someone has to have it on a hard disk or backup tape.

Even if it involves contacting people who don't work for the company any more.

Well all this just became moot. My manager has said to stop trying to find the code. She's going to go and admit to the business unit that we lost the code and suggest either we rewrite the app (which has been slated to happen for a while anyway- in fact, it's why I was hired) or do full regression testing with the users. If they choose the latter it'll be very interesting because this app is so buggy it never made it out of QA in the first place.

I've been pushing for testing anyway because I hate making changes to apps without being able to ensure that the functionality hasn't changed, so I'm relatively pleased. I feel bad for my manger- even though I don't care for her very much, she wasn't around when this source was written (and lost apparently) but she'll get her head handed to her when she talks to the business unit.

Out of curiosity, does the application show other signs of being sloppily written? (E.g., bad comments, no bug tracking, no unit tests, no design documents, etc.) I suspect that it's a given that poor process leads to poor results.

Ugh. Your job sounds like my previous job, which very nearly put me off computers entirely.

Okay, I'm not a programming imbecile (though I'm no expert), but are these people really using a loop with a conditional inside the loop to do things in sequence instead of just, well, doing them in sequence?

Thank god for DeVry graduates.

I am continually amazed at some projects I've been working with over the past few years. I meet some other company who is doing some programming work and think "damn, they must be really good, my code is going to look really amateur when they see it". And then I see while they may talk the talk, what comes out is not that good.

An example is a project where 99% of the code was to be written in India. Now they may be cheap, but the coding must take four times longer, and the project manager admitted he had wished he had paid up for UK developers because they are really slow. Also the entire project was supposed to be localised in a second phase (already priced up), but much of the coding wasn't written with this in mind, eg. pieces of text called "Label12" which will make no sense in the resource files. Also the project managers are given bonuses according to the project's profit, so they have an incentive to have the spec altered so it can be charged for, and an incentive to have defects accepted when they should be fixed.

A much more recent example is a project I am working on right now. I am doing a new website for a long-term customer in another area. They have just bought an expensive membership management system from a large general purpose software company. The software has a web-module which allows users to alter their addresses, pay their subs etc. Anyway, I was looking through the cookies that it drops when you log in, and yes, it seems that the UserID is set as a cookie and is the only thing used to subsequently authenticate the user..... now this will be a delight to report, because during the planning stages I was advising against certain things because I believe them to be an excessive amount of work and not in the client's interests - it was then suggested that it was because we weren't able to do it, I will certainly get great delight in reporting this flaw! (obviously I will do it carefully, I know this sort of thing can backfire easily)

Gareth

Well, the plot thickens. Apparently my manager and I miscommunicated, because she is not meeting with the business partner. Rather she and I are going to meet with the company’s CIO and CTO to determine a course of action. Wheeee!

So I looked into version control some more and this is what I found:

The binary that was released into production was first checked in BEFORE the source code was labeled. Other changes were checked in AFTER the binary was initially checked in, changes that are not in the release. The question is whether we can assume that everything in version control as of the point the binary was checked in is correct. Sounds like a dangerous assumption to me.

I thought version control was a relatively simple concept. Apparently I was wrong.