This Q&A is part of a weekly series of posts highlighting common questions encountered by technophiles and answered by users at Stack Exchange, a free, community-powered network of 100+ Q&A sites.

user1454517 asks:

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 because I had never tackled a project of this scale before I'd been spending too much time overthinking 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?

See the full, original question here.

Planning in moderation

JeffO answers (50 votes):

When you start out programming, everything is a proof of concept even if it is just to yourself. There are cases when an idea requires something quick and dirty or a prototype because time is a key factor. The massive fear among developers is stakeholders thinking the little app is ready for production or you should be able add features at the same rate forever. You work on a large project and find out this isn't the case.

Large projects usually have more complex requirements, so there is a temptation to try and implement complex designs. You'll spend a lot of time reading, researching and trying to implement them. This can become a big time waster, but it is all part of learning and gaining experience. Knowing when to use a particular design is difficult and usually comes with experience. I tried "that" on "this" project and it didn't work but now I see it should work over "here."

You have to plan and plan a lot, but don't do it all at once. It definitely doesn't have to be done all at the beginning. I'd rather see someone create their first large project like this:

Design and discuss a little bit. Write a bunch of code that does something. Recognize the problems and STOP coding. Get serious about design and stop worrying about losing momentum or your code-mojo and ignore the project manager (You're doing him/her a favor.). Get the project under control. Fix your messes. Make sure everyone understands the plan. Keep the project under control.

Sometimes you hit one of those features that really makes you concerned on how to implement it in the existing codebase. This is not the time to "just make it work." I had a boss who said, "Sometimes you have to grab a stool instead of a hammer." He told me this after he caught me "thinking" at my desk. Unlike a lot of bosses, he didn't assume I was goofing-off and made sure I understood he wanted me to do more of it. Genius.

Ultimately, your code is the design. It is supported by documents, diagrams, meetings, email, whiteboard discussions, SO questions, arguments, cussing, fits of rage and quiet chats over coffee. There is a point where you can't design any more and risk having to throw more design time away because of the flaws you will only discover trying to write the code. Also, the more code you write the better chance you will introduce a design flaw that you can't code your way out of. Time for the stool again.

Related: "Should I plan ahead, or figure out programs as I'm writing them?"

F*ck building for now, the future is important

superM answers (18 votes):

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. It's your work, and you should do it well, at least in order not to forget how good work is done.

Leave the cowboys behind

Mathew Foscarini answers (2 votes):

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 "overthinking" 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.

The middle ground is best

haylem answers (62 votes):

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 whether 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 you need 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.

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

Find more answers or leave your own at the original post. See more Q&A like this at Programmers, a question and answer site for professional programmers interested in conceptual questions about software development. If you've got your own programming problem that requires a solution, login to Programmers and ask a question (it's free).

