If anyone is looking for some rep and wants to take a shot at it:

http://superuser.com/questions/53962...alid-command-n

Ah **** me. I said I'm done. Sorry

Good programmers tend to prioritize things well - if he thinks I'll fix it later, there are probably good reasons - there are more important things to do, currently unknown factors may have bearing on the correct fix, the entire bit may be a throwaway eventually due to changes elsewhere, etc, etc. Bad programmers think in terms of rigid rules and managing their own comfort level (whether it's I don't want to change what's working, it feels risky regardless of the future ramifications of not fixing or I hate having to fix other people's code or my own code months after I wrote it so I should fix it now, regardless of how many more important things I have to do now) their judgments are likely to be suspect either way.

Oddly, I think the "must fix everything now" mindset is driven by the same sort of fear that drives "don't change anything that works" mindset. Fear of your own (organization's) incompetence.

Edit: Of course, this doesn't mean the fear is unfounded. This is the same reason that "no debt" policy is useful for some people. But just as it's better to get your mind in order so that you can be trusted with debt, than to live with "no debt" rule as a crutch, it's also better to become a better programmer/software organization so that such extremist mindsets are unnecessary.

It's not imaginary. I've seen (and written) code for sites/applications that have become torturous to maintain and it's not because of making a few really naive choices.

It's accumulating a million extremely tiny "meh, fix it later... easy" choices because they never get re-written until it's such a mess that you have to reboot the whole project.

It's such a beneficial and significant decision to make it right from the beginning with only a TINY bit more effort (maybe 10% more time up front total, but that's going to save SO much time while maintaining the project) that it baffles me that people who disagree are even employed or willingly write code like that because they think it's good.

It's the exact opposite really. Maintenance require changes. It's best to put some effort up front to make that aspect of the project a lot less time consuming and flexible. I refactor and try to fix problems as that occur, not before I code.

What level of complexity are we talking about here? Like what complex custom functionalities do these sites implement in the first place?

Any time you hear this, you assume either whoever created the mess is lazy and/or incompetent or the current maintainer is lazy and/or incompetent. The latter is slightly more likely, assuming they are different. Much bigger messes have been cleaned up. Also, million little easy choices do not doom a project. There must be a certain structure to it that's difficult to refactor. Even then, there's always a way around it. If you assume away extreme incompetence, the only other reasons to throw away and start are dependency on a framework/design that cannot be salvaged for some reason (external dependency, obsolescence, violation of fundamental assumptions) or what you have is trivial and commoditized that you're not throwing away much.

This makes no sense. Why are fixes cheaper earlier than later in the cycle? This is entirely situational - a lot of fixes are much cheaper later. A lot of fixes cannot even be properly designed until later. Say, you have some common pattern, but not enough to correctly design an abstraction - if you try to fix this too early, the design of your abstraction may be too specific that it may have to be thrown away or too general that you may have wasted a lot of effort.

Why does this have to happen at a particular point in time? What's so torturous about doing this a couple cycles later?

Perhaps could be a problem with character encoding? Try opening up the file in a text editor and converting to UTF8 without BOM, then doing it.

Edit: Make sure you back the file up before trying this, it's probably not the right way to do it

Actually, I think it may be encoding. Check this out:
http://postgresql.1045698.n5.nabble....td1907861.html

Here's how to convert a DB from SQL_ASCII to utf8:
http://stackoverflow.com/a/5091083/1091949

If that works let me know and I'll post an answer on superuser.

TINY! 10%! Total! SO!



I mean, its hard to take anyone seriously that makes generic claims like this about all software development projects.

@candybar,

Level of complexity is on par with something like basecamp + highrise but way less user friendly and feature rich.

It's a lot easier to spend 3 minutes to refactor something when you think it would be beneficial to do so rather than wait until you have 750x 3 minute things to do. At this point laziness does kick in for almost anyone, and it's not just being lazy but you get the "fk it" attitude.

Who said anything about making changes and fixes later in the cycle? Products obviously evolve and change over time. How can you possibly think it's easier to maintain a code full of poor decisions?

It sounds like it was largely commoditized? Technology available for building these types of websites has gotten dramatically better over the years, so unless you had lots of domain-specific special sauce, it's likely that the code base wouldn't be worth much. I don't know what this has to do with avoiding lots of 3-minute refactoring opportunities. If you have a valuable code base, you can't afford to throw it away and start over. We took a system originally built in the 90's in Access and VB and continously improved it over the last 10+ years into a modern SaaS (latest version being built in AngularJS based on RESTful API) while never at one point replacing more than a small portion of the code base. And a lot of the code was painfully bad, as in goto/global-variables everywhere bad. Why? Because we had working software and behind it tons of valuable domain-specific logic that no one understood all that well.

