Trial By Fire

Scouse

Hello WTFers - I have lurked around here for quite a while but only actually registered recently :)

Anyway, I recently joined a company which both manufactures hardware and develops software based around the hardware. It's only a small company, and everyone is friendly and helpful. It's a good job, and I'm enjoying it. The problem with being a developer in a small company, however, is that when outsourcing needs to be done, the biggest factor when deciding who to outsource to is cost. Apparantly, the project I'm responsible for at the moment was originally (partially) outsourced to the lowest bidder. Needless to say this company made a complete mess of it and now I have to fix it (there were several components outsourced, so me and an external contractor are working together to get everything up to at least a 'demo' standard) amidst the looming threat of legal action from our customers who keep changing their 'requirements' and harrassing us for a demonstration (My own quick-thinking skills managed to appease them for a while by making a few mock-ups, like Frederico's pal Steve!). The general gist of our two-man team is this: the contractor works on the application - the interface, the networking etc, while I work on the libraries the application will use to produce the output the user wants to create.

Unfortunately for me, the guy or girl who originally developed the code I'm working on is either blind or insane, or both. It's a complete mess. It 'works' in the sense that it compiles and does about 1/10 of the things it's supposed to, but it does them in such a roundabout and convoluted way that I have had to basically re-write the entire thing. For the parts which made at least a modicum of sense, a bit of refactoring and tidying up was mostly all that was needed, but I'd say about 95% of the thing has had to be re-written from scratch. There is no consistency whatsoever in the original code, apart from the consistently mis-spelled variable names. I have spent most of the last two weeks reading the outsourcing company's documentation (Half gibberish, half broken English), banging my head against the desk and then just re-writing whatever part I'm currently working on. My coffee intake has increased ten-fold, and my left eye is beginning to develop a twitch. Reading the previous developer's code makes me feel physically sick (although that may be the Pot Noodles which I am developing an unhealthy addiction to). There are no comments, the documentation is a joke, and the amount of duplicated code is ridiculous. Classes are instantiated and referenced, while their source files contain only stubs.

One of my toes now has an inexplicable and unscratchable itch, and my favourite musical genre is now death metal (According to the infinite wisdom of my mp3 player).

On Friday, we were told the customer wants to see a 'mostly working' demo within a week. We exchanged knowing looks - we've both had to basically re-write our respective parts from scratch, and to make matters worse, his project's prime function depends on my own project being usable. This doesn't sound so bad at first - my part 'basically works' - at least it works much better than it did when it was handed over to me (I'd say it is now about 70% complete, rather than the 10% it was two weeks ago), and the contractor has had a lot of success ironing out the user interface and fixing some of the internals, but getting this thing up and running in a way which is going to convince our customer not to run away is going to be a challenge.You see, the user interface (which I have no control over) was developed...wrong. There is no other way to put it. I don't know whether this is a classic case of the customer simply not describing what they want properly, or the developers not interpreting the requirements correctly (I joined well after this project was undertaken and it seems to have become something of a hungry beast - swallowing up time and money without ever really achieving anything). Whatever the problem is, this thing just does not do what the customer expects it to do. The user interface demands user input, but this input never actually gets processed. Well, that's not strictly true. Two of the user-input fields do actually have an effect on the output, but the 15 or so remaining fields do not. The UI isn't even meant to contain fields, it's supposed to be something more akin to MS Word or Photoshop - drag and drop interface, toggled options etc. Imagine Photoshop, but instead of using the mouse to create wonderous works of art, you are only allowed to create two text boxes and to position them you have to manually enter the co-ordinates in a field (and then the software just randomly positions them anyway). You are not allowed to change the default colour settings. Oh, and if you save your work, there is only a 20% chance that you can ever open the file again. If you can imagine such a UI disaster, you are pretty close to imagining the current state of our software.

