Software Design
I caught up with a wonderful essay yesterday, and I was amazed at its simplicity.
What Is Software Design? By Jack W. Reeves is worth a read for any engineer, specially for the ones in software.
It was a really bold idea to try and potray what he was trying in 1992, and it still is...but I for one simply love it.
Ever since college when I first read Software Engineering as a paper, we've been taught preconcieved notions about what Software Engineering, its phases and its outcomes are. Jack totally thrashes that, though very subtly.
Infact, he wrote the original essay so very brilliantly, that it seems to just strike through if you take time to read it with patience.
His core idea, "Final source code is the real software design and then examining some of the consequences of that assumption", is so simple and so revolutionary, that almost every one in the industry would be against it. And that is really the what he had to keep in mind when he wrote the essay. For he has done his best to unleash the revolutionary idea very subtly, very.
That is the core idea of the essay. But on the lines he comes up with some very interesting analysis of facts about the software industry and about software engineering in general...
Real software is what runs on computers. This means that real software is not C++ (or any other programming language).
Real software is built by computers (via compilers and linkers).
This means that a source code listing (in any programming language) is really a software design.
It follows from the above that real software is incredibly cheap to build, and getting cheaper all the time as computers get faster.
Software is incredibly expensive to design. This is true in both an absolute sense (because of its ever increasing complexity), and relative to the cost of a software build.
Programming is a design activity - a good software design process recognizes this and doesn't hesitate to code when coding makes sense.
Coding actually makes sense a whole lot more often than traditional software design processes would have you believe.
Testing and debugging are design activities - they are the software equivalent of the analysis, simulation, modeling, and testing phases of other engineering disciplines. The goal is to validate and improve the design before the final product is built. A good software design process recognizes this and doesn't try to disown or short change the steps.
There are other design activities - call them top level design, module design, or whatever. A good software design process recognizes this and deliberately includes the steps.
All design activities interact. A good software design process recognizes this and allows the design to change, sometimes radically, as other design steps reveal the need.
Many different software design notations are potentially useful - as auxiliary documentation (it would be nice to have some tools that help us generate and maintain auxiliary documentation automatically from the actual source code. This would be particularly useful in maintaining a graphical representation of thestructural aspects of the design).
Ultimately, real advances in software development depend upon advances in programming. C++ is a good step in the right direction. For software engineering'ssake, we need a great many more steps.
Take time and go through the whole essay and its follow up 13 years later. It might just shake you up.
What Is Software Design? By Jack W. Reeves is worth a read for any engineer, specially for the ones in software.
It was a really bold idea to try and potray what he was trying in 1992, and it still is...but I for one simply love it.
Ever since college when I first read Software Engineering as a paper, we've been taught preconcieved notions about what Software Engineering, its phases and its outcomes are. Jack totally thrashes that, though very subtly.
Infact, he wrote the original essay so very brilliantly, that it seems to just strike through if you take time to read it with patience.
His core idea, "Final source code is the real software design and then examining some of the consequences of that assumption", is so simple and so revolutionary, that almost every one in the industry would be against it. And that is really the what he had to keep in mind when he wrote the essay. For he has done his best to unleash the revolutionary idea very subtly, very.
What I want to do in this article is take a look at the relationship between programming and software design. For almost 10 years I have felt that the software industry collectively misses a subtle point about thedifference between developing a software design and what a software design really is.
This lesson is that programming is not about building software; programming is about designing software.
That is the core idea of the essay. But on the lines he comes up with some very interesting analysis of facts about the software industry and about software engineering in general...
Take time and go through the whole essay and its follow up 13 years later. It might just shake you up.
posted by Ankan at 5:30 AM
1 comments
