fix and extend buggy unfinished software or..

At the beginning of last year I was given unfinished software written by two newbie software developers that had recently left the company. After going through a bug fixing cycle I realised the software was only 20% finished and on top of that was riddled with bugs. I rewrote all of it (not included a new piece of functionality) in 6 weeks. It is now at the client's being evaluated. This worked for me. As I was writing the new software, I looked at the joke code left behind to get clues about functionality etc.

Now my next task is 'polish' and get out the door some software written by a company co-founder in the next two months. If done full-time the software I've been given looks a month's work or so. The company isn't a software development one and so company co-founder here doesn't mean someone who has founded a software company.

The co-founder told me the software works 30% of the time. He tried to show me a demo of it working on Friday but even for one set of input data it only worked if certain input parameters were supplied.

This software is unfinished. It has virtually no comments in the source code. There is no documentation about how the code works.

I am wondering again whether I should rewrite the thing from scratch or go through a cycle of bug fixing and extending.

I find this annoying. It would be faster if I could have been given a written list of pointers rather than software that doesn't work.

The source code I've been given looks hacky. The co-founder told me he likes writing all loops as
for i = 1 to 100 .... Next i
as while loops can spin forever but for-next loops always terminate. Hence the code he has written will either run for more iterations than needed or silently fail with less iterations. The co-founder believes this 'technique' is defensive programming.  The code also uses on error resume next to surround code that would normally blow up.

Savage
Sunday, April 18, 2004

I'd just rewrite it. The FOR loop thing is fairly common, although most people break out of the loop when the terminate condition is met.

And don't fret about working without a spec; the people who went before you didn't have one either. Just leave nicely commented code so the next guy doesn't say the same thing about you...

Tom H
Sunday, April 18, 2004

Determine your objectives, and go for them. The coding style that the cofounder used does not matter, what matters is that you keep getting your paycheck. Keep this in mind.

The place you work at seems to rely on "C" coders and you aren't going to change that. Adapt or else ... If you do not like such environment, try to find some other jobs where you could work with "A"s - i.e. people who actually know what they are doing.

Mr Curiousity
Sunday, April 18, 2004

Rewrite it from scratch, but keep the founder's code around for reference; I've found that even really crappy code can sometimes help you understand the project's specs.  On an Access database redesign I did a couple years ago, the old database wasn't usable, but it was still valuable for reference and it helped me know what questions to ask to clarify the requirements.

Kyralessa
Sunday, April 18, 2004

Diplomacy is the art
of letting someone else get your way.



Have you asked the customer (company founder/coder) what HIS goal is?

His ego MAY be invested in his code. So his goal may be "make my code shine".

However, if he is truly a businessman his goal is likely "make a program that can make me money".

If so, you can DIPLOMATICALLY explain to him how you can use his prototype as an EXAMPLE but that it will be much easier to start from scratch so that you can hand craft a solution. Find some benefit to HIM of starting from scratch. A benefit that does not mention "we want to get rid of your crappy code".

My $.02 worth as a company founder and amateur (but learning !) coder.


P.S.

If it were me, all I'd care about is having code that:
a. Works
b. Is extensible by me. (i.e., good, clear architecture, clear design/variable names are more important than comments.) I ascribe to the XP view of "the code is the documentation".

But that's me.

Mr. Analogy
Sunday, April 18, 2004

The 'don't rewrite' rule only applies to finished software. For stuff that has never functioned and in the state you describe, write from scratch is the correct choice. I would not even call it a rewrite since that would imply somethingh was written in the first place which isn't really the case.

Dennis Atkins
Sunday, April 18, 2004

I just fear that you will have this kind of NIBM (Not invented by ME) attitude for each piece of software you're given. It's very easy to find bugs and issues with someone else's code. But be careful, as your code is not perfect either.

You may be using the rewrite technique as a defense. It's rather easy to write coda than it is to read and understand the code from someone else. But take that as a challenge. Read and understand the code, without snide remarks, and extend it. This will help you when you get to work on a project involving dozens of people, where rewriting modules or the entire project is not an option.

Mauricio Macedo
Monday, April 19, 2004

Thanks for the last piece of advice.

I've worked on many very large, multiple person projects before - even on projects which have been the work of 300 developers over 5 years.

I never considered any rewrites in those situations. Why? Because the software actually worked. It had bugs, but the majority of it worked the majority of the time.

The situation here is different. The software hasn't got just a few bugs in it. It is far less than 50% complete and has never been released or used even internally.

It has hard to convey the situation in just one post. I am no longer working in a software company, rather a company doing mainly business that does a tiny bit of bespoke software development on the side. Hence the company can be really bad at it, because its success doesn't depend on the success of the software.

Savage
Monday, April 19, 2004

  Recent Topics

  Fog Creek Home