XPost: alt.os.development   
   From: alexfru@chat.ru   
      
   "Ekrem SABAN"  wrote in message   
   news:dtclda$j7c$1@newsreader1.utanet.at...   
   >   
   >>> The project manager was responsible for the main fraim of the software,   
   >>> from   
   >>> where all the parts were called. And he had a lot of time to spend to   
   >>> find   
   >>> the errors (mostly memory errors) of the programmers.   
   >>   
   >> Poor quality personnel is always a bad thing.   
   >>   
   > Oh, come on, Maxim! Do not judge the personnel, but see the real-world!   
   > This is what you get in large projects.   
      
   There's enough crap in midsize and small projects too. You just don't see   
   the side effects because of the too little size.   
      
   > You cannot have a C/C++ expert at each position. What you need are a few   
   > experts who *really know* how to make a WORKING environment. It must be   
   > robust and not weak, i.e. allowing alot to do, and a lot of wrong-doing   
   > also... ;))   
   >   
   > An unrealistic way would be to throw away all the "coders" & employ   
   > specialists. Then, the program would be well, even if it is programmed in   
   > C, even if you use machine language! But then either   
   > (a) nobody will buy it either, as it is too expensive, or   
   > (b) a few happy customers will buy it, but the company will go bankrupt,   
   > as the price for the software does not cover the expenses.   
   >   
   > Nobody will accept that a plain programmer must be an expert.   
      
   And that is why? Because indeed nobody wants to pay great salaries to   
   specialists (well, at least decent programmers), hiring people (among which   
   there must be technical people, btw, to judge not only the resume and   
   personal characteristics but also put the person through a formal test   
   related to the position and work functions) and, god forbid, spend money for   
   keeping track of the quality/performance (through specifications and   
   testing) and actually even improving the worker's skills. If you see typical   
   bugs over and over again, find ways to get rid of them. No, don't clean up   
   after everyone. Explain them what's wrong with their code, make sure   
   everyone understood that and has no doubts about that, and force them to fix   
   it. If we don't invest into quality, we get crap. We basically buy what we   
   pay for. There're a couple of good Russian sayings: "We're not rich enough   
   to buy cheap things" and "The stingy pays twice" that address this.   
   Unfortunately, writing software isn't the same as sewing the clothes and   
   off-by-one bugs cost more than 1-millimeter-misplaced buttons and the more   
   people doesn't necessarily mean the faster or the better. It's not right to   
   think "everyone can do it". Of all the population only 20% can deal with   
   technical stuff in principle. Those 20% aren't all doing software and those   
   who are are subject to further selection. So, if we may want to pay less,   
   it's unreasonable to expect the quality.   
      
   > I would not accept to communicate with YOU, if I would need a physiologist   
   > that knows about YOUR exceptions and specialities in your body. That will   
   > be too expensive for me. I prefer to communicate with humans over a   
   > high-level protocol. I do not care about the carriage return at the end of   
   > my string. You do not have to know HOW you do process my words. It would   
   > be a terrible chore to communicate with others knowing ALL about their   
   > thinking process, the electro-chemical reactions in his nervous system, in   
   > his brain...   
   >   
   > Maxim, if you want to, you can see the problem from this way: stop to   
   > think that you can CHANGE the way people are thinking! YOU have to find   
   > the proper language for the people. Otherwise, what you get with large   
   > complexity is clearly A MESS.   
      
   Which is basically the same mess as in low complexity, simply multiplied by   
   the square (or some other degree) of the complexities' ratio. You could   
   stick with something more strict and better defined as C, but you'd probably   
   lose performance and that would still not save you from design problems. And   
   implementation bugs would still be there too, just different, never craching   
   the system but not working very well either (crappy user interface, stupid   
   logic, etc)...   
      
   ...   
   > So what is the realistic answer to THIS problem?? Quitting the SW   
   > industry?   
      
   Understanding and accepting its difference from a factory manufacturing   
   clothes or cars. Actually, if more people got killed as result of software   
   bugs (as in car crashes), we'd probably establish procedures for quality   
   control (throughout the entire process from design to implementation) and   
   solve the problem. Software doesn't seem to be threatening enough and so bad   
   quality is considered to be OK. But if it was...   
      
   ...   
   >> Their choice. Another large companies - like Microsoft, Oracle, Google   
   >> etc -   
   >> have efficient software development (doing it in C/C++/C# mainly, not Ada   
   >> or   
   >> Eiffel). So, this is the issue of _Siemens cannot organize efficient   
   >> software   
   >> development_, which is mostly HR issue, according to what you described   
   >> above.   
   >>   
   > Microsoft is efficient? Really?? What about comparisons between MS and   
   > other operating systems? Have you read any? What about the blue screens   
   > that occured so often before the xp-era?   
      
   That's due to the software youth, crappy non-NT kernel and absence of the   
   internet. Bad things improved it.   
      
   > And whatabout the stand-still with the new OS developments. MS decided in   
   > 2004 to restart all over again! The OS they developed at last (Windows xp)   
   > has such a high complexity that it cannot be handled anymore! They wanted   
   > to make a new OS that keeps all information in a DB. I forgot what they   
   > wanted to call it. But they started in 2001. In 2004, they told that it   
   > will be available in 2006. We will see if this deadline can be reached...   
   >   
   > Microsoft has a lot of AVERAGE PROGRAMMERS. That's why you have so many   
   > errors! They cannot afford to employ experts only.   
      
   They spend a lot of money to ensure they don't get a crappy coder. That's   
   for sure. As for bugs/errors, it's a business matter. The business side says   
   the acceptable rate and kind of errors/bugs. Unfortunately. Or fortunately.   
   One can look at it differently. Too much of testing (especially where   
   unnecessary) is going to cost money. Too little will testing and lots of   
   bugs won't bring much money. And then again, if your software or cellphone   
   or pair of shoes is going to be thrown away in a couple of years, who'd care   
   make it perfect. Good enough for a couple of years is perfect. It will be   
   replaced anyway, so. I can understand the bitterness of coming across of   
   crappy products, I hate that too, but that's the way to make money every   
   year by doing more or less the same things and keep people's jobs.   
      
   >> With hardcore C++ or Ada or such, this kind of personnel will do another   
   >> stupid   
   >> errors, mainly due to mis-understanding of the language features.   
   >>   
   > Again, the mis-understanding of a real high-level language is less   
   > possible, as the language IS the more high-level the more it FOLLOWS human   
   > thinking!   
   >   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)