Should you go forward with a project if the code isn’t clean?

solidsnake asks:

I'm a beginner Web developer (one year of experience). A couple of weeks after graduating, I got offered a job to build a web application for a company whose owner is not much of a tech guy. He recruited me to avoid theft of his idea, the high cost of development charged by a service company, and to have someone young he can trust onboard to maintain the project for the long run (I came to these conclusions by myself long after being hired).

Cocky as I was back then, with a diploma in computer science, I accepted the offer thinking I can build anything. I was calling the shots. After some research I settled on PHP, and started with plain PHP, no objects, just ugly procedural code. Two months later, everything was getting messy, and it was hard to make any progress. The web application is huge. So I decided to check out an MVC framework that would make my life easier. That's where I stumbled upon the cool kid in the PHP community: Laravel. I loved it, it was easy to learn, and I started coding right away. My code looked cleaner, more organized. It looked very good.

But again the web application was huge. The company was pressuring me to deliver the first version, which they wanted to deploy, obviously, and start seeking customers.

Because Laravel was fun to work with, it made me remember why I chose this industry in the first place—something I forgot while stuck in the education system.

So I started working on small projects at night, reading about methodologies and best practice. I revisited OOP, moved on to object-oriented design and analysis, and read Uncle Bob's book Clean Code.

This helped me realize that I really knew nothing. I did not know how to build software the right way. But at this point it was too late, and now I'm almost done. My code is not clean at all, just spaghetti code, and it's a real pain to fix a bug. All the logic is in the controllers and there is little object-oriented design.

I'm having this persistent thought that I have to rewrite the whole project. However, I can't do it. They keep asking when is it going to be all done. I cannot imagine this code deployed on a server. Plus I still know nothing about code efficiency and the web application's performance.

On one hand, the company is waiting for the product and cannot wait anymore. On the other hand I can't see myself going any further with the actual code. I could finish up, wrap it up and deploy, but god only knows what might happen when people start using it.

What do you think I should do?

See the full, original question and all answers here.

Don't rewrite the code

Joeri Sebrechts answers (194 votes):

You have stumbled on the Achilles heel of most CS educations: they teach you the tools and techniques, but not the trade. Building software is a craft, one which you only acquire through years of practice and the experience of having your software used (users are much harsher critics than teachers). Building software is also quite often a business, one where the business goals may override the technical ambitions.

First of all, ship. If you show the business owner the software, and they feel it's ready to ship, then ship. If it's not to that point, but close, finish it. The only software that matters is that which is actually used. The only software business that earns money is one that has a product.

Secondly, you have learned a lot of valuable things, so you should appreciate the experience for  what it has taught you:

1. Slinging code without a plan or architecture is a recipe for disaster.
2. There is much more to programming than writing code.
3. Non-technical business owners often do not understand the impact of technical decisions (like who to hire), and it is up to the developers to explain things to them.
4. Most problems are already solved much better than you would solve them, in existing frameworks. It pays to know the frameworks that exist and when to use them.
5. People fresh out of school assigned to a big project with little guidance tend to produce a bowl of spaghetti code. This is normal.

Here is some more advice for you on how to proceed:

1. Communicate, communicate, communicate. You must be very open and frank about the state of the project and your ideas on how to proceed, even if you're unsure and see multiple paths. This leaves the business owner the choice on what to do. If you keep knowledge to yourself, you deprive them of choices.
2. Resist the temptation of the full rewrite. While you are rewriting, the business has no product. Also, a rewrite rarely turns out as good as you imagined it. Instead choose an architecture and migrate the codebase to it gradually. Even a horrible codebase can be salvaged this way. Read books about refactoring to help you along.
3. Learn about automated testing and unit testing. You have to build up confidence in the code, and the way to do that is to cover it with automated tests. This goes hand-in-hand with refactoring. As long as you don't have the tests, test manually and comprehensively (try to break your code, because your users will do so). Log all the bugs you find so you can prioritize and fix them (you won't have time to fix all bugs, no software ships bug-free in the real world).
4. Learn about how to deploy a web application and keep it running. The book Web Operations: Keeping the Data On Time is a good start.

Related: "How to convince my boss that quality code is a good thing to have?"

Maintain the mess

Jan Hudec answers (49 votes):

Whenever you start from scratch, you'll almost certainly make the same amount of mistakes or more due to the Second System Syndrome. Your new mistakes will be different mistakes, but there will be similar time required for debugging, and similar despair about how your framework isn't a good fit for the project. Starting over will also delay deployment into production or deployment of new features if the first version is deployed, which will be serious trouble for the company. Joel Spolsky calls rewriting from scratch the "single worst strategic mistake" that any company or developer can make.

The recommended approach is instead to clean the initial mess bit by bit during maintenance. And don't even try to refactor it just for the sake of it. Besides, managers usually see that as a waste of money (which it often is); it brings the unnecessary risk of introducing new bugs. Once you painfully debugged the code, it may not be pretty, but it will work. So let it be until you need to touch it for other reasons (be it a bug fix, new feature or just a change requested by marketing). Clean up the parts that are most difficult to adjust. This is often called the Boy Scout Rule.

And one more bit of recommended reading: the Big Ball of Mud.

Finish the job

Patrick Collins answers (21 votes):

I forget where I first read it, but I just wanted to echo, somewhat more forcefully, what other people have said:

Shipping is a feature.

There is nothing worse than that one guy who keeps "cleaning up" existing (possibly hacky, ugly, dirty) code that works perfectly well, introducing new bugs, etc. What matters in the real world is getting your job done. You've done that. Ship. Don't get lost in redesigns of a project that works perfectly well, even if it's ugly under the hood. When you fix it, do so incrementally, and make yourself a good test suite so that you have as few regressions as possible.

Find more answers or leave your own answer at the original post. See more Q&A like this at Programmers, a question and answer site for professional programmers interested in conceptual questions about software development. If you've got your own programming problem that requires a solution, log in to Programmers and ask a question (it's free).