On 09/01/2018 05:06 PM, Ola Fosheim Grøstad wrote:
If you have a specific context (like banking) then you can develop a
software method that specifies how to build banking software, and repeat
it, assuming that the banks you develop the method for are similar
Of course, banking has changed quite a lot over the past 15 years
(online + mobile). Software often operates in contexts that are
critically different and that change in somewhat unpredictable manners.
Speaking of, that always really gets me:
The average ATM is 24/7. Sure, there may be some downtime, but what, how
much? For the most part, these things were more or less reliable decades
ago, from a time with *considerably* less of the "best practices" and
accumulated experience, know-how, and tooling we have today. And over
the years, they still don't seem to have screwed ATMs up too badly.
But contrast that to my bank's phone "app": This thing *is* rooted
firmly in modern technology, modern experience, modern collective
knowledge, modern hardware and...The servers it relies on *regularly* go
down for several hours at a time during the night. That's been going on
for the entire 2.5 years I've been using it.
And for about an hour the other day, despite using the latest update,
most of the the buttons on the main page were *completely* unresponsive.
Zero acknowledgement of presses whatsoever. But I could tell the app
wasn't frozen: The custom-designed text entry boxes still handled focus
events just fine.
Tech from 1970's: Still working fine. Tech from 2010's: Pfffbbttt!!!
Clearly something's gone horribly, horribly wrong with modern software
development.
