[Craig328]

Although it's nothing exceptionally earth-shattering, sometimes coding it to work IS what is acceptable and here's why:

If you are employed and paid as a coder, congratulations, you are one of the survivors of the current crappy economy. If you were employed prior to, during and after the dotcom bust, even bigger congrats. The true object of the game as a paid coder is to produce the product that best assists the business' goals for whom you toil. That is to say, you do the work that meets their goals and deadlines as best you can...and sometimes that means you code it to "just work" and, regrettably, don't code it to be bullet proof...because the business demands your attentions elsewhere.

What is missed from this entire discussion is that the coder almost never determines from the business perspective where his/her time is best spent. Coders see their ideal work product as fully functioning, error free code while the guy that signs their paycheck sees their ideal work product as a functioning module that is integral to their overall business with which they generate a profit (and can so pay their valuable coder employee amongst others). Sometimes that functionality is achieved via ironclad code and sometimes it's achieved by spit and baling wire code. Which is "right" isn't up to the coder many times...it's up to the people who decide whether the coder's time is better spent fixing three modules with half-ass code (but they work) and they get lower paid employees to field questions/complaints from users/customers when/if it breaks OR whether the coder takes three times as long to fix 3 modules and do it better.

You see, some of you will think the business equation of that second option means you won't need the lower paid monkeys to answer phones/emails because your...what?...code will never error now? Guess what, next guy you meet who writes code that he claims will never error...well, don't go buying any bridges from him. From the business owner's perspective, you just took longer to do something and he'll still need someone to handle calls for issues related to the code you produced. Those issues may not be as frequent...but nobody writes 100% guaranteed, fail-proof code. Hell, if it relies on anything you didn't write, the quality of the code you wrote is built on the foundation of something someone else did...and you can wave bye-bye to your perfect code product's guaranteed stellar performance.

As coders, all of us would like the freedom of time and resources to produce the best code product we're able to generate. However, the actual world in which we live means that almost all of us collect a paycheck from someone else...and many times that someone else is the determiner for how idiot proof your code product has to be to pass business muster.

THAT is reality.

This post has been edited by Craig328: 09 June 2010 - 10:33 AM

[KidD1988]

Hi all
i vote for just making stuff work! srsly can u honestly say that u fixed a problem befor it became one ?
What i am trying to say is, if u make ur program work (remember and readable) it is much easyer to fix whatever problem that just might occur, then trying to think of things that could go wrong(and that is impossible in my mind)



What i am trying to say //lol do u guys and girls understand what i am trying to say

Do u understand the words comming out of my mouth

This post has been edited by KidD1988: 10 June 2010 - 10:08 PM

[PsychoCoder]

Yes we do KidD1988 you're one of those programmers (term used loosely) who looks for the easiest way out, regardless of how many techs lose sleep through the night trying to resolve issues from your application). It isn't a hard thing to take a few situations in mind when planing a new application, and it's too a hassle for you then you're in the wrong line of work kiddo.

People like you are more concerned with But it works on his system than any kind of stability for all systems that access your work, and to be that's just disgusting. To me that makes you a code monkey not a real developer. You make statements like We'll cross that bridge when we get to it, or When the call(s) come in we'll deal wit it then.

Is it really too much trouble accounting for these situations before turning over the application to your userbase? If that answer is yes then, once again, you're in the wrong line of work

[Atli]

KidD1988, on 11 June 2010 - 04:05 AM, said:

it is much easyer to fix whatever problem that just might occur, then trying to think of things that could go wrong(and that is impossible in my mind)

Please stick to software "development", as apposed to things like architecture or designing space shuttles. And avoid building software for critical systems, like medical equipment or security systems.

It's not all that hard to imagine most of the things users may do to break your code, and to fix it proactively. In most cases you don't even have to do that, you can just "blacklist" every possibility except the one you need. (E.g. only accepting numbers within a certain range, rather than strings or whatever else the user may thing to input.)

Simple design *bugs* early on in a project can derail everything, forcing you to rewrite a bulk of the code just to fix it. I've seem more of those than I care to remember. Spending a few hours, or even days, "imagining" what your program will look like after a few thousand lines of code can spare you endless wasted hours re-factoring/rewriting them.

To paraphrase something a smart man once said: "Code-monkeys fix problems, real programmers prevent them."

