Re: Is writing software for Windows just too damn hard?
On Steve's FurryGoat.com weblog, he poses the question:
So my question is: Why is that? Is writing software for Windows just too damn hard?
Coincidentally, I had a discussion with a few colleagues about this matter the other day as well. Of course, given our personal preferences, we did not discuss software development for the Windows platform, but thought in more general terms.
I posed the hypothesis that building software is an immature engineering discipline, which most notably shows in our lack of ability to make true black boxes. "Classical" engineering, like building bridges, dams, and other structures, has mastered the art of specifying components to such a degree that they can be described with only a few parameters. In the art of software engineering, we do not have this down yet.
For example, the Service Oriented Architecture consists of many different layers. From an engineering point of view, that is a highly desired design feature. By attacking any problem with a divide and conquer strategy, things should get easier all alround.
Unfortunately, an implicit assumption in systems theory is that each system (or black box) can be considered independently of all others, and there is no need to understand the inner workings of each system. It is exactly this aspect that we have not yet mastered in software engineering. To be able to build a software system that is layered, the application developer will have to be very intimitatly familiar with each layer, including all the interactions between those layers.
While I do not know anything about Windows programming (which I sometimes regret), general GUI programming definitely suffers too much from this. Java programming libraries, such as the AWT or Swing, the Tk toolkit from Tcl/Tk, but also applications developed according to the service-oriented computing paradigm still require too much knowledge in a programmer.
Steve's point that there may need to be more documentation is partially true. However, documentation only serves to increase the knowledge of the developer. My point is that the developer should not have to know all that he needs to know today.
Until we know how to build true software black boxes, software engineering will always remain an art, and will never become a science.
So my question is: Why is that? Is writing software for Windows just too damn hard?
Coincidentally, I had a discussion with a few colleagues about this matter the other day as well. Of course, given our personal preferences, we did not discuss software development for the Windows platform, but thought in more general terms.
I posed the hypothesis that building software is an immature engineering discipline, which most notably shows in our lack of ability to make true black boxes. "Classical" engineering, like building bridges, dams, and other structures, has mastered the art of specifying components to such a degree that they can be described with only a few parameters. In the art of software engineering, we do not have this down yet.
For example, the Service Oriented Architecture consists of many different layers. From an engineering point of view, that is a highly desired design feature. By attacking any problem with a divide and conquer strategy, things should get easier all alround.
Unfortunately, an implicit assumption in systems theory is that each system (or black box) can be considered independently of all others, and there is no need to understand the inner workings of each system. It is exactly this aspect that we have not yet mastered in software engineering. To be able to build a software system that is layered, the application developer will have to be very intimitatly familiar with each layer, including all the interactions between those layers.
While I do not know anything about Windows programming (which I sometimes regret), general GUI programming definitely suffers too much from this. Java programming libraries, such as the AWT or Swing, the Tk toolkit from Tcl/Tk, but also applications developed according to the service-oriented computing paradigm still require too much knowledge in a programmer.
Steve's point that there may need to be more documentation is partially true. However, documentation only serves to increase the knowledge of the developer. My point is that the developer should not have to know all that he needs to know today.
Until we know how to build true software black boxes, software engineering will always remain an art, and will never become a science.