My Code Sucks

Well MOD, you are not alone. Regretfully, we are not alone.

I wonder how the others are fighting that. I have read "Code complete" long time ago, Fowler's "Refactoring" not that long ago, and some articles on those things, and still I find my code sucks. Badly.

Does somebody care to share some resources/knowledge on how to improve things?

Mike

bellyripper at 2007-7-6 21:13:29 >

> Does somebody care to share some resources/knowledge

> on how to improve things?

Just Do It (tm)

Start small. Everytime you have a bug, write test cases. While you're writing cases to uncover the bug, write a few more that might be related. It takes time, but you're gambling that you get it back in the end ... my experience is that it's got good odds.

kdgregory at 2007-7-6 21:13:29 >

> > Does somebody care to share some resources/knowledge

> > on how to improve things?

>

> Just Do It (tm)

>

> Start small. Everytime you have a bug, write test

> cases. While you're writing cases to uncover the bug,

> write a few more that might be related. It takes time,

> but you're gambling that you get it back in the end

> ... my experience is that it's got good odds.

or "How to fall in love with XP"

(which is much more realizable when your customers are waiting for the software...)

Franck_Lefevre at 2007-7-6 21:13:29 >

> or "How to fall in love with XP"

> (which is much more realizable when your customers are

> waiting for the software...)

>

I am planning to read "Extreme Programming Explained" and "Extreme Programming Installed" in some near future. Is this a book title? I couldn't find it with google.

Mike

bellyripper at 2007-7-6 21:13:29 >

> What's the answer to folks who don't like JUnit

> because it doubles the size of your code base and

> maintainence burden? Deadlines are always tight.

That's why I suggested starting with tests to identify known bugs, and at the same time probing other parts of the class under test. It's been my experience that bugs are like cockroaches and deer: when you see one, there's always a bunch more that you haven't seen yet. If you manage to uncover them with your tests, then you've just saved debugging time and perhaps customer complaints.

As far as integration and acceptance tests go ... I've done integration tests with JUnit. It does require more work than true unit testing, particularly in thinking how to isolate a particular test from what's going on in the rest of the world. But the times I've done it, it's been early on in the development process, and has helped me to what I considered a better design.

Of course, many people (managers especially) believe that bugs are caused by quantum effects, not programmer mistakes. Not sure that you'll ever convince them ... in this case it might be better to follow the second part of "change your organization or change your organization."

kdgregory at 2007-7-6 21:13:29 >

> I'm betting that jschell's and DrClap's code don't

> suck.

I have in mind a program that I wrote earlier this year. It processes about 90% of the orders that come in to our company, so you'd have to say it's mission-critical. I translated it from Visual Basic to Java, so we could get it off the PC and onto a reliable platform, so OO-wise it's rather embarrassing. Select-Case all over the place, methods returning public instance variables. I'm not going to post any of it.

But here's the first rule from the article:

"Your code sucks if it doesn't work.

Does your code work? How do you know? Can you prove it?"

The article then goes on to blather about testing. Well, sorry, I don't have any tests for this program. At least no automated tests, so I guess my code sucks. But the real testers are the customers. Do they get what they ordered? Exactly once? That's the test I go by, and it works really well. I haven't heard a thing from the outside world for a couple of months now.

PC²

DrClapa at 2007-7-19 23:15:54 >

> I don't think this is a core part of XP. My reading of

> the "big three" (Cunningham, Beck, Jeffries)

> emphasizes flexibility and feedback rather than

> zealotry ... of course, Jeffries' insistence on YAGNI

> could be considered zealotry, but it's modified by

> Beck's comment that "YAGNI isn't an excuse to be

> stupid".

I hadn't read Beck's comment. Thanks for sharing it.

> I think a lot of the zealotry comes from the

> flavor-of-the-month people: they latch onto XP as the

> greatest thing to come along, and the thing that is

> sure to save their project. Unfortunately, from what

> I've seen, they seem to latch onto only part of the

> message: limited up-front design, for example, but not

> the system metaphore or test-driven development, which

> drive emergent design (and most of the time, they

> think it's "no upfront design.")

Right, I have the apostles in mind more than the Holy Trinity.

I've heard about "oil canning" that came about because anyone can change anyone else's code at any time. Programmer A checks out code from Programmer B and changes something to their liking. Programmer B sees it the next day, gets mad, and changes it back. Communication is needed to resolve, but there's energy dissipated until it occurs.

%

duffymoa at 2007-7-19 23:15:54 >

> Does somebody care to share some resources/knowledge

> on how to improve things?

Well, I've been basically forced to have code that doesn't suck due to my style and interests:

I enjoy making tools -- bits of a project that do a task, do it well, and keep on going under the greatest abuse we can give it. After all the bits are done, then the project is done too. You just have to make sure all the bits integrate (the integration is one of those bits too).

properly conducted code reviews -- this, to me, is a forum to show off your cool stuff and I delight in others seeing my code.

planning and design -- sucky code is not always the total fault of the programmer, when time for proper planning and design are not given by higher ups, then you are going to get proportionally sucky code. Design and plan your portion of the project before you touch the editor to start coding: it really pays off in maintanability and, frequently, in stability.

mentor somebody -- it becomes very apparent what you're doing wrong when you have to show somebody.

Basically I just enjoy programming: coding, designing, refactoring, support, mentoring, leading teams, consulting, etc... I first was introduced to computers 20 years ago and I loved it, then I found out that people would actually give me money for it--wow what a rush that was. After 15 years of programming professionally, I still love it and cannot believe they actually pay me to do this--if I could afford it I'd do it for free. It's some of the best fun I've ever had--with my clothes on. (well, most of the time the clothes are on when I program these days). And yes, I do have a life outside of work--with a wife and kids that I adore and spend lots of time with.

morgalra at 2007-7-19 23:15:54 >

geeze my code sux big time, but I blame it on .... geeze.... there is nobody to blame it on but me. well, i know WHY it sux at least. when i started this huge project I didn't know **** about programming. I just sat down and started doing it. when you learn as you go, your code tends to be choppy and just... uh.... basically SUCK (as that web page pointed out)

moerderina at 2007-7-19 23:15:54 >