Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've made a poorly written, yet fully functioning website, in (shock, horror, shock) PHP. Everything works as expected, I've implemented the necessary security measures: and

It's poorly written in the sense that it's a bunch of functions thrown together that do something...oddly enough I was consistent with the naming conventions.

Would you release something you were not happy with, but worked?

I would also like to point out that I don't collect much user information (username, email and password) is about it -- but it's not really the security part I'm worried about, it's the spaghetti code I've written.


migration rejected from Sep 16 '13 at 20:19

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by gnat, GlenH7, MichaelT, Kilian Foth, ChrisF Sep 16 '13 at 20:19

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Not really a good question. But here's mine: do you sleep well, knowing you did that? – Linus Kleen Jan 8 '11 at 18:15
Voting to migrate to programmers.SE - no need to do anything, the question will move there automatically if five users cast the vote. – Pekka 웃 Jan 8 '11 at 18:15
Wow,...I didn't even know there was programmers, so what exactly is the difference then? – eddienotizzard Jan 8 '11 at 18:18
@Phoenix Should link the permalink so future visitors of this question understand what you're talking about. – mririgo Jan 8 '11 at 18:18
What does relasing mean in your context? Do start to sell said software right away, or do you "release" it as open source project or something where it's gonna get incrementally improved anyway? – mario Jan 8 '11 at 19:11

Of course. If you wrote software with the purpose of running it, and it runs - you should release it. You can start fixing it after that. Refactoring is part of software evolution.

Also, if you completely happy with the code you wrote and it is longer than a dozen of lines - you are missing something. Everything can be improved given infinite time.


Do you imagine how many websites are there, used daily by hundreds of thousands of people who don't care that the website they use is poorly written?

Even better, do you imagine how many websites are there, not only poorly written, but also unsecured, unusable, but still used by many people?

Your website is functional and works well? So release it. An end user doesn't care about the quality of your code. If the website doesn't crash every minute, doesn't make the user feel stupid or uncomfortable, or doesn't suck too much, there is nothing to worry about.

If have to worry about in several cases, which doesn't seem yours:

  • When the website was done for your customer, and you were payed for it. A customer may not be able to make a difference between a high quality code which works and a code that suck but works, but if one day this customer asks some other developers what they think about the code you made, you have strong chances to lose this customer forever.

  • When you seriously intend:

    • to enlarge, promote and modify the website. If half of daily visitors ask for a feature, and you cannot implement it, because it requires to rewrite the whole source code correctly, well, there will be a problem.

    • to share or sell your source code. In a first case, your reputation may be affected if other developers see a very low quality code. In a second case, the buyers will expect some quality, and will be disappointed.

    • to invite somebody to work with you on the source code to enhance the website.

Last advice: don't try to make things perfect. Release first, then do it. By releasing a website, you will receive feedback sooner. It means that you will be able to implement some modifications according to this feedback sooner too. Thus, the quality of your next version of the website will be higher.

Agreed, a well coded feature no one wants is just practice. – JeffO Jan 8 '11 at 23:25

If it works, it's not broken.

Release it, every time a projects completes, you realize the improvements that could have been done. It does not mean that you don't release a lesser sophisticated working software. Embrace incremental improvement instead of build, scrap, rebuild.


If it's stable and does what it is supposed to, then release. Sooner is better.

However - apply extra effort to make sure your data model is well structured, consistent and long-term ready.

It's usually easy to change and republish the software part, but restructuring of the data model with the living precious data already in it is often a huge pain. Normally you don't want to change it, only extend it. In that regard make sure your data scheme is good enough now before you launch.

Another thing that applies to web products is the SEO and stability of your urls. It's probably even harder to have to redesign your site links and desperately wait for months until Google recovers your previously earned page ranks.

So, two things matter:

  1. Stable and future-ready data model
  2. Stable, consistent and future-oriented route concept

If you think you got 1 and 2 right -> go!


It's your call whether you should run with it or not. But understand a couple things.

  1. Yours would not be the only bad software out there. There are a lot of nasty apps that work. And if you throw in corporate IT apps from the non-shrink-wrap world, you can multiply that number by about a million.
  2. Good and bad are subjective terms. Your standards of good may be way higher or lower than someone else's. So it's tough to know where on the spectrum of software quality an app is without multiple opinions or a reliable metric.
  3. Code quality doesn't matter. There's a StackOverflow podcast somewhere where Jeff and Joel talk about that. For those of us that live in the code and recognize that code does have to adapt to new business rules over time, yes, the quality of construction, and especially of design, matters. But to project managers, bosses, clients using your software and everyone else, code quality doesn't matter (unless it's an issue of user interface, reliability or performance [and even then only the users would care, not the bosses or project managers]). That is why there is such a huge disparity between developer and non-developer perceptions of the effort involved in making truly good software.

We just implemented SugarCRM for a project... but we found out "in time" that it is a (sugar coated) piece of sh1t and now we are catching up with a custom implementation.

Lesson here is: if it gives you time to catch up without messing your relation with your client, do it, but strive for plan B ASAP.


Are you planning on charging a fee? If so you need to decide if you can reasonably fix soon to be discovered bugs without your users wanting a refund. Until you release it, you won't know if anyone wants to use it so what good is clean code going to do beside boost your ego?

Your secret is safe with us ;)


I've been in the web development field since 1998, and I can count on one hand the number of things I've released that I HAVE been entirely happy with.