Skip to main content

Code before design?

Last post 09:34 am April 10, 2018 by Thomas Owens
3 replies
10:51 pm April 9, 2018

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?

 


12:19 am April 10, 2018

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.


06:33 am April 10, 2018

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?


09:34 am April 10, 2018

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.