Christof Ebert: Aside from better coding, such programming environments also made the incremental approaches feasible that we discussed earlier. Academics and researchers talked about components and reuse for decades, and nothing happened. The direct-manipulation, drag-and-drop, point-and-click programming interface was a revolutionary advance.
Christof Ebert: Even more relevant is the single measure of speed of penetration of VB. Only Java passed it recently in speed. Visual Basic is limited, but within those limits it has had a profound impact on software development and has made meaningful development possible for a much larger group of people than would have been possible without it. More than organizations and projects have undergone SW-CMM assessment, and dozens of organizations have produced mountains of compelling data on the effectiveness of process improvement programs based on the SW-CMM model.
Steve has explained the case for a best influence. However, I have also seen a lot of gaming and misuse of the CMM that leads to wasted and counterproductive activity. Even worse, it has spawned a growth industry in CMMs for all kinds of things—apparently based on the premise that if your model has five levels it must be right, regardless of whether you have any real knowledge of the subject matter. My expectation was that an organization that was found to be weak in risk management, for example, would read one of the many good books on risk management or get help from an expert in the field.
Instead, what many if not most organizations do, is to take the 4 pages in the CMM that describe risk management and re-package it as pages of their local process documentation. Overall, I believe the CMM has helped a lot. However, I think it does have some harmful side effects that can be mitigated if the community is willing to recognize them. Moreover, there are limits to how far it can take us into the 21st century. Robert Cochran : Standardization is key.
I would say that SPI using any of the recognized frameworks or indeed a mixture of them is where benefit is gained. They give a structure and coherence to the SPI activity.
But I disagree that the CMM taken as a whole has been one of the most positive influences of the twentieth century. Wolfgang Strigel: This one can really stir the emotions. Despite its simplicity, the main problem with the CMM is its rigid and ignorant interpretation. The concept itself is sort of a truism. Its problems get aggravated with people reading too much into it.
The grading is questionable and not the most relevant part of the CMM. I disagree that ISO would merit a similar place in the hall of fame. After all, with ISO you can diligently do all the wrong things, and you will be compliant as long as you do them diligently. It may be time to throw away the old CMM model and come up with an update that takes into account the experiences from the last 10 years.
At present, it is the framework that allows benchmarking and that contributes most to solving the software engineering crises—just by defining standard terminology. After the initial hype faded, practitioners were sometimes left with programming technologies that increased complexity, provided only marginal productivity gains, produced unmaintainable code, and could only be used by experts.
In the final analysis, the real benefit of object oriented programming is probably not objects , per se, but the ability to aggregate programming concepts into larger chunks than subroutines or functions.
Terry Bollinger: Whatever real benefits people were getting from OO, it was mostly coming from the use of traditional Parnas-style information hiding, and not all the other accoutrements of OO. OO is a badly mixed metaphor. The result, surprise surprise, is an ugly mix that is usually neither particularly intuitive nor as powerful as it was originally touted. Has anyone done any really deep inheritance hierarchies lately? And got them to actually work without ending up putting in more effort than it would have taken to simply do the whole thing over again?
Takaya Ishida: I think it is questionable whether Cobol and Object Oriented Programming should be on the 10 best list or 10 worst list. It seems to me that Cobol and other popular high level procedural languages should be blamed for most of the current problems in programming. It is so easy to program in such languages that even novice programmers can write large programs.
But the result is often not well-structured. With object-oriented languages such as Smalltalk, programmers take pains to learn how to program, and the result is well structured programs. Having programming approaches that can be used only by experts may be a good idea. Component-based development has held out much promise, but aside from a few limited successes, it seems to be shaping up to be another idea that works better in the laboratory than in the real world.
Glass: The reuse component-based movement might have trouble getting off the ground, but some related developments have shown great promise. The patterns movement looks to be the successful end-run around the reuse movement. Compiler-building was perhaps the first such success many decades ago. Steve McConnell: Yes, 30 years ago a person could get a Ph. Glass: There have been too few successes other than compiler building. Visual Basic is an example of how component based design can work if the environment is sufficiently validated ahead of time.
Christof Ebert: Work on components helped to see the direction towards frameworks, reuse, and pattern languages. So it is a useful intermediate step. Thinking in components still is a good design principle and entirely in line with the point made earlier about information hiding. Metrics and measurement have the potential to revolutionize software engineering.
The metrics community seems to forget this lesson again every year. Deependra Moitra: Any problems are not with metrics but with the metrics community. Engineers learn what is true, what is useful, and how to apply well-understood knowledge to solve practical problems. Scientists must keep up to date with the latest research. Engineers must be familiar with knowledge that has already proven to be reliable and effective.
An undergraduate engineering education prepares students to enter the workforce immediately after completing their studies.
They are called scientists, but they are performing job functions that are traditionally performed by engineers, without the benefit of engineering training.
The effect is roughly the same as it would be if you assigned a physics Ph. Bridge designers and aeronautical engineers consider both safety and cost.
Whether the calculations involve functionality, time, money, or human safety, striking the right balance in a deliberate, informed way is properly the domain of engineering—applying scientific principles toward practical ends. Many current software projects strike that balance poorly, or with little awareness that trade-offs even exist.
An engineering approach can only help them. Another objection is that treating software development as engineering will take all the fun out of it. Software development in many quarters is a fast-and-loose craft, and many fast-and-loose craftsmen are making fantastic incomes without knowing much about effective development practices.
All other engineering fields are self-accredited and self-regulated; software developers will either voluntarily swallow the medicine of software as engineering or we will have it forced down our throats. I know which way I prefer to take my medicine. Some students will major in electrical engineering or aeronautical engineering with an emphasis in software.
They will lead the software parts of their engineering projects, and their classmates who choose pure electrical engineering or aeronautical engineering will not. Some students will attain degrees in general software engineering.
A major distinction between software engineering and other kinds of engineering is that software is so labor intensive that a significant amount of engineering energy must be focused on project goals in addition to product goals—on the means to the ends as well as the ends themselves.
Other kinds of engineers choose components to be used in the structures they build. Software engineers choose both the tools used to build the software and the components to be used within the software itself.
I can fix a broken railing on my stairs without a civil engineering degree. I can mix a gin and tonic without a chemical engineering degree. But can I build a second story on my house? My local government will require me to have an engineer sign the building plans.
We should eventually see a similar stratification of software jobs into amateurs, skilled craftsmen, and engineers. How should software engineers be trained? How should software engineers be certified? And, perhaps the hardest to answer, How long will it take for all this to happen? Two cultures or an ideal unmet?
0コメント