Now, my portion of the project now at least allows the flexibility the final product is supposed to have. Sure, some things don't work 100% correctly yet, but it's getting close. The issue is that since we need to demonstrate what state the software is in next week, I need to get a working version of the new library and hook the user-end software up to it. Since the user-end software is in an even worse state than my part, changing ANYTHING is likely to bring the whole system to its knees. We have come to something of a compromise: The user-interface will stay exactly as it is for the next few weeks - while I now have to go back and support the old, completely broken, illogical, and essentially non-functional API. So although the new library is technically capable of doing what the user will tell it to in the UI, it will not actually take into account what the user wants it to do, because the UI garbles user-input and then throws most of it away before calling the public API of my library. You want a text box saying 'Hello!' at 0,100 on your screen? Tough - you're getting a text-box saying 'Undefined Field' at 800, -100. You want to save this file for later? Fine, but this software doesn't support its own file format, and even if it did, 'Undefined Field' would become 'No such image exists'!. Obviously, the old API I now have to support again will be making use of the new, mostly functional code I've written, but since the user-interface doesn't ever pass the user-input to the library, the most I can do is make nice-looking error messages demonstrating the technical capabilities of the software.

What should I do? I don't blame my own company for this mess. In fact, my supervisor and boss seem pretty sorry for lumping me with this disgrace straight away. We are now suing the outsourcing company into oblivion in the hope that they will never inflict such pain on their customers again. The problem is that, being a fairly small (and young) company, losing a contract is incredibly damaging - particularly in the tough economic climate we have right now. Since I only just started, I don't want to start throwing my weight around just yet - but I really feel that if we go ahead and demonstrate this monstrosity next week, the customer is just going to walk away (it's a pretty big customer too, so getting this thing right is very important). Both myself and the contractor know that this thing just isn't ready, but since the project is so delayed already, the customer is understandably getting nervous. Supporting the new API will definitely mean the thing won't be ready in a week, but supporting the old API means we're going to be demonstrating a horrific product which doesn't do what the customer wants.

To make matters worse, this is my first 'real' job after graduating from university. I don't really have a lot of experience with the business side of software development, and although I graduated with a first and I have demonstrated my ability in the interviews and through my dissertation project (I have also contributed code to open-source projects and done a few small things of my own from time to time), the company is obviously putting a lot of faith in me. Most software companies in the UK require 3-4 years commercial experience, so just getting a foot in the door is hard enough. The contractor has been doing development for years, however, and both of us can see that getting this thing into a working state in a week is no easy task. Should I just battle on and hope the contractor is able to sort out the user interface problems, or should I put my foot down and tell the higher-ups that they will just have to push the demonstration back? It's obvious that the real problem at this point is getting the software to make use of the new API, which will actually allow the user to do something which at least remotely resembles what they want, but since I have no control over the UI, all I am doing is making the old API work. This won't fix the main problem of the UI being hopelessly broken, and when it comes to demo-time, all the customer is going to get is a piece of software which pretends to work, but then gives them something which looks nice, but isn't what they wanted.

Any advice?

Holy smokes, that has to be the longest first post ever. Anyways, If a customer demands a demo, and you cannot say no to the customer, then you'll have to have a demo. Work as hard as possible to get this thing to work better by friday. Be careful when demoing to not do things that break. Also be careful not to oversell what is ready as that might make them demand a Beta in a month or something. On the bright side, if you work hard and save the contract, you can probably leverage the situation into a bigger raise in your next performance review.

bjolling

@Scouse said:

Should I just battle on and hope the contractor is able to sort out the user interface problems, or should I put my foot down and tell the higher-ups that they will just have to push the demonstration back?

I would do both. Tell the higher-ups that the UI isn't ready for a demonstration, but you'll continue working on it. Have them decide to cancel the demo or not. I wouldn't want to carry the blame of a failed demonstration all by myself.

Possible workaround that I might try is creating my own quick and dirty UI to showcase the API. Looks like the contractor's UI is a total loss anyway.

galgorah

I would also add that you should make sure to get everything you discuss documented.If you talk to them in a meeting then send out a group email to confirm what was discussed/decided upon and ask if everyone feels its accurate. CYA! you don't want to get thrown under a bus if their bosses start raising hell.