3-minute refactoring is your strawman. Anything that takes 3-minutes to do isn't really refactoring and is unlikely to matter that much. And anyone who sees this as a streamlined process (refactoring, auto-replace, etc) is going to do the wrong thing often enough to make it a net negative. There are tons of examples, but I'd already pointed out one - if you don't distinguish between incidental repetition and meaningful repetition, your refactoring makes the code less flexible by making it too tightly coupled.

When a good programmer does something that looks like you could refactor in 3 minutes and he doesn't, it's unlikely that he's too lazy to spend 3 minutes - it's much more likely that he doesn't think your 3-minute solution improves the code and thinks he needs either more time or more information to decide how to improve the code base. Unrefactored code is preferable to poorly refactored code.

And repetition just doesn't cost that much either way - it's straightforward to refactor. You don't see this often as a result of laziness because it takes longer to repeat yourself many times - repetition out of control is usually a sign of incompetence and in some cases lack of taste. And a much more likely example of lazily written code may involve someone stuffing features/functionalities in a class/module/function where they don't really belong, and over time the class/module/function becoming a global kitchensink with no clear meaning. Here, the problem isn't repetition - the problem is that the programmer should've either designed abstractions cleanly or not used abstraction at all (if he simply repeated himself all over, it would be easy to clean up) but instead he's three-minute-refactored what should've taken more thought and consideration.

This is what's being discussed. You and clowntable are saying, everything must be done now, just about everyone else is saying, well sometimes you can fix it later. It seems to me that you don't trust yourself to fix something later.

Anytime you're thinking abstractly about code quality without regard to concrete engineering goals, you're making a poor decision. This is why I'm saying that your philosophy results in worse code base - because your code base will evolve to solve non-existent problems, while ignoring actual engineering and business problems (which you must take time away from to solve your non-existent problems). I also don't get the sense that you have a good feel for what makes for a good code base. Here are some useful articles:

http://en.wikipedia.org/wiki/Couplin...er_programming)

http://www.joelonsoftware.com/articl...000000069.html

I stopped reading after your 2nd paragraph. If that's the case, let's just use in line CSS everywhere and not package/namespace our code all. We should probably copy/paste repeated things too, because functions seem stupid.

You then missed this paragraph (refactored for your consideration):

\r = repetition
\a = and
\t = that
\y = you
\d = don't
\s = some
\h = the
\i = time
\p = problem
\o = should
\k = take
\f = function
\b = abstraction
\e = here
\m = more
\c = class
\u = module
\v = refactor

The point here, btw, is that repetition that's otherwise easily fixed is legitimately a big problem with your code base that limits its scalability, you don't have a code-base problem; you have a talent problem. I made this point before you did - replacing specific cases with a general case isn't part of some magical refactoring process, but fundamentally all that we do as software developers. Comments like above make it sound like you just learned functional/procedural abstraction a few months ago and think it's a new big thing that others haven't caught on to. We create these abstractions because they make us more productive, not because they only cost 3 minutes, while resulting in a better code base or something. If you can't use them to save you time, then you're doing it wrong and missing the entire point of abstraction.

I just spend an hour debugging a problem caused because somebody used a magic string in the code instead of using the constant declared at the top of the file.

Perfect example of a ****ing 1 minute refactoring that would have saved me an hour (and not at all an example of a refactoring I would skip).

I was thinking along the encoding problem. I think the issue is that the Vista machine is NOT in UTF-8. I had a ton of encoding problems when I was rebuilding the database last month, diving into the raw .csv files and removing all sorts of junk to make it work. Basically, I had to resave everything as UTF-8 to make it work, but their Excel program insta-switches everything over the ASCII, I think. That was my first exposure to Windows cross-pollination and encoding issues. Not fun.

The interesting thing was that the spreadsheets exported from their system would import just fine into PostgreSQL with no issues at all even after opening the file with Excel, so I assumed that as long as the data is kept internal, everything would be fine.

Regardless, I was looking through the .backup file and it is in UTF-8, and I'm about 99% certain that the database at the office is in UTF-8, so I'm not sure why there would be an encoding error at this time. The .backup file they are trying to use never touched my computer, so I can't imagine what is happening. I'll check tomorrow and see if the encoding is correct. I'm trying to do all of this over the phone. It would be 100% easy if it wasn't for every recovery attempt screwing up.

