When building a non-trivial application, is it best to focus on getting things working quickly, and taking shortcuts in the code like mixing model logic with your views, breaking encapsulation - typical code smells? Or, are you better off taking the time upfront to build more architecture, build it right, but running the risk that all this extra code might not be used since your design is quite fluid and you might have to throw it away if feedback causes you to go in a different direction?For context, I'm building a desktop application. I'm the only developer, and I'm doing this part-time since I have a day job. Now, for work, I try to do things the right way, schedule permitting. But for this project, which I expect will morph as I get feedback from people, I'm not sure that's the right approach. I spent several hours this week putting in a textbook Model View Controller design in place to communicate changes in the model to the view. This is great in general, but I'm not sure if I need multiple views to display the data and I know that I could have had things displayed more quickly without the additional architecture. With maybe 10-15 hours a week to spend on the project, I feel it will take ages to get something built that I can demo if I follow good software practices. I know that my users won't care that I used MVC internally, they just want something that solve their problem. But I've also been in the situation where you've incurred so much technical debt from short cuts that the code is just incredibly difficult to maintain and add new features to. I'd love to hear how other people approach this kind of problem.
Software Design: Build it fast or build it well?
design;architecture;quality
Build it well.Building it fast is a logical fallacy if you look at the big picture.  It will prevent you from ever having it built well, and eventually you will become bogged down by bugs and fundamental architecture flaws that prevent refactoring or even makes adding new features next to impossible.Building it well is actually the opposite.  At first it may be slower, but eventually you will realize the efficiency gains from having taken the time to make the right choices up front.  In addition, you will be able to adapt to future requirements easier (refactoring if needed) and you will have a better end-product due, at the very least, to fewer bugs.In other words (unless this is a one-and-done contract), built it fast = build it slow, build it well = build it fast.Also there is something important to realize about building it well and designing an architecture. You asked......but running the risk that all this extra code might not be used since your design is quite fluid and you might have to throw it away if feedback causes you to go in a different direction?That is not really a true risk from spending architecture time.  Architecture design should be organic. Don't spend time designing an architecture for any part until it's justified.  Architecture should only evolve out of observed and confirmed patterns in your project.John Gall's law from Systemantics:A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.