From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,1042f393323e22da X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,1042f393323e22da X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,1042f393323e22da X-Google-Attributes: gid103376,public From: eachus@spectre.mitre.org (Robert I. Eachus) Subject: Software Engineering is not a hoax... (was Re: Any research putting c above ada?) Date: 1997/05/22 Message-ID: #1/1 X-Deja-AN: 243103492 References: <5lsjb3$bqc@bcrkh13.bnr.ca> Organization: The Mitre Corp., Bedford, MA. Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.ada Date: 1997-05-22T00:00:00+00:00 List-Id: In article <5lsjb3$bqc@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes: > I would go as far as saying that ``software engineering'' is a hoax. Huh? > Developing a correct program is much more akin to theorem proving than > engineering activity... Ah, programming is not software engineering. Software engineering is all that other stuff which successful projects do that results in projects being successful. We had an interesting case a few weeks ago here. A project manager wanted to know if switching from X to Y at this point in the project made sense. (X and Y here are irrelevant to the discussion.) He ended up talking to five people who really are software engineers. The first person gave him a lot of advice that basically amounted to do NOTHING to change the specifications for build one, but start a small scoping activity to make sure that all functions of the current system are scheduled for build two, and anything else that can be moved to build three, is. Then once build two is complete come back and discuss X vs. Y. The project manager thought that this was good advice, but didn't really answer his X vs. Y question, so he called someone else. Got the same answer. Tried a third person, got the same answer, called me. I went over to his office, looked at his schedule charts, and gave the same answer. At this point he was suspecting a conspiracy, because the answers were almost identical and didn't address his question. I suggested a fifth person who had been in meetings all morning, but was familar with the project. The project manager used his speaker phone and after asking a few questions got basically this reply: "The thing you have to understand is that even asking the design team to look at this at this point will cause at least a three month slip, and you can't afford that, because you are tied to the (system Z) deployment schedule. In fact, it is not clear that build three will be ready by then in any case, so you should make sure that any functionality provided by the current system is provided in build two. If it looks like build two will meet your current schedule, then you can evaluate this question in that context." PM: "But is this BETTER in the long run? That is what I want to know." In chorus: "Trying to answer that now will kill the project." All of this had NOTHING to do with actual programming, but everything to do with software engineering. Software engineering is all about knowing the difference between want and need, and keeping the focus on meeting requirements, whether they relate to cost, schedule, maintainability, or even to actual product functionality. The usual stock in trade of the software engineer is managing complexity, because we know that the project staff can only deal with so much at a time, and any attempt to exceed that real world limit can result in disaster. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...