Captain Obvious to the Rescue!
I'll be Captain Obvious here and say that there's some middle ground to be found.
You do want to build for the future and avoid locking yourself into a technological choice or a bad design. But you don't want to spend 3 months designing something that should be simple, or adding extension points for a quick and dirty app that will have a 2 year lifespan and is unlikely to have follow-up projects.
It's difficult to find the distinction, because you can't always predict the success of your product and if you'll need to extend it later.
Build for Now if...
- the project is going to get scrapped,
- the project has a short life-span,
- the project should not have extensions,
- the project doesn't have a risk impact value (mostly in terms of image).
In general, in-house projects or something built for a customer should developed by being more on the side of what your colleague said. Be sure to have straight requirements, and relate to them as needed to know what's needed and what's not. Anything that's a "nice to have" you don't want to spend too much time on. It doesn't mean you should code like a pig either.
Leave the General Problem for later, if it may ever be necessary and worth the effort:
Build for the Future if...
- the project will be public,
- the project is a component to be reused,
- the project is a stepping stone for other projects,
- the project will have follow-up projects or service releases with enhancements.
If it's for something public, or that's going to be reused in other projects, then you've got a much higher probability that a bad design will come back to haunt you, so you should pay more attention to that. But it's not always guaranteed.
I'd say adhere to the following and go from there as best as you can, and you should be in the position of designing products that aren't eating at your resources and time but still are relatively adaptable without requiring major rewords:
- know that YAGNI,
- whenever you feel like scratching a itch and think of an addition, write it down, and look back at your requirements (you should have some, even large guidelines for a small project) and ask yourself if these are priorities or not, and add primary business value or not.
I know that I personally tend to overthink and overengineer things, and it really helps me to write things down and very often re-think if I need that feature I think about. Often, the answer is no or "it would be cool later". Those last ones are dangerous, because I keep thinking about them, and I need to force myself not to plan for them.
The best way to code without overengineering and without blocking yourself for later is to focus on a good minimal design. Break things down nicely as components that you can later extend, but without thinking already about how they may be extend later. You can't predict the future.
Just build simple things.
Is this a trend programmers typically follow when going about a project like this?
Hell yeah. It's a known dilemma, and it only shows that you care about the product if you face it (or maybe that you're bored and that your mind wanders). If you don't, that worries me more.
Don't worry, it's an age-old debate, which has other ramifications. The one where you believe in the Right Way / Right Thing wonder if less is always truly more and if worse is always truly better, and if you are a MIT or New Jersey kind of guy.
Prototyping / Quick-n-Dirty / Less is More
Is it a typical trend just to mash a workable example out as soon as possible?
It's kind of a trend, but not how the vast majority or projects are approached. But this is a good trend in my opinion. However, it's got a mean downside to it.
Is it common to churn out quick and dirty prototypes? Yup. Unfortunately, it's also a trend to promote quick and dirty prototypes to actual products or to use them as the base for actual products under some pressure of some kind (management, time, money, bla bla bla). Just be careful with that and to put your foot down if someone wants to do this. That's when a prototype comes back to haunt you.
There are obvious advantages to prototyping, but also a lot of potential for misuse and abuse (many the exact inverse of the previously listed advantages as an outcome).
When to Use Prototyping?
There's also some hints on the best types of projects to use prototyping:
[...] prototyping is most beneficial in systems that will have many interactions with the users.
[...] prototyping is very effective in the analysis and design of on-line systems, especially for transaction processing, where the use of screen dialogs is much more in evidence. The greater the interaction between the computer and the user, the greater the benefit [...]
"One of the most productive uses of rapid prototyping to date has been as a tool for iterative user requirements engineering and human-computer interface design."
On the other hand:
Systems with little user interaction, such as batch processing or systems that mostly do calculations, benefit little from prototyping. Sometimes, the coding needed to perform the system functions may be too intensive and the potential gains that prototyping could provide are too small.
Ah and if you have a green monster around, just make sure to keep it within your budget...: