Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Would you refactor your app as you go or focus on completing app 1st. 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?

share|improve this question
    
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? –  mlschechter Dec 2 '10 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 '10 at 4:01

11 Answers 11

up vote 15 down vote accepted

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

share|improve this answer
    
+1 for Make it work. Then make it fast. Finally, make it beautiful. –  Karthik Sreenivasan Jan 20 '12 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 '12 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. –  Michael Anderson Jan 20 '12 at 8:01
    
I would rather say: Make it work, make it right, make it fast - in that order. –  Niklas H Jan 20 '12 at 9:09

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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

+VES

  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.

-VE

  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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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