(Ovid) RE: Good, Fast, Cheap: pick the last two or get out!

Lamentably, one of the facts of life is that poor systems get thrown together on tight budgets with even tighter deadlines. They sometimes work, but have sacrificed maintainability. One project I am working on right now involves copying a hybrid flat file/Access database driven Web site to exclusively use MS SQL Server 7.0. The original project was put together by a novice Perl programmer who's prior programming experience was JavaScript (his subroutines that end in return true work because he fails to use strict, -w, or taint checking).

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.

Comment on (Ovid) RE: Good, Fast, Cheap: pick the last two or get out!

Replies are listed 'Best First'.
RE: (Ovid) RE: Good, Fast, Cheap: pick the last two or get out! by stephen (Priest) on Sep 19, 2000 at 03:44 UTC
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	[reply]
RE: (Ovid) RE: Good, Fast, Cheap: pick the last two or get out! by jplindstrom (Monsignor) on Sep 18, 2000 at 11:13 UTC
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	[reply]