Saihatsu Boshi & Low Code

Years ago, I read an article about Saihatsu Boshi. It's a process of root cause analysis and putting countermeasures in place.?

The article describes a shipment that misses a delivery date when the transport ship sinks after being hit by a typhoon.?The shipping company couldn’t produce a countermeasure because, from their perspective, what do you do about a typhoon??The article points out that you can always do something. For example, looking at improving transport systems or using a more accurate weather forecast system.

This process doesn’t accept excuses as “random” or “human error” – it promotes taking action to prevent a recurrence.

Preventing recurrence of issues and requests in low-code development

If you are a developer building low-code apps for other people, with each app there will be some level of feedback in terms of support, changes, and bugs.?More apps result in an increasing amount of feedback. ?

Imagine taking steps to make sure that you are never asked that same question twice.?No excuses. Commit to understanding what happened and how to prevent it from happening again.?

Let’s look at some examples:

When a bug is detected

1. Fix the bug, but void workarounds that won't conclusively resolve the issue. Remember the old journalism saying to avoid becoming part of the story? ?When there is a known issue that requires developer intervention, the developer becomes a part of the process.
2. Don’t treat it like a one off.?Where did the error happen, and why??Were the requirements vague? ?Was it tested??Identify the point(s) where this could have been prevented.

A change request is made to update content, like an approver or email text.

Resist the urge to fix this by making the requested change.?That might be faster, but it won’t stop the flow of change requests. ?

Store interchangeable values in a list or table that can be updated by the data owner and retrieved by a workflow. ?Use security groups and roles that can be managed by the data owner.?Create an admin form to allow self-service for these changes.?Then make it a best practice for all your solutions. It’s easier to build that up front than it is to go back and add it in later.

A user has a question

Users don’t want to hang out in your app. They want to open it, do what they need to accomplish and leave as quickly as possible.??If they can do that without fumbling around to find information, that is a success.?

If someone is reaching out to the developer to check on something:

1.??????Help them find what they need.

2.??????Add that information to your app.?This is especially important if you have a long running process.?Provide updates or links that explain the process or status, when there might be an issue, and who to contact if they have questions.

It's worth the effort.

Low-code platforms like Power Platform are documented, reliable, and feature-rich.??Nobody is asking you to develop countermeasures for typhoons, only to take an honest look at your process for shortcomings. ?

Don’t just fix the issue or answer the immediate question at hand– dig deeper, understand what led to the error, and prevent recurrence.?Maybe the only possible countermeasure is to document something and post it somewhere easy to find. That’s acceptable, and an improvement to answering the same question repeatedly.

Benefits

1.??????The accumulated lessons learned will fine tune your development process and make you a better developer.?Your solutions will have increasing maturity on first release.?

2.??????More solutions equal more potential for requests. ?If you’re new to low-code, that’s probably not having an impact right now. You receive an email requesting a change, respond and move on.?Three years from now, when the emails are about apps you don’t remember building, it’s a different story.?

3.??????Grow your reputation and career.?It’s not job security or good customer service to make people dependent on you. ??You’re likely missing opportunities for research, innovation, and creativity.

I went through this process. ?I was already a good developer, but I was struggling to manage the accumulating number of apps and the time spent supporting changes and turnover.???This was a reflective process that forever changed the way I do planning and development.?