When using an analogy, it's important to elicit the differences, otherwise it's not truly an analogy. One notable difference that comes to mind is malleability. Additionally, user needs and software instability seem to be closely linked, as users may not realize if the abstraction is good until they actually use it. These differences illustrate the opposing aspects of the soft vs hard design in place here. For instance, until a user interacts with your api, it's impossible to know if the data structure (which shapes the interface, much like a plug shape in the analogy) is truly useful.
The flexible nature of software means that design changes often occur during the coding phase, and these changes may not receive the same level of review as high-level design changes. This can result in important modifications happening without the necessary attention. Due to the malleability of software, it can be challenging to maintain a high-level design throughout the building process. This creates a more fluid and less straightforward development process compared to designing hard artifacts.
Thanks! Important modifications without proper attention happen with house construction too. For example, adding a last minute doorway to a load bearing wall without adding a reinforcing header.
Good thing there are inspectors, much like code reviewers. Unfortunately, issues still slip by them when changes are introduced at the last minute–much like code reviewers 😅.
I agree for a specific type of software. Usually, critical function software has requirements that are well-specified and stabilized from the beginning. The vast majority of software systems I worked with don’t have precise and stabilized requirements, and they are discovered, changed, and refined during development due to the very nature of the volatile business environment and the malleability of the artifact. So, in the analogy, it’s more like the client doesn’t know where to put the kitchen or how many windows or doors to put or what kind of electrical power to use. After they started living, they started having an idea influenced also by the houses of their friends using your competitor design. And you need to change while they live inside it. Of course, with hard artifacts, it’s harder 😊 to do it, but with soft artifacts, it’s softer, but it requires a different design approach since the beginning. The recent Continuous Architecture “philosophy” is a good example of a design approach in response to that need for the majority (imho) of software projects.
Part of my job now, before implementing a new feature, I was asked to write a technical design docs. Honestly, I don't know where to start and this post is super useful. I should focus on the boundaries and ignoring the implementation details in the design.
Do you have a template or how to write a good technical design doc that we can share/present to other devs?
I love the analogy! ❤️
When using an analogy, it's important to elicit the differences, otherwise it's not truly an analogy. One notable difference that comes to mind is malleability. Additionally, user needs and software instability seem to be closely linked, as users may not realize if the abstraction is good until they actually use it. These differences illustrate the opposing aspects of the soft vs hard design in place here. For instance, until a user interacts with your api, it's impossible to know if the data structure (which shapes the interface, much like a plug shape in the analogy) is truly useful.
The flexible nature of software means that design changes often occur during the coding phase, and these changes may not receive the same level of review as high-level design changes. This can result in important modifications happening without the necessary attention. Due to the malleability of software, it can be challenging to maintain a high-level design throughout the building process. This creates a more fluid and less straightforward development process compared to designing hard artifacts.
Thanks! Important modifications without proper attention happen with house construction too. For example, adding a last minute doorway to a load bearing wall without adding a reinforcing header.
Good thing there are inspectors, much like code reviewers. Unfortunately, issues still slip by them when changes are introduced at the last minute–much like code reviewers 😅.
I agree for a specific type of software. Usually, critical function software has requirements that are well-specified and stabilized from the beginning. The vast majority of software systems I worked with don’t have precise and stabilized requirements, and they are discovered, changed, and refined during development due to the very nature of the volatile business environment and the malleability of the artifact. So, in the analogy, it’s more like the client doesn’t know where to put the kitchen or how many windows or doors to put or what kind of electrical power to use. After they started living, they started having an idea influenced also by the houses of their friends using your competitor design. And you need to change while they live inside it. Of course, with hard artifacts, it’s harder 😊 to do it, but with soft artifacts, it’s softer, but it requires a different design approach since the beginning. The recent Continuous Architecture “philosophy” is a good example of a design approach in response to that need for the majority (imho) of software projects.
I love it!
Part of my job now, before implementing a new feature, I was asked to write a technical design docs. Honestly, I don't know where to start and this post is super useful. I should focus on the boundaries and ignoring the implementation details in the design.
Do you have a template or how to write a good technical design doc that we can share/present to other devs?
Thanks. I’m working on a template. I’ll follow up in DM.