My first #blog serie is coming .... It will be about #DomainDriverDesign
My first #blog serie is coming .... It will be about #DomainDriverDesign
Design and Delivery: Two Sides of the Same Coin
One of the points of agile development is to seek input from customers throughout the development process, including early stages. But if a development team isn’t allowed, without authorization from some outside body, to change requirements or specifications in response to what they discover, their ability to innovate is sharply inhibited. —Nicole Forsgren et al.,
Accelerate: The Science of Lean Software and DevOps
Good design is not a one-and-done activity—it is an iterative process of shaping, testing, and refining ideas in response to how real users engage with them. The best designs emerge not from isolated studios or static documentation, but from rapid cycles of delivery, feedback, and improvement.
Unfortunately, this is where many government digital services fall short. The issue is not simply a lack of design talent or access to modern design methods. Rather, it is the friction in delivering design outputs to real users, and the difficulty of iterating quickly once those outputs are in production.
Why Iteration Matters
When users cannot interact with design artifacts, or when changes take weeks or months to deploy, the quality of the resulting services inevitably suffers. Designers are left guessing about user needs, and by the time changes are implemented, the context may have shifted entirely.
The lifeblood of good user experience is frequent deployments. Continuous deployment (the CD in CI/CD) is not just an industry trend, it is literally how improvements and enhancements get into the hands of users. If the time between software deployments is measured in months (or even years for some government organizations) no amount of user research or data analytics can save you. You can’t meaningfully help users unless you can get them enhancements quickly, reliably, and securely.
As service design scholar Lara Penin puts it in her book An Introduction to Service Design: Designing the Invisible:
Designers of interactions not only need to spend a lot of time trying to anticipate people’s reactions but also – and foremost – they need to get their interaction ideas out there and test them with users in context throughout the development process.
This is the heart of good design: short, frequent feedback loops that allow teams to adapt based on what they learn. Understanding the connection between deployment frequency and user experience is critical to successful digital solutions.
The Barriers Governments Face
Government agencies face unique challenges in achieving this kind of rapid iteration. Compliance requirements like Authority to Operate (ATO) add delays before new features can go live. Legacy systems make deployments risky and expensive. And many teams lack mature DevOps practices that make delivery seamless and low-risk.
Poor DevOps practices are often the unseen culprit in poor digital service designAs a result, even well-researched, well-crafted designs often stall before they can make a meaningful impact.
Making Iteration Easier
Improving government services isn’t just about bringing in skilled designers or training staff in human-centered design, though that’s important as well. Those investments will only go so far if agencies cannot act quickly on what they learn from users. The key is reducing the cost, in time, money, and risk, of delivering and iterating on design ideas.
Mature DevOps practices make iteration cheap, secure, and fast. Automated testing, continuous delivery pipelines, and modular architectures mean teams can experiment safely, deploy quickly, and revert easily when needed. Frequent deployments aren’t just a nice-to-have—they are how user experience improves in practice.
If we want better digital services for the public, we need to focus not just on designing the right things, but on making it easier for governments to deliver and refine them—over and over again.
It's our job in #softwareDevelopment to solve problems. This begins with identifying the problem and ends with us avoiding as much work as possible.
It's our job in #softwareDevelopment to solve problems. This begins with identifying the problem and ends with us avoiding as much work as possible.
Software Performance: Avoiding Slow Code, Myths & Sane Approaches – Casey Muratori | The Marco Show
https://yewtu.be/watch?v=apREl0KmTdQ
(or YT: https://www.youtube.com/watch?v=apREl0KmTdQ)
Very inspiring #podcast/ #interview with Casey Muratori on how to create performant software - by The Marco Show.
Apparently, we are storing log output in .yml files now! 😬
Apparently, we are storing log output in .yml files now! 😬
Dear null,
A blog post by Dmitrii Aleksandrov:
https://home.expurple.me/posts/dear-null/
"Get the domain model out of your head. Get it out of external docs. Get it out of the unit tests. Put it right into the code that represents it. Let the compiler validate the model that you’ve designed."
THIS! 💯
#ProgrammingLanguage#SoftwareDevelopment#SoftwareEngineering#NullSafety
Dear null,
A blog post by Dmitrii Aleksandrov:
https://home.expurple.me/posts/dear-null/
"Get the domain model out of your head. Get it out of external docs. Get it out of the unit tests. Put it right into the code that represents it. Let the compiler validate the model that you’ve designed."
THIS! 💯
#ProgrammingLanguage#SoftwareDevelopment#SoftwareEngineering#NullSafety
Marketing people should be let anywhere near the software versions!
Windows: 2000, XP, Vista, 7, 8, 8.1, 10
Unity: 5.6, 2017.1, ..., 2022.3, 6.0
iOS: 18, 26
Now one guy at Unity (me) has to change iOS min version check to also include check for non-existent 19-25 range. Hopefully it is not me in the future who'll have to deal with those skipped version somehow coming to existence.
Marketing people should be let anywhere near the software versions!
Windows: 2000, XP, Vista, 7, 8, 8.1, 10
Unity: 5.6, 2017.1, ..., 2022.3, 6.0
iOS: 18, 26
Now one guy at Unity (me) has to change iOS min version check to also include check for non-existent 19-25 range. Hopefully it is not me in the future who'll have to deal with those skipped version somehow coming to existence.
Examples
Manifest function (expected/stability):
- Sending kids to school, so that they become well educated
Manifest dysfunction (expected/instability):
- Holding on to fossil fuels as a ("cheap") energy source
Latent function (unexpected/stability):
- Kids might form deep relationships and belonging with other peers in school
Latent dysfunction (unexpected/instability):
- Increased human, social and economic cost of climate change caused by using fossil fuels for energy
2/3
I find this kind of stuff super fascinating! 🤓
You can recognize/apply these concepts everywhere:
Also in software dev:
Not properly fixing something, but instead do a workaround:
Manifest dysfunction:
Might be harder to extend in the future.
Latent function:
If it was properly fixed, the software would have become 2x faster, because the actual error has manifested itself in the execution of unnecessary logic.
3/3
Every day is a day to be remembered of how "Individuals and interactions over processes and tools" is totally ignored by "modern software development leaders".
Not doing unit-/integration testing is not a strategy - it's a clusterfuck!