23

Whenever possible I have been requiring an understanding of the requirements and architecture for the next scope of work before starting to code.

Sometimes due to schedule pressure on larger projects I have to start coding before I know everything I need to know for that scope of work, but in that case I make it a priority to catch up as soon as possible. And if I can't get caught up on everything going into a release, then at least get caught up on what I need to know for the next few weeks.

This seems like such an obvious no brainer that I'm embarrassed to even ask it, but I've been getting pushback so I wanted a reality check. Maybe there are some downsides to understanding what you are about to do before you do it, and if so I'm hoping someone can fill me in.

Or, if what I'm doing seems like a best practice, then a simple confirmation would be appreciated.

If it makes a difference, the pushback I am receiving is on a project with a development timeline of about five months and a value to the company I am working for in the millions.

0

6 Answers 6

84

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.

4
  • 14
    I've always been a "seat of the pants" coder, and I find that I expose holes in the requirements when I'm trying to implement. But I've also never worked in an organization with highly formal specification processes.
    – Barmar
    Feb 25, 2023 at 23:43
  • this is true and i have some issues when I begin getting role of making the spec and not touching, just reading the code. I'm the kind of get dirty first to test the water then speak, now that I can only see the water from afar, there are too many things that feels like slipping through, yet I don't have the luxury of taking time to do what I used to do anymore Feb 28, 2023 at 2:01
  • case in point, current project I am working on the requirements were so broken that the implementation tooks weeks longer than expected because they kept changing constantly during development. Which sadly is common across the industry.
    – jwenting
    Feb 28, 2023 at 7:19
  • @Barmar I think exposing requirement issues, which are common, is one of the reasons agile was invented. Show the customer early stuff. Does he like what he sees in the mirror of his requirements? Feb 28, 2023 at 14:14
16

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

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.

2
  • Good answer. I founded and continue to operate a small custom coding shop since 1987 and have seen the evolution of philosophy around this subject over years. We have done applications that were a week or two and perhaps 15,000 in todays dollars to well over a million dollars. In the early days I used to write very detailed specifications and solved many problems, and answered many questions before they were coded. That said I am a coder myself not strictly a business analyst. Changes got dealt with much like building a building with architectural drawings have changes discovered. Feb 27, 2023 at 17:05
  • 2
    Now is different. Now I must have a list of goals that must be achieved to be worth doing the coding. Sometimes I call it what in the world will be different once this code is complete. We can discover how to accomplish that as we go along. After that it's prioritize the goals, work on one at a time starting with get more detail in collaboration with the client. Yes goals can sometimes change but I build confidence between myself, any in the team and the client as we move along. I have also gotten pretty good at estimating projects this way being well under 10% off even on 100k + projectts Feb 27, 2023 at 17:10
15

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.

4

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

23
  • 10
    ... and though I have some sympathy for your line of thinking here, I think the opposite of "asking for requirement" is not "not to bother with requirements at all". The opposite of asking someone else for requirements is to work out the requirements with a customer or user together - ideally by the person who implements them, or by a person who is himself dev in a small team who implements them (and not some BA who has never written a program larger than 500 lines of code).
    – Doc Brown
    Feb 25, 2023 at 18:59
  • 4
    I like this answer. What you're essentially saying is that writing good specifications is essentially a programming task. But the business people who set the requirements are not programmers, they don't know how to be precise about these things.
    – Barmar
    Feb 25, 2023 at 23:46
  • 8
    This answer is nonsensical, on its face. If there are no requirements, then my coding task is complete before I've even started. I don't have to do any work to implement nothing. So, you must mean something other than what I mean by the word "requirements", but I have no idea what that may be. Can you elaborate? A business's requirements for functionality have nothing to do with coding, directly.
    – Corrodias
    Feb 27, 2023 at 10:46
  • 1
    This is one of those answers that in my opinion simply doesn't fly for most real-world companies of any significant scale. I'm thinking security and safety software, medical or financial etc; even integrating with a third-party in any domain. You just can't get away with not bothering with requirements and architecture.
    – Zimano
    Feb 27, 2023 at 14:25
  • 4
    @Ewan This is why I asked you to elaborate on what you mean when YOU say "requirements", because In Agile (not Waterfall), "requirements" are the things that need doing. Without a requirement, there is nothing to do. If the business didn't have any requirements (or approved tech debt), we'd have no stories to work on and would effectively have the day off. "At its simplest, a requirement is a service, function or feature that a user needs." -- agilebusiness.org
    – Corrodias
    Feb 27, 2023 at 15:35
-1

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.

-1

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.

2
  • One of the issues with the Manifesto is people take it as Working Software instead of documentation. Nothing in Agile work does it say don't have ANY documentation. Same with the other three, It is not individuals and interactions and no processes. It is especially not customer collaboration instead of any contract. etc. Feb 27, 2023 at 16:58
  • I hope my answer doesn't read as "instead of". Of course the other things are not irrelevant either. I find the formulation "over" pretty clear in that. I'll add a short blurb on top to make this clearer.
    – AnoE
    Feb 28, 2023 at 8:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.