…by some estimates software problems cost the American economy $59 billion annually
Out of the Tarpit summary (section 2)
In their report, Out of the Tarpit, Moseley and Marks insist that “Complexity is the only significant” difficulty in designing robust software systems. In forming their hypothesis around complexity, Moseley and Marks present a ‘complexity-optimised’ approach to database design using relational theory and functional programming.
Out of the Tarpit summary (section 3)
Moseley and Marks identify a common disconnect between understanding, the way in which we attempt to understand a system and the barriers the are presented by complexity. In doing so they draw upon the reflections of Backus, that “…conventional languages create unnecessary confusion in the way we think about programs”. Moseley and Marks delve into two widely used mechanisms for understanding:
testing: an attempt to “understand the system from the outside”, through observation of behaviours. A classic methodology for debugging (if there is a methodology for debugging!). I would argue the dangers here are of understanding. Fix the symptom, or fix the problem? The problem I see with testing of this nature, is that complexity is your enemy. It is often difficult to know exactly why a symptom arises and it is even harder to anticipate all the ways in which the users might interact with a system. I guess this is why banks pay mega-dollars for systems testing!
informal reasoning: an attempt to “understand the system from the inside”. The way I understand this, informal reasoning is about clear design and ensuring that the implementation meets the design requirements.
Moseley and Marks suggest that “improvements in informal reasoning will lead to less errors being created”, compared to testing which will only lead to more errors being detected. Again they quote Dijkstra’s famous Turing Award Speech:
Those who want really reliable software will discover that they must find means of avoiding the majority of bugs to start with
Testing is hopelessly inadequate… (it) can be used very effectively to show the presence of bugs but never show their absence
I’m really enjoying this article. It is simplicity or perhaps better, clarity that appeals to me in all things. Especially as a problem becomes complex, obtaining a clear view of the situation is immensely satisfying. I think this is why I really struggle to understand something until I have dived down into the complexity and clawed my way back up to a ‘big picture’ view.
This is my project!!!! Not specifically, I am still a little undecided on an exact definition for my project. But I want to dive under the cover of databases and find out what really make them so fantastic. After talking to Clare yesterday I am a step closer to pinning down my subject: at this stage I am thinking about identifying the functional characteristics of data storage systems. What makes a relational database so powerful? A good answer will hopefully highlight the weaknesses of relational databases. In which case, I want to look to other methods (OO, data warehousing, Ruby on Rails) and investigate their application.
Relating this back to Moseley and Mark’s work, this is about reducing the complexity of interaction within a system. Choosing the appropriate database tool that will interact seamlessly with the system. I still have HEAPS more thinking to do around this -I need to better define the question. But I am getting there