Releasing poorly written software

Question

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: http://php.net/manual/en/security.php and phpsec.org/projects/guide/

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.

Answer 1

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

If by "release" you mean "start operating" - why, of course! As they say, shipping is a feature.

As time progresses, you will probably want to rework parts of the code because updates and new developments are cumbersome to implement. Maybe you want to start another branch of the project, in which you rewrite things from scratch. But if you have a mature site that needs to get running, and you have taken care of security concerns (which should always be top priority), of course launch it first.

If by "release" you mean "release as an Open Source Project" - hmm, maybe not. Well structured code is one of the key necessities for a FLOSS project to succeed and thrive. Countless badly written projects have been released to the public, of course - and many have become very popular. But future generations of programmers are likely to curse your name if you do this.

Answer 2

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.

Answer 3

As a programmer, I often find myself wanting to recode every piece of code I previously wrote.

I once found an article explaining this phenomenon. Apparently it's because it is easier to write code than to re-read it. When you are coding you have the sense that what you are doing is perfect, but when you come back and look at it you often think it's not that great.

To answer your question though, I would start using the current code (if it works good) and slowly refactor it section by section.

You might also want to write unit tests as it will help you make sure the code you refactored still works as expected.

Answer 4

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.

Answer 5

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.

Answer 6

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!

Answer 7

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.

Answer 8

Yes! As long as it pass the testing stage you can rewrite/work of your techinal debt in later releases.

Answer 9

It depends on my time frame. If I need to pump out a project very quickly, often times I will release it with code I wouldn't feel comfortable with another PHP professional looking at. However, I will always make an effort to go back and clean and improve it in pieces later on.

So, to answer your question: Yes, I would release to meet deadlines but that would not mean I wouldn't improve the code later.

Answer 10

Sometimes you have to release something, otherwise your users will lynch you. The answer to your question is refactoring and unit test (PHPUnit?). It will take time, but eventually your code will be less spaghetti like.

Answer 11

You can release if it works and then work on your code to make it more efficient for next version.

Answer 12

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.

Answer 13

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 ;)

Answer 14

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.