It may be inexperience, but in the small projects I've worked on, I've often found it super useful to completely start over. Is this unique to novices or is it a real thing?

It obviously doesn't make sense for all projects. If you have a well defined goal, organized documentation and a strong product owner, hopefully it's never even considered. But I feel most projects are more exploratory than anything. In addition to moving requirements, we are constantly learning new methodologies, patterns and "tricks".

I guess my question is this: There are many methodologies, paired, lean, etc... is there any movement for iteratively, intentionally, starting over?

closed as unclear what you're asking by enderland, scriptin, gnat, Tulains Córdova, Robert Harvey Jul 31 '17 at 1:40

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Most companies need to make money and cannot afford to rebuild their app from scratch. But I don't really know what you are asking here. – enderland Jul 28 '17 at 20:44
  • What do you mean by "iteratively ... starting over"? To me, completely starting over is the opposite from an iterative process. However, there is a technique for iteratively improving code quality. It's called refactoring. – Frank Puffer Jul 28 '17 at 21:06
  • Feature creep and entropy continually happen. I mean you develop for a month, some features stay in, some don't. You start over. You do another month, again, some things will be final, some things won't. You start over again. Iteratively starting over. – Scott Beeson Jul 28 '17 at 21:08
  • 1
    I think that if you continually find it easier to completely start over, then something about the development process or methodology is not right. The code should be written to not just work, but to also be extendable. – Thomas Carlisle Jul 28 '17 at 21:21
  • 2
    @ThomasCarlisle: "extendable" can have a bunch of different meanings, and sometimes trying to build "extensibility" is inappropriate. Any code can be extended with the right skills. The OP needs to develop those skills. – whatsisname Jul 28 '17 at 21:32

Required reading: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

With that said, for professional software development, it is rare that a complete start from scratch is ever a good idea. About the only scenario where a complete rewrite makes sense is when you need to make an ancient software, dependent on a discontinued old platform, work on modern software. Even within that scenario, a total rewrite is still unnecessary.

A complete rewrite being a good idea means that 100% of your work from before is complete garbage, with nothing worth keeping. Writing 100% complete garbage is never something you want to be doing on a regular basis.

When you do your job well, most of the real guts of the value adding parts of your work should be in reasonably modular, packaged groups: classes, libraries, whatever. Usually, much of the cruft of an initial stab of a project and source of confusion is how everything is hooked together. Replacing all that glue code, and reorganizing and refactoring your code base, can let you keep 90% of the meat and potatoes of your code, but reorganized into a more sensible project.

But I feel most projects are more exploratory than anything. In addition to moving requirements, we are constantly learning new methodologies, patterns and "tricks".

Your perceptions don't reflect the reality of the working world. Few projects are completely exploratory. I work doing R&D for medical devices, working on software to do things that have never been done before, and only a sliver of a given project is actually exploratory. The majority, like any other application, is more mundane like saving and loading data files/databases, communicating with hardware, drawing charts and making PDF reports. Someone working on a shopping cart or CRM application will have even less exploratory work to do.

New methodologies, patterns and tricks don't move as quick as some javascript bloggers might make it seem to be, and new tricks or patterns don't invalidate years of working code.

So in short, a complete rewrite is pretty much always a bad idea. Identify whats good and bad, keep the good, refactor and reorganize the bad, and keep moving towards a good product.

  • Thank you for the well thought out response. It's useful. For "mundane" things (reading/writing data, etc) you obviously wouldn't rewrite from "scratch". I suppose all my concerns can be alleviated by refactoring complex functions and doing code coverage tests (to remove unused code). Thank you again. – Scott Beeson Jul 28 '17 at 21:17

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