[SixOfEleven]

There have been a lot of topics in the C# forum like this one where the OP was asking about initializing variables. I thought that it would be a good debate on if we, as programmers, should right good, solid code from the start or if we should just get the job done quickly and move on to the next problem. In my opinion you should write good, solid code that will preform as the user of the code would expect, that would be very easy to read and understand 6 months down the line (maybe even documented but we won't go into that can of worms) and follow good programming principles to reduce the possibilities of those "undocumented features" that we as users of software are so found of.

What are your thoughts on this?

[FlashM]

I always go for a good, solid and understandable code. And I always follow the rule: simpler code is always a better.

[plasma-hand]

I always ask whether the employer want it done fast and cheap, or done slower and more efficient,with a higher cost.

That sentence sounded like I was a prostitute

[DuoShin85]

I support writing solid code the first time around. There is a lot less hassle working with solid code than instant spaghetti code when you or some other developer performs maintenance down the line.

Don't get me wrong. I like spaghetti but only for dinner.

[Adkins]

Without a doubt I go for the good solid code. You will make up the time and more down the line when you or someone else starts doing maintenance. Quick cheap code is only a benefit in the here and now, but hopefully any software that is made will stay around past that.

[KeyboardKowboy]

There's a paradigm in software development where you draw a triangle, and at each of the three points of the triangle you have a different result. The three points are GOOD, FAST, CHEAP. You only get to pick two.

So far instance, if you pick GOOD and FAST, your product will not be CHEAP.
If you pick FAST and CHEAP, your product will not be GOOD.
Etc...

Writing code quickly, without fully analyzing the problem or trying to future proof, although solving the problem for the time being, will come back to bite you should you need to make modifications or additions later on. Often fixing one problem, breaks another area of your system.

Take the time to write robust and efficient code, start creating templates that can be reused to save time in the future. You will be more than happy when you revisit the project and realize you can easily do what you need to.

I always try to follow the Three Tier Architecture. Data Access Layer -> Business Layer -> Presentation Layer.
Remember that high cohesion and low coupling will undoubtedly save you time and frustration.

[PsychoCoder]

Whenever I an negotiation with a client for a job the first thing I let them know is that it may take me a little bit longer than other developers he's negotiation with simply because I refuse to take shortcuts and take the time to ensure it right, efficient and extensible the first time, and that it's not even an option to :"ust get it to work".

I inform them right upfront that there are 2 ways of writing code

• Just make it work
  
• Make it work and be efficient and extensible

When I explain it that way they normally understand why I do it the way I do, and why my bids are normally a little higher than most they receive. I have yet to lost a bid for it being higher once I explain why and how I work.

EDIT: I featured this (good conversation piece) and am moving it to Corner Cubical so all programmers, regardless of language, can chime in with their thoughts on the topic

[Core]

Donald Knuth said:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Write code that works first, then optimize. With experience, the code you write becomes better and eventually you will reach the level of experience when the initial code is very efficient and there is little or no need to optimize.

[NeoTifa]

I do both, but I focus on the quality of my work. I am known around the building for having my work done the fastest and most satisfactory, but if I had to choose, it'd be quality over speed.

[BenignDesign]

I hate spitting out 8 tons of crap code because someone wants something done tomorrow. It only ends up costing more time and money in the long run. I would much rather take a little longer and create something simple, functional and easily maintainable than rush a project to a temporary state of completion.

[milleja46]

You know all this is great to talk about. I know some people like neotifa might think i want to get things done fast. But the simple fact is it I know I CAN'T! Take one of my friends for example, it took him at least 4 months to learn c++ then even longer to put it to use and develop something. He recently uploaded a video of something he did with c++ and allegro, and it took awhile to do. You are one lucky person if it does not take you that long. You may know the language, but you don't know the language fully. You know what the code does but you may not be able to piece it together to a fully functional program, or webpage. So take your time. That's all i have to say here, and sorry if it offended but i think that is the cold hard truth.

This post has been edited by milleja46: 08 January 2010 - 01:25 PM

[aceofspades686]

I personally hate having to rush projects, but sometimes it has to be done unfortunately to keep a client. Far too many people want software written but have no idea of the process that goes into it, and seem to think its just "flipping some switches in the right order."

Typically, if I get one of these rush projects, I warn people of what they're asking upfront, and I typically charge a sizable markup.

[erik.price]

Since almost all the code I write is for my own benefit, and not for school assignments or a job, I tend to take my time on it.

However, sometimes, I won't care about the end result at all, and will just hack something ugly together quickly.

[SixOfEleven]

As developers, we have a responsibility to write good code that will preform the way the end user of that code will expect. I believe that is something that we should stive for. I'm fond of the saying, "Just because you can do something with code doesn't mean that you should."

[Theaegd]

I say just take your time. Think about every line of code before writing it. Think about how that line will go with the one before and after. Do the same with your code blocks, and clases, and so on. Great, powerful, fully functional code is the key.