I would not be surprised if programming job opportunities doubled in less than 3 years!
The catch is, you need to move to a third word country to get one of those new programming jobs, or at least be willing to work at 3rd world rates.
Depends on the job. Not all of us program database frontends and order entry systems. I work for a company that builds medical instruments. Until a few months ago, my department (SW development) was actively hiring (we're now fully staffed) and employees are offered a nice bonus if they recommend someone who gets hired. So I asked a few people, but the result surprised me: people are scared that "what if I have a bug in my code and it kills someone?" Forgetting for a moment that it's unlikely that such a major defect would get past our QA processes, I was really surprised that people would rather stick to doing boring, easy work than interesting, if more involved development. I've often wondered how many people stick to coding where defects have little importance rather than take a more interesting job where errors are more critical (and so your code is scrutinized, more thoroughly tested, etc). In other words, taking the path of least resistance. IMO, those are the types of jobs more likely to be moved overseas.
But with zero revenue deductions are not that usefull.
Not so. As a Schedule C business, even if all he has are startup costs, they're still deductible from his personal income, but they must be amortized over 3 (5?) years. But realistically, if you have no revenues at all, you'd better have excellent records if you want to prove you're a business.
You are a consultant because they are going to you for advice, in addition to implementation -- if you were there solely for implementation, your title would be "Gofer" or some such.
Hear, hear!! This question isn't only relevant to consultants/contractors. As a software engineer employee it's my responsibility to question decisions I feel are wrong. I'm not just paid to pound out code and documents, but to evaluate what I'm asked to do and find the appropriate path to a solution. In fact, the ACM code of ethics covers this somewhere (I'm just too lazy right now to read the whole thing to find out where:-) In fact, this goes beyond ethics: bad decisions by your employer can cause the company that employs you to fail
While I think this device is ridiculouly overpriced for what it does... nuked food generally isn't too tasy anyway, they're on the right track. I considered converting a coffeepot into an oatmeal cooker cause I like oatmeal, and I was running out of time to make it right in the morning (hate that instant craap!!) Fortunately I figured out the problem was just that I needed to get up earlier, so I started going to bed 15 min earlier. But I digress. A better idea would be a crockpot that refrigerated the food. I often used my crockpot when I knew I'd be home late (like on a night when I had a 3-hour class after work and wouldn't be home before 9:30). If I could put meat, veggies, spices, etc in it the night before and keep them refrigerated until the morning at which point it would begin slow cooking, then we're on to something. This a couple of Peltier devices could handle. It should be pretty easy to convert a regular crock pot to do this. I'll have to see if I can get some cast off Peltier coolers from work to try it. Might even be a reason to build a website with instructions:-)
Lets get some facts correct. In most of the US, you are an engineer if you study engineering in college, be it electrical, mechanical, etc. To manage projects in civil engineering you have to be a licensed Professional Engineer (P.E.). That
No! In most of the US, it doesn't matter if you have an engineering degree or not; you cannot hold yourself out as an Engineer to the public in the sense that you can't call your company "Joe Sixpack Engineering" unless you have a P.E. after your name. You can work as an engineer and use that title on your resume, but not as a business name.
The whole point of the P.E. (in whatever field) is that the holder is expected to have met a certain minimum level of competency and experience and has been recommended. It is not a guarantee that he is capable of doing the work, but it's highly probable that he can.
I also have a bachelor's in EE and considered getting my PE years ago, but after looking into the process, concluded that it didn't offer me any advantages, so I bailed. Personally, I think the areas that they test are a bit of a stretch, but I can generally understand what the tests are trying to accomplish.
I also had another throught: imagine the world once we really get serious about robotics. Robot cars, domestic droids, etc. Software engineering could very well become a safety issue.
Could become a safety issue?? I've got news for you dude: software engineering has been a safety issue for decades. Sure, it may not harm anyone if your spreadsheet crashes, but medical devices, avionics, engine controllers, brake systems all have significant software content and are often safety-critical systems. There's an entire body of research dedicated to safety critical software systems. Read Nancy Leveson's excellent paper comparing the current state of software to that of steam boiler design in the 19th century. It's an eye-opener.
As far as the previous poster's comment that after design, everything is boring: I have to disagree. Like all other forms of engineering, once the design is done, actually getting it to work is another task in itself!
It is a matter of perspective: it's a matter of how you approach "failure." On my last two job interviews (got both jobs) I told how a previous employer was sued over a product I designed. The interviewers and I always laugh about it because the whole story is a tragedy of how not to run a business. The point I make by telling that story is that I understand how contracts can go bad and the right and wrong way to respond to it. It also demonstrates that I know to pay attention to the customer's wishes. Most interviewers respect someone who knows more about how business works than just how much C++/Java I can churn out each day.
Now, from the perspective of some posters, anything that went wrong should be hidden because it might work against you. I disagree: show that you learned from your mistakes, or better yet, from the mistakes of others.No-one expects you to be perfect. Experience is valuable!
Heh. The point I was getting at with this train of thought was that you wouldn't have to heat a huge stick of metal. You could make it AA-battery powered instead of wall-powered, and it wouldn't have to contain volatile fuels like butane to make it portable.
It really doesn't matter what the source is: you still have to put X joules of heat into the metal to raise its temperature Y degrees. I doubt you could get enough energy out of a couple of AA cells to do much more than a solder joint or two.
This is interesting. I have a basement full of old ICs including drivers, microprocessors, digital/analog devices and thousands of LEDS and other things I've bought surplus over the years for various projects. I've thought of packaging them up into little "hobbyist paks" and selling on EBay, but never could think of what kind of project to sell them for. Perhaps a kit with parts like a UDN2987 octal driver, 8 leds, a connector and a schematic showing how to build a parallel port I/O interface along with some Linux C driver code for $15-20 shipping included? I think I even have artwork for a PCB I made to do this years ago!
Think anyone would be interested?
Then again, do I really want to deal with the support emails from people who can't hold the right end of a soldering iron...
So, maybe you'd think that we'd all be more free if the government tells us what we can and can not drive, or if you think you should dictate my life based on your preferences, but personally, I don't care. There are things out there that pollute much more than my SUV, and I don't just mean cars. So, yeah, I guess you could say I am 'aiding the terrorists' in your mind. Personally, I'd rather be considered doing that than removing freedoms of those wishing to drive whatever the hell they want to
man, if I had points, I'd mod you up to infinity!! I'm so sick of these "you must only drive the vehicle we deem environmentally correct and then only when absolutely necessary" idiots!!! FWIW I own both an SUV and an old Toyota 4x4 pickup modded for offroading. I have no apologies for either. I drive them cause I like trucks. No other reason.
This guy is absolutely right and it's frightening to read all the responses along the lines of "nothing is perfect, so it makes no difference that Linux is being used." For those of you who think that nothing bad could happen, please read up on Therac 25 [uoguelph.ca]. Perhaps the drill would "just shut off" if the power went off, but what if the user accidentally enters errorneous data which was not anticipated?
The Linux kernel was almost definitely not inteded for use in brain surgery. Frankly, if I were contributing to the kernel I would be very
The very nature of software development means that operating systems are always being used for things they weren't intended. In the medical device industry we are well aware of the safety issues surrounding the software we write and a great deal of evaluation time goes into choosing tools and platforms.
And as far as Therac-25 goes, my opinion is that a large part of those problems were caused by the very lax attitude of the FDA to medical device software back then. Things have changed!
An interesting contrast to this is in embedded development. I can't think of a single embedded designer who doesn't consider tools, esp. debugging tools, when choosing a processor for a project. No, they're not sexy, but they can make or break a project.
6) Don't go into business with a partner. They'll want to do it their way. You're better off working alone. If you insist on doing a partnership, organize yourself in such a way that they are running their own business and you are running your own business, and you work togethor for a common goal
I have to agree with this... sorta. When I was starting my business with a partner, everyone told me that partners were trouble. Well she wasnt. She had her own skillset that I didn't -- she was an engineer who was really good at sales. But in time, I became better at sales and cold-calling and for other reasons we decided that it was best if we split up, so the partnership became two sole proprietorships. She got new business or took orders from existing customers and sent them to me. I deducted a fixed percentage for Cost of Good Sold and we split gross profit 50/50. Worked really well.
We both had extensive customer contact at our old job, so we knew what customers wanted. I had told my boss, but he was reluctant, so we started a company to build and sell the product ourselves. The first place to look for unfulfilled customer needs is in the domain you already know: your day job.
Whether the input is supplied digitally or analog makes no difference. At some point it will be converted to analog. Your CD experiment isn't going to work for the purposes you want: you will find a volume setting where a test tone CD will produce distortion, but pop in a different CD (or tape, or tuner...) and the output volume will be different cause that media was mastered at a different level. I think you're stuck with just turning the volume down when it gets too distorted, just like the rest of us:-)
this was my guess, but to get that 70w output do I set the volume to -2db or -20db?
Doesn't matter: i.e., you don't get a fixed x watts out at 20% volume knob rotation and 2x at 40%. It depends on the input signal. At say, 50% knob setting, a quiet music passage may result in 3W out to the speakers, a second later, someone banging a big drum can result in 100W out. Input signal amplitude and volume control (which is usually just an input attenuator) combine to produce an excitation signal whose amplitude, or level, determines what the output level of the amp is. Hope I explained that clearly:-)
Reuse of components can help -- the problem is that a component that doesn't behave EXACTLY the way a given developer wants it to is often discarded in favor of custom code. No electrical engineer would design their own timer circuit when a simple 555 might be adequate. But this kind of thing happens in software development all the time because it's relatively easy to do.
If you buy into my little pet theory, most of the problems associated with software development will likely remain with us for some time to come.
I agree with your little theory:-) Actually I've been wondering for some time why we can't build software the way we build hardware: by gluing together mostly off the shelf parts and adding some custom business logic. I think the problem is that, to use your 555 example, if the part doesn't exactly fit the requirement, we adjust the circuit elsewhere so a 555 will be fine (perhaps the powersupply is too high -- add a regulator) because we realize it would take a LOT of time to design a replacement that meets all the specs of a 555 that are important to us. But in software, the "engineer" thinks, "damn component is useless, I'll just create a replacement myself" and usually ends up with something that just barely works under the conditions he happens to use it, and the minute the program is stressed or gets out of range data, or other common occurrence, his poorly build custom component fails.
We are well on the way to building software by components -- for the most part we use COTS databases, operating systems, compilers, and some lower level components such as XML parsers and libraries. But to go farther we need interchangeable "software parts" (think 74xx TTL) that are fully spec'd and glue together easily (I think this latter part is going to require increased use of frameworks).
I should start reading up some more on frameworks that are out there. Perhaps look into creating some for the embedded systems I work on.
Engineers tend to deals with physical structures that need to be built and tested. That means that they are more likely to carefully consider their design, and borrow from previous designs
Bingo!!! One of Boehm's (?) "essential problems" of software is that because it is so easily changed, there is great pressure to make changes on a whim. But incremental engineering can be one of software's strengths when applied properly: the customer can start using the product before it's completed.
To the original poster: perhaps a better way of teaching software would be to give students examples of OK and bad solutions to problems they are assigned and ask them to improve on the good solution while avoiding problems in the bad one. I agree that most students don't get an opportunity to see the difference between good and bad code...or good and bad designs for that matter.
especially entertain the possibility that observing fine code written by masters just might improve your own. The Master of Software Arts sounds like an acheivement to be proud of.
This part I agree with. When I took my Software Project Management course, the two most useful aspects were listening to the war stories of this 60+ year old instructor with tons of experience and reading business case studies. Similar thing in my Software Quality Assurance and also OO Patterns classs. Seeing how software projects failed, and in some cases killed people really drives home the point that QA is not to be ignored and teaches how to (hopefully) avoid making the same mistakes they did. So I do believe that learning by seeing what others have done is a powerful tool. But where his argument falls apart is in treating it like an art. Engineering is already considered a creative process, but it's a disciplined creative process. The problem with software, as earlier posters have said, isn't too much engineering; it's too little.
down into simpler components, etc, etc, etc. Fact is that the tools keep changing but the tool users don't, thereby negating many of the benefits of having "better" tools. Crappy code is crappy code regardless of the methodology behind it, the fact that is crappy in an object
I wholeheartedly agree, but that's not the point. An expert craftsman will produce good work whether he has good tools or not; but the reason craftspeople invest in good tools is that it makes their work easier and faster. A large part of the problem is people keep expecting that tools will make mediocre developers into expert ones; they won't, but they will make the expert developers immensely more productive. And that's what really matter.
I have a degree in Computer Science, but most places I work give me the title of Software Engineer. I took some of the same classes that my friends took (mechanical, electrical). But something I mull around every so often is - does software really require engineering? It is a little more wooly than something like building a bridge, or a roadway, or electrical circuitry. With the advent of a new language, or method of developing, the whole ballgame can change
Well, I have a degree in Electrical Engineering and (almost:) one in Software Engineering. Some (but not all) software does require engineering, in much the same way that some, but not all electronic products require engineering. If I'm building a blinky-lights toy for my kid, I'm probably not even going to draw a schematic of the circuit; just do it all in my head. If I'm designing an aircraft fuel pump controller, you bet your ass I will follow rigorous engineering methods. You fit the development model to the thing being developed.
The ballgame does not change just because of language or method changes, it should just adapt. The entire reason for engineering in any product is predictability. Be it predictable cost, predictable quality, or predictable delivery. Now, before you explode in laughter, let me clarify that it doesn't guarantee that the predictions will be perfect, or even good. But they're a whole lot better than just the off-the-cuff guesses that passes for most SW development these days. The creation of software fits perfectly into engineering molds: we do it at work every day, and not all of us have engineering backgrounds. A large part of the problem is that it is apparently easy to change software, so it's easy to not take it too seriously and not follow any particular process. But look at even the garage down the street: mechanics will follow a process (even if it's a simple one) when quoting a price then repairing your car. Mistakes there are harder to fix than just an edit and recompile, so people are more careful about what they do. In software, only personal discipline makes us follow a process, and too many developers have none.
As I've been following their progress, many of the electrical/electronics problems they've had were obvious from the descriptions given: noisy sensors, ground loops in power, etc. There have been many times when reading the archives I thought "that's going to cause trouble..." and sure enough, I get to the next archive and it did. Problems any EE with a few years experience would have seen immediately.
So, why are there no EEs on the project? It doesn't even have to cost them. I'm sure that many experienced engineers would happily volunteer a few hours a month if only to review their designs. Hell, if they were doing it around here I'd happily offer my time just to be involved with a really cool project.
The thing that really bothers me is, if as an EE myself, I see such glaring errors, how many problems are the aerospace engineers reading the archives also predicting?
Don't get me wrong; I think these guys are reallly inspiring, but they could probably move a lot faster if they had expert help in a few fields they might be weak in.
There is a lot to be said (from an educational and a practical viewpoint) for doing your further study while you are working. An employer with their head screwed on will support you, and you will be able to relate your learning to real-life.
I have to agree with this. I'm almost done with my MS in Software Engineering, and there are many concepts that would not have fully sunk in were it not for work experience I could relate them to. Conversely, many things I learned in class I was able to try out at work on production practices, and received good feedback on the useful(less)ness. I'm one of those people who learns best by doing and real work often brings up issues that the toy projects of classwork can't. Plus the fact that my employer picks up the full tab for education doesn't hurt:-) Private universities ain't cheap!!
Slashdot Mirror
Depends on the job. Not all of us program database frontends and order entry systems. I work for a company that builds medical instruments. Until a few months ago, my department (SW development) was actively hiring (we're now fully staffed) and employees are offered a nice bonus if they recommend someone who gets hired. So I asked a few people, but the result surprised me: people are scared that "what if I have a bug in my code and it kills someone?"
Forgetting for a moment that it's unlikely that such a major defect would get past our QA processes, I was really surprised that people would rather stick to doing boring, easy work than interesting, if more involved development.
I've often wondered how many people stick to coding where defects have little importance rather than take a more interesting job where errors are more critical (and so your code is scrutinized, more thoroughly tested, etc). In other words, taking the path of least resistance. IMO, those are the types of jobs more likely to be moved overseas.
Not so. As a Schedule C business, even if all he has are startup costs, they're still deductible from his personal income, but they must be amortized over 3 (5?) years.
But realistically, if you have no revenues at all, you'd better have excellent records if you want to prove you're a business.
Hear, hear!!
This question isn't only relevant to consultants/contractors. As a software engineer employee it's my responsibility to question decisions I feel are wrong. I'm not just paid to pound out code and documents, but to evaluate what I'm asked to do and find the appropriate path to a solution. In fact, the ACM code of ethics covers this somewhere (I'm just too lazy right now to read the whole thing to find out where
In fact, this goes beyond ethics: bad decisions by your employer can cause the company that employs you to fail
While I think this device is ridiculouly overpriced for what it does... nuked food generally isn't too tasy anyway, they're on the right track. I considered converting a coffeepot into an oatmeal cooker cause I like oatmeal, and I was running out of time to make it right in the morning (hate that instant craap!!) Fortunately I figured out the problem was just that I needed to get up earlier, so I started going to bed 15 min earlier. But I digress. A better idea would be a crockpot that refrigerated the food. I often used my crockpot when I knew I'd be home late (like on a night when I had a 3-hour class after work and wouldn't be home before 9:30). If I could put meat, veggies, spices, etc in it the night before and keep them refrigerated until the morning at which point it would begin slow cooking, then we're on to something. This a couple of Peltier devices could handle. It should be pretty easy to convert a regular crock pot to do this. I'll have to see if I can get some cast off Peltier coolers from work to try it. :-)
Might even be a reason to build a website with instructions
No! In most of the US, it doesn't matter if you have an engineering degree or not; you cannot hold yourself out as an Engineer to the public in the sense that you can't call your company "Joe Sixpack Engineering" unless you have a P.E. after your name. You can work as an engineer and use that title on your resume, but not as a business name.
The whole point of the P.E. (in whatever field) is that the holder is expected to have met a certain minimum level of competency and experience and has been recommended. It is not a guarantee that he is capable of doing the work, but it's highly probable that he can.
I also have a bachelor's in EE and considered getting my PE years ago, but after looking into the process, concluded that it didn't offer me any advantages, so I bailed. Personally, I think the areas that they test are a bit of a stretch, but I can generally understand what the tests are trying to accomplish.
Could become a safety issue?? I've got news for you dude: software engineering has been a safety issue for decades. Sure, it may not harm anyone if your spreadsheet crashes, but medical devices, avionics, engine controllers, brake systems all have significant software content and are often safety-critical systems. There's an entire body of research dedicated to safety critical software systems. Read Nancy Leveson's excellent paper comparing the current state of software to that of steam boiler design in the 19th century. It's an eye-opener.
As far as the previous poster's comment that after design, everything is boring: I have to disagree. Like all other forms of engineering, once the design is done, actually getting it to work is another task in itself!
It is a matter of perspective: it's a matter of how you approach "failure." On my last two job interviews (got both jobs) I told how a previous employer was sued over a product I designed. The interviewers and I always laugh about it because the whole story is a tragedy of how not to run a business. The point I make by telling that story is that I understand how contracts can go bad and the right and wrong way to respond to it. It also demonstrates that I know to pay attention to the customer's wishes. Most interviewers respect someone who knows more about how business works than just how much C++/Java I can churn out each day.
Now, from the perspective of some posters, anything that went wrong should be hidden because it might work against you. I disagree: show that you learned from your mistakes, or better yet, from the mistakes of others.No-one expects you to be perfect. Experience is valuable!
I dunno. Do you have the right to step on a cockroach?
It really doesn't matter what the source is: you still have to put X joules of heat into the metal to raise its temperature Y degrees. I doubt you could get enough energy out of a couple of AA cells to do much more than a solder joint or two.
This is interesting. I have a basement full of old ICs including drivers, microprocessors, digital/analog devices and thousands of LEDS and other things I've bought surplus over the years for various projects. I've thought of packaging them up into little "hobbyist paks" and selling on EBay, but never could think of what kind of project to sell them for. Perhaps a kit with parts like a UDN2987 octal driver, 8 leds, a connector and a schematic showing how to build a parallel port I/O interface along with some Linux C driver code for $15-20 shipping included? I think I even have artwork for a PCB I made to do this years ago!
Think anyone would be interested?
Then again, do I really want to deal with the support emails from people who can't hold the right end of a soldering iron...
man, if I had points, I'd mod you up to infinity!!
I'm so sick of these "you must only drive the vehicle we deem environmentally correct and then only when absolutely necessary" idiots!!!
FWIW I own both an SUV and an old Toyota 4x4 pickup modded for offroading. I have no apologies for either. I drive them cause I like trucks. No other reason.
The very nature of software development means that operating systems are always being used for things they weren't intended. In the medical device industry we are well aware of the safety issues surrounding the software we write and a great deal of evaluation time goes into choosing tools and platforms.
And as far as Therac-25 goes, my opinion is that a large part of those problems were caused by the very lax attitude of the FDA to medical device software back then. Things have changed!
An interesting contrast to this is in embedded development. I can't think of a single embedded designer who doesn't consider tools, esp. debugging tools, when choosing a processor for a project. No, they're not sexy, but they can make or break a project.
I can't believe I'm saying this, but is that the clock speedup on a CoCo II?
I have to agree with this... sorta. When I was starting my business with a partner, everyone told me that partners were trouble. Well she wasnt. She had her own skillset that I didn't -- she was an engineer who was really good at sales. But in time, I became better at sales and cold-calling and for other reasons we decided that it was best if we split up, so the partnership became two sole proprietorships. She got new business or took orders from existing customers and sent them to me. I deducted a fixed percentage for Cost of Good Sold and we split gross profit 50/50. Worked really well.
We both had extensive customer contact at our old job, so we knew what customers wanted. I had told my boss, but he was reluctant, so we started a company to build and sell the product ourselves. The first place to look for unfulfilled customer needs is in the domain you already know: your day job.
Best of luck!!
Whether the input is supplied digitally or analog makes no difference. At some point it will be converted to analog. :-)
Your CD experiment isn't going to work for the purposes you want: you will find a volume setting where a test tone CD will produce distortion, but pop in a different CD (or tape, or tuner...) and the output volume will be different cause that media was mastered at a different level.
I think you're stuck with just turning the volume down when it gets too distorted, just like the rest of us
Doesn't matter: i.e., you don't get a fixed x watts out at 20% volume knob rotation and 2x at 40%. It depends on the input signal. At say, 50% knob setting, a quiet music passage may result in 3W out to the speakers, a second later, someone banging a big drum can result in 100W out.
Input signal amplitude and volume control (which is usually just an input attenuator) combine to produce an excitation signal whose amplitude, or level, determines what the output level of the amp is.
Hope I explained that clearly
I agree with your little theory
We are well on the way to building software by components -- for the most part we use COTS databases, operating systems, compilers, and some lower level components such as XML parsers and libraries. But to go farther we need interchangeable "software parts" (think 74xx TTL) that are fully spec'd and glue together easily (I think this latter part is going to require increased use of frameworks).
I should start reading up some more on frameworks that are out there. Perhaps look into creating some for the embedded systems I work on.
Bingo!!! One of Boehm's (?) "essential problems" of software is that because it is so easily changed, there is great pressure to make changes on a whim. But incremental engineering can be one of software's strengths when applied properly: the customer can start using the product before it's completed.
To the original poster: perhaps a better way of teaching software would be to give students examples of OK and bad solutions to problems they are assigned and ask them to improve on the good solution while avoiding problems in the bad one. I agree that most students don't get an opportunity to see the difference between good and bad code...or good and bad designs for that matter.
Software does one thing only: solves the customer's problem. What's the difference?
This part I agree with. When I took my Software Project Management course, the two most useful aspects were listening to the war stories of this 60+ year old instructor with tons of experience and reading business case studies. Similar thing in my Software Quality Assurance and also OO Patterns classs. Seeing how software projects failed, and in some cases killed people really drives home the point that QA is not to be ignored and teaches how to (hopefully) avoid making the same mistakes they did. So I do believe that learning by seeing what others have done is a powerful tool.
But where his argument falls apart is in treating it like an art. Engineering is already considered a creative process, but it's a disciplined creative process. The problem with software, as earlier posters have said, isn't too much engineering; it's too little.
I wholeheartedly agree, but that's not the point. An expert craftsman will produce good work whether he has good tools or not; but the reason craftspeople invest in good tools is that it makes their work easier and faster.
A large part of the problem is people keep expecting that tools will make mediocre developers into expert ones; they won't, but they will make the expert developers immensely more productive. And that's what really matter.
Well, I have a degree in Electrical Engineering and (almost
The ballgame does not change just because of language or method changes, it should just adapt. The entire reason for engineering in any product is predictability. Be it predictable cost, predictable quality, or predictable delivery. Now, before you explode in laughter, let me clarify that it doesn't guarantee that the predictions will be perfect, or even good. But they're a whole lot better than just the off-the-cuff guesses that passes for most SW development these days. The creation of software fits perfectly into engineering molds: we do it at work every day, and not all of us have engineering backgrounds. A large part of the problem is that it is apparently easy to change software, so it's easy to not take it too seriously and not follow any particular process. But look at even the garage down the street: mechanics will follow a process (even if it's a simple one) when quoting a price then repairing your car. Mistakes there are harder to fix than just an edit and recompile, so people are more careful about what they do. In software, only personal discipline makes us follow a process, and too many developers have none.
As I've been following their progress, many of the electrical/electronics problems they've had were obvious from the descriptions given: noisy sensors, ground loops in power, etc. There have been many times when reading the archives I thought "that's going to cause trouble..." and sure enough, I get to the next archive and it did. Problems any EE with a few years experience would have seen immediately.
So, why are there no EEs on the project? It doesn't even have to cost them. I'm sure that many experienced engineers would happily volunteer a few hours a month if only to review their designs. Hell, if they were doing it around here I'd happily offer my time just to be involved with a really cool project.
The thing that really bothers me is, if as an EE myself, I see such glaring errors, how many problems are the aerospace engineers reading the archives also predicting?
Don't get me wrong; I think these guys are reallly inspiring, but they could probably move a lot faster if they had expert help in a few fields they might be weak in.
I have to agree with this. I'm almost done with my MS in Software Engineering, and there are many concepts that would not have fully sunk in were it not for work experience I could relate them to. Conversely, many things I learned in class I was able to try out at work on production practices, and received good feedback on the useful(less)ness. I'm one of those people who learns best by doing and real work often brings up issues that the toy projects of classwork can't.
Plus the fact that my employer picks up the full tab for education doesn't hurt