I've been working as an app developer for a year and a half now (not long I know), and I've just been given my first big project.

Needless to say it didn't go very smoothly, so I sought advice from a senior programmer involved in the project about how to approach it. 

He said that I had drastically been over thinking the task at hand, and that because I had never tackled a project of this scale before I'd been spending too much time over thinking design patterns. In his wise words, he told me "F*ck the future, build for now".

Is this a trend programmers typically follow when going about a project like this? For example, if you were asked to do a proof of concept model, is it a typical trend just to mash a workable example out as soon as possible?  

Edit: In light of the debate this has sparked, I'd like to mention that this situation is fairly extreme: we have very tight deadlines due to factors beyond our control (i.e. the market we're aiming for will lose interest if we don't show them something) and his advice proved to be very effective for this particular task.

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 be developed for now. Be sure to have straight requirements, and relate to them as needed to know what's needed and what's not. Don't want to spend too much time on anything that's "nice to have." But don't 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 you're building 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.

Guidelines

I'd say adhere to the following principles as best as you can, and you should put yourself in the position of designing efficient, adaptable products:


know that YAGNI,
KISS,
whenever you feel like scratching an itch and think of an addition, write it down. Look back at your project requirements and ask yourself if additions are priorities or not. Ask if they add primary business value or not. 


I know that I personally tend to overthink and overengineer. It really helps to write ideas down and very often re-think if I need additional features. Often, the answer is no, or, "it would be cool later." Those last ideas are dangerous, because they stay in the back of my head, 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 extended later. You can't predict the future.

Just build simple things.

Dilemmata

Overengineering


  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 don't, that's more worrying. There is disagreement about whether or not less is always truly more and if worse is always truly better. You may be a MIT or New Jersey kind of guy. There is no easy answer here.

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 a prevalent practice, but it's not how the vast majority of projects are approached. Still, prototyping is a good trend in my opinion, but one with a mean downside. It can be tempting to promote quick and dirty prototypes to actual products, or to use them as the base for actual products under management pressure or time constraints. That's when prototyping can come 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 are hints as to 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.


And if you have a green monster around, just make sure to keep a prototype within budget...


