[PsychoCoder]

Let's have a discussion here. 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. Well here's why:

There are always two ways of doing something:

• Get it working
  
• Get it working the right way

Most anyone with any programming knowledge at all can get software to work when the happy path is present. And so many students today and perfectly fine with that kind of mentality.

I think any instructor, or employer for that matter, has a serious problem on their hands if they let that kind of mentality exist. What are they going to do when reality hits, i.e; no happy path, and the software they're so proud of pukes all over the user. If there's one things I've learned in my years in this industry it that if something can be broken an end user will find it, and employ it so fast it will make your head spin.

One thing I always tell new programmers is to think like an end user. Get your software working the right way not just get it working. So many students are in such a hurry to have a social life that they just care if it works long enough to be tested, bad answer.

If you want to make it in this industry you need to learn from the start to think long and hard about how an end user can break what you've worked so hard to create. Don't settle for what I call Happy Path Programming, strive for better from yourself. Strive to create software that is as bullet proof as possible. I know it's really impossible to get it 100% fool-proof (because society is always turning our better & better fools), but it pays off in the long run to strive for it.

I seen that statement today on Dream.In.Code, they said

Quote

But it works this way and that's all that matters

They were fine with catching (or throwing an exception) when the happy path fails. Exceptions cost a lot of overhead, and if you know something can happen if the user enters ABC instead of DEF why not take the time to account for that beforehand? Is it worth the performance hit for a shortcut?

Discuss...

[RedSon]

Here is the problem...

When I was in school they taught "program defensively" and when you turned in homework they would test your code with both garbage and good data.

The problem is that when the real world hits the new software developer is driven by time schedules and quarterly projections and marking timetables and executive bonuses. The first thing to take a hit is the robust programming that we all expect our programs to have but never get a chance to write ourselves. That is why support contracts and "sustaining engineering" are so lucrative for companies to be involved in. You may end up with a shit code base, but at least it will take you years of slow paced engineering to get the work done. That's 3 extra years of revenue for your company, fixing problems other programmers have created!

When you n00bs get out of college, you will want to write good code. You will want to spend the time to design and analyse it. Maybe write a few prototype apps or proofs of concept to get it down first. And if you can do this then DO IT! If your job lets you, then take the time to do it!!! But most cases you will be asked to implement something with a vague spec, on a tight schedule, with no design time, that is then handed off to a QA person who logs a few bugs that you will fix in *version 2* (whenever that is). The point is, don't lose sight of the dream, but if you want to keep your job, be wary of the tradeoffs.

Boy, that sounded a little bitter... oh well.

[JackOfAllTrades]

I have worked for seven years in a job where it's all about "get it working" and "refactoring" is frowned upon. That's not bitter at all

[dragon-slayer]

very Interesting, It got me thinking. It explains why a lot of open-source and free software suck compared to commercial software. Programmers tend to program open source software on the "happy-path" which is why a lot of open source software is not user friendly while commercial software gives programmers and incentive to "do it right". Am I right or wrong?

[PsychoCoder]

I do honestly understand deadlines and time lines, I've been at this a long time. But that's not what this is about, it's about errors that would have taken a simple if statement to check for a null value (Never assume something cannot happen, as soon as you do it will happen), or a case statement checking for a certain value. It takes all of 5 extra minutes.

I've seen error message from applications that are along the lines of

Quote

You will never see this because it cant happen

There's no sense in that ever happening in my opinion. It's bad practice and bad coding plain and simple

[RedSon]

dragon-slayer, on 08 June 2010 - 01:35 PM, said:

very Interesting, It got me thinking. It explains why a lot of open-source and free software suck compared to commercial software. Programmers tend to program open source software on the "happy-path" which is why a lot of open source software is not user friendly while commercial software gives programmers and incentive to "do it right". Am I right or wrong?

Actually I would say 100% wrong on that (unless you forgot the sarcasm tags). It is proven that open-source projects are (often) more robust and more feature rich then their commercial counterparts. The problem is that FOSS needs a certain critical mass of adopters and developers to make it into something great. But FOSS is not pinned down by the need to follow a schedule or meet deadlines or make payroll.

PsychoCoder, on 08 June 2010 - 01:39 PM, said:

I do honestly understand deadlines and time lines, I've been at this a long time. But that's not what this is about, it's about errors that would have taken a simple if statement to check for a null value (Never assume something cannot happen, as soon as you do it will happen), or a case statement checking for a certain value. It takes all of 5 extra minutes.

I've seen error message from applications that are along the lines of

Quote

You will never see this because it cant happen

There's no sense in that ever happening in my opinion. It's bad practice and bad coding plain and simple

Okay, granted. It's unreasonable to blame all lack of robust code on time lines. If you can add to the stability of your code by spending an extra 5-10min on it to check return values or add an "else" even if you think never in a million years will your if statement be false; then you should take that.

10 min here, is going to save you hours later.

This post has been edited by RedSon: 08 June 2010 - 03:43 PM

[tlhIn`toq]

Range checking... real world qualification... various environments... Its a lot.
People sometimes forget that not every PC starts from the C: drive. It is possible to have a boot drive be F:, but experience teaches you that, not college. So newbies don't mind hard coding a path of "C:\blah\blah".

Not every country uses a period for the decimal. Many use a comma. "1.000.000" is a million. That plays havoc with parsing routines that make the assumption of a period instead of taking the time to get the globalization decimal separator from the OS/framework.

What if the real world environment isn't perfect like it is in the lab? They don't teach that you might have to retry for 30 seconds before giving up on a network file write. Or lack of permissions.. or... or... or the 3rd party vendor's SDK isn't robust so *it* throws an unexpected error because (like you) they didn't have enough time to fully qualify all the possible problems.

I made the directory, so it must be there... So they don't check if it exists after they make it... and the routine fails because they didn't have permission to make directories.

"RIGHT" means your employer being willing to allocate 10 times the development period/budget, and 3 times the QC.
"RIGHT" means you have the experience to look for things that can go wrong.

Personally, I look at every user as someone who INTENDS to find a way to break my software. If I tell them to enter a number, they will type "ten".
So I program defensively by trying to limit the user input to only acceptable values. Don't give them a textbox: Give them a numericUpDown with acceptable limits. Don't let them type in a path (because they will frak it up), but make them browse to it.

This is my generic copy/paste response to a lot of users when I see they have no qualification or problem anticipation in their code:

I can make some general suggestions that apply to good coding practice.

• Assume that everything is broken, or at least not ideal.
  
• Presume that the user is going to provide data in a format or manner that you just didn't expect. If you use a textbox for a number, the user will type "One".
  
• Assume that hardware breaks in the middle of what you are doing, so you have to recover.
  
• Take a few extra lines of code to get standards like the boot drive, the number thousands seperator etc. Don't assume that you have a C: drive or that a comma is the separator because not everyone is in America.
  
• Check that files/folders exist, even if you just did a call to make it: You may not have permissions.
  
• Don't assume the harddrive has room for what you are doing: They do fill up. Usually right in the middle of you writing to your log file.
  
• Get used to placing breakpoints and walking through the code line by line. Double check EVERYTHING on every line. Keep the "Locals" and "Autos" windows open so you can see your values.
  
  • Put a breakpoint on the first line of the method causing trouble.
    
  • When the code stops there, walk through line by line with F-10.
    
  • Check the values of your assumptions (looking at the Locals and Automatic variable windows as well as hovering the mouse over the variables in the code (hothelp will popup).
  
  
• Stop. Breath. Relax. Then reason out the problem. Cut it down by sections or halves. "The value was good here, then at this method it wasn't. Where did it go between 'A' and 'B'?"
  
• Range check and validate values. Confirm that you didn't get a zero when you are only set to accept 1-10. Confirm your objects and values aren't null. Initialize them to a known default if possible. If a selection can be from 0-10, then initialize to -1: Now you have something to check for.

Example:

Graphics g = Graphics.FromImage(m_Undo);

Presumes that m_Undo must be good (not null)(actually exists)(not in use)(you have permissions)(doesn't time out when accessed). If that assumption fails so does the program, because you can't make anything from a file if the file is null. Get used to validating data and assumptions in your code if you want it to be robust. For example:

if (m_Undo != null)
{
   bool bSuccess = false;
   // Do your thing here, for example:
   if (myObject != null) bSuccess = true;
   // or
   if (denominator > 0) bSuccess = true;
   // or
   if (MyFunctionReturn != Failed) bSuccess = true;
   // Hurray, your thing worked!

   if (bSuccess)
   {
      // Then do this other thing if it worked
   }
   else
   {
      // Then do the failure recovery part / user failure message
   }

   return bSuccess; // If you want the calling method to know if it worked.
}

[m-e-g-a-z]

Theres the difference in meeting the deadline and doing it the crap way. If you have got crap code then obviously, you are not going to get amazing grades. I have seen people drop alot of points at uni due do messyness, bad indentation, complicated things which they dont need and extra things such as variables which they have created but never use. I know people that code really messy and they have got into the habit of that and say 'well it works'. Having messy code, you are most likely to loose track and end up with generating errors in some cases because everything just looks hard to read whilst writing.

I once remember seeing 70 if statements mastermind game, where it could of easily been done using for loops and they said 'oh well, it works'.

Its good to get into the habbit of writing good code rather than compiling code because it will become a 'good habit'. There are times where employers want to see code you have written during interviews. I recently went to a job interview and they asked for sample code and to briefly explain it. Now imagine if your 'that person' who gets code working, wouldn't make a good impression would it?.

[baavgai]

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.

The purely "goal" oriented programmers are the least of us. They take no pride in their work, trying only to get done and call it a day. A real programmer can't consciously let broken code stay that way. It's like a crookedly hung painting, nagging to be put right.

While there are surely programming sociopaths, I think most programmers avoid fixing problems they perceive out of fear. They've struggled to get this far, it finally "works", and they're afraid of doing anything to mess with what they see as the fragile state of good enough. Yes, mucking with code can break it, probably will; so what? You'll never learn more than when you take your own work away from running, break it down, and bring it back improved.

There is a dichotomy of to how individuals approach projects. It's often expressed as process oriented versus goal/results oriented. The goal oriented are the "eyes on the prize" group, wishing the release of project completion. The process oriented get distracted, or engrossed, in the elements that are required to the complete the project. Both groups get to the end, but the process group tends to enjoy the trip more and learn more from it. All the good programmers I know are process oriented.

The process oriented meme has been around for a while, most often being evoked in business and sports, rather than computers. Probably because computer folks don't need any explanation of how to be process oriented. I couldn't find anything definitive, but this was pretty good: Being "Process Focused vs. Results Focused"

Btw, I totally love "happy path". It's now a permanent part of my lexicon, right up there with Cargo Cult Programming.

[alias120]

Very interesting read everybody. I will say that I have been guilty of the "it just works" mentality. When I first began programming, I would attempt to work my way through problems that I did not fully understand. What I did not do was conduct the necessary research to understand the problem in full. So I would eventually get the program "working", but it would be flawed. I am still learning, and I still occasionally jump into coding without performing the research I should. It does takes practice, and a dedication to your program that you will do all you can to try and deliver a good/complete product. The community here at DIC is great about helping us new programmers with that. Keep it up everybody.

-alias

[baavgai]

dragon-slayer, on 08 June 2010 - 04:35 PM, said:

Programmers tend to program open source software on the "happy-path"

Quite the opposite. Open source programmers are proud of their code. They enjoy writing it enough to do it for free and aren't ashamed for others to see it. As a result, they often only do the "fun" parts. A programmer doesn't want to do documentation, they merely recognize the necessity. Also, they lack a project manager with a threatening pink slip.

dragon-slayer, on 08 June 2010 - 04:35 PM, said:

a lot of open source software is not user friendly while commercial software gives programmers and incentive to "do it right".

Most programmers are more concerned with solving the problems of the project rather than putting together yet another UI. ( I make my junior programmers do all the UI elements, it's trivial but required work. )

In contrast, commercial programmers can hide their shame, if they're so inclined. The user isn't privy to the code quality; they can only see the facade of the UI.

dragon-slayer, on 08 June 2010 - 04:35 PM, said:

Am I right or wrong?

Wrong. Sorry.

[Raynes]

I'm a young programmer, so maybe my input might we helpful.

I personally get absolutely no satisfaction out of creating something that "just works". If I don't think I have done a good job, and people tell me I haven't done a good job, I'll rewrite it, or throw it away completely. I don't want that kind of thing on my back. I don't want to be a coder; I want to be a good coder.

[red_4900]

I know most of my friends do this. I do this too most of the time. I don't know about others, but when faced with time constraints, I usually can't think properly and all I want is to get it to work. It is after the deadline that I usually try to get it to work the right way. Although I'll get no extra points as it is already past the deadline.

I'm interested about this : define 'the right way'. For example, if you know that performance is not an issue at all, why bother for all the performance hit?

There was a time when doing my school project, I delegated all my stuff to 3, 4 function and some of it is recursive function. While my friend accomplished the same task using one function consists of one single, complex mathematical function. I know his code works better(from algorithm point of view) but mine has a better readability. Facing with such trade-off, how do you know which is the right way of doing things?

[baavgai]

red_4900, on 09 June 2010 - 02:18 AM, said:

Facing with such trade-off, how do you know which is the right way of doing things?

If I wanted the fastest code possible, I'd write machine code... Every abstraction that a programmer, or programming language, introduces is overhead. The very nature of OO is to favor abstraction.

Optimization, like specialization in nature, allows a program to take the most advantage of a very specific set of circumstances. Conversely, when those circumstances change, over specialized code may be rendered useless. Programmers learn to balance optimization with maintainability, which is sometimes called refactoring.

If a program isn't flexible enough to allow for modification, it's wrong. Code correctness must include maintainability. This does take more effort up front, but pays off dramatically when the first change request is made.

[raziel_]

as an young programmer i rly try avoiding fixed paths or what ever fixed things you can think of (rs232 ports etc.) in my programs. but then again there is the dead line that force me some time to just write a ton of useless code just to get the job done. and i find no point of doing so. even if i manage to be in the dead line the time i spend supporting after releasing some idiotic creation is equal (probably even more) then to just do it right. of course bugs will always exist only god don`t make mistakes.

This post has been edited by NoBrain: 09 June 2010 - 06:11 AM