benjaoming/tinytechbureau.com
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity

Clarify some differences co-realization vs rapid development

Browse source
This commit is contained in:
Benjamin Bach 2024-07-09 19:35:36 +02:00
parent f7ec046bc5
commit 485b831ea6
No known key found for this signature in database
GPG key ID: 486F0D69C845416E
1 changed files with 6 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
content/_index.md
View file

@ -118,6 +118,8 @@ One of the reasons for minimizing a tech stack or being fairly skeptic about tec
Sharing contexts means to take part in the world of users and other stakeholders.
There are several reasons why it makes sense for developers and designers to share as much context as possible with other stakeholders, especially users. Firstly, it makes developers able to become designers and make more qualified proposals. But secondly, it also helps to prioritize in harmony.
Co-realizing is also said to grow the "design space". This means that by *directly* sharing technical understanding with users and vice-versa sharing user experience with the developer, everyone's understanding and ability to generate relevant ideas grows.
</div>
</div>
@ -133,9 +135,11 @@ There are several reasons why it makes sense for developers and designers to sha
The idea of "rapid development" has a long historical run-way, leading up to ideas like "ship early, ship often", agile programming methodologies etc.
With rapid development, we mean that the developer should participate in the context/domain that the software seeks to solve problems and create value in. The developer needs direct feedback from seeing the software in use.
As with co-realization, in our understanding of rapid development, we place the developer in the context/domain that the software seeks to solve problems and create value in. The developer needs direct feedback from seeing the software in use.
This in turn saves costly interactions and translations across actors. By fixing the problem here and now, we don't risk that the context is diluted, nor that elements are lost in transmission or translation between designers and managers. By letting the programmer be the designer, we in turn push responsibility and initiative to the user that gets to instruct the programmer directly. These methods are known also as co-realization and to expand "design space".
The short and tight feedback-loop enables developers to act as designers and to generate instant feedback for new features.
This in turn saves costly interactions and translations across actors. By fixing the problem here and now, we don't risk that the context is diluted, nor that elements are lost in transmission or translation between designers and managers. By letting the programmer be the designer, we in turn push responsibility and initiative to the user that gets to instruct the programmer directly.
</div>