There is another possible difference as well: I am not 100% sure about Linux, but at least on Windows, getting 0% CPU usage is impossible.
At least on all computer's I've used, there's a multitude of small programs running, each of which seems to want do wakeup briefly every second or so. I don't know why - most of them probably just want's to realize there's nothing for them to do and goes back to wait mode again. However, each of these wakeups, are potentially causing cache-misses, memory swap-ins and outs.
This is not nessecarrily the fault of Windows itself, but the applications running on a normal Windows box.
But the end result is the same - an "idle" Windows box excercises the memory more than it really would need to, just because of the behaviour of its applications.
Prevas is my employer, a scandinavian-based design house, specialized in developing intelligence in products and industrial systems for the world's leading companies. Over 550 consultants in these fields help make our clients more competitive through innovative, profitable, futureproof solutions.
Prevas is a publicly traded IT consulting company with rock-solid expertise and 20 years' experience. We are based in the Nordic countries and serve clients in a range of industries around the globe.
One of Prevas' strongest competitive advantages is our ability to deliver IT solutions at previously agreed upon terms. These terms might be regarding the functional requirements, financial requirements, or both.
* Prevas deliver 95% of its projects on time, with just 3% of all projects requiring warranty services upon completion.
* As far as customer satisfaction goes, our customer rate us at 8.6 on a scale of 1 to 10.
Prevas is a Microsoft Windows Embedded Gold Partner as well as National Instruments Alliance Program Partner, and - of course - have excellent relationship with selected PCB manufacturing plants that are capable of producing anything from prototype to million-unit series. Prevas also have exellent knowledge of the UL, CE, WEE, RoHS and other directives required for producing products for the major world markets.
Reference customers include both major companies such as Nokia, ABB, Panasonic, Siemens, Stoneridge, Volvo, and minor companies that are still growing, including start-ups.
Yes, this was done a couple of years ago in Sweden as a Master Thesis, which was described in Swedish Engineering paper Ny Teknik http://www.nyteknik.se/efter_jobbet/kaianders/article32986.ece (sorry, swedish only).
The student Marie Sandström tested a simple yello, which was created using the same method as mentioned in the article above, on three commercial fingerprint-readers on the CeBit fair in 2004.
I regulary use Understand C/C++ from SCITools (is available for Java and other languages) to browse source code (in my case, embedded sources that is supposed to be compiled using the Keil compiler). It's "right-click, for information" attetude makes browsing around a breeze. The reason is that it builds an internal database when loading the project (which takes a second or a few, depending on the size of the sources), and once built, the interface is astonishingly fast!
One of the things I like most, is that it also colours all parts of the code that is #ifdef'ed out. Another thing is that the information windows for any token displays all kind of information: calls, callees, references, uses (including sets/get/modifies), used locals, used globals, exposed globals etc - all of which in a tree view, so it is very easy to decide what's important and what's not.
It is possible to use it as an editor as well, which I do, but as such it isn't perfect.
Also, importing a completely new project requires almost no intervension - it will simply prompt for where any missing #includes are located and add them to the searchpath, so just setting it up for a quick test is done in no-time.
Working with embedded software, I know for a fact that things that intuitively ought to be more effiecent, doesn't nessecarrily be that. The only things that can be trusted is the compiler output - which is valid for that version alone, and might change if I change some other part of the code.
For example, for one loop, a=i++ became the best thing, but for another one, writing the code such that I could do a=++i was better!
In another (8-bit) compiler, writing to word was more effiecent than reading from a word, even though the CPU contained the requred instructions for equal effiecency.
When there's no particular need for speed, I just write for clarity. If I know that a function will be called several times, I sometimes make several attempts to find out what becomes the best code.
But in the end, leaving C and using the best possible assembler-algorithm might be the only option, since that way, for carfylly crafted code, I've experienced 5-10 times speed improvements, compared to the best possible algorithm in C.
I work in a company that produces products that are oftenly compared by performance by our customers. And as in many other trades, we and all our competitors regulary quote maximum attainable performance figures in the sales materials.
Of course, all customers know this, and regulary benchmark the products before making larger purchases.
Thus, of course we want or sales reps to be able to match the competitors figures, but in many cases it wouldn't be comparing apples with apples. Because of that, we are very open with our customers what and how we are measuring, when we get our numbers. And, since we don't want the customer to be unsatisfied, we make sure we perform measurments in relevant ways, too.
So when the customer performs his benchmarks, he will be able to receive figures in the same range.
If the customer wouldn't be able to reproduce our results, we would simply loose our reputation. And that simply wouldn't be worth it.
I work designing software for coin-processing machines. Coins make a great deal of noise (easily over 80dB, way above that when all the noise-cancelling hoods are removed for easy access during work), so I regulary use ear-protection while debugging.
Anyway, last winter, we were redesigning the office, so we all had to be cramped up in small spaces while the new offices were prepared. And a lot of equipment had to be stored away. Our new, sound-proof 2 by 3 meter sized testrooms were perfect for storing lots of prototypes, tools, sharp pieces of metal etc.
This was great if it wasn't for the fact that I had keep a few machines running as well in one of the testrooms in order to find a very nasty memory-trashing bug. Did I forget to mention that the rooms weren't just soundproof at the time? They were airproof as well. So the heat was way above 35C in the morning, before I turned all computers and test equipment on and put on my earprotections.
But the worst thing wasn't neither the heat or noise. It was actually the fact that the total free floor space was three small areas, each being the exact size of a foot, located half a meter apart with lots of equipment inbetween. Operating a machine or computer in that area required a masters degree in ballet, with a missed step not just a slight fall, but it surely would mean a severe accident, since all pieces stored away in that room had _really_ sharp, metallic edges, and really seemed to be in the perfect path of my head if I would fall. Each time I moved within that room I would remind myself of my wounded knee which still hasn't recovered from a small incident in a similar environment.
I spent approx 3 weeks in that room before I finally managed to locate and fix that bug. I surely don't miss that time at all.
as the best camera. Just stay with the larger brands such as Pentax, Nikon, Minolta or Canon, and you can't make a bad purchase. Most of the entry-cameras lack some features only found on the higher end ($600 and upwards) cameras, but you won't miss those features until you're good enough to consider the cost worth it.
Allmost all new cameras today are equipped with manual and autofocus, as well as manual and automatic aperture and shutterspeeds.
Personally, I own a Canon EOS 300, purchased a couple of years ago.
I think there's a few things done in Sweden that can explain some (although not all) reasons for Sweden being a good source of IT personell, and in some cases I believe the similar is true for the other nordic countries.
For Sweden, I think the reason is spelled Ericsson.
Why?
Take a look at these reasons:
GSM basestations. Ericsson is one of the leading developers of the technologies behind the GSM network, and most development is done in Sweden. However, they needed to be able to sell handsets as well to get telecos to purchase basestations. Thus, they do both. For Finland, Nokia is in a similar situation.
ENEA. Ericsson uses OSE from Swedish company ENEA in its products, and ENEA was the first internet node in Sweden, back in the days when Sweden was connected to USA using a dialup modem.
SUNET. ftp.sunet.se is not only a huge ftp server, it is also the name of the university backbone network which connects all major cities and a lot of minor cities, too.
Distances. Sweden is a looong country, approximately 3000 km's from top to bottom, with a fairly poor airline and train system. Videoconferences have always been seen as the solution to the long distances. Guess what the Uni's do research on, using which network and guess if the telecom business likes video?
Neutrality. Sweden has a policy of being a neutral nation. Because of this, Sweden manufactures and develops almost all of its militiary technologies like the SAAB (they don't manufacture cars, BTW) JAS 39 Gripen fighter plane, Kockums submarines etc, rather than purchasing US, UK, German, French or Russian-made military technologies, like most small countries do. And, yes, Ericsson does military equipment as well!
Growth. A couple of years ago, Ericsson was the #1 mobile phone manufacturer of the world, outselling Sony, Motorola, Siemens and Nokia, with a lot of resarch on 3G and UMTS being done. They had a need for every single Master and Bachelor of Computer and Electronic and Physics Engineering student being examinated every year alone. Guess if technology studies got popular?
Oki, there are a few other things as well, that does help Ericsson quite a bit:
Free education. The government pays even the university studies. All you have to pay for is food & living.
Subsidized computers. In Sweden, the taxes are redicilously high. But, since 5 years back, it is possible for everyone to purchase a computer through your employer at an approximat 50% (!) discount solely because of tax reductions, and it is totally costless for the employer!
Computers in school. A couple of years ago, a reform was done to increase the number of computers in schools. Well, contrary to what one would believe, the kids weren't really those in the most need for more computers, but the teachers were!
Former prime-minister Carl Bildt. Extremely technology friendly, he was the first MP to bring a lap-top (well, at the time the lap-tops were heavy enough to crush your lap in case you tried to put it there) into the parliament chamber for actual use - and he was almost thrown out of the chamber the first time he did it. It is claimed that he was the first prime-minister of any country to use e-mail to communicate with another prime-minister (which, of course, was the US president at the time).
IT-boom. There were a couple visionary geeks that knew how to speak that managed to start a couple of high-tech companies that needed a lot of people. Framtidsfabriken, Hardvarubolaget & Bredbandsbolaget had a vision of video-on-demand in every household. All started by the same person, they really wanted to make money on high-tech internet services, but they had to build the infrastructure in order to create the marked.
Teleco monopoly. This may sound strange, but: Telia had a monopoly on telephony and networking. Any
My initial reaction when reading your posting was of course Java - but of course - that would require a complete rewrite, which is out of the question. A decent rule-of-thumb is that a rewrite takes as long time as it took to get where you are now, despite the initial thought that "this time we make it right from the start".
The second alternative is to minimize the number of compiler versions used. Standardize on one that is available on all platforms (gcc comes to mind, since it can be run on most platforms, including windows). The platform-specific code probably needs a specific compiler, though.
However, if you manage to standardize more code than is currently being done on one compiler, it is also an indication that it really isn't platform-specific.
Thirdly, new applications might be written in Java, utilizing the JNI to get access to already written libraries. However, this would add one more configuration to test the libraries against as well, so it might even turn out to be counter-productive.
The fourth step is the step your customers don't want you to take; drop your support for the least used platform - or make sure you charge enough money to pay for the additional cost of supporting that platform - or the platform which is hardest to support, with "dedicated" engineers that provides "fixes" for that platform only, letting the main engineers focus on the main platforms.
Hopefully, not so many people are trapped by the spammer anymore, since it was written about in the largest newspapers in sweden.
Actually, in Sweden, it could be fraud to fool anyone to call a premium-rate service witouth notifying the caller (callee?) about the cost. Unfortunately, the swedish allmänna reklamationsnämnden (Better Business Bureau) don't accept claims on less than 300 SEK (~30).
How much responsibility do you think you have about your job, the project, and the company?
What is your actual responsibility?
Locate areas where new resources can help (doesn't need to be coding)
Reconsider your own role within the project
Do you want to be able to work with your coworkers in the future?
Quite some people have suggesting various kinds of threats, "show them the door" etc. to get the other's to realize the problem. Bad coding suggests inexperience rather than lack of interest, and I really don't think an inexperienced person will perfom better just because he's threatened.
What to do depends a lot on what your personal goal is, and what you're trying to save.
If you want to be doing design, coding etc., just stick with what you've been doing, and don't care about the others. Review your _actual_ responsibilities, not implied. Are you an appointed PM? If not, just go on, design and code, report your part as done as usual, mention the problems with integration tests for the PM etc. Your PM will recognize you as a good SW engineer, especially when he realizes the other's problems, and that will become his problem.
If you want to become a true PM, then your job will become solving these kind of problems. Learn from the situation, and just get used to it! Remember, a project without problems doesn't need a PM!
So, for the assumption you want to do something than just doing your part of the job, the next question is: What do you want to save? The project, or the company?
Even if you're very good, taking over the other's part probably won't help, unless they are only producing less than 15% of what you're capable of (remember that you're most likely going to throw most of their code away and restart, since if they still can't get it to compile, they are probably having major design problems as well).
Getting more resources are too late, you say. So did I at a project I was working on, but we were somehow always able to find isolated parts that could be done by external personell with fairly little support. Surely, support will be needed, so tell the PM that you're willing to sacrifice your own kloc-productivity, to concentrate on support. However, new resources can't rewrite existing code in an effiecent way. You will need to find parts that has little or none existing implementation.
If it's just the project you're wanting to save, make the new resources take parts of your fellows code, and let them work on small, well-isolated fragments of less importance.
However, this approach might intimidate them, and some might even start hating you. If they leave (or are forced to leave) that will be good for the company, but if they stay, productivity between you and them will be even lower whenever you need to cooperate again.
If you're thinking larger, make sure your colleguaes start seeing you as the mentor. Work with them and let them (mostly individually) ask for your guidance or asisstance. Offer to do boring work etc. Let them grow and give them confidence. Let any extra resources do what you used to do.
This is a larger risk for the project, but it will be the PM's job to convince management of that. However, your colleguaes will grow and become more productive in the future.
Also, remember that the program produced is a mix of time, resources, features and quality!
So, if there is too little time to introduce new development resources, try getting them at the test stage; Do integrations and builds as often as possible! Get testers to test whatever's done. Get testers to write unit tests, and perform intergration tests. Make sure they produce written step-by-step instructions of what works and what doesn't, so that the developers don't have to chase the bugs, just fix them! Let the testers re-test everyting that used to work (and everything that didn't work) with every new build.
I hope you all succeed in producing your application!
It would be kind of stupid to stamp 40x on a box just to sell it for a lower price. Why not sell a 48x for the lower price and intice the customer further?
Why? Not all can (or want to) pay the price for a 48X drive. The cost of manufacturing is probably something like 10-20% of the sales price, and the difference in component cost is most likely just 5% - of the few components that actually would need a change.
It's not at all unlikely that it's actually cheaper to manufacture several similiar boards with just a firmware difference than administrating several different modules.
So, they would just set a price for the max version thus gaining as much revenue as possible, and and another price for a crippled version, and sell that as well, for the people that won't pay the higher price.
/Flu
Bugs caused by development environment...
on
Pet Bugs?
·
· Score: 1
While I was learning C (several years ago), I had some great problems with gcc; I tried to bit-mask an ulong, but the result sometimes was quite unexpected.
On a non-gcc compiler, the result was correct. On gcc running on a motorola 68020 system, the result was correct, too, but the same gcc version on a sun sparc system returned random data in the two upper-most bits....
As a side-note, compiler bugs still cause me problems; The Keil C167 compiler I use at work doesn't support the %-operator between two ulongs. No compiler error, but random result when the code is executed! The debugger for that compiler isn't exactly bug-free, either:
Watches set on variables pointed out by pointers does most oftenly display data located at a random location, rather than the location pointed out by the pointer!
A PM with a technical background is by no way a guarantee for better management; Actually, IMHO, the damages caused by a technical, non-leader-type manager can be far worse than those caused by a non-technical leader-type manager.
The reason is, that a (good) leader-type manager is humble, acknowledges his own lack of technical insight and thus listens to his crew, while a technical manager might fully understand the schedule and risks, but is unable to resolve interpersonal conflicts, favour technical solutions instead of customer-requirements or simply fail to turn the upper-managements attention to important desicions.
I work for a machine-manufacturing company, where software is just one of many ingredients of a machine, and mechanical design is very important. Thus, our PM (and many others in leading positions) is a mechanical engineer from the start, but he is very open to suggestions and arguments from us software designers and gives us lots of freedom.
Despite his technical background, I rate him as a leader-type manager, because of his interpersonal skills and total lack of experience in research-driven projects.
Actually, we do leave some bugs in the Shuttle software for exactly that reason
At first I actually got surprised by you saying that the Shuttle does have bugs, but I quickly realized that my own wording of course applies to your development as well!:-)
I guess I got blinded by a quote made by my lecturer in SW Quality at the time, who claimed that the difference between a Level-4 and a Level-5 shop is that Level-4 can produce SW with very few bugs, and Level-5 can warrant that the SW is bug-free.
First of all, how many bugs are "too many"? Some bugs should (unless you're coding Space Shuttle Software) never be fixed; The hazzle they cause for some users will never justify the cost of fixing the bugs.
Next, unit- and integration-testing only detects so many bugs.
How many steps are there in the developement process?
An exampe of steps to take:
Writing specification
Writing analysis documents
Writing design documents
Writing code
White-box testing code
Black-box testing testing
Unit testing code
Integration testing code
Acceptance-testing the product
Writing test specification for each of the test steps
And, of course, for each document (specification, code as well as test code and its result) produced, a FORMAL REVIEW of that document also counts as a step in the process.
One rule-of-thumb I've learnt is that each step in the process cuts the number of remaining bugs to half. (A bug found in the specification might cause 10000 bugs to be detected in testing).
Thus, assuming that a 64kloc program must contain less than one bug, at least 16 steps must be involved.
Both your solutions are good, but in different situations:
If isNotNull and isNotEmpty are together only at that spot, then the latter suggestion is much better than the first, unless the expression is obscure (for example if the variables would be names isOneLeft and isTwoRight), or very complex, or the comparation needs to be done several times.
In those cases, a well-named constant boolean can actually make the code more readable than a (potentially invalid) comment.
We started using a standard commenting-style which differentiated between a comment that is valid for a single-line only and a comment that is valid for a group of lines.
Of course, single-line comments starting at the end of the line are simple to understand, but when the line is 80 chars+, and the comment is too, things get hairy.
So we simply did
// This comment is valid for // the next code-line, only. doSomething();
longVariableName = doSomethingReallyLongAndHairy() + anotherLongFunctionName();// And the above comment style // is better than this for a single line.
doSomethingAgain();// But we do allow this for short lines.
// // However, this comment is valid for all code // lines until the next comment of this kind // is used, or until the next }-brace appears in // the code. //
Apart from that, we also use self-describing names (unless they get too (>40 characters) long). This definitely reduces the need for comments. We also try to minimize the number of sequences in a single function.
Another good thing we started with was adding notaion of in-, out- and in-and-out parameters, to separate them from auto's and globals.
Parameters that are in (readonly) always start with i, parameters that are pointers to uninitialized buffers that are initialized by the funcion starts with o, parameters that point to initialized buffers that are modified starts with io, all variables defined in a function starts with t (yes, could be confused with types, we really should have selected another letter instead), and all attributes starts with m.
This way, we never accidently create bugs by accessing a local instead of a parameter or a global or static variable, or an attribute, which we found was a Good Thing(tm). Also, the parameter list became more self-describing.
If a single ad-publisher gets $0.25M in commision just for running ads for "escorts", I would guess the organization behind the prostitutes gets _lots_ more.
Say, 75% of the prostitutes' income, then another 90% of their money as they buy their drugs.
There are biiig money involved behind the scenes. Street violence, bodies of gang-members in the bushes etc, is only what "we" see of the underground world, but they surely have the resources to use technology as well for their purposes.
Getting a competitor out of business using non-violent methods might not be as "impressive" (or frigthening) among the other competitors, but surely doesn't attract the police and media as much.
That is actually a very common problem among the currencies of the world. I work as a software designer for a company that manufactures coin-sorting machines that are able to identify and reject coins that was incorrectly accepted by your local cigarette-automat, and we get reports of collisions between currencies all the time.
Just think about it; There are some 200 countries in the world. Assume they all have 10 different coins in circulation (some of the coins are old and have been replaced by newer versions, but still). That makes 2000 different coins in the world.
The mints only have a few parameters to work with; physical size being the most obvious, but also the metal combination and alloys in different layers.
Also, since there are several manufacturers of coin-accepting modules used in the various automats, there are several different methods used to identify the coins, and a certain collision may be present in equipment from one manufacturer, but not from another.
Slashdot Mirror
At least on all computer's I've used, there's a multitude of small programs running, each of which seems to want do wakeup briefly every second or so. I don't know why - most of them probably just want's to realize there's nothing for them to do and goes back to wait mode again. However, each of these wakeups, are potentially causing cache-misses, memory swap-ins and outs.
This is not nessecarrily the fault of Windows itself, but the applications running on a normal Windows box. But the end result is the same - an "idle" Windows box excercises the memory more than it really would need to, just because of the behaviour of its applications.
Prevas is my employer, a scandinavian-based design house, specialized in developing intelligence in products and industrial systems for the world's leading companies. Over 550 consultants in these fields help make our clients more competitive through innovative, profitable, futureproof solutions.
Prevas is a publicly traded IT consulting company with rock-solid expertise and 20 years' experience. We are based in the Nordic countries and serve clients in a range of industries around the globe.
One of Prevas' strongest competitive advantages is our ability to deliver IT solutions at previously agreed upon terms. These terms might be regarding the functional requirements, financial requirements, or both.
* Prevas deliver 95% of its projects on time, with just 3% of all projects requiring warranty services upon completion.
* As far as customer satisfaction goes, our customer rate us at 8.6 on a scale of 1 to 10.
Prevas is a Microsoft Windows Embedded Gold Partner as well as National Instruments Alliance Program Partner, and - of course - have excellent relationship with selected PCB manufacturing plants that are capable of producing anything from prototype to million-unit series. Prevas also have exellent knowledge of the UL, CE, WEE, RoHS and other directives required for producing products for the major world markets.
Reference customers include both major companies such as Nokia, ABB, Panasonic, Siemens, Stoneridge, Volvo, and minor companies that are still growing, including start-ups.
In the rest of the world, the copyright _always_ belongs to the original author. But USA never wants to do what the rest of the world does...
Yes, this was done a couple of years ago in Sweden as a Master Thesis, which was described in Swedish Engineering paper Ny Teknik http://www.nyteknik.se/efter_jobbet/kaianders/article32986.ece (sorry, swedish only). The student Marie Sandström tested a simple yello, which was created using the same method as mentioned in the article above, on three commercial fingerprint-readers on the CeBit fair in 2004.
One of the things I like most, is that it also colours all parts of the code that is #ifdef'ed out. Another thing is that the information windows for any token displays all kind of information: calls, callees, references, uses (including sets/get/modifies), used locals, used globals, exposed globals etc - all of which in a tree view, so it is very easy to decide what's important and what's not.
It is possible to use it as an editor as well, which I do, but as such it isn't perfect.
Also, importing a completely new project requires almost no intervension - it will simply prompt for where any missing #includes are located and add them to the searchpath, so just setting it up for a quick test is done in no-time.
For example, for one loop, a=i++ became the best thing, but for another one, writing the code such that I could do a=++i was better!
In another (8-bit) compiler, writing to word was more effiecent than reading from a word, even though the CPU contained the requred instructions for equal effiecency.
When there's no particular need for speed, I just write for clarity. If I know that a function will be called several times, I sometimes make several attempts to find out what becomes the best code.
But in the end, leaving C and using the best possible assembler-algorithm might be the only option, since that way, for carfylly crafted code, I've experienced 5-10 times speed improvements, compared to the best possible algorithm in C.
Or Would someone be willing to pay a russian hacker $10.000 to create a virus that infects 100.000 zombie PCs and runs the decryption overnight?
Thus, of course we want or sales reps to be able to match the competitors figures, but in many cases it wouldn't be comparing apples with apples. Because of that, we are very open with our customers what and how we are measuring, when we get our numbers. And, since we don't want the customer to be unsatisfied, we make sure we perform measurments in relevant ways, too. So when the customer performs his benchmarks, he will be able to receive figures in the same range.
If the customer wouldn't be able to reproduce our results, we would simply loose our reputation. And that simply wouldn't be worth it.
Anyway, last winter, we were redesigning the office, so we all had to be cramped up in small spaces while the new offices were prepared. And a lot of equipment had to be stored away. Our new, sound-proof 2 by 3 meter sized testrooms were perfect for storing lots of prototypes, tools, sharp pieces of metal etc.
This was great if it wasn't for the fact that I had keep a few machines running as well in one of the testrooms in order to find a very nasty memory-trashing bug. Did I forget to mention that the rooms weren't just soundproof at the time? They were airproof as well. So the heat was way above 35C in the morning, before I turned all computers and test equipment on and put on my earprotections.
But the worst thing wasn't neither the heat or noise. It was actually the fact that the total free floor space was three small areas, each being the exact size of a foot, located half a meter apart with lots of equipment inbetween. Operating a machine or computer in that area required a masters degree in ballet, with a missed step not just a slight fall, but it surely would mean a severe accident, since all pieces stored away in that room had _really_ sharp, metallic edges, and really seemed to be in the perfect path of my head if I would fall. Each time I moved within that room I would remind myself of my wounded knee which still hasn't recovered from a small incident in a similar environment.
I spent approx 3 weeks in that room before I finally managed to locate and fix that bug. I surely don't miss that time at all.
Allmost all new cameras today are equipped with manual and autofocus, as well as manual and automatic aperture and shutterspeeds.
Personally, I own a Canon EOS 300, purchased a couple of years ago.
Yes, of course, but we don't have to pay the uni' for its costs, like in most countries.
That's why the retirement age has to be increased from 65 to 79 by the time we're about to retire...
For Sweden, I think the reason is spelled Ericsson.
Why?
Take a look at these reasons:
Oki, there are a few other things as well, that does help Ericsson quite a bit:
My initial reaction when reading your posting was of course Java - but of course - that would require a complete rewrite, which is out of the question. A decent rule-of-thumb is that a rewrite takes as long time as it took to get where you are now, despite the initial thought that "this time we make it right from the start".
The second alternative is to minimize the number of compiler versions used. Standardize on one that is available on all platforms (gcc comes to mind, since it can be run on most platforms, including windows). The platform-specific code probably needs a specific compiler, though.
However, if you manage to standardize more code than is currently being done on one compiler, it is also an indication that it really isn't platform-specific.
Thirdly, new applications might be written in Java, utilizing the JNI to get access to already written libraries. However, this would add one more configuration to test the libraries against as well, so it might even turn out to be counter-productive.
The fourth step is the step your customers don't want you to take; drop your support for the least used platform - or make sure you charge enough money to pay for the additional cost of supporting that platform - or the platform which is hardest to support, with "dedicated" engineers that provides "fixes" for that platform only, letting the main engineers focus on the main platforms.
Actually, in Sweden, it could be fraud to fool anyone to call a premium-rate service witouth notifying the caller (callee?) about the cost. Unfortunately, the swedish allmänna reklamationsnämnden (Better Business Bureau) don't accept claims on less than 300 SEK (~30).
Quite some people have suggesting various kinds of threats, "show them the door" etc. to get the other's to realize the problem. Bad coding suggests inexperience rather than lack of interest, and I really don't think an inexperienced person will perfom better just because he's threatened.
What to do depends a lot on what your personal goal is, and what you're trying to save.
If you want to be doing design, coding etc., just stick with what you've been doing, and don't care about the others. Review your _actual_ responsibilities, not implied. Are you an appointed PM? If not, just go on, design and code, report your part as done as usual, mention the problems with integration tests for the PM etc. Your PM will recognize you as a good SW engineer, especially when he realizes the other's problems, and that will become his problem.
If you want to become a true PM, then your job will become solving these kind of problems. Learn from the situation, and just get used to it! Remember, a project without problems doesn't need a PM!
So, for the assumption you want to do something than just doing your part of the job, the next question is: What do you want to save? The project, or the company?
Even if you're very good, taking over the other's part probably won't help, unless they are only producing less than 15% of what you're capable of (remember that you're most likely going to throw most of their code away and restart, since if they still can't get it to compile, they are probably having major design problems as well).
Getting more resources are too late, you say. So did I at a project I was working on, but we were somehow always able to find isolated parts that could be done by external personell with fairly little support. Surely, support will be needed, so tell the PM that you're willing to sacrifice your own kloc-productivity, to concentrate on support. However, new resources can't rewrite existing code in an effiecent way. You will need to find parts that has little or none existing implementation.
If it's just the project you're wanting to save, make the new resources take parts of your fellows code, and let them work on small, well-isolated fragments of less importance.
However, this approach might intimidate them, and some might even start hating you. If they leave (or are forced to leave) that will be good for the company, but if they stay, productivity between you and them will be even lower whenever you need to cooperate again.
If you're thinking larger, make sure your colleguaes start seeing you as the mentor. Work with them and let them (mostly individually) ask for your guidance or asisstance. Offer to do boring work etc. Let them grow and give them confidence. Let any extra resources do what you used to do.
This is a larger risk for the project, but it will be the PM's job to convince management of that. However, your colleguaes will grow and become more productive in the future.
Also, remember that the program produced is a mix of time, resources, features and quality!
So, if there is too little time to introduce new development resources, try getting them at the test stage; Do integrations and builds as often as possible! Get testers to test whatever's done. Get testers to write unit tests, and perform intergration tests. Make sure they produce written step-by-step instructions of what works and what doesn't, so that the developers don't have to chase the bugs, just fix them! Let the testers re-test everyting that used to work (and everything that didn't work) with every new build.
I hope you all succeed in producing your application!
Software Designer
Why? Not all can (or want to) pay the price for a 48X drive. The cost of manufacturing is probably something like 10-20% of the sales price, and the difference in component cost is most likely just 5% - of the few components that actually would need a change.
It's not at all unlikely that it's actually cheaper to manufacture several similiar boards with just a firmware difference than administrating several different modules.
So, they would just set a price for the max version thus gaining as much revenue as possible, and and another price for a crippled version, and sell that as well, for the people that won't pay the higher price.
On a non-gcc compiler, the result was correct. On gcc running on a motorola 68020 system, the result was correct, too, but the same gcc version on a sun sparc system returned random data in the two upper-most bits....
As a side-note, compiler bugs still cause me problems; The Keil C167 compiler I use at work doesn't support the %-operator between two ulongs. No compiler error, but random result when the code is executed! The debugger for that compiler isn't exactly bug-free, either: Watches set on variables pointed out by pointers does most oftenly display data located at a random location, rather than the location pointed out by the pointer!
Software Designer
The reason is, that a (good) leader-type manager is humble, acknowledges his own lack of technical insight and thus listens to his crew, while a technical manager might fully understand the schedule and risks, but is unable to resolve interpersonal conflicts, favour technical solutions instead of customer-requirements or simply fail to turn the upper-managements attention to important desicions.
I work for a machine-manufacturing company, where software is just one of many ingredients of a machine, and mechanical design is very important. Thus, our PM (and many others in leading positions) is a mechanical engineer from the start, but he is very open to suggestions and arguments from us software designers and gives us lots of freedom.
Despite his technical background, I rate him as a leader-type manager, because of his interpersonal skills and total lack of experience in research-driven projects.
At first I actually got surprised by you saying that the Shuttle does have bugs, but I quickly realized that my own wording of course applies to your development as well! :-)
I guess I got blinded by a quote made by my lecturer in SW Quality at the time, who claimed that the difference between a Level-4 and a Level-5 shop is that Level-4 can produce SW with very few bugs, and Level-5 can warrant that the SW is bug-free.
Software Designer
Next, unit- and integration-testing only detects so many bugs.
How many steps are there in the developement process?
An exampe of steps to take:
And, of course, for each document (specification, code as well as test code and its result) produced, a FORMAL REVIEW of that document also counts as a step in the process.
One rule-of-thumb I've learnt is that each step in the process cuts the number of remaining bugs to half. (A bug found in the specification might cause 10000 bugs to be detected in testing).
Thus, assuming that a 64kloc program must contain less than one bug, at least 16 steps must be involved.
If isNotNull and isNotEmpty are together only at that spot, then the latter suggestion is much better than the first, unless the expression is obscure (for example if the variables would be names isOneLeft and isTwoRight), or very complex, or the comparation needs to be done several times.
In those cases, a well-named constant boolean can actually make the code more readable than a (potentially invalid) comment.
Another good thing we started with was adding notaion of in-, out- and in-and-out parameters, to separate them from auto's and globals.
Parameters that are in (readonly) always start with i, parameters that are pointers to uninitialized buffers that are initialized by the funcion starts with o, parameters that point to initialized buffers that are modified starts with io, all variables defined in a function starts with t (yes, could be confused with types, we really should have selected another letter instead), and all attributes starts with m.
This way, we never accidently create bugs by accessing a local instead of a parameter or a global or static variable, or an attribute, which we found was a Good Thing(tm). Also, the parameter list became more self-describing.
Say, 75% of the prostitutes' income, then another 90% of their money as they buy their drugs.
There are biiig money involved behind the scenes. Street violence, bodies of gang-members in the bushes etc, is only what "we" see of the underground world, but they surely have the resources to use technology as well for their purposes.
Getting a competitor out of business using non-violent methods might not be as "impressive" (or frigthening) among the other competitors, but surely doesn't attract the police and media as much.
Just think about it; There are some 200 countries in the world. Assume they all have 10 different coins in circulation (some of the coins are old and have been replaced by newer versions, but still). That makes 2000 different coins in the world.
The mints only have a few parameters to work with; physical size being the most obvious, but also the metal combination and alloys in different layers.
Also, since there are several manufacturers of coin-accepting modules used in the various automats, there are several different methods used to identify the coins, and a certain collision may be present in equipment from one manufacturer, but not from another.