What's wrong with "Bad" Code?

I'm sitting here wondering what's wrong with poorly written code. I think that poorly written code is code that has no error handling, no documentation, uses a lot of random global variables, undefined variables, repeating lines of code in a procedure instead of calling subroutines, and so on.

What's wrong with it if it works?

In Feb, a friend asked me to develop something for him and demanded that it be in VB.Net Express. I wanted to do it in old faithful, VB 6.0. He said, "I want to be able to follow what you're doing."

I developed the entire thing he wanted with his constantly changing requirements (his first time as a s/w project manager) and changing plans. When it was all done, he found out it would cost him too much money to distribute his project in the .Net format and wanted to redevelop the entire thing in VB 6.0. He asked me to do it in three weeks. I said I'd do my best but it wasn't likely.

Friday he released "his" version of the project with the above described method of coding. Apparently, after I started his VB.Net version, I inadvertantly inspired him to learn VB. The only thing he had access to was VB 5.0 (yes 5.0). So while I was killing myself to meet his constantly changing requirements and deadline, he was "learning on VB 5."

He told me he was sorry he didn't need my version afterall and that he was very lucky because "he's a quick learner." But, "thanks for all your help because my work spun off of yours."

When I explained to him that his code had no documentation or error handling and his code had profound reduncancies, he replied, "it works on my machine, I don't see the problem." "I looks like [a child] wrote it, but it's done and I didn't need error handling or documentation." He plans to sell his project to 30,000 people.

Mind you I offered to help my friend to renew my skills. I vowed to do a professional job (to the best of my abilities), and did that. But, I sort of feel like I wasted six months of my life developing something, and then redoing it. Only to be told, "Nevermind I bought a book and taught myself."

My friend wrote "bad" code to meet his immediate needs and feels fabulous about it. Why should I bother trying to write professional code when customers feel this way. I suspect non IT managers feel this way too.

What do you think? Oh try not to beat on me too hard.

If a badly written code runs properly or atleast appears to do so superficially, it is do to sheer luck and the chances of surprises popping up out of nowhere is very high.

Further, it would be almost impossible to modify this code at a later stage for any improvements or it the requirements change - which do more often than not. When u have to enhance your program, you will find it increasingly going out of control as new unexpected errors will creep at the least expected time and place.

The time and efforts to tame such a source code would be much more when compared to that which can be invested in systematic software development process. So it would always be a safer bet to stick to the standards and processes as far as possible. you would be glad you did.

As far as the layman is concerned, he may not realise the importance of this or the difficulties that may arise due to lack of standards. I have mentioned only a few of the possible problems. It could be worse.

So his solution may apparently work, until some terrible flaws are unearthed. Then it becomes all the more difficult. That's why it is important to be systematic.

Quote:

---

Originally Posted by Binish

If a badly written code runs properly or atleast appears to do so superficially, it is do to sheer luck and the chances of surprises popping up out of nowhere is very high.

Further, it would be almost impossible to modify this code at a later stage for any improvements or it the requirements change - which do more often than not. When u have to enhance your program, you will find it increasingly going out of control as new unexpected errors will creep at the least expected time and place.

The time and efforts to tame such a source code would be much more when compared to that which can be invested in systematic software development process. So it would always be a safer bet to stick to the standards and processes as far as possible. you would be glad you did.

As far as the layman is concerned, he may not realise the importance of this or the difficulties that may arise due to lack of standards. I have mentioned only a few of the possible problems. It could be worse.

So his solution may apparently work, until some terrible flaws are unearthed. Then it becomes all the more difficult. That's why it is important to be systematic.

---

I think I understand what you're saying. Future enhancements and fixes are made more difficult when you don't stick to standards. So, it's not just a matter of doing it right because I was taught to do it right. It's a matter of doing it right so that future development and enhancement goes more smoothly.

Well, I do not wish my friend ill will. If he's lucky and it works error free, I'm happy for him. I've heard a phrase, "I'd rather be lucky than good." So maybe that's how he feels.

I appreciate your feedback.

Quote:

---

He plans to sell his project to 30,000 people.

---

If you see it as bad code, I would get this in writing:

Quote:

---

He told me he was sorry he didn't need my version afterall and that he was very lucky because "he's a quick learner." But, "thanks for all your help because my work spun off of yours."

---

That way when those 30k people flip out and sue, you're not liable.

Quote:

---

Originally Posted by sevenhalo

If you see it as bad code, I would get this in writing:

That way when those 30k people flip out and sue, you're not liable.

---

Steve,
Good point. I hope I saved the email. I was pretty furious when I read that.

The code is for a game. The worst I thing that will happen is he'll lose subscribers. If it was a finacial tool or something that contained secure data I'd pursue it harder, or put a stop to it.

In the larger scheme of things, it probably won't matter. I wish him the best. I hope he's lucky and succeeds and goes on to learn more about programming. It's my wish that he learns enough to do better.

Thanks for pointing this out. I will save this email for damage control.

Jesus,

Emails can be spoofed, get it in physical writing (whether the writing says you are creditted for the code or absolved from any liability).

Quote:

---

Originally Posted by sevenhalo

Jesus,

Emails can be spoofed, get it in physical writing (whether the writing says you are creditted for the code or absolved from any liability).

---

OH boy. You mean have him write me a letter stating that he's using his own code that spun off from mine? How about I write him a letter saying something to that effect and asking to be released from any liability?

Wow, I never thought of this situation, as you can see.

Is your name in any way associated with the program?

Mentioned in the About box (if he has one lol) - instructions, documentation, any type of credits at all anywhere?

That is something you can ask him...in writing.

Do no accept a verbal answer either regardless of whether it is yes or no.

If it is yes, then state, in writing, that you want your name removed from all places that it is mentioned. Make sure you date the letter, send it signed receipt confirmed, and save a copy.

Quote:

---

What's wrong with "Bad" Code?

---

Maintainability.

I make it a practice to write good code, and, if it is a program of any significant size, there, there will probably be some errors, I would count on it.

Personally, I agree that good code makes it easier to maintain, but also, when you have a formatted way of doing things, it helps with the logic of the flow and goes a long way in preventing bugs.

If this is a big program, and he did it in three weeks, I would start brushing up your skills even more because you are probably going to need them when he runs back to you crying for help because he has paying customers wanting refunds for the program that they bought that doesn't work. In my experience, programming isn't just making something work in a certain way, it is making it so that it doesn't work in ways that it wasn't designed to work, not just in error handling, but preventing the wrong input in the first place.

Quote:

---

Originally Posted by Krenshau

If this is a big program, and he did it in three weeks, I would start brushing up your skills even more because you are probably going to need them when he runs back to you crying for help because he has paying customers wanting refunds for the program that they bought that doesn't work.

---

Oh no, don't do that. The last thing you want to do is be lumped with someone else's steaming pile of spaghetti. If it's not your code you're not responsible for it.

I agree with 7 and Hack. Wash your hands of anything to do with this project and then quietly forget about it.

Bad code is just plain bad. Eventually it will be exposed by way of program crashes, data inconsistancies, and resource usage. Your friend still should owe you for the project he requested if he ended up doing it himself or not.

In the future, I would also suggest you draw a deffinite line between your friends and clients. That way, things like this aren't so difficult since everyone has a set role.

And get a contract in writing, so that everyone thinks it's the same project being worked on the same way toward the same goals for the same price.

Otherwise you're giving your knowledge, time and effort away for free.

The difference between good and bad code is about maintainability, manageability, flexibility, usability and of course, efficiency and effectiveness.

spaghetti code runs out of control. Even if it is written by you.