A few weeks ago a blog was published asking a rhetoric question "Can software be created in factories?". My good friend pointed me to the wikipedia post on "Software Factory". What I would like to point out is that the statement "Software factory refers to a structured collection of related
software assets that aids in producing computer software applications or
software components according to specific, externally defined end-user
requirements through an assembly process. [1] A software factory applies manufacturing techniques and principles to software development to mimic the benefits of traditional manufacturing. Software factories are generally involved with outsourced software creation." from the wikipedia is completely incorrect and fallacious, despite the number of individuals who believe it.
Martin Fowler's bliki, Code as Documentation, has a link to Jack Reeve's famous essay "What is Software Design?".
This article first appeared in 1992 in the C++ Journal. It was written by Jack Reeve who had been in the industry for more than 10 years at the time and the trigger was the fact that C++ had taking the software world by storm. It was being seen as the panacea for all the problems plaguing the software industry during that time.
He summarizes the article as follows:
To summarize:
Another interesting excerpt is "In software engineering, we desperately need good design at all levels. In particular, we need good top level design. The better the early design, the easier detailed design will be. Designers should use anything that helps. Structure charts, Booch diagrams, state tables, PDL, etc.—if it helps, then use it."
This was the statement of the author in the essay published in 1992. Writing about this in 2005 the author says "Today, I would phrase it differently. I would say we need good architectures (top level design), good abstractions (class design), and good implementations (low level design). I would also say something about using UML diagrams or CRC cards to explore alternatives."
This is what the author is referring to from the earlier article: "We must keep in mind, however, that these tools and notations are not a software design. Eventually, we have to create the real software design, and it will be in some programming language. Therefore, we should not be afraid to code our designs as we derive them."
The author goes on to say "This is fundamental. I am not arguing that we should not “do design.” However you want to approach the process, I simply insist that you have not completed the process until you have written and tested the code."
Note that the author bolsters the argument that software development involves design at all stage. It is not limited to a single design phase.
Martin Fowler's bliki, Code as Documentation, has a link to Jack Reeve's famous essay "What is Software Design?".
This article first appeared in 1992 in the C++ Journal. It was written by Jack Reeve who had been in the industry for more than 10 years at the time and the trigger was the fact that C++ had taking the software world by storm. It was being seen as the panacea for all the problems plaguing the software industry during that time.
He summarizes the article as follows:
To summarize:
- Real software runs on computers. It is a sequence of ones and zeros that is stored on some magnetic media. It is not a program listing in C++ (or any other programming language).
- A program listing is a document that represents a software design. Compilers and linkers actually build software designs.
- Real software is incredibly cheap to build, and getting cheaper all the time as computers get faster.
- Real software is incredibly expensive to design. This is true because software is incredibly complex and because practically all the steps of a software project are part of the design process.
- Programming is a design activity—a good software design process recognizes this and does not hesitate to code when coding makes sense.
- Coding actually makes sense more often than believed. Often the process of rendering the design in code will reveal oversights and the need for additional design effort. The earlier this occurs, the better the design will be.
- Since software is so cheap to build, formal engineering validation methods are not of much use in real world software development. It is easier and cheaper to just build the design and test it than to try to prove it.
- Testing and debugging are design activities—they are the software equivalent of the design validation and refinement processes of other engineering disciplines. A good software design process recognizes this and does not try to short change the steps.
- There are other design activities—call them top level design, module design, structural design, architectural 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 various design steps reveal the need.
- Many different software design notations are potentially useful—as auxiliary documentation and as tools to help facilitate the design process. They are not a software design.
- Software development is still more a craft than an engineering discipline. This is primarily because of a lack of rigor in the critical processes of validating and improving a design.
- Ultimately, real advances in software development depend upon advances in programming techniques, which in turn mean advances in programming languages. C++ is such an advance. It has exploded in popularity because it is a mainstream programming language that directly supports better software design.
- C++ is a step in the right direction, but still more advances are needed.
Another interesting excerpt is "In software engineering, we desperately need good design at all levels. In particular, we need good top level design. The better the early design, the easier detailed design will be. Designers should use anything that helps. Structure charts, Booch diagrams, state tables, PDL, etc.—if it helps, then use it."
This was the statement of the author in the essay published in 1992. Writing about this in 2005 the author says "Today, I would phrase it differently. I would say we need good architectures (top level design), good abstractions (class design), and good implementations (low level design). I would also say something about using UML diagrams or CRC cards to explore alternatives."
This is what the author is referring to from the earlier article: "We must keep in mind, however, that these tools and notations are not a software design. Eventually, we have to create the real software design, and it will be in some programming language. Therefore, we should not be afraid to code our designs as we derive them."
The author goes on to say "This is fundamental. I am not arguing that we should not “do design.” However you want to approach the process, I simply insist that you have not completed the process until you have written and tested the code."
Note that the author bolsters the argument that software development involves design at all stage. It is not limited to a single design phase.
Another interesting statement in the second essay is "When the document is detailed enough, complete enough, and unambiguous enough that it can be interpreted mechanistically, whether by a computer or by an assembly line worker, then you have a design document. If it still requires creative human interpretation, then you don’t.". Again goes on to prove that software cannot be created in factories.
One final argument to support that Software cannot be created in factory "The problem with software is - design is not just important, it is basically everything. Saying that programmers should not have to design is like saying fish should not have to swim. When I am coding, I am designing. I am creating a software design out of the void."
Update
When this was sent to a few people the reply I got back is "In the Indian IT industry, there is no such thing as a "Less Able Programmer". All donkeys can be "processed" to become a stallion. all crows can become swans..." and all that can be said about this sad fact is that "This belief is exactly the bane of the Indian IT industry and in my, black, cynical, negative opinion is going to lead to the downfall of the what we today consider to be a cash cow."
Update
When this was sent to a few people the reply I got back is "In the Indian IT industry, there is no such thing as a "Less Able Programmer". All donkeys can be "processed" to become a stallion. all crows can become swans..." and all that can be said about this sad fact is that "This belief is exactly the bane of the Indian IT industry and in my, black, cynical, negative opinion is going to lead to the downfall of the what we today consider to be a cash cow."
No comments:
Post a Comment