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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f849b,d275ffeffdf83655 X-Google-Attributes: gidf849b,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,d275ffeffdf83655 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: 101b33,d275ffeffdf83655 X-Google-Attributes: gid101b33,public X-Google-Thread: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public From: "Bruce Detter" Subject: Re: Ada vs C++ vs Java Date: 1999/01/18 Message-ID: <780j6i$7522@svlss.lmms.lmco.com> X-Deja-AN: 434215413 References: <369C1F31.AE5AF7EF@concentric.net> <77o1qr$8iu3@svlss.lmms.lmco.com> <36a32a9d.12623551@news.demon.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Organization: Lockheed Martin Corporation Newsgroups: comp.lang.ada,comp.lang.c++,comp.vxworks,comp.lang.java,comp.java.advocacy,comp.realtime,comp.arch.embedded,comp.object,comp.lang.java.programmer Date: 1999-01-18T00:00:00+00:00 List-Id: Sorry about that.... I did oversimplify my thoughts and you caught some of my "gaps". Let me state right up front, PM cannot possibly work (be anything other than a paperpushing nightmare) without the SW engineers "buying into" the plan. In my mind (dangerous territory) PM is a tool to help the engineer focus on the job at hand if properly used. I think my concept of PM is very close to your 'inverse management hierarchy' idea in that the management plan is developed and agreed to by the engineers involved. There should be some means of keeping the HW/SW engineers on the same page rather than the engineer developing in isolation only to find out in code review they were "off base". I believe development tools are now available to minimize the intrusion to the engineer, let the engineers coopertatively manage their own project, and permit management to see what the progress and activities are without bothering the engineers. Getting a little wordy here, so the upshot is more teamwork/cooperation from management down, less "us vs. them" attitude. BCD3 John Birch wrote in message <36a32a9d.12623551@news.demon.co.uk>... >On Fri, 15 Jan 1999 10:35:43 -0800, "Bruce Detter" > wrote: > >>This thread seems to have generated a lot of interest (and a lot of >>interesting and informative reading). > >Indeed > >>I think your question misses the real issue for a project such as yours. >>Project management is far more important than the tool you chose for >>implementation. Programmers and languages come and go (you may have to >>integrate current code with new code in some as yet unspecified language >>with personnel who never worked on the current code). But if the project is >>properly managed (all documentation maintained, coding styles enforced, >>programmers and engineers kept current on training, etc.) then the choice of >>languages is of secondary importance. > >Well.... > >This is a bit like saying it doesn't matter if you build a bridge from >wood, steel or glass as long as the project manager is good! >While project management may be of great importance on a large >project, the number of good project managers (to bad ones) is probably >in the same ratio as _you_ put good C++ programmers. Your paragraph >sounds a bit like an advocation of the 'straight jacket' approach to >projects, i.e. keep the programmers in their place we'll tell them >what's good for them. > >Whilst documentation is fine, enforcement of coding standards is a >very emotive issue. If we're simply talking about commenting and >header blocks then I have little argument, but in many shops - coding >style is taken a lot further than that. > >BTW I'm all for training too. > >But... the most critical part to the success of any large project is a >good design, that is well understood, abstracted into several layers >so that management, projects and engineering staff can see the level >of detail they require. Now part of realising a good design is >choosing the appropriate tools for the job. This includes the >methodology used, the testing strategy, the design notation, and the >language (not an exhaustive list by any means). Just having the right >person to monitor progress and facilitate comunication between client, >management and workers will not make a damm's worth of difference in a >project that does not have a sound technological basis. > >BTW if you anticipate a high degree of 'churn' amongst the developers, >perhaps that should tell you something about the development strategy. >IMHO people leave companies because they disagree with something >(their managers, the design, the salary or the conditions). It's >actually quite hard to get rid of a well motivated developer working >on a project which he believes in! > >>That being said, I think your choices are between Ada, C++, and Java. > >Wow, insight here, I think this was the original question; which >langauge should I choose from Ada C++ and Java ;-) > > > >> C++ has the largest pool of programmers, but 'real' C++ OO programmers are fairly rare. > >Agreed > >> Unfortunately, far too many >>'C++' programmers are just enhanced C coders with minimal OO understanding. > >More accurately, most of them have no knowledge of C and minimal OO >understanding :-) > >>Java, as an embedded system development environment, is still in its infancy >>(As is Windows CE, not to be compared to VxWorks). >>I believe project management and the architecture development tools >>(Rational Rose, ObjectTime, etc.) you choose are more critical than the >>language(s) you choose. > >You're not by any chance a project manager are you? > >>I also believe that one common language is not >>always the best solution. Determine what your objectives are, then choose a >>tool or resource that can best fulfil each objective. A short term cost hit >>on more resources and tools up front can mean long term savings (but be >>smart about it, know why you're spending the extra money/time) > >Oh I see from your sig that you're not, so I don't understand why you >think the language choice is unimportant. In a C++ shop, choosing Ada >could result in a rapid lack of staff ;-). OTOH choosing Java for a >mission critical, hard real-time embedded application could be a RW >disaster too! Or are you saying that by choosing the right project >manager / methodology this would not happen? > >I'm trying (and probably failing miserably) not to be too anti PM, but >all my experience to date has been that PM's make effective fire >starters, but are very poor at putting them out (a job they generally >leave for engineers ;-) Besides from your first paragraph I get the >impression that the PM should control the project rather than assist >it. I personally favour the 'inverse management hierarchy' ideas of >project control. I.e. the Software / Hardware engineers produce the >goods for the client, everybody else in the company should be working >to help them! > >Forgive me if this posting appears somewhat inflammatory, but your >first para really got my dander up. > > > >regards John B. >