How important is it to clearly understand requirements and architecture before starting to code? [closed]

I've seen people dive straight into the code, make bad assumptions and spend ages writing the wrong thing.

On the other hand, I've seen people spend weeks "understanding requirements", drawing pretty architecture diagrams and whatever else - only to discover when they actually got round to coding that there was a fundamental problem they'd missed and would have found much earlier if they started writing code.

Or in other words: everything is a balance. One of the critical skills of a senior developer is working out where to set that balance for a particular piece of work. For some pieces of work, the risk is in the requirements and you should spend more time on those. For other pieces of work, the risk is in the implementation and you should spend more time coding. There are no simple answers, sorry.

There is a large field of study devoted to this.  See for example:

• https://en.wikipedia.org/wiki/Category:Software_project_management
• https://en.wikipedia.org/wiki/Agile_software_development
• https://en.wikipedia.org/wiki/Iterative_and_incremental_development
• https://en.wikipedia.org/wiki/Waterfall_model

Fundamentally, complete requirements may not be knowable until there is an implementation for users to use, to study, to give feedback.  For this reason and others, in almost any software project, requirements shift over time to meet the needs of users and the market being addressed.

So there's reasons you cannot necessarily know complete requirements ahead of time — in part there are chicken-n-egg problems, and in part because we cannot foresee how new markets develop.

So, the best wisdom we have seems to be around coding to current known (and prioritized) requirements without wasting time architecting & coding features anticipated but not actually requested and/or prioritized — as those may very well disappear in the future, in favor of something different.

Still, there are many differing opinions about how to go about this, and, there are plenty of competing and rather formalized or at least well-documented processes to choose from or adapt, and lots of stories around (un)successful project developments due to the issues of fluidity along with (good or bad) choices of development process for the given situation (i.e. goal/project, team involved, company, etc..).

Keywords are refactoring, technical debt, incremental vs. waterfall.  (Note that simplified waterfall is sometimes thought of as a capture of a proposal at the extreme that no one in fact can actually follow because of feedback issues from one part of the development process to another.)

Let me add that I have found re-architecing when fuzzy requirements become clear is not as difficult as it may seem, since knowing what code to write is harder than writing it.

The most important thing is knowing when to stop.

Gather requirements. Do architecture design. Stop when it's not teaching you anything. I think of them like making popcorn. When it's making ideas pop it's great. Soon as that stops knock it off and get back to work.

If you're only doing it because your supposed to do it you're wasting time.

I swear to god I've sat in meetings where the coder used a UML diagram from a different project having only changed the names of the classes (with windows paint no less). Most brilliant thing I've ever seen. I hate when good tools get turned into pointless ceremony by people who only care about checked boxes.

I hate these wishy washy "it depends" answers. Here's my answer: Don't bother with requirements and architecture.

Why?

Requirements

• You are just pushing back the coding problems to the person who has to write the requirements.

  This is fine for something like the space shuttle or some specialist field where some scientist is going to know exactly what your software should do, but 99% of the time in business people don't know the requirements. They just have an idea of what kind of thing they want to get. They can't think through the detailed combinations of features etc. Asking for requirements just delays things.

Architecture

• There are only so many architectures you can use for a project and the reasons to pick a given one often boil down to "what infrastructure do we have already"

  Just use the same architecture as all your other projects unless you know it won't work for some reason.

Finally

People like progress. They like to see stuff working and then make changes rather than think ahead. They want you to make the hard problems go away before they have to think about them. Just make it like facebook but better godammit!!

Extreme Programming (XP) calls what I think you're describing a spike, and the term has proliferated around to a degree. If for example:

• the customer changes their mind about what the UI flow should look like every time you ask them
• you are dependent on some exact behaviour of an external system that is not documented
• you need to get an idea of how computationally intensive a process is in practice to be able to provision an environment for it

...or any number of other eventualities where it is necessary to discover something by writing code, that could be called a spike. It sounds as though your workplace isn't inclined to adopt the broader philosophy of XP, but writing code to find answers to unanswered questions in the design process when nobody else can offer those answers through other means ought to be perfectly defensible.

This answer is to be seen in the context of the question, i.e. when having the need to do something, but simply not being able to procure req's and architectural decisions in time. I.e., when developers are sitting around twiddling thumbs. The contrasting 4 bullet points say "over", not "instead of"; the parts on the right-hand side are still valid, but there is a priority.

Agile development has an opinion about that. In fact, the 4 core tenets of the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

For your question this means: Working software is the most important objective you should have when developing software (for some definition of "working" which may include aspects like security or performance in addition to the actual features). Every other artifact (i.e. preliminary architectures living just in the form of documents) is of secondary importance.

The issues stemming from missing requirements or architectures are handled by being about to quickly respond to changes. This is a second hallmark of agile development.

While this may sound fuzzy, it is very concrete. A good development approach is styled such that from the very get-go, you are able to achieve bullet point 2 and 4 with relative ease. Granted, this is a catch-22 in some part since a good architecture is somewhat of a prerequisite to be able to respond to changes well, but then there are also ready-made "meta-architectures" like the The Twelve Factor App, which can readily be used as guidelines of how to approach things if you don't have a particular hand-crafted architecture yet; or to be more concrete, most modern programming environments come with opinions or defaults for good architecture (i.e., Spring Boot, Ruby on Rails etc.).

So, for a fresh application, you can do worse than pick some existing agile process (e.g., Scrum, Kanban etc.), take a quick reminder glance over the 12-factor app, grab a modern programming environment focused on the kind of app you want to create, and start coding. Your main goal is to get the app out to users ASAP (via the concept of the Minimum Viable Product), to gather feedback, and start the loop of continuously extending and fixing your app.

You will quickly see where your randomly picked architecture went wrong, and as you don't have a codebase of decades yet, it should be relatively easy to refactor or start individual parts from scratch after a very short time.