... Sadly, it seems the professional programming world prefers code-monkeys these days

[KidD1988]

i'm rly sry for not being clear m8! i love doing what i do, and pride myself on being able to produce the best i can!!

what i find to be "best practise" is making stuff work, now when the program as a whole works, all the functions do what they are surppose to under all the "Right" circumstances!

Quote: it is much easier to fix whatever problem that just might occur

mening : i find it much, much easier and faster to fix problems when i have a program as a whole. I would never AND i mean NEVER sell or even relese anything that only just worked, but i find that it is necessary to get it working, to be able to get it working the right way!

//edit
?? was that clear or is it true am i a monkey

This post has been edited by KidD1988: 11 June 2010 - 12:20 AM

[keakTheGEEK]

baavgai, on 08 June 2010 - 05:25 PM, said:

( I make my junior programmers do all the UI elements, it's trivial but required work. )

I also hope you let them do more than just "trivial required work". Having your junior developers do all of the grunt work and not providing them with opportunities to work on challenging, more interesting projects (i.e. encouraging growth), will only result in a high turnover.

As for getting code to work vs working right... if you know that a potential scenario could occur and you don't provide the few necessary lines of code to handle it, well that's just being lazy. If you're serious about programming and really enjoy doing it, then something like not checking the format of a date that a user enters in or not checking if a required field is blank or not will stick out like a thorn in your side and you won't be able to call your code complete until you handle it.

Also, when you develop in a team environment where Sr. Developers verify and approve your code then things start to become even more critical. Being lazy like that is definitely not a great way to gain the confidence of your peers (if it happens too frequently it could even cost you your job).

So, I have to agree with getting it working the right way. I think that it's good practice to try and come up with as many possible scenarios that you can think of that might break your code and handle those cases. You're probably not going to think of everything, and more experienced developers will have better ideas about what to anticipate, but always make the effort. If you have something in mind that could possibly happen (but most likely won't), just spend the few extra moments to write the code that handles it. Because if you don't guess what? Either the user reports it or it gets kicked back by Q.A. dept because some software test engineer broke your code by doing what you thought wouldn't happen...

[Atli]

KidD1988, on 11 June 2010 - 06:08 AM, said:

?? was that clear or is it true am i a monkey

There is a little monkey in all of us

I do get what you mean. But it's a very dangerous way to code; to leave the "grunt-work" for later. I always think "mehh, I'll come back to it", but I rarely do... It just get's left in there until the client discovers it. (Which is bad in o so many ways.)

Best to think proactively. That way you won't regret it later, or be stuck debugging your code forever... And besides, "design phase" sounds a lot better in the project time line than "debug period"

[baavgai]

keakTheGEEK, on 11 June 2010 - 03:41 AM, said:

baavgai, on 08 June 2010 - 05:25 PM, said:

( I make my junior programmers do all the UI elements, it's trivial but required work. )

I also hope you let them do more than just "trivial required work". Having your junior developers do all of the grunt work and not providing them with opportunities to work on challenging, more interesting projects (i.e. encouraging growth), will only result in a high turnover.

You're right, of course. However, getting all the screen widgets playing nice is more than enough challenge until you get the hang of it. Hell, the reason I'm not fond of it is that there's always some UI element that's not working right and sends you off on ugly tangents.

On a good day, UI design is just implementing elements you've done a hundred times before. However, there's always the unforeseen that's the challenge. Also, if I provide the MC of the MVC, it common for the V programmer to write code that should properly be control. The beginning design is rarely the final product and the UI developers can end up adding a lot. When one of those programmers is ready to develop an entire project start to finish, I'm thrilled.

KidD1988, on 10 June 2010 - 11:05 PM, said:

if u make ur program work (remember and readable) it is much easyer to fix whatever problem that just might occur, then trying to think of things that could go wrong(and that is impossible in my mind)

If I read this correctly, you are correct. There are two issues here.

Everyone wants code that is simple, clear, and readable; I don't think that's debatable. Your code should be clean enough that when another programmer, or you in six months, look at the thing it's not a magical mystery tour. To a very large extent, good code is about clarity.

As for plugging unforeseen holes; no one is claiming clairvoyance. Rather, if there is place where user input could take the program off the "happy path" and make it crash and burn, it's up to the programmer to make sure that can't happen. This doesn't mean getting bent about everything, or cramming loads of exception handling just because you can. It's about making reasonable choices based on your understanding of the requirements.

More than anything, it's about being flexible enough to adapt to changing requirements. This is hard to understand when you're writing stuff on a small scale for yourself. However, after a client makes their "OMFG another" change request, the wisdom of this becomes pretty clear.

[Craig328]

Atli, on 10 June 2010 - 10:55 PM, said:

KidD1988, on 11 June 2010 - 04:05 AM, said:

it is much easyer to fix whatever problem that just might occur, then trying to think of things that could go wrong(and that is impossible in my mind)

Spending a few hours, or even days, "imagining" what your program will look like after a few thousand lines of code can spare you endless wasted hours re-factoring/rewriting them.

I don't know about you but it is the rare employer indeed that will tolerate any employee spending a few hours or days "imagining" anything. Real world software development simply doesn't work like that. You can't possibly imagine how stupid/lame/lazy it'd sound if your supervisor, senior dev, VP of IT or whomever walks past your office, questions why you have your hands behind your head staring blankly at the ceiling and you come back with "I'm imagining what my program will look like after a few thousand lines of code". Try that out the next chance you get and we'll all wish you well on your job search. I'm not trying to be harsh but software development as taught in schools is not the software development that tends to occur in the working world is all I'm trying to say here.

Quote

... Sadly, it seems the professional programming world prefers code-monkeys these days

To some degree, that is true. But, as I said earlier, if you're developing a system that someone somewhere else will use as a tool on a daily basis, no matter how good a developer you think you are, I can assure you that somewhere lurks a powerful force that is bent on causing your application a world of unrelenting misery. This force is better known as "users" and they are the ones that put the "idiot" in "idiot proof". What's more, the moment you think you've finally idiot proofed a particular piece of your app will be the same moment they find a more powerful and sinister idiot to prove you wrong.

The real problem is that as a developer you are at least a little educated and think with a logical, thought-progressing mind. This is your biggest hindrance. If you sit in an absolutely silent office and close your eyes, do you hear circus music playing faintly in yer skull? No? Well then, you're at a disadvantage because I can assure you, a fair chunk of your users can...and the same mind that has a soundtrack from Ringling Brothers can dream up stuff to do to your poor app that you never thought of.

So, to a certain extent, you code to cover the most obvious sources of derailment and then wait to discover the other sources that will almost certainly follow if your app is ever actually touched by users. For example, this morning as I sit here I am looking at the 4th iteration of a data import file in less than 2 weeks. This is a daily data import that my app is expected to seamlessly pick up, parse, sift and stick into a database table for consumption by other parts of my app. Thing is, it was built upon one small assumption: that the file spec that everyone agreed upon months back and that was perfectly adequate to relay all the pertinent data would remain the spec without unapproved or unannounced unilateral changes by the customer.

Oops. See if this sounds familiar:

Quote

The first data import module I wrote was quite naturally perfect. It was a work of art. Flawless. Sublime. A triumph only equaled by its monumental failure.

Software development in the real world is like that. A lot.

[JackOfAllTrades]

Quote

You make statements like "We'll cross that bridge when we get to it", or "When the call(s) come in we'll deal wit it then".

And what are you supposed to do when it's THE BOSS making these statements?

All of you pie-in-the-sky'ers would probably KILL YOURSELVES if you had to work with the code and in the environment I do. The specs generally consist of a single sentence fragment. The code is primarily C with no shortage of 1000+ line monolithic functions. In the UI we have thousands of lines of PHP and HTML, all commingled together...little-to-no OOP. Configuration information is scattered everywhere, and everything is interdependent on everything else. I do my best to refactor what I can from time-to-time within the framework of the too-short deadlines provided, but for the most part it's simply heaping hack upon hack.

But...it pays my bills and the boss understands my needs as a human being and a member of a family.

[raziel_]

what if your boss tell you: get it done by <insert date here> and we will install it to that client. he is close and we can run now and then to fix it

[Atli]

Craig328, on 11 June 2010 - 11:44 AM, said:

I don't know about you but it is the rare employer indeed that will tolerate any employee spending a few hours or days "imagining" anything.

True

But I wasn't really picturing myself sitting and staring at a ceiling while doing this. The process of "imagining" what the program will look like should involve a diagram or two, and perhaps some sort of schematic that wallpapers the offices.

Although I am hardly an expert on the practices of corporate software development. I'm more a freelance, work-at-home sort of guy. I can do all the imagining I want without anybody bothering me... given that I get enough work done to finish on time

[Craig328]

Atli, on 11 June 2010 - 05:07 AM, said:

Craig328, on 11 June 2010 - 11:44 AM, said:

I don't know about you but it is the rare employer indeed that will tolerate any employee spending a few hours or days "imagining" anything.

True

But I wasn't really picturing myself sitting and staring at a ceiling while doing this. The process of "imagining" what the program will look like should involve a diagram or two, and perhaps some sort of schematic that wallpapers the offices.

Although I am hardly an expert on the practices of corporate software development. I'm more a freelance, work-at-home sort of guy. I can do all the imagining I want without anybody bothering me... given that I get enough work done to finish on time

Ah. Then what you're actually talking about is the design phase. That I can get 100% behind. I DO spend hours and days basically whiteboarding each screen with an attendant write-up for what goes on in them and between them in an app. That part of producing an app is absolutely crucial. Once you start writing it though...it's a hindrance. My bad for the misunderstanding.

And you have my envy. I too have freelance, on-the-side projects and I used to work from home until recently. Believe me, nothing clears the mind from pesky dev roadblocks like a brisk round of Left4Dead...but I don't think I'd be pulling that same solution strategy where I work now.

[tlhIn`toq]

KidD1988, on 10 June 2010 - 09:05 PM, said:

Hi all
i vote for just making stuff work! srsly can u honestly say that u fixed a problem befor it became one ?
What i am trying to say is, if u make ur program work (remember and readable) it is much easyer to fix whatever problem that just might occur, then trying to think of things that could go wrong(and that is impossible in my mind)



What i am trying to say //lol do u guys and girls understand what i am trying to say

Do u understand the words comming out of my mouth

I'm not sure if you are trying to be funny, or not. Your name is Kidd, you write like a kid texting on a cell phone. There is clearly no actual work experience bhond your comments.

Was this meant as a joke?

[Frinavale]

PsychoCoder, on 08 June 2010 - 02:16 PM, said:

So many times I see new & young programmers make the statement

Quote

But it works and that's my main goal

I just shudder when I hear/see this comment (or something similar to it) and they just cant figure out why

I shudder when I see this statement made as well.

baavgai, on 08 June 2010 - 04:07 PM, said:

Drives me absolutely mad when a programmer says "but, no one would ever do that." There are two kinds of issues a program can have, those the programmer can anticipate and those they can't; the former being unacceptable. If the programmer understands that someone can stray from the "happy path" they are obliged to prevent that. Running under ideal conditions is simply working. The program isn't done until it runs under all conditions.

I completely agree with you Baavgai!

I wish that other people would agree with you too...

Recently I found a bug in some code that I was testing. It had to do with a method in a class that never ended. I had a lot of problems with it when I tried to stop my test and re-start the test. I also encountered some nasty crashing when I called the method twice (...which was a problem because I couldn't stop the test nicely). I figured out a way around the issue but the solution "hackish" and I didn't like it so I confronted the individual who created the method. When I showed the individual that when I ran the code twice it crashed badly they said "Why would you run it twice?" and I replied with "Because I'm testing the code"... The problem was never fixed because according to them "In the real world you wouldn't be running the method twice...you'd just call the method once and never have to stop it". I still feel dirty from working with that code (especially since I'm responsible for creating the documentation on how to use it...complete with examples).

I can't stand it when software developers do not take responsibility for their code. There is no reason for allowing known possibilities for bugs to exist, and there is no reason why you shouldn't always try to develop code to the best of your ability: with the fewest bugs and with the most efficent code.

I know that my style of programming can be greatly improved upon but I don't have the luxury having someone to show me better ways to do things. I try to read up on the best practices and read about new technologies that can help my code be faster, cleaner, more efficient.

I have no idea why someone would resist good advise on how to develop better code...but for some strange reason I have seen the "But it works and that's my main goal" come up as well.

It baffles me.

-Frinny

This post has been edited by Frinavale: 11 June 2010 - 02:01 PM