The formality of formal software engineering
posted September27th, 2007 @ 02:23:52
tags:
development
comments: 0
I am taking a class in Quantitative Software Engineering. It's a discipline that likes to throw around all these numbers, but is mostly posturing as something more defined and understood than it really is. The professor is smart and encouraging and I like to write on the discussion boards.
I think it is interesting and worthwhile that the actual foundation of the whole discipline is in question, and that this is being discussed. Too often people believe everything they read, especially when it seems very complex. Here is something I wrote today in response to: "There is an active debate on the utility of Formal Methods for Software Engineering. How do you stand on the issue -- are Formal Methods worthwhile?"
I am a cautious skeptic who sees the necessity of formal methods but is unhappy with their current state.
My main complaint on a lot of the formal methods of software engineering is that they are not derived formally in the classical sense. There is no mention or even attempt at doing controlled experiments; at applying the scientific method. Instead, anecdotal evidence is offered, and in the utmost perversion, statistics and case studies that fit (or even don't fit) the models are offered as evidence of their veracity. UFP = 4I + 5O + 4E + 10L + 7F. Am I supposed to believe that?
Why? It might be a reasonable model, but I think the presentation of it wrongly postures as formality rather than embracing the rich history and ingenious intuition it is built upon. Brooks' treatment of the subject seems to fall in line with what I am referring to, and the quest for formalizing his insights has, I think, largely proven empty handed.
I also see no evidence that "great" software is designed by a conference of users and software experts in an iterative process. In fact, I don't see any evidence that anything great was ever designed in this way. One cohesive determined vision by a skilled and enthusiastic designer always seems to come along and steal the carefully committee designed software's lunch. As a software engineer, it's my goal to be involved in the creation of "great" software.
That having been said, there's no way that a chaotic process of "visionary design" can be repeatable by enough people to create the volume of software solutions that are necessary (or desired). Frank Lloyd Wright conceived of the Guggenheim after lots of personal effort and vision, and you won't see such a masterful structure coming from New York City's public housing commission; but more buildings are required than the masters can design, and they are built in all levels of competency. I think that the act of introspection into the software engineering process is very interesting and yields a lot of insight into how to make the process more smooth; not all software needs to be great, just like not all buildings have to be great. But, since most software is so lousy, it would behoove everyone to adopt and experiment with formal methods that can improve the bottom line.
The question then, along side with these assertions, is how do you allow for the creation of great software when you propose this top-down "anti-greatness" structure? Software engineering books seem to go to great lengths to move the goal posts and attempt to modify the meaning of "great". If that's the real consequence out of all of this work, I'm not sure it was worth it.
Even though a small bit of process is a great improvement on the cowboy coding you might think I have been describing fondly, I think it's a fallacy to assume that a much greater amount of control and formal process around software engineering would yield much greater results. This is all somewhat paraphrased from Alex Martelli, but there comes a point where the management process takes on a life of it's own and absorbs boundless energy in a self perpetuating mess of documenting insignificant minutiae.
I think in the end, like most people, I favor formal methods that provide me with the language and tools to describe processes I understand or use intuitively. Along with language and vocabulary comes understanding, more intuition, and more complex formulations. Any sufficiently complex area of study, whether it be biology or social sciences, develops it's own precise language out of necessity; such a foundation is required in order to build more complex models of reality. It was only after a comprehensive language was laid down about computation that it really started to explode, even though it was many decades after the possibility was first postulated. I favor methods that take the vocabulary seriously and favor precision, not the bizarre collection of acronyms and abbreviations in the current literature that look more like the result of a marketing department.