I think the answer you gave is plenty fine and I at least know some new directions to try. Worst comes to worst, I'll just have to go in for an hour and straighten the mess out.

In regards to the current discussion about never writing bad code: this is one situation where I had to rebuild a database, rewrite quite a bit of code, and then write hooks to bring it all together. I had 4 days to complete it and people were constantly asking if I was done yet. Unfortunately, I was not able to protect the data completely in this short time. Turns out they managed to screw it up the first time they used it. Really was a dumb thing: "Does it matter if I upload Three months of Sales again?" I know everyone will ask why I didn't use unique constraints, and I'll only direct the fault to the idiots that built the company's database.

So, never right bad code? Bull****.

daveT,

Yeah man, tbh I really don't have much experience with PostgreSQL. For better or worse, I'm comfortable with MySQL so that's what I default to. But, since I work almost entirely on a Windows 7 laptop, I've run into those encoding issues before, and seeing an error message about a \N null character shot up a red flag.

If you do have to work on a Windows machine for coding, and you happen to use Notepad++ (highly recommend), you can click "Encoding" at the top and select "UTF8 without BOM" to automatically save everything in that format. That definitely has made my life much easier.

Cool, I'm going to convert it to UTF-8 without BOM. I read that a few places and I didn't know what that meant.

I suspected it was an encoding issue as well, but I didn't want to mention that, but the \N was def. a red flag.

irt to MySQL -vs- PostgreSQL, I don't think the differences go too far afield except in more esoteric issues, but yeah, not my territory to talk about that either.

I'll convert it tonight and send in a new file to the place tomorrow.

Thanks.

It didn't work. I seriously think it is because the machine is not in UTF-8 and the database is in UTF-8. I just got off the phone and stepped through how to make it UTF-8 without BOM and it turns out the file was already encoded as such. To say the least, my heart sank when I heard that.

Guess I'll just have to go in and fix it with my bare hands.

Check out:

http://openacs.org/forums/message-vi...sage_id=148479

http://forums.devshed.com/postgresql...-n-429554.html

I'm just going to copy-paste into a text file, write a quick loop in Python to add in insert statements, save it as a SQL file, then send it over. That is quick, dirty, and totally non-cool, but keeping with the spirit of saying **** it and not wanting to waste time with bugs...

I think you're answers are really good and are all definitely "correct" in the parameters of the posted question. You can post an answer with those links and how to do the w/o BOM and I'll select it, since it it most certainly correct in most instances. I think the real issue is the Vista machine is doing something to the encoding and I'm not interested in trying to dissect the problem any more.

definitely when i think of not wasting time with bugs, i think of this process:

I have to admit that this is not my proudest moment.

"So, daveT, tell me about a time that you were faced with a bug and how you solved it?"

-->> Well... er... uh... I used a bunch of print statements?

I'm doing this remotely...

My usual method in situations like this it to take both and drop whichever one is shaping up to be less useful. I took this approach in actual college too.

david,

tbf, just last month i professionally performed a database migration from sqlite to mysql with the mysql command line tool and vim.

IN MY DEFENSE,

1. it was just one table, the schema was simple, and it turns out the sqlite dump format is mostly like mysql's -- something about `begin begin`, double quotes, and backslashes.

2. i discovered that the real answer is to use sqlfairy, but given #1 i didn't think it was worth setting up a whole goddamn perl stack. perl, i will always you, but it's 2013 and your children have outpaced you and i have work to do. let's hook up in another 10-20 years, Giving Tree style.

2a. the sqlfairy logo is aMAzing:

[IMG]http://sqlfairy.****************/images/logo.jpg[/IMG]

(they even sell t-shirts, but what i really want is light blue with the pink logo but on the site the image transparency is wrong so i'm worried it would be a big black rectangle on the shirty, which is obv ridic. anyone know if that's something cafepress would sort out in production?)

You can't* print using PNG / JPG files. You have to use vector art, so if all else fails, you can grab a screen shot of the fairy off their homepage, convert it to vector, and take it to a local t-shirt screen printer who can do it for you.

It looks like the cafe press shirts are heat transfer which totally sucks, but I suspect they are doing that because the color of the t-shirt will show through the white fairly legs. You can, of course, find a local printer who will be willing to cut the transfer so it is shaped, assuming cafe press won't do it.

*you can, but no...