Hackers As Factory Workers? 342
DevDude writes "A strangely interesting article is running on MSDN, entitled: The Case for Software Factories. It suggests creating 'development environments configured to support the rapid development of a specific type of application.' As a developer thrust into many an unsavory situation, I am constantly stepping in the remnants of some development methodology or other. Will super-specialization of software development teams help the industry to push out better software faster? Or are we hassled enough without being treated as an assembly line?"
And while we're at it (Score:5, Funny)
Re:And while we're at it (Score:3, Funny)
Food chain (Score:5, Insightful)
Re:Food chain (Score:3, Insightful)
Re:Food chain (Score:4, Insightful)
"Ooo. This not look cheap."
Re:Food chain (Score:4, Insightful)
Re:Food chain (Score:5, Interesting)
There is this curve where when you learn how to program and write a few small projects you extrapolate from that experience and believe that large projects must be the same.
Part of the misconception lies in the belief that the difficult part is knowing a programming language. Being able to competently write code is only being conversant. It is really the higher levels of organization that are difficult.
You don't need to hire a genius to slap together a porn site for you...it is a solved problem and much like hiring a factory worker, you don't have to look hard to find someone who can assemble the pieces. But as you start going out into uncharted waters doing things that are more technically interesting, you will find that you cannot just hire anyone who knows how to type out correct code.
The good news is that believing that all programmers are the equal doesn't make it so. Any company who wants to try this experiment does so at its own peril.
Re:Food chain (Score:3, Insightful)
MBA types don't understand anything. They're oxygen thieves.
Re:Food chain (Score:4, Insightful)
Good to see I'm not the only one who's noticed this. People write some 10 line BASIC program, and then can't understand why writing an 100,000 line one is a much bigger problem. (And that's not even the biggest of projects.)
You don't even need to go into uncharted waters: if you tried writing an 100,000 line as the same kind of unstructured mess, you'd end up with a nightmare to debug and/or maintain anyway. The size alone, and the fact that you're essentially looking at it through a keyhole of 25 (or 50 or 100) lines at a time makes it a fundamentally different kind of problem than that 10 line BASIC exercise.
And it's not only MBA types. Most programmers (and I mean actual programmers) come out the college without ever having had to maintain anything _near_ the scale of actual projects. And some of the flamewars (e.g., about how any kind of structure or strong typing sucks) are nothing but proof that someone never was in a large project, but is extrapolating out of their ass anyway.
Either way, IMHO that's only one of the problem types. The ones I've had trouble with include, but are not limited to:
1. The extrapolating type you've just described.
2. The "form before function" type. If it's easy to drag and drop some buttons in a form editor, surely any monkey can put the code together in no time. I mean, phbt, programming is easy. It was dropping those buttons that was the real problem.
3. The living proof that "just a little knowledge can be dangerous."
E.g., someone who doesn't really understand XML, but just heard that it's good. Dunno for what. Probably for everything. 'Cause SUN said so. So next thing you know, everything _must_ happen in XML. Even calls inside the program have their parameters passed as XML, and every method starts by parsing its arguments out of XML. (Not a joke: I know at least one project based on that idea.) Or since XSLT is all the rage too, let's have business logic and workflow control in XSLT. (Again, sadly not a joke.)
E.g., the PHB (or even programmer) who bought some book about patterns or best practices on Amazon, didn't really understand it, but now everything must use every single one of those. If every single of your objects doesn't also involve a singleton, which gives you a factory, which gives you an object registered with a manager, etc, it's coming out of your pay. (Again, not a joke: one PHB actually went through a phase where everyone was required to write endless reports about which patterns they used. And would get berated if they didn't use enough. No matter for what.)
4. The invisible man. Now much as I'm weary of over-management, the worst situation so far was basically not being managed at all. Everyone just go code something, and, hey, you can go talk to the others (and other teams) personally if you need something from them.
Re:Food chain-Bowling for IT. (Score:5, Insightful)
At least for Google we had a recent article right here on Slashdot: they have a very high number of well paid Ph.Ds. Quite the contrary of what your average clueless PHB or beancounter does in the name of efficiency.
Microsoft makes money by selling PHBs the illusion of "buy our patented snake oil, and you can make quality software fast with any burger flipper turned VB.NET developper." But suspiciously enough that is _not_ who Microsoft employs.
Yes, you may rant and rave about how much Microsoft's software sucks, or how it misses deadlines too. But guess what? Most other companies software sucks twice as hard, and costs more too.
While Microsoft does have buffer overflow exploits, other companies had those _and_ a bunch of bugs or broken design decisions of their own. Or shipped downright broken and non-functional software, just to keep a badly planned deadline.
Among the closed source world, Microsoft actually does an outstanding job. So, you know, maybe hiring smart people actually does something for them.
Re:Food chain (Score:3, Interesting)
Reasoning and analysis, as you put it (also called logic and deduction) are pinacle traits of programming. They are not even generally considered necessary skills for most run-of-the-mill business people, and there-in lies the problem: business folks fuck things up for everyone else.
The only reason programmers
Yeah, right. (Score:4, Interesting)
Re:Yeah, right. Adapt or DIE (Score:2, Insightful)
From The Tao Of Programming (Score:2, Insightful)
``It will take one year,'' said the master promptly.
``But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?''
The master programmer frowned. ``In that case, it will take two years.''
``And what if I assign a hundred programmers to it?''
T
code monkeys (Score:5, Insightful)
Not every programmer who resents the idea of typing repetitive instructions all day has gone crazy. In fact if implementing your project requires lots of mindless, repetitive work, then your design decisions are crazy. The very term 'project' implies that you're doing something new you haven't done before.
Example: the cheap, unskilled code monkey spends lots of time repetitively building mediocre GUI components with his, err, GUI builder, while the 'artist' uses the same time to write a factory that constructs the GUI components on the fly, considering things like the data structures they'll edit etc. One central place to enforce consistency and human interface guidelines. No mindless repetition.
Re: (Score:2)
Re:Yeah, right. (Score:3, Insightful)
Neither of those is done on an assembly line, in a factory, or with an emphasis on speed. (They probably also take more skill and creativity than you think.)
Repetition is not Programming (Score:3, Insightful)
If so, something is wrong. Computers are good at repetition, humans can do better things. If your programming is repetitive, you are using the wrong tool. Heck, you should spend your time developing exactly this missing tool. Build a decent library or a preprocessor, then use it to automate away the repetition. It pays off soon. Compare http://c2.com/cgi/wiki?SharpenTheSaw [c2.com] and http://c2.com/cgi/wiki?ThreeStrikesAndYouRefactor [c2.com].
everyone knows it's like this: (Score:2)
Assembly Line? (Score:2, Informative)
Libraries... (Score:4, Interesting)
It suggests creating 'development environments configured to support the rapid development of a specific type of application.'
That's all well and good, but after a developer codes 5 apps which work pretty much the same way, won't he just develop libraries so that any subsequent app will take less than an hour to code?
Re:Libraries... (Score:2)
Re:Libraries... (Score:2)
Not exactly the right interpretation of the metaphor. Your analogy refers to the duplication process (make 20 cars is equivalent to 20 copies of the same application). The article discusses the difference in economies of scale (making 20 cars vs 20 copies) and economies of scope.
To go with the car analogy, if I need to make a sedan, a coupe, and luxury car.
Re:Libraries... (Score:3, Insightful)
The real work piece is the executable, and once we've built our source code, we can turn out as many copies of the executable as we need. If it's really complicated, we need a
We as
Re:Libraries... (Score:2)
--dave
Re:Libraries... (Score:2)
Most of the code written today falls into one of two categories:
1) Forms. Applications for getting data from a human into a database.
2) Reports. Applications for getting data from a database and into a human.
This sort of development is a commodity.
simple (Score:5, Insightful)
It would be foolish to say that there is no place whatsoever for one or the other type of worker in the programming ecology (extrapolate this analogy to society and economics at your own risk).
Re:simple (Score:2)
Seems to me that anything that is well-understood and capable of being banged out many times repeatedly is instead coded up into a library. Reusing a library requires no coding at all.
Doesn't matter though... (Score:4, Insightful)
Eliminating the "Good" option. (Score:5, Insightful)
"Good. Fast. Cheap. Pick two."
Outfits like the one proposed here elminiate the choice of "Good."
Re:Eliminating the "Good" option. (Score:5, Insightful)
Re:Eliminating the "Good" option. (Score:2, Interesting)
I have to say, I find this trend more than a little disturbing. I mean, have electronic or mechanical engineers been attacked as much as programmers? What about artists and teachers? Factory line production, this phrase is just another way for the suits to feel good about outsourcing the jobs of highly skilled and creative people.
It seems to me that this is coming to a showdown between the talentless parasites (sales reps, office politician middle managers, and marketing types), and the honest to god educ
You just aren't buying the right computers (Score:5, Insightful)
This is all real, and is what runs mission critical stuff across the world.
However, as the orignal poster pointed out, it's good/cheap/fast pick two. I'd even say pick at most two. These systes are neither cheap nor fast. They do not use the latest greatest shit, they use proven reliable hardware that has undergone lots of testing. They are also not in any way shape or form cheap. Whatever level of processing they offer you, you can beat 10 times over with commodity hardware and still be under their price.
The software that runs on them is likewise ultra reliable. Crashes just arne't an option, and they don't happen. The OS and apps are just rock solid. Of course, that means they also don't support all the whiz-bang features. No happy candy-coated bouncing docks or the like.
It's the same deal as in consumer electronics. I continually see peopople lament how poor quality theri $40 DVD player or $20 VCR is as compared to the $500 model they bought years ago. Well DUH, they could afford to put some quality into a $500 DVD player, they can't in a $40 one. Thing is, you can still buy high end electronics, they just still cost lots of money. Go get a studio grade DVD player. It'll be built to last, produce a better picture, but it'll cost $500.
Whatever the level of reliability you demand, there is probably a solution out there that can meet or exceed it. However, don't whine that it costs money. Quality costs money, always has, always will. If you want it cheap, be prepared to accept the consequences that come with that.
Also, in computers, many times it's better to just go with multiple cheap systems. Ends up being as reliable and much cheaper. I mean say you have a server app that is prone to crash, because it is continually hacked and updated. Also, it runs on cheap hardware, so that's not reliable. Ok, so you design it such that it runs on 3 parallel servers, each capable of taking 100% of the load. So even if the hardware fails on one, you still have two, and your testing indicates that it's likely that if one crashes, it'll get back up quick enough that the other won't crash in the mean time. Maybe you go for 4x just to be safe.
You end up having what appears from a user perspectinve to be an ultra-reliable setup, however it still allows you to quickly hack out new versions, that may not be as stable as they should.
Re:Eliminating the "Good" option. (Score:2)
Final Cut Express
iDVD
iMovie
iTunes
Mail
Safari
OS X
Photoshop Elements
iChat
Where are you looking that you can't find good software?
Re:Eliminating the "Good" option. (Score:2)
Deadline, features and money. If you have one that's pinned down, you can usually move the other two in your favour.
If the deadline is short, you can either a. hire more people to alleviate some of the work load (doesn't always work) or b. lessen the features. Want it for cheap? Decrease the features. Want more features? increase cost and time.
Re:Eliminating the "Good" option. (Score:2)
gee... that beowulf thing seems ontopic for the first time
Re:Eliminating the "Good" option. (Score:2)
Re:Eliminating the "Good" option. (Score:2)
Re:Eliminating the "Good" option. (Score:2)
No, it won't; just because a task can be done by mediocre coders using a rather simple development methodology, you can't automatically speed it up by clustering lots of mediocre coders together. You can have a factory that houses several such teams, but making all of them work on the same code wouldn't be economical. You simply can't get a two-year project done in four months by emplying six or
Re:Eliminating the "Good" option. (Score:2)
What part of "cheap" do you not understand?
Maybe (Score:4, Insightful)
Re:Maybe (Score:3, Interesting)
Based on the quality of Windows this wouldn't surprise me in the slightest.
It Won't Work Because Of Programmer's Personalitie (Score:5, Insightful)
Those that don't quit will burn out and self destruct. While there is a surplus of IT workers, a sweatshop like this will burn through programmers fast enough that it'll only last a few years before the quality of code gets shoddy because there's no good programmers left that are NOT burned out that will willingly work at such a place.
Re:It Won't Work Because Of Programmer's Personali (Score:2)
everytime someone creates some ms access db with some wizard that happens.. everytime someone uses some wizard to create something that does something it's akin to the factory model where there's only pre-designed assembling.
when creating something totally new though.. do they create car designs in a car designs factory?(no they don't but they have their own model of how it gets done anyways.. software des
Re:It Won't Work Because Of Programmer's Personali (Score:2)
So there is a role
Re:It Won't Work Because Of Programmer's Personali (Score:3, Interesting)
Re:It Won't Work Because Of Programmer's Personali (Score:2)
Re:Who cares? (Score:2)
Then think.
First: You don't know how many of those applicants are unemployed, and how many are looking for something better. Many of those who are employed may not have applied for a sweatshop job.
Second: Your point was addressed. Even if you're getting a 100:1 applicant to job ratio, there is still a finite supply of IT pros.
For example fast food drains their workers, uses them up, and forgets them. They can do this. There is an endless supply of teenagers who need spending cash
Think Peoplesoft, Oracle, etc. (Score:3, Informative)
For well-understood problems... (Score:4, Insightful)
Re:For well-understood problems... (Score:3, Insightful)
Specifying software products (Score:2)
Software development projects? (Score:4, Insightful)
200 projects sounds extremely low, unless they mean 200 projects per business which is extremely high. How do they define a project? I would guess there are nearly 200 videogames a year so they can't be included in this figure. Does a project need to be >1000000000$ before it is considered as a project in this group?
Re:Software development projects? (Score:2)
I'm an electrical engineer at a relativly small company that designs and manufacturers auto parts. We are not a "software company", but we write a suprising amount of software, for example:
Microcontroller/microprocessor code used in some of our higher-end products
Ladder-Logic style (for simple tests) or LabView software for product validation test stands, end-of-line t
it's a typo (Score:5, Informative)
Re:Software development projects? (Score:2)
Similar to my paper... (Score:2, Interesting)
Engineering (Score:2, Interesting)
Historically, the way to make things that people make better is to make them using methodologies derived from manufacturing. why is software not subject to the same rules?
sorry folks, it's 1840 again, and this "Steam Engine" is going away.
The up side is that you don't have to co
Re:Engineering (Score:2)
Because making software is a design effort, not a manufacturing effort. Any attempts to understand or control the process as if it were a manufacturing process is doomed to failure.
Same old same old. (Score:3, Interesting)
Re:Same old same old. (Score:2)
Mods take less time than the original game, because the original game you have the complexity of creating the engine, this is the economies of scope the article describes.
Right. (Score:3, Insightful)
Around it comes again (Score:5, Insightful)
In this case, we're seeing the re-awakening of the notion of "commoditizing" programming. Back in the day, it was the notion of "deskilling" programming with forth-generation languages; before that it was the development of general high-level languages like FORTRAN and COBOL; before that it was the realization that you didn't have to be either Goldstein or von Neumann to successfully program a computer.
So, yeah, it's possible to improve programming productivity by building specialized environments for certain classes of problems. That trick worked for report programs with RPG in the 60's; works marvelously with parser generators; works pretty decently with GUI tools for UI programming now; and will undoubtedly work for other classes of programs in the future.
Then you'll find people programming new classes of programs by hand, and a few years later someone will say "wouldn't it be better if we could do this with specialized tools?"
And you can bet that 50 years from now the big issue will still be figuring out what you want to do, and figuring out how to describe that.
Re:Around it comes again (Score:2)
--dave
Re:Around it comes again (Score:2)
Re:Around it comes again (Score:3, Interesting)
All of this discussion about the front-loaded
Re:Around it comes again (Score:3, Informative)
Twenty years ago.
Sometimes I think I should have been an English major.
This nonsense has been around before (Score:5, Insightful)
But writing the software which will go on that CD-ROM is the software analogy of designing the 2005 model of the Nissan Maxima. Now, some software development is not very creative. Just as tweaking the design of a car model that's been around for 10 years, to get something a little bit new for a new model year, is not very creative mech engineering. But it's still design, not assembly-line production. A competent software engineer will be able to do it better and faster than a bad one. And a factory worker will not be able to do it at all.
Re:This nonsense has been around before (Score:2)
Another analogy might writing a novel. The actual writing is a creative task that isn't amenable to mass production. But banging out 100k copies of the book once the writing is done is an industrial process.
Re:This nonsense has been around before (Score:2)
The article discusses economies of scope, which is like using the same basic design of
This is/was inevitable (Score:3, Interesting)
When I started, computing was more like being a scientist, the journeys one would undertake would lead to wild, mysterious and interesting places. Now you need 30 years experience in SOAP and XML and JSP and Java and etc. etc. and all you do all day is read documentation telling you how to use some crappy proprietary set of classes that some daft bugger threw together one Sunday night because the boss needed a color wheel widget that allowed him to choose colors based on the phases of the moon.
Sorry, but programming these days is so unbelievably boring and if you want to be a factory worker then knock yourself out and get an IT qualification.
Other evidence can be seen merely by walking into a software shop. You'll either be faced by rows of cubicles (which I'm actually quite envious of as at least you get some privacy) or, more likely, a huge open plan shop floor which is noisy as hell, totally unconducive to doing any sort of work beyond drone coding and ugly as fat in a liposuction canister.
There is no "will it be", IT already is a factory style production environment. It's just the "managers" that keep telling you how "valuable" you are that make it seem anything different.
Re:This is/was inevitable (Score:2)
Unfortunately, these are still noisy as hell, except you won't know where the noise is coming from. My next-cubicle neighbour used to have an admin visit him every afternoon. For the entire duration of the meeting, I kept hearing this "thump, thump, thump-thump". After three days it drove me nuts, and I just had to find out what the noise was... she was bending her knee and thumping the floor
this doesn't work! (Score:2, Insightful)
I've been under many different managements and the most common call to action when projects fail is, "Change the methodology!" For some reason this is the all too common diagnosis. I've worked with, under, etc. many "methodologies", and generally these methodologies correlate loosely at best to measured success. Of course authors, pundits, and visionaries continue to make fortunes rolling out countless new methodologies and writing books proving they are right.
As for the notion of a "factory" -- I find
Re:this doesn't work! (Score:2)
They are not new methodologies. They are just variants of the same old tired methodology, the algorithm. For a completely different non-algorithmic solution, take a look at the The Silver Bullet [adelphia.net] and Project COSA [adelphia.net]
Not (only) a technology problem (Score:2)
They make the point for domain-specific frameworks by comparing them with SQL and GUI builders. But I feel they de-emphasize the importance requirements gathering and overall developer-stakeholder interaction has. It's not about better tools from a technical point of view, i
We need a better software creation methodology (Score:2)
The answer is a resounding no. The problem is not how to manage or organize teams. The problem is in the way we develop software. We are doing it wrong. The solution requires a fundamental change in the way we program our computers. In my opinion, the main reason that software is so unreliable and so hard to develop has to do with a custom that is as old as the computer: the practice of using the a
The Hard Part (Score:3, Insightful)
Software development should be treated as a multiplayer team communications game. The success of the team depends more on how successful the communications are.
Everybody missed the obvious (Score:2)
... a certain company [google.com] with the coolest remuneration [google.com] packages ever? And going public soon for tons of moolah?
Code factories *will* work, but they'll only ever be bottom feeders: eating away at overpopulated markets because they're cheaper than anyone else. Companies which produce good quality, innovative products will win. But only - ONLY - if they're good at figuring out what they do best (searching [google.com], making computers nobody ever gets fired for buying [ibm.com], making gizmos [apple.com] or allowing interoperativity and caterin [microsoft.com]
Cut to the chase (Score:2)
2. Every model relies on pre-built components being glued together by programmers who understand a business issue (how to calculate a bank balance) but have no idea of the technology behin
I don't buy it... (Score:2)
The article seems to "solve" this with two pretty old ideas: abstraction and reuse. Both of these has, at one point, been hailed as the silver bullet of software development, and they have both failed to deliver their initail promise of fast and dirt cheap develo
Better options available (Score:2)
The basis of putting something into a 'factory' and mass producing it is that it shouldn't require much in terms of creativity, it should be just a process of putting together the parts. If that is all a particular piece of software is, shouldn't it be easier, quicker, and cheaper to automate the development than to stick it in an assembly line type of thing?
More evidence of MS trying to take credit for.... (Score:2)
I wrote this in late 1996 [threeseas.net] and even more can be found here regarding autocoding [debian.org] and I'm sure there is plenty more I can bring up.
Hey MS, how come you don't understand teh concept of "Credit where credit is due", Hmmmm?
Re:More evidence of MS trying to take credit for.. (Score:2)
Microsoft is selling utter snake oil again (Score:2)
A full explication of the disaster anyone buying this line of insane bullshit is setting themselves up for is detailed in The Programme [reciprocality.org]
The first time they did this, it was really cool! (Score:2, Insightful)
I thought the concept was really cool!
I no longer had to re-invent the wheel every time I wanted to build an app.
I saw this effort very similar to my construction in electronics where I buy components off the shelf and know what I'm getting. I wouldn't even think of trying to build an IC, resistor, capacitor, or large inductor.. albeit I could if I
Time to get over it (Score:2, Insightful)
Developed at Microsoft, eh? (Score:2, Interesting)
Summary: Briefly presents the motivation for Software Factories, a methodology developed at Microsoft. A Software Factory is a development environment configured to support the rapid development of a specific type of application.
Well, I guess when the Software Engineering Institute held the Software Factory Forum in 1985 (or was it '86... I forget) with various luminaries from around the software industry to discuss just these issues, they were really helping Microsoft develop the software factory met
I RTFAed: Empty Gibberish. (Score:3, Informative)
It's "10 printed pages" of Business 2.0 cliches that was probably lifted out of some dot-commies VC proposal:
One way to do this is to give developers ways to encapsulate their knowledge as reusable assets that others can apply. Is this far fetched? Patterns already demonstrate limited but effective knowledge reuse. The next step is to move from documentation to automation, using languages, frameworks, and tools to automate pattern application.
This is about the most concrete sentence I found, and it ain't all that concrete, besides simply repeating the same mantras we've been hearing for the last decade or so: code reuse is good, frameworks increase efficiency, design patterns are distilled knowledge... There's a bland and unhelpful, not to mention trite, rejection of comparing software development to the production of physical goods in manufacturing.
Don't bother wading through it. It's tripe.
Read between the lines (Score:4, Interesting)
This whole idea is centered around getting more code written, cheaper. While it may in the short term improve quality due to specialization, in the long term it serves to replace software engineers with codemonkeys.
Ideas like this make Stallman look like an optimist.
Microsoft still doesn't get it... (Score:3, Insightful)
Re:Microsoft still doesn't get it... (Score:3, Insightful)
The people who don't understand what's going on are their customers. They're content to get a junk product with no service, and Microsoft cleans up at their expense.
Manufacturing model dead wrong (Score:5, Insightful)
Programming computers is an almost entirely an art form. It was the same way 10 years ago. It will be the same way 10 years from now.
Parts of programming which were art forms 10 years ago are a science today. Memory management, for example, is now a very well understood process. What happened? It ceased to be a programming task. Think: Java verus assembly language. Don't spend much time juggling pointers in Java, do you?
Unlike manufacturing, once we've solved a problem it stays solved. That means the role of a specialist who is very good at some technique is necessarily short term: As soon as someone gets good enough to automate the technique, the need to repeat it disappears.
As a result, computer programming remains a high art form: programmers are only needed for the tasks which still defy rigid definition. Art favors the renaissance man, the master of a breadth of disciplines who works with all of them. Computer programming will continue to favor such broadly skilled artists.
So, those of you who style yourselves java coders or C coders or MSCE's, take heed: Become a generalist because your days as a specialist are numbered.
Speaking From Experience (Score:2)
If software engineering goes this route, I'll just find something t o do which gives me the freedom that I value and enjoy.
Good analogy (Score:2)
In part, it's due to protective moves of foreign companies trying to establish their own software industry. But American software rarely enjoys the opportunity to compete with other American software companies. I was dissapointed with the Department of Justice's missing teeth once a conviction was upheld a
Software development has gotten harder (Score:5, Insightful)
In the old days of machines of 8KB of memory and sub-Mips processors, programming was easier. The space of what programs you could potentially implement was much more limited than today (although both are obviously very large spaces). Most of the development time back then was devoted to figuring out how to implement a program, e.g. how to fit it in memory and make it fast. The was no operating system and the language was assembly (for the 8KB sub-Mips machines anyway).
Today we spend a great deal more time deciding what a program should do, since better machines have expanded the possibilities to an extent we could scarely imagine 35 years ago. But we also spend more time deciding how to implement programs, though for different reasons than before. Now we choose languages, databases, GUI frameworks, and on and on. And the basis for making those choices intelligently involves much more knowledge than was needed before, i.e. not just knowledge of the target machine, but knowledge of the capabilities of the potential languages, operating systems, databases, etc. So the how part is now much more knowledge intensive, whereas it used to be more like solving a puzzle.
So programming really has gotten harder! Is it really any wonder it takes longer and is so often screwed up?
How to improve the situation? Well, the what part is only going to get worse, and we want it to, because that means we can do more with computers. The how part, on the other hand, can and probably will get easier. Standardization is the easiest way that can happen, though I wouldn't call standardization "easy". Using higher levels of abstraction is another way, but the current means of achieving this is mostly through components, the use of which narrows the spaces of both what and how. The problem is that component packages often make incompatible decisions about the how of their implementation, which often makes it difficult to combine multiple packages. And that gets back to the need for standardization.
Re:Software development has gotten harder (Score:2)
Oh PLEASE. Put any of today's PHP-kiddies in front of one of those and watch them crap their pants. Programming is EASY and it's going to get easier. Programming is data entry. The skill is in SOLVING PROBLEMS. Programming is just writing your solution down in a structured way, that's all. And really, it's no more difficult than typing. But some typists are just typists (like today's PHP/My First SQL kids), and so
Probability of failure is multiplicative (Score:2)
The probability of failure in software is multiplicative, meaning that if any one person in the chain is a "zero" at their job, the result is a zero.
interesting tidbits (Score:3, Interesting)
Without comparable increases in capacity, it seems inevitable that total software development capacity is destined to fall far short of total demand by the end of the decade.
There are a lot of unemployed sofware engineers out there who will be glad to hear this bit of news.
Of course, if market forces have free play, this will not actually happen, since the enlightened self interest of software suppliers will provide the capacity required to satisfy the demand.
Is it just me, or is it terribly ironic that Microsoft is talking about letting "market forces have free play"?
Re:Does not compute. (Score:2)
For certain types of applications (accounting, ERP, that sort of thing), every business wants something a little bit different but fundamentally the same.
We already have (relatively) off-the-shelf packages like SAP that companies take in and customize. If all those SAP customers are making simliar modifications and reports and whatever in parallel, there is (theoretically, theoretically!) a lot of efficiency to be gained
Re:Author (Score:2)