I have a lot of garbage data in the database because there was no validation of data on either the client or server side and because I cannot change all of the system, I have to modify all subroutines to not only work with the new system I am implementing, but to also be 100% backwards compatible with any scripts that I may not have the opportunity to work on (that was one heck of a long sentence). It's quite a challenge and is terrible coding practice.

Properly, a project manager should have been assigned to redesign the entire system. Unfortunately, while a system redesign is superior to a conversion or upgrade, it's not always economically feasible in the short run. In the long run, it would pay off, but we have to worry about earning money NOW.

One of the worst aspects of "fast and cheap" mentality is that code is usually thrown together without good structure. When the inevitable bug-fixes and enhancements are added, the code becomes a little more unmanageable. As more bug-fixes and enhancements are added, this further increases the unmanageability. Over time, we have the "US Tax Code" style of programming. Any individual fix might make sense in its context, but throw it all together and it's a mess.

I love my job and so far I've been given a lot of freedom to implement things properly, but not everyone has the luxury. I sympathize with you and I wish you the best of luck.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just go the the link and check out our stats.

In my experience, corporate bosses are not against good code per se. They merely think of everything in terms of cost/benefit analysis. If you can think like they do for five minutes every day (yes, I know, it's harder than profiling a serial killer sometimes) then you can present your boss with good arguments for good code.

For example, why factor out similar/identical code into subroutines? Because it's easier to understand and debug, plus future code is faster to write. It's in the company's best interest to have good code. Why do an analysis phase before a single keypress? Because it'll save you from having to rework everything at the last minute.

Good code is not always clever or artistic code. For me, good code is the easiest code to write and understand later.

Yes, bosses demand insane schedules. There are some ways of handling that. For example, check out IFPUG, the International Function Point User's Group (www.ifpug.org). Doing a function point count of a new feature request can be a good reality check for your boss, since it gives a fairly solid measure of the amount of effort required to get the new feature done. Coding the thing well or poorly won't get you done any faster, really... you need to implement the same features, and that simply takes a certain amount of time, no matter what the code quality. If you can inform your boss of that... okay, it won't make you any more popular, but at least you'll be accurate and consistent.

So it's really just a question of when you spend the time on the code: in the design phase, in the coding phase, or in the debugging phase. (Or in the lawsuit phase.)

stephen

My experience is that once you go beyond small "script" like programs and into Software Land, it always (always!) pays to do things Right(tm) rather than fast. It simply takes less time to do it that way :)

In my case it is because I'm not clever enough to do things complicated and ad hoc. I need the structure to lean on so to speak.

/J

Mow your lawn. =P

I'm not trolling here, this is a real point. Things decay systems change, requirements change, hard-drive space vs. memory speed trade-offs change as the market pulls $300 80Gig HD out of thin air, etc etc.

Some code is just naturally going to be disposable. Fast and Cheap is just fine there. Good coders know what not to spend time on too. I modules for things that last and 12 line nightmares of 90% punctuation for throw-away.

--
$you = new YOU;
honk() if $you->love(perl)

~acolyte d4vis
#!/usr/bin/fnord
Update: Just one clarification. I do clean up anything that might have to be used by others in the future. That's just common courtesy.

my definition of GOOD(tm) does include "sufficently well written so i can put my hands on it a month later"
deadlines are important but too short deadlines are simply stupid.

deadlines are important but too short deadlines are simply stupid.

And believing deadlines are selected according to how long it will take to do the job perfectly is naive. Dealines are selected according to when the product is needed. If I need a script to take care of a frequent problem, I need it before the next occurance of the problem - not two weeks from Tuesday. If that means the code will not be as elegant as it could be - oh well. If it does the job, good enough.

- email Ozymandias

There are 3 points to any project:

• resources,
• time, and
• scope. They are all interdependent. If you can control 2 for any project, you cannot go wrong.

  Por ejemplo, if your boss suddenly wants to cut delivery time in half, and you control the number of people on the project, and what the project will actually do when delivered, you have no problems

  Even if you are allowed to control one of these factors, you are at an advantage. Say you are told that your code now has to move mountains, and your staff has been cut in half. Crap. But if you are allowed to push back delivery date, who cares?

