[Moshambi]

I am guilty for messy code sometimes, but those are usually my own projects, and I just want to see it in action and then clean it up.

But most of the time I even start on paper before I code. That way when I sit down at the computer my thoughts don't get disorganized and confused by the editor in front of me.

Clean efficient code...FTW!

I am guilty for messy code sometimes, but those are usually my own projects, and I just want to see it in action and then clean it up.

But most of the time I even start on paper before I code. That way when I sit down at the computer my thoughts don't get disorganized and confused by the editor in front of me.

Clean efficient code...FTW!

[coden4fun]

Good code that exectues and is extensible. Write it good and clean, and write it fast, or stay up all night writing it. Either way both needs to be done. I would also like to add in that we should TDD our code either with Unit Testing, NUnit, Nhibernate? I only use Unit Testing so the rest I'm not as familiar with as I should be, but this speeds up the process of writing good clean code that is extensible.

[Amadeus]

SixOfEleven, on 8 Jan, 2010 - 04:09 PM, said:

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."

I'd suggest this has nothing to do with programming, but a work ethic in general. Developers have no more a responsibility to write good code than painters have to paint well. The vocation does not define one's approach to quality...one's internal motivations do. If you have that drive inside that pushes you to do the best job possible, it does not matter if you are a programmer, project manager, or busboy. Quality will win out.

[NickDMax]

I am a consultant -- which normally means that I need to work fast and cheap. While I try my best to make the code I produce with as much quality as I can -- the truth is, schedules are pretty unforgiving.

To my knowledge I have never produced BAD code... but I have been very disappointed with having to make do with rushed code.

As an example, on one project I was working on we had a "new requirement" that for contractual purposes was not new (it was always in the spec. but exactly HOW it was to be implemented was not) -- we asked for a weekend to better refactor our code to fit the new requirement -- we were denied and reminded that if we missed the deadline there were penalties. So we made it work as-is but the solution was ugly. In the end it turned out that there would have been nothing lost by giving us the time (turns out all of the teams needed extra time to integrate these changes) -- but some blow-hard PM was just so sure that pushing the project schedule was their job.

Basically -- I don't have a great deal of control over the deadlines. So generally if I CAN meet a deadline, then I generally have to... The thinking is that if something goes wrong later we can write and "update". The get-it-done-now-fix-it-later mentality.

This is why I like working with a good PM -- good PMs listen, sure they push back sometimes, but they listen and when developers ask for a weekend they make it happen.

[Delta_Echo]

From my understanding quick-and-dirty is scripting languages are for.

[Raynes]

Do both. Use technologies that allow you to do both.

[Astraeus]

Even as a student I like to take time to make my codes good and solid. But then again I get 2 weeks to make a simple class so that doesn't exactly count..

But I imagine in the working - world it's no different, it's important to create good code that will work and is able to be modified, used and understood easily. I mean what would happen if a defense contractor rushed code for something that can be dangerous if it malfunctions, or Microsoft with Windows, or thousands of other electronics we use on a daily basis? We'd have a lot of unhappy people in the long run.

[Dogstopper]

Delta_Echo, on 9 Jan, 2010 - 06:44 PM, said:

From my understanding quick-and-dirty is scripting languages are for.

For things like bash scripting, sure, but for languages like Python, whiting good code is what it's for! I also heard that Ruby is another language similar that also demands for well written code.

[Programmist]

A few years ago I would have said "Duh, of course you always write solid code up front." Since then, however, I've had the opportunity to work on several agile projects and I've seen the benefits of what we called "throw-away code." I soon learned that I did not coin the term and that XP (extreme programming) uses the term "spike solutions" for the same concept. As weird as it may sound to the uninitiated, it is actually very useful in certain situations, especially where the use case is a little fuzzy (to everyone, including the SME) or the problem is tough to solve (from a design or technical perspective).

Edit: Here's a link.

This post has been edited by Programmist: 09 January 2010 - 09:32 PM

[cmh0114]

I'm still a student, and I like to take some pride in my programming, so I like it to be able to work for any applicable situation, not just the one on paper. So, I prefer to write good, solid code, but I could understand that if someone just wants a code that will work once or twice for a certain range of variable values, I can understand just having throwaway code, especially if it won't be used for something very valuable. Or, given time restraints when people won't cooperate, I can understand just writing throwaway code and then fixing it later. It's not preferable, but it's not horrible, either.

[blackpowder.fred]

So it seems that people feel there is a place for fast, ugly code, and a place for solid code. I agree, and though I'm just a student, I've used quick, sloppy code to help me understand a concept or idea. However, when I have to write a program for a grade, writing good code helps me to master the subject matter and prepares me for tests. We're given plenty of time to write programs for classes, though, and I haven't been forced into a situation where I need to write something very quickly.

[demosthenes2k8]

I prefer to write good quality code, but I typically get it done quickly-I make my own projects because I finish the school assignments too quickly.
With my own major project, I like to take my time and make sure that it'll work, even before I compile.

I agree that there are uses for quick and dirty code, and that it's sometimes required if you have a time crunch, but I frown upon it.

@Astraeus: It's called Vista. (xD)

[Vermiculus]

Bill Gates once said that measuring a program's progress in development by lines of code is similar to measuring the construction of a lightweight airplane by pounds of material used.

Get the code working first, and don't forget to comment; then go back to optimize.
This is significantly easier when the program is encapsulated, and optimization will go by much faster.

[NickDMax]

Take a look at Douglas Crockford's talk on Quality... I find the part about incrementalism (about -20.10) to be kind of poignant.

[nathanpc]

First make it work, then you tune up, that's how I do the things most of the time