I'm one of those guys programming in my 50s. Technically my jobs involve project management and consulting as well but I still love programming the most.
Saying that programming "requires little or no education" is from the perspective of either a naturally smart person or the Dunning–Kruger effect. Like any profession, there are some self-motivated people who can do the job effectively without formal education. Yet it saves time to have everyone on the same page with knowledge of basic algorithms, terminology, and problem-solving methods.
If money is your motivator for programming in your 20s, the odds are that you will find some other way to make more money and not last until you're 50. At least I hope so.
I said "little or no education" compared to other fields. I'm a grad school dropout, so my bet is that my CS education is above average for a working programmer. A hiring process considered "demanding" (such as Google's) is basically testing if you know the stuff they learn in the first year and a half of an undergraduate program. Contrast that to the amount of training and test-taking that a doctor must go through and it'll put what I said in proper context.
In that case I think "little or no certification" would be more appropriate. It does seem kind of strange that doctors, lawyers, electricians, plumbers, and barbers all have to take tests to get into (and sometimes remain in) their professions, but a programmer can write the software for a missle system, voting machine, or power plant with no certification whatsoever.
The litmus test is not the complexity or impact of the product a professional is working on, but rather: how savvy are the customers and do they need the protection of regulation?
All of the professions you named are people who hang a shingle and sell services to low-information customers.
Missile systems, voting machines, and power plants are all "sold" to high-information customers that need less gov't protection.
Other engineers do need certification and do face legal culpability if they are negligent in their work, but it's inherently different I think. We can talk more about that if you're interested, would like to hear your take.
I think "little required education" is true, for programming, in both senses: no certification, and not that much to learn to become productive compared to other professions. As I said in another thread, I think the reason is that the field is younger and that computers are designed to be comprehensible, unlike human bodies that doctors deal with or legal documents that lawyers deal with, etc.
There are programmers with almost zero CS education, formal or otherwise, who are rather productive. This may make the more educated among us cringe at some of their work, but the fact remains. If CS education was essential, it wouldn't happen, whatever we think about the merits of CS education (I rather value mine). A high school dropout could not successfully operate brain tumors; there are many countries where the fact that it's illegal wouldn't stop the practice if it were effective, but it can never be. Similarly for most high-paying professions other than programming and certain types of business.
One piece of the puzzle is that programming education is not very effective. Most computer science programs teach you almost nothing about software engineering, partially because many CS profs know almost nothing about it.
I think one of the problems with software engineering is that [almost] no one knows anything about it.
I've been a working programmer [or software engineer if I've just met you at a party and I think you're cute] for long enough to work on >5 multi-billion dollar projects. Of these, one was delivered on time and according to spec. That company went down the toilet within four years.
I've read fairly widely in the software engineering literature starting with Weinberg and Brooks in university, and chasing my share of papers, 'blogs and web pages since then. One of the most positive things that has happened to the field is the recent discovery that the only thing at the end of the methodology rainbow would appear to be consultants [wearing suits with slits for the dorsal fins [h.t. Mr Stross]] and stacks of unread Learn Florble-Oriented Development in 21 days.
I know I can build complex systems. I know I can sometimes build simple systems [much much harder.] I don't know how to reliably schedule a project to build a new thing. I think anyone who thinks they do know this is delusional or lying.
And in the end, I think it probably doesn't matter. The truth of the software engineering crisis, is that it never existed. And it's possible that software engineering never existed either. We program. We do it because we like it and it pays. The folks who do it only because it pays usually end up in management fucking things up by assuming they can motivate people always and only with money.
[oh, on a tangent I've also been a manager. I wasn't all that good at it. The team I managed delivered good stuff, some of it on schedule, but the company still went belly-up. And I learned that I don't enjoy management, and would rather have less money and more fun - take from that what you will]
WRT to those hugely expensive projects: for a while I've thought the real secret about offshoring is that it's simply a cheaper way to fail. Since most projects fail (outright canceled, declared a victory when they aren't, or over budget and time and generally far from feature complete), a cheap way to pretend you're doing software development has its attractions.
As for methodologies, perhaps getting everyone to actually use one is the biggest problem; that's been my experience. I have myself found about 4 things that seem to work:
The project should have a specifications document of one or two pages, no matter how complex. This is to try to get everyone on the same page, as it were, it has goals and requirements, must do N transactions/second, must run on X, etc. As much what and as little how as possible.
Further project documentation efforts must factor in the Don't Repeat Yourself (DRY) principle, i.e. the code is the only truth, and attempts to duplicate it are going to get out of sync unless you work really hard at avoiding that.
From OOSE/RUP: do short ("several week", 2-4) iterations and get your complete software and systems stack into a "Hello, world!" end-to-end state very early in them.
Otherwise, yeah, I've read a lot about software engineering beginning within the first month or two I started programming in the fall of '77 (sic) and while I think there is such a thing, it's indeed not really engineering as we otherwise know it. There's something there, but you learn it as much by doing as by more formal methods (classes, reading books) and there's no substitute for a serious amount of experience.
I think timescale may be applicable here. Some key programs for large companies will spend several million a year for several years - particularly if you are taking your Mainframe applications and trying to restructure them to have more easily changed business rules and a new infrastructure.
That said, I also suspect he may have been exaggerating for effect :-)
The NHS (Britain's state healthcare provider) famously had a project with a budget of £12.7bn (about $20bn). It wasn't entirely software although that was the main part. It famously fell apart, but billion-sized parts were handed off to companies like Accenture, British Telecom and Fujitsu: http://www.guardian.co.uk/business/2010/mar/21/nhs-national-...
It's horrific. Some bits work and are implemented, other bits don't and wont ever work.
Connecting for Health (and all the rest) are the programmes that persuaded me that governments should just define a standard, and then let providers build software and clinicians buy software that conform to the standard.
There are lots of things wrong with email, but SMTP was pretty robust across a range of platforms for servers and clients for many years.
The first project; the one that finished nearly on time, ran for three or four years. I joined half way through as a crispy graduate. It came in within a couple of weeks of schedule. It seemed very well managed for the whole of time on it. The project manager left that company, and went to work for Apple. When I googled him just now, all the top hits where at Microsoft. Perhaps he knows how to do software engineering. Or perhaps he got lucky that time. I don't know which.
The project developed a new CPU architecture, several variant implementations and ported several operating systems to that architecture. Amongst the more impressive feats I saw during that project:
- a compiler from assembler of architecture A to assembler of architecture B. This was necessary because we had a lot of code [~10^6 lines] in architecture A assembler
- several other compilers that handled code written for A, with no thought to portability, and produced asm for B.
- a modular emulation environment. Initially it ran on a larger example of A that had a programmable microcode feature. Later it was ported to other examples of A. Some of my colleagues were in the room when the ported OS first booted on a machine of type A with the funky microcode. As I recall, it took most of a day to reach the banner.
- my own part was very modest, but I had fun. Amongst other things, I ported a disk checking utility [think fsck] from A to B. That was easy. To test it I had to create bad blocks for it to find. So I got a SCSI 1.44 floppy drive [!], and a box of new disks. Then I formatted and scratched each disk with a paperclip, and did a disk copy.
So, that was lots of bucks, hundreds of software engineers, and some number of hardware people. I don't know how many of the latter were involved. But remember that nearly everything was custom; CPUs obviously, boards, buses [though that was fixed eventually], bent metal, power supplies. The lot.
That was one fairly large company.
I've done other large projects that had many cooperating companies, usually with one or two large partners and a number of small outfits. Those involved similar sums, but a large part of that was in the equipment deployment, land purchase and so on. Not so much fun. I did once crash the wireless data network of New Zealand because a radio [or possibly an antenna] came loose on a mast and flapped around in the wind. Every time it swept through 120 degrees, all the effected clients channel hopped, provoking an exciting synchronisation bug in my multithreaded code.
Oh, and I got paid for all of it. Not as much as I would if I'd become a banker [though it's presumptuous to assume I _could_ become a banker]. I'd quite like the money, but then again I have more fun that the bankers I know. I've built software that was used [and is used] by fairly large numbers of people [if you're reading this, then you're one of them]. This is satisfying. Even it I can't call it 'engineering' with a clear conscience. If computer programming hadn't been invented, I don't know what would have become of me. There aren't that many other occupations for people with my particular blend of what I'll call talents. If you fall into that category too, then get your laughs while you can. You're a lucky person right now.
[and since it behoves me to actually answer the question, I've never done any work for a government or defence contractor. I've no particular objection, it just hasn't come along]
Execution: Generally no. There are sub-contractors, out-sourcing, COTS, etc. And there may be a program management team of companies.
Software only: The three I've worked on, no. Hardware, software, "mechanisms".
Outside of NASA: Yes, although the US government probably has the lock on the sheer number of such programs. Chip-makers, with fab plants, are one sector. Vehicle manufacturers (planes, trains and automobiles) are another. Construction--especially massive high-rises--is probably another.
Google sure has multi-billion dollar projects. Chrome is an example. They're spending that much just _marketing_ the thing every year.
Even if we stick to just the development side, I would be very surprised if Google has not spent > 250 million a year on Chrome development over the last 4 years.
Even ignoring the google.com thing, estimates are they're spending at least $500 million a year on Chrome marketing for ads on other sites, various bundling deals (including pre-installs on new PCs and auto-installs with other software), etc.
As far as people on Chrome go, you're right that back in 2008 they likely did not have 1000+ people on it. The best data I can find for mid-2008 on the Internet says about 50 in mid-2008.
Looking for newer data, according to the last several updates on http://peter.sh/ at this point there are about 100 daily WebKit commits (not all by Google, obviously) and about 120 daily Chromium commits. That's not counting the parts of Chrome that aren't WebKit or Chromium. What fraction of the WebKit commits are from Google is an interesting question; as of early 2010 according to http://neugierig.org/software/chromium/notes/2010/02/webkit-... it was around 40-45% and growing rapidly.
Now going from "number of commits" to "number of engineers" is hard. For comparison, as of today according to http://oduinn.com/blog/2012/09/04/infrastructure-load-for-au... Mozilla has about 200 commits per day, but about half of those are to the automated testing repository, not to the main code. So that's about 100 commits per day. Mozilla right now has around 700 employees, I believe. So if you assume similar commit patterns (which is an assumption, granted), Google certainly has 1000+ people on Chrome now.
But I'm also not sure you need 1000+ people to hit $250 million/year in spending. In addition to Silicon Valley compensation packages, there's also a lot of test infrastructure and whatnot as part of every browser project which costs nontrivial amounts of money to create and maintain.
Again for comparison, since there's data available there, Mozilla spent about $63 million on "software development" in 2010 ($85 million if you include stuff like office space, HR, marketing, etc) according to http://www.mozilla.org/foundation/documents/mf-2010-audited-... and had about 200 engineers at the time, I believe... and Mozilla does not give out huge stock bonuses, like Google has done with Chrome.
1000 engineers? Probably not, but likely many hundreds plus all the organizational support people like designers, product marketers, product managers, people managers, and admins.
Consider Google's opportunity cost for advertising on the "internet's home page". I've read estimates of $2B.
For a while, Google was also paying Adobe to bundle Chrome with Flash (in addition to bundling Flash with Chrome).
I seem to recall iPhone 1.0 being called a $100 million dollar project in some Wired article. They were several hundred people (not thousands), working together for about 2-3 years. That seems sensible, and the numbers seem to add up.
Apple's strategy is to assign fewer people than you would expect when building a new product to ensure focus / reduce feature creep. Staffing on stable products are in line with what you would expect.
For example, I heard (from an ex-Apple co-worker) that the entire iTunes.app team was about 25 engineers. In contrast, Adobe's Flash plugin team had about 50 engineers (not including QA).
I would argue that if your team delivered good stuff, mostly on schedule, and your team was happy, then you were good at being a manager. The company failing despite your team deliver quality product hints that there was probably a flaw in strategic vision or external market factors.
When companies that are large enough to spend "multi billion" dollars on a software project blow up "within 4 years" it makes the news. Like Enron. And Worldcom. And Lehman. Etc. And in those cases it's usually a very deep systemic rot. So I don't know how much all of that matters.
I also echo the concerns below about the "multi-billion" comment. Did somebody just mention sometime that it's that expensive? Because that's a remarkably large amount of money for business. Government? Not so much. But for a business, well, there are very few billion-dollar businesses and a scarce handfull that are spending a billion+ on any single project. My fiance is a PM on the largest electronic medical records rollout in the nation, which includes visits to over a thousand clinics around the country to install hardware, convert paper records and train people, as well as all the infrastructure, and it's reportedly going to bust through the original budget but still clock-in around $100 Million dollars.
I think CS education is extremely effective, if one does the exercises himself, and as to software engineering, they don't teach about snake oil, either.
It's just that there's not that much to learn that is universally applicable, comparatively. The field is young, and then computers are easier to make sense of than most things, because we made them that way. Doctors need to deal with human bodies which aren't designed for human understanding and tinkering. Lawyers need to deal with documents which aren't designed for easy understanding, either - they're designed to prevent hostile, malicious parties from screwing each other. We simply have it easier than most skilled professionals.
> One piece of the puzzle is that programming education is not very effective. Most computer science programs teach you almost nothing about software engineering, partially because many CS profs know almost nothing about it.
And mostly because computer science is not software engineering. If you want to learn software engineering, find a degree or diploma program in software engineering.
Being frustrated that your computer science degree did not teach you about software engineering is like being frustrated that your civil engineering degree did not instruct you how to physically build a bridge, or that your mathematics degree did not teach you how to corporate accounting.
If you want to learn software engineering, get a job as a software engineer after a degree in CS. You will learn far more from the job than from the degree.
Sure, that could work too, it's basically apprenticeship. But it's still not the CS degree's fault or problem that you're learning software engineering on the job.
Yup. While formal education is not necessary, one has to keep learning to stay in the forefront of this profession. If you stop, your 'shelf-life' is 10 yrs at most.
I disagree, if you did any application programming in the mid to late eighties in C/C++, TCP/Sockets, CORBA, Sybase, and X11, about 90% of your experience directly translates to today's Web based application development.
Hell, if you use a Linux development environment you will feel right at home.
I think he means little or no formal education required; i.e. something the self taught can get into based on merit alone. You can't do that with a lot of high paying professions as they absolutely require formal education.
I'm 35 and I just recently started trying to turn what had been a hobby into something that pays. I harbor no illusions about ever making decent money at it though.
I want to. I do have a ton of for-the-love projects which seemed impossible when I started, that i've learned a lot from, failure by failure. I've even got an app I'm building in Laravel (and this is the last you'll likely hear about it.) Unfortunately with where I'm at right now it's just been scutwork that puts gas in the car.
I might even take a cs course this year assuming it's possible to get the loans. I'm still paying off an art degree though.
You can take lots of courses from top universities online for free. That won't give you the piece of paper, you'd get when you paid for them, but all the knowledge is still there.
Saying that programming "requires little or no education" is from the perspective of either a naturally smart person or the Dunning–Kruger effect. Like any profession, there are some self-motivated people who can do the job effectively without formal education. Yet it saves time to have everyone on the same page with knowledge of basic algorithms, terminology, and problem-solving methods.
If money is your motivator for programming in your 20s, the odds are that you will find some other way to make more money and not last until you're 50. At least I hope so.