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.

Guidelines

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,
• KISS,
• 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.

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 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...:

Do programmers typically build something that works now without thinking about the future?

Yes.

Should they do so?

No.

At a first glance it would seem that "thinking about the future" violates established design principles like KISS and YAGNI, which claim that there shouldn't be implemented anything that isn't required right now.

But actually it doesn't. Thinking about the future means designing simple, extensible and manageable software. This is especially important for long-term projects. New features will be required with time, and having a solid design will make it easier to add new pieces.

Even if you aren't going to work on a project after you complete it, you should still develop it intelligently. Its your work, and you should do it well, at least in order not to forget how good work is done.

Agile developers have a saying, "You Aren't Gonna Need it (YAGNI)" which encourages that you design for what you need now rather than what you think you might need in the future. To extend a design to work in the future, the recommended route is to refactor.

The important aspect to this is to keep the requirements for your product in your mind as you design, and to ensure that you are not designing for a bunch of requirements that might happen in the future.

There is something to be said for developers who can think two or three iterations ahead - they know their clients or the domain so well that they can anticipate future needs with high degrees of accuracy and build for them, but if you're not sure, it's best not to spend too much time on things that you or the clients don't need.

Is this a trend programmers typically follow when going about a project like this?

I suspect what your mentor meant was that you shouldn't build in any additional complexity that may not be required by the final solution.

It is all too easy to think that an app should do this and that and get massively sidetracked.

As for design patterns, it is worth remembering that they're a means to an end. If you find with experience that a certain design pattern doesn't fit despite your earlier hunch, then this could indicate a code smell.

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?

It is worth getting a steer before the project starts as to what milestones there are and whether they'll want to see a bit of everything (vertical slice) or just each part in detail as you develop it (horizontal slice). As part of the initial design, I find it worth story boarding the whole app so even though the code isn't written you can do a helicopter view of the whole thing or a deep dive of a given area.

Design is usually open-ended so it is way too easy to apply too much or too little of it. And you will know the correct amount only after the project is done or discarded. Or even not then.

There's no general recipe for success, but you can learn to recognize extremes. Complete design of everything up front hardly ever works beyond trivial stuff. It's okay to leave components for refining and just have a feeling that it can be done, or there's a way to discover problems early.

You may look up how incremental development works if you're not familiar. Successful methods usually are iterative on one or more levels, seek tight feedback and grow on some skeleton.

He said that I had drastically been over thinking the task at hand, and that because I had never tackled a large project like this 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".

I think that's a bit of a cowboy mentality from the other developer. The modern day's version of a tough nerd who just "does it now". It's become a popular theme among startups and no thanks to people at Facebook for starting the phrase "getting it done is better than doing it right".

It's appealing. It's encouraging and offers visions of developers standing around a console clapping their hands as they launch their big project into the world on time, on budget and all because they did not over engineer anything.

It's an idealistic fantasy and life doesn't work this way.

A fool will rush into a project thinking he can just "do it" and get it done. Success will favor the developer who prepares for the unseen challenges, and treats his profession like fine craftsmanship.

Any senior developer can criticize, condemn and complain - and most do!

While he/she tells you that you are "over thinking" the project. I congratulate you on actually "thinking" first. You have taken your first steps in being a better developer then the other guy.

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?

That's exactly what a proof of concept is. It's an attempt to mash something out as quickly as possible so that people can take a step back and look at it. It's done to prevent mistakes, misdirection and wasted time/money.

There are many different kinds of proof of concepts. You can build something that is thrown away in the garbage when done, or you can build something that represents a starting point for the project. That all depends upon what you need, and how close the concept is to the final product.

It's also an opportunity to demonstrate your ideas. There have been times when I've presented a prototype that took things to a level they didn't expect.

Show me your code and I will tell you who you are

Your code is your visit card. If you write messy code, what tell you about yourself to the other people? Just think of that. Every time we find in office a really bad fragment of code, we ask ourselves, who have written it and how on hell was he passed through the university?

You are becoming what you code

Your code is your program for life.

A programmer writing bad code is like a ballet dancer dancing in striptease club

Some people don't care dancing in striptease club. But if they are tallented dancers, they are wasting their skills. If you are poor dancer but have nice legs, you can strip for many.

Finally, you should read Gogol's novelle 'The Portrait', and you should be warned by the story of the main character. You friend is similar to the man from the portrait. He is luring you with money, but you'll pay the high price for it.