Would you refactor your app as you go or focus on completing app first? Refactoring will mean progress of app app will slow down.

Completing app will mean you get a possibly very hard to maintain app later on?

The app is a personal project. I don't really know how to answer "What drives the functionality and design", but I guess it's to solve inefficiencies in current software out there. I like minimal easy to use software too. So I am removing some features and add some that I feel will help.

  • 1
    Could you provide some additional data about your scenario? For example, is it a one-person project or are you in a team? Is it a commercial product, in-house, or open-source? What drives the functionality and design? Dec 2, 2010 at 2:04
  • @mlschechter, I am currently actually working on a personal project. Have not decided on whether I will sell (eg. on codecanyon) it or release it Open Source. I don't really know how to answer "What drives the functionality and design", but I guess its to solve inefficiencies in current software out there. I like minimal easy to use software too. So I am removing some features and add some that I feel will help
    – Jiew Meng
    Dec 2, 2010 at 4:01

11 Answers 11


Make it work. Then make it fast. Finally, make it beautiful.

If you have good separation between your code (presentation, business, and data layers) using interfaces, and it's not a monolithic design, then refactoring should not be that difficult.

If you're having that much difficulty refactoring, that's probably a code-smell -- I suggest you look at Solid Principles

  • +1 for Make it work. Then make it fast. Finally, make it beautiful. Jan 20, 2012 at 4:53
  • My point as well. Do not refactor before you make it work unless you realize that your design prevents you from completing the task.
    – Gus
    Jan 20, 2012 at 6:25
  • If you make it work by using unit test to be sure it really works, rather than just seems to do the right thing, then the structure induced by those tests will be 90% of the refactoring you'd ever want to do. Jan 20, 2012 at 8:01
  • I would rather say: Make it work, make it right, make it fast - in that order.
    – Niklas H
    Jan 20, 2012 at 9:09
  • It would rather go like: Make it work, make it fast, make it work again, make it beautiful, make it work again. If at that point you need to make it fast again, you did it wrong.
    – Florian F
    Aug 22, 2014 at 7:23

I think the essential point is to keep interfaces clean. You can always refactor or even rewrite module / class / whatever implementations later on, as long as the communication layers between them are sane. Spend some time figuring out what's easy to change later on, and what's not. Make the latter right.

This is consistent with the spirit of TDD. To write good tests, you need a good interface to test against. How messy it's behind the scenes at the moment is not that important, because you can improve it later.


I always refactor as I go, especially using TDD.

  1. Write the tests

  2. Make the tests pass

  3. Refactor

This will help you have less bugs and better code for the finished product. It will also let you have less code to maintain when you are done.


Refactor early and often! The time you "save" on not doing it is spent many times over trying to hack in the next feature and searching for bugs in overly complex or chaotic code.


Refactoring is like picking up your room.

If you keep things tidy, you have a linear overhead, proportional to the amount of productive work you're doing on the code, O(n) in algorithmologist terms. Assuming you spend 10% of your time refactoring (or keeping your room tidy), that 10% is a given, and it will remain constant over time.

If, however, you toss your dirty clothes in a corner, and keep doing it, the amount of time you are going to spend picking up your room grows as the mess becomes more complex. Assuming that each individual piece of dirty laundry contributes exponentially to the required cleanup time, you are now in an O(en) situation.

Anyone who has ever digged into the concept of algorithmic complexity will observe that there is a break-even point somewhere, that is, there is an optimal amount of dirty laundry to accumulate; how much that is depends on the constant factors that are discarded in big-O notation. Another factor is the value of your work over time: if your work is worth a lot now, but cheap next week (i.e., there is a deadline this friday for this project and three more, but after that, you'll be mostly idle), the equation might turn out in favor of not refactoring.

And then there's the complexity critical mass. At some point, the mess ('critical mess', if you will) gets so bad that it seems easier to just burn down the entire room and buy new clothes. In reality it usually isn't, but it appears that way, and psychological effects will make it ten times harder to tackle the thing.

And obviously, if you step into a project that is a giant multiply-redundant mess already, you have limited choice.

TL;DR: If in doubt, refactor. You should have really good evidence before deciding not to.


If you have the chance to add features or crush bugs to get your sales/customer satisfaction where you think it should be, do it. Once there are fewer new demands, you can balance with refactoring. At some point you have to make sure you're writing code people want. All things being equal, I'd rather throw away 100 hours of code than a 1000. Which is what you'll do if no one wants it.


Really depends on where you are at!

Other things to think about:

How certain are you, you've really got the functional design right? Could you end up re-designing again after you get some user feedback?

I'd prefer to release than rewrite. Optimize after you are sure you've nailed the functional design.


As long as you are sure you can meet deadline sure you can refactor all you want. However even if there is a bit of uncertainty better to stick with development and may be refactor only in modest incremental step.


If the bad design you want to refactor really hurts you, you better fix it now than create more code that depends on it. Refactoring later would be more difficult and more expensive; chances are you won't be able to do it anymore.

On the other hand, if your only issue is the uglyness, you might want to complete your software first, because hardly anything beats getting things done.


Refactoring will be very important as you work on completing your application.


  1. Clear Flow: Refactoring will give code clarity because sometimes if the code is little unstructured, understand the flow of the code after a period of time would become difficult and refactoring code could become an uphill task and bugs could get introduced.

  2. Improve performance: Proper refactoring of the application will definitely help improve application performance.

  3. Maintenance: Last but not the least, it would be easier to maintain on the long run.


  1. Time Consuming: It would be a lot more time consuming at every stage of your progress. So there could be a delay in completion.

Bottom Line

Depending on the project type, you can prioritize on code quality or completion whichever is demanding for the current situation.

  • What are VES and VE? Aug 18, 2014 at 12:52
  • positives and negative.
    – Florian F
    Aug 22, 2014 at 7:27

Based from my personal experience, I would usually go to finish the apps first with the condition that there is a deadline to reach. once you completed you can refactor it.

Finish it and refactor it. But if there's no deadline to be rush or time frame, I suggest refactoring it would be good.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.