Code before design?
https://medium.com/@JonHall_/weve-been-getting-devops-vs-itil-wrong-ab6…;
(I still have the textbooks from my 1990s university Computing course. These twenty-year-old tomes admonish the experimenting “hacker” and urge the systems analyst to complete comprehensive designs before a line of code is written, as if building software was perhaps equivalent to constructing a suspension bridge).
In agile development methodology, would someone start writing the code before the architectural design had been completed?
Architectural design is when needed. The minimum needed to complete the requirements for the selected items in an iteration needs to be designed by the Development Team. As learnings or new requirements come out the architectural design will evolve/be adapted to answer the needs.
The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product increment.
My understanding of this sentence from the Scrum Guide is: start with what you know now, keep your focus on what is being worked on and adapt if needed as new needs come out.
In agile development methodology, would someone start writing the code before the architectural design had been completed?
Might writing code during architectural development help to validate the work being done and any assumptions being made?
First, what is "architectural design"? A while back, a similar question was asked on the Software Engineering Stack Exchange and I wrote a pretty detailed answer. There are a lot of definitions and takes on what it is, but I tend to favor the definition commonly associated with the Rational Unified Process:
An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition.
Some of these decisions need to be made before you start writing a lot of code. For example: Is your product going to be a web-based system or a locally run desktop system? What types of separations of responsibilities or layering will the system be designed in (MVC vs MVVM, for example)? What programming languages and frameworks will you be using? Of course, in some of these, writing some code may help to validate what you are doing is correct. However, eventually, you need to make that architectural decision and move forward to allow you to write code.
I believe that concepts from Lean Software Development come to play. Specifically, "empower the team" to make decisions based on their combined knowledge and experience. Process frameworks, such as Scrum, that build cross-functional teams ensure that the team has or is working toward building the knowledge internally to make decisions. However, the team should "decide as late as possible" to gain as much expertise and information as possible before walking down a road that is incredibly hard to walk back.
The hard part is when you make a decision that ends up being wrong. Fortunately, with process frameworks like Scrum that have frequent iterations, you will hopefully realize this quickly and be able to adapt and begin to migrate to a new architecture as your system evolves. There are a number of options to help incrementally change the architecture of a system if one proves to be unsuitable over time.