3 ms·

I’ve been talking about the problems with tech-driven architecture for years. I would simplify this entire discussion by saying… “When you create distance fro

I’ve been talking about the problems with tech-driven architecture for years. I would simplify this entire discussion by saying… “When you create distance from code to business processes, the less effective and maintainable your architecture and software development becomes.” I have always argued that your stakeholders should be able read your code, understand your architecture as an automated view of their world. Any abstraction away from that perspective is self-serving, tech-driven, and bad for the business. Agile project management isn’t about unit tests and CICD. It’s about removing the gap between the business and its software development. I appreciate SOLID principals and use various patterns, but my number one rule is we should never build something that does directly equate to a business process. ORM’s hide business processes. Complex abstract frameworks hide business processes. We need to stop doing that.

crdoconnor 9y ago
>I have always argued that your stakeholders should be able read your code That doesn't sound plausible.
- hackerfromthefu 9y ago
  It takes discipline, and a certain approach, but it's actually achievable - I've done it, and taught many others to do it. Usually takes six months to a year of regular coaching to train it for most experienced developers. This is in C# and Python, but it's generalisable to most high level languages. Harder with lower level languages because of the higher noise to signal ratio. I've been able to take function I wrote and work through them with non technical stakeholders, successfully, for them to verify the behaviour matches their understanding of the business logic. I only did that occasionally, the major value is more in the ease of understanding for the developers. The key is the code must read quite similar to English, and be written in an expressive style conveying intent.
  - crdoconnor 9y ago
    I've written executable user stories that stakeholders can read, which is a good way for them to verify that the implemented business logic matches expected behavior, and is significantly easier to read than turing complete code. I'm honestly not sure if there's value in going beyond that though. The "signal to noise" ratio in any turing complete language is too high even when you try to write code as clearly as possible (which I do). Implementation details aren't all that interesting to stakeholders and understanding code even in languages that emphasize readability requires tons of implicit knowledge.

crdoconnor 9y ago

>I have always argued that your stakeholders should be able read your code That doesn't sound plausible.

hackerfromthefu 9y ago
It takes discipline, and a certain approach, but it's actually achievable - I've done it, and taught many others to do it. Usually takes six months to a year of regular coaching to train it for most experienced developers. This is in C# and Python, but it's generalisable to most high level languages. Harder with lower level languages because of the higher noise to signal ratio. I've been able to take function I wrote and work through them with non technical stakeholders, successfully, for them to verify the behaviour matches their understanding of the business logic. I only did that occasionally, the major value is more in the ease of understanding for the developers. The key is the code must read quite similar to English, and be written in an expressive style conveying intent.
- crdoconnor 9y ago
  I've written executable user stories that stakeholders can read, which is a good way for them to verify that the implemented business logic matches expected behavior, and is significantly easier to read than turing complete code. I'm honestly not sure if there's value in going beyond that though. The "signal to noise" ratio in any turing complete language is too high even when you try to write code as clearly as possible (which I do). Implementation details aren't all that interesting to stakeholders and understanding code even in languages that emphasize readability requires tons of implicit knowledge.