We, as software industry at large, however should work on two fronts:
- Try to make things, which can be simple simple. Many do that out of self interest, but sometimes one is so used to complexitiest, that one doesn't see them anymore and we often fear redoing grown things as "it works" and we might break use cases and we don't want to relearn things ...
- There is a large room for enabling non-programmers to build tools. In the past™ people built fancy tools on top of dbase, delphi, access, excel (world runs on excel ...) etc. without being programmers. There is an easy start allowing a domain expert to build a tool in their office faster than explaining the problem to the IT department. The solutions weren't nice from an Software Engineering view, but solved problems. This we have to enable with modern technologies instead of access conflicts to an excel file on a windows share ...
We, as software industry at large, however should work on two fronts:
- Try to make things, which can be simple simple. Many do that out of self interest, but sometimes one is so used to complexitiest, that one doesn't see them anymore and we often fear redoing grown things as "it works" and we might break use cases and we don't want to relearn things ...
- There is a large room for enabling non-programmers to build tools. In the past™ people built fancy tools on top of dbase, delphi, access, excel (world runs on excel ...) etc. without being programmers. There is an easy start allowing a domain expert to build a tool in their office faster than explaining the problem to the IT department. The solutions weren't nice from an Software Engineering view, but solved problems. This we have to enable with modern technologies instead of access conflicts to an excel file on a windows share ...