In natural language (eg., English), the more complex and useful the idea you are trying to express, the more it behooves you to plan the structure of your writing ahead of time. Simple conversation -- meant to be used once to accomplish a singular purpose and then thrown away -- can't be designed. It's counter-productive. However, when drafting the constitution of a new country, it is imperative that you plan ahead in order to forge a document that will thrive and live beyond you, be maintainable, encourage improvement, but still contain the values with which it was forged. The same valuation applys to Perl, as I suspect it does to any language, machine or otherwise.

Of course Perl is a good tool for one-off quick tools; its "whipupitude," to quote Larry Wall, is par none. You can get away with this because one-off tools don't require maintenance or improvement. If they do, you'll quickly find that you are spending more time maintaining your tools than accomplishing anything useful with them, especially if they grow at all.

Perhaps, then, one of the most important skills to have as a coder is the ability to distinguish between things you will have to maintain, and those you won't. If you can conceive of the possibility that you might have to reuse your code, you'll always reap the rewards of a good design.

I would have to agree with you - there does seem to be a trend in many newer companies to produce things quickly. The philosophy is often: "If we're still around later, we can fix it."

Which is unfortunate. You can refuse to work that way, but it's never as simple as it sounds.

Personally I would choose good and fast - but then, I'm currently in academia. <grin>

Now that may seem a bit backward, but if you cough up the money in the begining and do it right the first time, then you save money in the long run. Take, for example, a POS car you see for sale for less then 1000 USD!!!, wow, right? No. You could spend ten times that, buy a new car (with a warranty) that will last ten times longer with less need for repair. So which car really costs more? Now I understand... that sometimes you just need a junk car because you only need it for a year while you wait for your long lost rich uncle to die and leave you a couple million. But how often does that really work out?

I've written scripts that only needed to do a simple thing and would be thrown away shortly... They are still in use long after their experation date.

Actually, this is a pet subject of mine.

*If* you can buy a car for $10,000, and *if* it will last 100,000 miles, and *if* it required no maintainence, it would be costing you $0.10 per mile to drive it, minimum. And that's assuming someone gave you the gasoline, the oil, etc.

Now, I can go buy an $800 car, and assuming I use just a tad bit of analytical skills, wind up with a car that will go 8000 miles, and then can be thrown away. $0.10 a mile! And, I get to drive a different car more often (I mean, get real, do you *really* want to drive a Ford Escort for 100K miles? It's bad enough driving one just to the grocery store...)

But, you don't get a warranty, you don't get that new car smell, and the risk factor that you wound up with a piece of junk is higher (although not eliminated, let me tell you!).

Of course, the business world doesn't work like driving a car. Software typically has a deadline to be completed in. It's typically expected to have some sort of return for the investment (big or small), because it's not a companies job to be in business to lose money. Companies will *often* operate fairly short-sightedly, because they have a vicious group of sharks to satisfy, call "investors". Investors want to make money, but the majority are not going to continue to pour money into a company that doesn't generate some return, or at least an indication of progress.

There's also this thing called "market window", that can be more important than the circling sharks. Market window is the term used to describe the amount of time before someone *else* comes out with a product that obviates the need for yours. No one cares if you write the ultimate spreadsheet program, if someone else releases theirs a year early, and scoops market share, and the product becomes firmly entrenched, even though yours is better. Sound like a company we all know, and some of you hate?

Investors have to look at all sorts of factors: What's the market window? What's the viability of the product? Can it be accomplished in the investors lifetime, or fianancial window of opportunity? What's the existing market share? Who are the competitors? Is this a leading technology, or something that's going to be a flash in the pan?

If you've never been around these people, they can seem very cold and callous. But the reality is, they're out to make money. All companies are out to make money. Such a thing as an altruistic company doesn't really exist, because they can't *afford* to exist.

As a result of all this, software and hardware is sometimes forced to ship early. Sometimes, and this is sad to say, it can be more important to have a product with a mediocre reputation and get it to market early (or first), than it is to wait, and ship yours *after* Microsoft does. It's often easier to assauge the user problems than it is to get market share back. It may not be something that *we* like, but it's a real world business model, and real world business models factor in things like these. If you've never seen a business plan (and not one out of a cookbook, but one written by people who've had companies go down), go and find one. Read it. It's very interesting.

Now, one thing you'll never find written in a business plan is the phrase "And at this juncture, we plan to screw the users.". Investors don't like plans like that, because it indicates a company is unstable, or at least, the principals are. No, the customers get screwed later, and (if you have any brains) with no written memos about it. And it happens because of poor scheduling (unrealistic schedules), people that don't know how to manage, and a business plan that doesn't say "And at this point in time, we fire the prima donnas". (If you don't know what one is, go look it up. You don't want to be one. It's bad karma).

As you can see, there are a huge number of factors that affect "Good, Fast, Cheap, Pick two". And it has to do with competition. Perhaps it's not the best kind. But investors can't sit waiting indefinitely waiting for the return on their money, companies can't allow market share to be ursurped, and as long as there is money to be made, someone else won't play nice (they'll pick 2, and deliver a product), while you're still trying to write the perfect Doom game.

You can be a good citizen, and try to help people get out of this mindset, but as long is there is cutthroat business practices, people willing to undercut anyone else, blah blah blah, it's gonna happen. So just do the best you can do, within the time frame and and budget given, and try to prepare for the next phase. Don't set out to write obsolete software, but don't kill a company by trying to write the perfect XYZZY that they don't need, either.

--Chris

e-mail jcwren

Cheap is usually more costly then Expensive.

Or, as the saying goes:

Buy quality, cry once

/J

The other approach is a pragmatic code-warrior approach. Though I tend to overdesign things (like a good free software hacker, I believe in too much flexibility), there's definitely a place for getting things done quickly and not adding more features than you can handle.

There are even a couple of schools of thought in computer science that encourage this approach. One is refactoring, and the other is Extreme Programming. Fred Brooks said, roughly, "Plan to throw one away. You will anyway."

Of course, if deadlines are short, you may not have time to refactor your code or throw away legacy stuff, and you'll be left with a hard-to-maintain pile of proof-of-concept.

There's nothing like going through a nasty subroutine and cutting out half of it while making it run faster or use less memory -- but there's also nothing like going in to a well-designed module, pinpointing the bug, and fixing it without having to sift through the call stack for half an hour.

If you pressed me, I would suggest that you err on the side of clean code and good discipline -- if you clean up after yourself now, you won't have to dig yourself out of it next time. And there's almost always a next time.

I suppose I should give a little more background into my blunder, just so that others will not follow . . .

My last job was wonderful, too wonderful - so wonderful that we ran out of money and the business failed. Before this job I was a Visual Basic Programmer. I was so scared that I would have to return to that world that I took the first job that said 'Perl' and 'Linux' - thinking 'Hey, this just HAS to be good.'

Woah, was I wrong. Thanks to everyone for the advice, for the record I do consider coding an art form - just to the extent that I have a hard time leaving something behind that I am not proud of - and this place fosters leaving bad code behind for others to clean up.

Falling towards the ground, but feet ready for a rebound,
Jeff

In the last 15 years, I have worked for a government agency, a commercial publisher, two consultancies, and a corporate software center (current).

The consultancies often wanted the last two, even when it risked the integrity of the project, e.g. the safety and completeness of the custom application.

Often, fast meant reuse poorly conceived, designed, documented, and/or executed code written for a completely different client and/or business need.

If this is what you're facing, then jet. It's not worth the aggravation.

OTOH, if you're worried about the differences between servicable (80-95% perfect and the user knows it) versus elegant (100% perfect but nobody cares), then concentrate on the former. You'll be happier in the long run.

When writing code for hire, there's really only one benchmark: is the client happy? If so, then anything more is sugar-coating that should be avoided.

In my first job out of academia, I was working for a games company out of Boulder, CO. It wsa all about spend nothing, get it done yesterday, and it has to be like a $10K commercial product.

The network boss was a bit of a 'wide lad' - talked up a storm, had adequate NT skills and was the proverbial 100 monkeys typing on a keyboard with root access under Unix. They had a home brewed trouble ticket system that was a nightmare of early Perl4 scripts. The first day I was there the intranet broke - someone buggered up the secure keys. That got fixed after a week of persuading them to spend $200 on a key. The perl code I never got to the bottom of - in the end I wrote a new set of scripts to do what had been done by the old scripts. I was never so happy to get out of a job as that place.

MadraghRua
yet another biologist hacking perl....