Slashdot Mirror
Hackers As Factory Workers?
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?"
Do programmers really need to sleep and eat? What if we just give them implants and let them plug themselves into nutrient/rest bays at the factory? I'm sure it would be quite a bit more efficient. It worked well for the Borg.
Programmers are at the end of the food chain buddy. That's why you need to upgrade and become part of a function that requires decision and analysis. Or , if you're looking for the easy exit, a Sysadmin :)
This will never work. Not because it's impossible or inefficient, but because programmers will never submit to it. For some reason, people who type instructions into machines have gotten into their heads that they are underappreciated artists or that there is something uniquely heroic about what they do. The vast bulk of programming is just repetition. It's skilled repetition, but no more so than drafting or car repair.
There have been literally hundreds of posts about the horrible color scheme for IT. Yes, it was first in this particular story, but it has been said numerous times. Too bad it's so true.
push out better software, do it faster, employ mediocre 'mass production' coders for low pay: pick any two.
but what do i know, i'm just a model.
If we wont conform to an "Assembly Line" mentality they will probably just outsource it to another country.
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?
this is simple - it's the difference between the mass production line worker, and a master craftsman.
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).
It's 10 PM. Do you know if you're un-American?
It has always been said with software...
"Good. Fast. Cheap. Pick two."
Outfits like the one proposed here elminiate the choice of "Good."
"You spoony bard!" -Tellah
It could work, but only on a limited basis. They could probably make junk applications, things that don't really need very much polish on them. Maybe programs that would only be used for a small period, and not necessarily for a large market.
Most programmers have a strong desire to be challenged and to solve problems. They want to use their brain and imagination. (Wasn't there an article here within the last few weeks about charactistics of good programmers?) That's why they hate cubicles so much. If you try to stuff them into "factories" where they're doing nothing but making modifications to existing code over and over, the tedium will get them.
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.
This makes sense for companies that sell slightly customized versions of their packages. That really is an assembly line operation.
Once the software is written, why do you need a production line to keep writing it?
Many firms need banking screens designed, stuff like that. What's so special about writing a form that checks that no bill for less than $.001 get sent out ?
This is not a signature.
with well-understood types of solutions, one could presumely setup a "factory". Indeed, the off-shoring of programming task is part of that. On the other hand, there are programming/designing tasks where not even the problem is that well understood, or that require a high degree of independent, creative thinking.
Yes, there are some problems that have been solved thousands of times, this sort of thing might work to make cookie cutter software a bit more reliabily, but of course, won't somebody soon figure out how to automate this "factory"
I suppose it widens the gulf between problem-solvers and code monkeys.
But sooooo often, I've been called in to fix stuff that was developed according to some sort of "brilliant" methodology where totally obvious fundamentals were forgotten and well, it seemed better to simply start over.
How is this different from the disposable "API of the month club"
"According to the Standish Group [Sta94], businesses in the United States spend around $250 billion on software development on approximately 200 projects each year."
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?
Which is here: genprog.pdf
Redundancy only applies to posts in that story. Besides, that would rather stupid because there are many occasions when posting a link in multiple stories is helpful. Should people be forced to read all the posts in all other stories first instead of being given the useful information in the story its relevant to?
this would work as well as writing books in an assembly line.
You underestimate how poverty will facilitate these sorts of factories; 100 years ago constructing buildings was the work of artisians, now they are pre-fab buildings. Software is not immune from this trend.
Look, you can think what you want but this is BUSINESS -- and you need to adapt or die, if you cant cut it, get out of the way there is someone else who can.
'factory' made software(that is made on an automatic assembly line of sorts) is "made" all the time..
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 design has some models that it can be done with as well but that's quite fucking long from factory work)
world was created 5 seconds before this post as it is.
Seems someone is channeling L. Bob Rife, straight out of Stephenson's "Snow Crash".
If you haven't read it, do so.
I think this guy is going to get lambasted for saying things that are true. This is what people who don't subscribe to the SlashDotGroupThink (USPattent #43483598) have been saying for some time now: Software needs to get better.
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 convince programmers that this is true, just outsorce them until it's true.
This article is merely reiterating the idealized world that was supposed to result from using structured programming, then objects, and all the other names that have been tossed in for variations on those themes. Code re-use, clicky visual development environments, automagical code generation thingies, scripting... it's always been about concentrating the "hard work" into prepackaged elements and lowering the barriers to producing a finished application. The jigsaw pieces in the article's illustrations made me smile. I had always assumed they would be LEGO bricks, but it's all the same idea, isn't it?
It can be useful as an apprenticeship program for actual code and tool development. For example, getting all the change orders in for a commercial project can be a hell of a lot of work, equal in scope to building the damn thing in the first place. Adding a field, making one display have a link that points to another one, porting it to a new OS or modifying it to be compatible with newer graphics capabilities or API changes, etc. can all suck away the creative time of the original author.
So there is a role for minions to do such work, especially because the original authors often never have time to write *good* interfaces for other programs to interact with it, or may be unfamiliar with those new operational modes. The original authors need to take the feedback from them seriously, but it's awfully helpful to have the original author available available to look over the minions' shoulders and say "no, that's silly, I already did that in this chunk of code".
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.
but what do i know, i'm just a model.
Keep it simple. If your company competes against a large one that believes this mud, then punch it in its soft spot. If their outsourcing and/or code factory leads to bad quality, then market your product as having better quality. On the same token (though not necessarily in the context of this topic): If their outsourced customer support system is flimsy, then fight them with a local-hire system that gets the job done. And if that doesn't work, then you've just legitimized their operation. Boo hoo, not much more to discuss.
Well who says that existing programmers will be the ones to work these assembly lines? Couldn't traditional menial laborers be retrained for non innovative coding? just learning how to make some small part of an application? any shift in the way you make software would have to mean a shift in the mentality of the poeple who make the software. the quickest way to do that is to change the people themselves.
A major software projects starts with a handful of architects who must scope out every aspect of the project (reqs, overall and subsystem designs, APIs between subsystems) before development begins. The architecture and design must be audited. The design is then handed off to developers (i.e. tech leads) who work with programmers to implement each subsystem. All subsystems must be thoroughly QA'd. Finally, the subsystems are integrated and tested.
After design hand-off changes should be few but will happen. Anybody who whines about these changes will be fired on the spot. Any programmer who whines about bugs found by QA will be skinned alive.
In this model, the programmers are factory workers. You don't want to be a factory worker: become a tech lead and eventually an architect.
One of the really odd things about a long career in computer science is that you often find the Big New Thing was a big new thing ten, or twenty, or forty years ago. Wilbur and TSO and VTAM become EMACS on a terminal which becomes "thin clients" (and its dual, dedicated compute time becomes workstations become personal computers.)
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.
It seems like just specifying software products takes a lot of work. Part of my job as a developer is helping the stakeholders decide exactly what it is they want and pointing out risks. For example, they'll say, "I want it to work like this," and I'll respond, "Well, we can do this, but the consequence would be ..., and some alternatives are...." How would this kind of thing fit into a factory model?
The "software factory" analogy has been around before. It's nonsense, of course. The software analogy of a "factory" is the plant that presses CD-ROMs. Pressing the 10,000th CD-ROM of a software product is the software equivalent of building the 10,000th Nissan Maxima on a production line.
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.
Back in the early to mid nineties I became aware of how the software industry was changing and saw that programming would become like being a factory machine operator.
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.
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 the idea patently absurd. This idea presupposes software is a well defined "product", and all one needs to do is create an assembly line with interchangeable employees thus fostering efficiency, consistency, etc. It doesn't work! I've been there, done that.
As an aside, I've found IT people have a hard time picking up factory jargon and idioms, such as learning to insert the work "fucking" in between syllables of words to form new words.
I'd write a book on methodology that has ALWAYS worked for me and teams I've been on, but I could never find a publisher willing to publish a one page book:
Find someone who knows what they want. Find IT people who know how to do it. Put them in a room together until it gets done.
Readers are welcome to download this book for free.
I agree. I seriously wish more IT people would look at the facts: These companies you think you have "job security" at, you have no security at all. You are fodder. You are an easily replaceable renewable resource in their eyes, like paper. They do not care about YOUR quality of life, what YOU want in life, about YOUR security in life. All that matters is what they can get out of you and whether or not it's cost effective. And this will often be a deciscion made based on criteria other than your job performance.
IT workers either need to unionize, or better still, start their own companies and operate as contractors. Maybe a nationwide co-op might be a good idea. I'll never go back to a 9-5 job, ever. The pay is better and believe it or not, the job security is better too. Just be willing to branch out in every direction you have the resources to go in. I operate online stores in certain niche markets as well as contract. They'll never shove me in a factory. And the hours? Typically I work throughout the day a few hours at a time, then when night rolls around, I work into wee hours and wake up around 10 or 11. That's my natural geek work cycle. Very compatible. Screw the factories!
Think for yourself, destroy your television.
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, it's about tools that can speak and understand a particular business point of view.
I even think one could argue that the kind of software that seems amenable to this "factory" approach is the least common. We could challenge the article's premise with the tendence that open source is bringing to the market. If value is to be found in customising and adapting software to highly specific needs, as opposed to the traditional "software as a product", then the amount of technology you can reuse, whilst important, falls second to actually capturing the things that change and that make your application unique. That certainly has quite a bit of technology to it, but again there's much more than that.
Finally, even when focusing on the technical aspects I find it rare they made no mention of stuff like product line architectures and MDA, which seem to be all the rage these days when these topics arise.
The revolution will not be televised.
Will super-specialization of software development teams help the industry to push out better software faster?
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 algorithm as the basis for software construction. I believe that moving to a pure signal-based, synchronous software model will result in at least an order of magnitude improvement in both reliability and productivity.
Currently there exist hundreds of programming languages, operating systems and development tools competing against one another, not counting custom proprietary technologies. A veritable tower of Babel. Worse, the complexity of many of the tools is often greater than that of the applications themselves. Becoming proficient in their use often requires years of training and experience. This is a sign of the chronic immaturity of the software industry. Software engineering will not come of age until a single software construction and execution model is universally adopted. More on this at The Silver Bullet.
A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: ``How long will it take to design this system if I assign five programmers to it?''
``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?''
The master programmer shrugged. ``Then the design will never be completed,'' he said.
The hard part is not turning a specification or requirement into a working piece of software. The hard part is writing a specification that captures what the customer needs to have happen in unambiguous language.
Software development should be treated as a multiplayer team communications game. The success of the team depends more on how successful the communications are.
a CFO wet dream.
Unionizing and entrepreneurial instincts are diametrically opposed. Weird that you propose both.
factorys are geared to doing the same job over and over again
:/
software just isn't like that the only repeating which gets done is at the disk duplicators.
modular code and functions can help keep development costs down and maybe someone might come up with a way of building quickly searchable librarys of modules that can do specific tasks. so you can just include and call most of your way through
of course then you can then go about patenting each idea forget about producing a working model and sue your company into profit.
you can just imagine what it will be like paying for each patent used.
customers will be screaming when they realize they have to pay 1000,s just to click on the icon to launch the program
Blarney Quality Restaurant, Plants
Makes me think about the old Shot'em Up Construction Kit... and other Make-your-own-game RAD tools.
... a certain company with the coolest remuneration 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, making computers nobody ever gets fired for buying, making gizmos or allowing interoperativity and catering to the bottom line).
Otherwise - guess what? - that code monkey just took your idea, wrote it for half the price, and took away all your consumers. Tough luck.
Programmers are really just the semi-skilled assembly workers of the 21s century (c.f., "systems admins" who are basically janitors). These individuals commonly lack the inter-personal skills that are required in today's service-based economies and as such are mostly interchangable (especially given the "flexibility" that management innovations like outsourcing have wrought).
As such the "factory line" approach would appear to be neatly suited to both the nature of the work (viz a viz "codemonkeying") and the qualifications and credentials of those currently entering the workplace (the blunt pragmatism of Computer Engineering against the refinement and elegence of Computer Science).
The 'production line' approach is to be applauded as it restricts the many liabilities to be found when a mere implementor oversteps the bounds (through either arrogance or stupidity) and attempts architecture. Rightly these jobs should be seperated. It is a statistic oft quoted in software development that 20% of programmers do 80% of the work. This approach to programming fully allows the top 20% to be architects and thus restricts the remaining 80% to construction of pre-defined "blocks" of code, and at the same time leverages the "flexibility" within the semi-skilled computer programmer market to the advantage of organisations agile enough to take on this approach.
We keep hearing about this or that great revolution in software development based on the realization that software is just like X where X may be a story or a building or a car on an assembly line.
These ideas are usually pure intellectual laziness. Software can easily be demonstrated to be nothing like X. Download a house sometime. I'll leave debunking the rest as an exercise for the reader.
The fact is that software is just like writing software, and mixing metaphors is good for nothing except selling management books.
If you want to develop good software hire a very few excellent coders and fire everyone else. Test the heck out of everything they do and and don't let management start a software project without a clear idea of what they need and how it will pay for itself.
If anyone creates a powerpoint presentation at any point during the development process, shoot them. Shoot them twice.
[-- Trust the Monkey --]
but what do i know, i'm just a model.
Open aspect of open source software which is often overlooked is that it allows smaller teams to develop software faster. If the software is maintained by large self-regulating networks, than the network itself becomes like an assembly line, but better. This accomplishes what the article is talking about and does it better.
LedgerSMB: Open source Accounting/ERP
From TFA: Total global demand for software is projected to increase by an order of magnitude over the next decade
Didn't I just read an article about how Tech Employment is dropping sharply this year ?
We hired two programmers recently. Recieved 200 applications for two jobs. Sorry, this 2004 not 1996, industry no longer has to beg you to work for them. You are harping back to a world that no longer and will never again exist. Move on or get used to it.
1. Every generation of software architects fights to find a way to build a software "factory". I've seen this go through at least 4 full cycles: mainframe toolkits (first CASE tools 1980-1990); client-server (early-Windows, PowerBuilder et al, 1990-1995); OO (VB, VC++, Delphi, 1994-1999), web applications (1999-present).
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 behind their work (CICS, VSAM, WIN32, HTTP, whatever).
3. What MSDN is describing is "their way", a model that surely works very well indeed.
4. Every software factory includes its own obselescense, since it fixes onto a specific technological platform, and these platforms have a lifespan of 5, maybe 10 years.
Conclusions: (a) for any given technological platform it takes about 5 years to get to the factory stage. We are just getting there with web development. (b) the factory stage lasts for about 5 more years before it's wiped out by the next big thing.
It's worthy, and banal all at the same time. I remember looking for work in 1994, having 10 years' experience as a top-class technical architect, and getting offered only work for AS/400 RPG development. That was also a software factory, the ASP of the mid-1990's. Today I'm working on new programming languages (based on XML) which will, in 5 years' time, completely replace today's way of working. (or probably not, but the point is that IT goes through permanent fundamental change).
There is space in such a schema for all kinds of programmers. But I certainly don't see "hackers" as working in software factories except as toolsmiths.
Sig for sale or rent. One previous user. Inquire within.
Seems pretty stupid to me. The problem isn't really coding, the problem is to understand and describe to domain. This is (if any complexity is involved) an inherently iterative process - in essence the very opposite of the "Software Factory" model.
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 development. Instead they have been adopted and integrated as part of software development. I don't think that "Software Factories" is the silver bullet (in fact I very much doubt one exists), but in time the idea may prove useful in some reduced and limited form.
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?
Mathematics is made of 50 percent formulas, 50 percent proofs, and 50 percent imagination.
...that which is not to their credit
I wrote this in late 1996 and even more can be found here regarding autocoding 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?
In factory assembly, people are used to perform the same operation over and over again. In general there's no reason these steps couldn't be automated other than the cost of designing, constructing, and maintaining the necessary machinery. There is no way this can ever occur in software because whenever any thing can be automated in this fashion, the computer can do it without human intervention. This article presupposes a level of sophistication in the automation of programming that would make these programming factories totally unnecessary!
BTW, due to teh changing nature of the internet and how long ago the above link content was created, some the the links within those will not be available.... but you can use google to find the information and its new links
Software Engineering academics don't need to discuss this because it is silly. They understand the complexity involved in building software and it is not necessary a linear process much like making a chair. Assembly line is a totally wrong metaphor. Once software is created, it is copied and configured. That's it.
Authors are ignorant of the issues behind software.
More likely we'll have programmers programming on a higher level and computer generating more code for us.
A full explication of the disaster anyone buying this line of insane bullshit is setting themselves up for is detailed in The Programmer's Stone by Alan G. Carter (and here are the appendices.
http://rocknerd.co.uk
RTFA which is about economies of scope, not economies of scale.
Here's the deal. Approximately 5% (maybe 2%) of developers are god like creatures. Able to weave logic from gossamer webs of electrons and silicon. Stunning in their ability to move from ideas to usable systems in timeframes that leave the head spinning. Able to apply new paradigms .....
The other 95% (98%?) are hacks. They are the new medium skilled lathe operators of the 21st century. Their only claim to fame is that they execute their relatively unskilled efforts utilizing new technology.
So did telegraph operators. They were young, cool and too good to stay in a job for long. Train Engineers. Airplane pilots. For God's sake, captains and engineers of those new fangled steam riverboats were about as cool as they come.
But please. Wake up. It's almost over. Hacks are hacks are hacks. It doesn't matter what you're hacking on. If you're average - you're average. If you want to be special - make special things happen. But please please please stop for a moment thinking you're something new. Just the most recent in a long line of boys with the new toys.
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 methodology. Who knew?
Think what you like but these are people. Chucking them on the scraphead to save money in the short-term leads to problems in the medium to long-term.
Does a Christian soccer team even need a goalkeeper?
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.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
The effect of this is to make your skills non-portable. You won't want to leave your job because your experience is so highly specialized that you'd basically be an entry-level programmer wherever you end up. Not only will you be entry-level, but your MS will be only marginally more useful than the guy who took a couple community college courses in the cube next to you.
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.
WARNING: there is a trojan on your
Software is a service, not a product.
"Give away the stone, let the oceans take and transmutate this cold and faded anchor." - Maynard James Keenan
The manufacturing model of software development is dead wrong, and the reason why ought to be ovious to any good software developer.
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.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
I decided to go back to college to get away from the ass embly line. It's a dismal life, becuase I really don't like someone telling me what to do, then watching my every bathroom break.
If software engineering goes this route, I'll just find something t o do which gives me the freedom that I value and enjoy.
Assembly line? Wow! That sounds familiar.
There are plenty of systems out there that are made to be put in place for years and years. IBM makes mainframes that will be expected to last 20 years, and never fail during that whole time. They really deliver too, as their old ones do just that. You can get systems with hot swappable PROCESSORS, they are so redundant, and others where 2 CPUs run in parallel, checking on each other.
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.
The big problem of course, is that the "industrialization" has already happened, and software in america looks disturbingly like steel factories of the previous generation: losing to overseas competition.
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 against MS. It might seem that punishing MS might be a harsh detriment to the American economy, but this monopolization reduces incentive to compete, not just overseas, but in America too. No incentive to compete translates into a direct lack of tech jobs, especially in costlier places like the United States of America. By most every account Microsoft's behavior has not changed.
The fact of the matter is that Microsoft has only learned that violating the law is a winning investment. By most estimates, MS brings in upwards of a billion a month. If a string of decisions violates the law but keeps this earnings pace up, then the risk of a hundred million dollar fine every few years is likely worth the earnings it maintains. It reminds me a bit of football. Its not something publicly acknowledged, but most college programs try and coach players to selectively follow rules. It might be worth a 15 yard penaly from the spot of the fowl to stop Darren Sproles from making a touchdown return. Who this really hurts is the players, when they violate the "halo" that prevents a player from instantly getting creamed upon reciving the kick. In the same way, cutting your adversaries off early is typically dangerous to your advarsaries, but can bring in profit. While you might be okay with playing football against Microsoft's team, nobody wants to pay for your salary and insurance.
I Browse at +4 Flamebait
Open Source Sysadmin
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 had to. Or what building contractor would try to make his own lumber or nails.. even windows or doors?
It all comes preassembled - commodity items - and everybody knows how its built - and could build one themselves if they had to, but why? The vendor holds a "natural monopoly" on the things he makes because his "economies of scale" allow him to produce this item and even ship it to you at far less than the cost it would be to you if you had to make your own. Ever tried to build a light bulb? ( well yeh, I have with vacuum pumps and pickle jars..)
I loved the idea that Microsoft released this standard assortment of "objects" which supposedly are standardized. It took Microsoft hundreds of man-years to generate this code, it will take me years to master it, just like spending years to master the keyboard on a piano. I figured that an investment in my time learning Microsoft technology would be time well spent.
So, now where am I... I know an ancient technology . Microsoft keeps changing the keys on their piano keyboard! I can't keep up with their endless changing of things. I can't stay with one technology long enough to understand it thoroughly and avoid striking "sour notes".
This endless changing of things and their efforts to insure I learn only what they will allow is my main reason for avoiding Microsoft products.
I kinda see Microsoft products like fashion trends in pants. Its quite easy to slip one pair of pants off and another on when your pants go out of style. So, if its something where I am not counting on it being there in say three years, and nothing on the old will run on the new, Microsoft products fill the bill nicely.
But if its something like my tools, car, air compressors, home, anything I am counting on to sit there and do what it was designed to do until I dismantle it, then I want some platform where stability of design and maintainability is paramount.
I have no intention spending a helluva lot of time learning to play the piano if I know the piano manufacturer thoroughly intends to mess up the keys all the time so as to give the latest generation pianists an edge over the ones who bought into the plan a couple of years ago. With our playing skills being suddenly rendered obsolete by the change. I know big business can afford this kind of stuff, but as an individual running a small business, I can not.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
as a recent Comp-Sci grad I'd be more than happy to work in a factory, heck it would get me off unemployment.
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.
Dude, the software factory concept is way older than 1996. I don't think MS give a shit about whatever crap you dreamed up.
Software development, as currently practiced, is slow, expensive and error prone, often yielding products with large numbers of defects, causing serious problems of usability, reliability, performance, security and other qualities of service.
I couldn't have said it better myself, Microsoft!
Literalism isn't a form of humor, it's you being irritating.
The vast bulk of programming is just repetition.
.
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 and http://c2.com/cgi/wiki?ThreeStrikesAndYouRefactor
...and they don't come in the form of cheap code monkeys. I've often found that most of the problems associated with software development come down to these three issues:
Knowledge: you need programmers who KNOW what they're doing. They MUST be well versed in not only the particular language(s) that a system is coded in, but also in general software design concepts (e.g. Design Patterns). Without this fundamental knowledge, even the most well meaning code monkeys can turn even your best & most efficient libraries into a slow, bloated, buggy pieces-O-crap in no time.
Experience: not to be confused with knowledge, experience refers a programmer's grasp of the scope of your software. This includes the particular purpose (consumers, market, industry) that the software is designed for as well as actual experience coding inside the existing software. After all, in this high turnover world, where contractors are becoming the norm at many companies, it is very common for transient code monkeys to be totally unaware of an existing library, and/or not make connections with existing code and/or consolidate functions into common libraries in the first place. The results == redundant lines of code == bloated, buggy piece-O-crap.
Communication: This is the most important part of any workgroup. The "architect" needs to know about the existence of commonly used libraries and needs to relate this information to the programmers. In turn, the programmers need to recognize and inform the architects of the need to refactor/reengineer portions of the software. Communication must go both ways! Communication also tends to reveal who the code monkeys are and keep them from doing serious damage to the software.
Of course - a healthy compliment of unit testing, source control, debugging skills & documentation are also important, but you'll only find Knowledge, Experience & Communication associated with quality programmers - and quality programmers don't come cheap. Otherwise, you'll find that code monkeys will happily mass-produce lines of code (crap) that you're organization will have to pay loads of $$$ for over time to maintain.
Say that I specialize in middle-tier code. But if I'm working against a poorly designed database, my chances of delivering a successful product go down. If the front-end coder doesn't know what they're doing, again, my chances of delivering a successful product go down. The same with the documentation writers, the installer writer, the support staff, etc.
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.
What this proposal (software as a mass-produced item) does is put the burden of responsibilty of delivering a timely & quality product on the heads of technical management (where it ought to be). They have to select people with the right skills and skill level to form a team that is able to deliver the product on-time and on-budget.
However, my personal experiences to date are that technical managers got there via the Peter Principle and the chance of this idea actually working is about nil.
Chip H.
" Dude, the software factory concept is way older than 1996. I don't think MS give a shit about whatever crap you dreamed up."
Ok then I'm sure you are willing and able to show the evidence of your claim, so how about it?
But you won't because you can't.
Perhaps you should better follow the links and read what all I have pointed to, then you will know the falacy of the software factory and why FOSS will always be able to beat out MS, though this should be a good hint as to what MS is up to in their patent grab.
FreeSoftware will only become genuinely free when it is easy enough to create that anyone, regardless of their resource limitations (knowledge, time, etc.) can create it, from simple automations to improve their personal productivity level to full application programming. This is based upon the primary concept and purpose of programming:
Programming is the act of automating complexity in order to make the use and reuse of the complexity easy for the user of the complexity. Programming is a recursive act, as shown by any code/programming being done above machine language. And it follows that it is of such recursion that Software will become genuinely free, or otherwise contridict its own primary concept and purpose.
Or in other words, we don't need no stinking sweat shop software factories, we only need a general population understanding of the physics and nature of software development or general automation, and the non-patentable tools that allow us all to cause a generation of code based upon our design.
We're basically turning India into a large software factory. I'm surprised that nobody has made this point yet.
"It was hell!" recalls former child.
or maybe you just haven't worked at the right place. some companies actually do care about their employees, their way of life, and their standard of living, and will go to great lengths to secure all of the above for their workers. the company I work at is one such place. im sorry you have had such bad experiences.
Any part of a programming project that can be turned out by rote is a red flag: if it can be done repetitively, it should be done in software. Unlike a car, where the necessary robotics is still at the research level, it's easy to write a program to do the equivalent of replacing the spark plugs.
This isn't to say that there aren't situations where people are repeating the same code over and over again, it's just that anyone who's doing that doesn't need to worry about being replaced by a software factory... they need to worry about being replaced by software.
Only because I recognize that some people are better suited to a union, and some people are better suited to working for themselves. I don't see the concepts diametrically opposed in the big picture of things. I think those who can take the entrepenurial route, should. I highly recommend it, it's been rewarding. Those who can't, should take the union route. Doing nothing is letting others dictate to you how things should be. Either way I suggested, is you telling others how you think things should be. Just how I see it.
Think for yourself, destroy your television.
We've been building specialised application development environments for particular kinds of software for decades now. The problem is that we've been doing it so long we've forgotten the kinds of things that used to require dedicated programmers. For example, we've forgotten that generating charts and diagrams and doing calculations on tables used to require programmers... back in the days before VisiCalc.
As I have pointed out before- there is one resource just waiting to be tapped; the infinite supply of unemployed CS/EE/IT/programmer/software engineer/etc's out there. Sure, some of them are lame...but if you have an infinite supply of IT professionals, sooner or later some of them are going to crank out a POSIX compliant real-time operating system or something. Anything that you as a soverign being can do that can make use of an infinite supply of energy from an infinite supply of unemployed CS people, is obviously well worth taking, from a purely economic standpoint; and factory lines form some of the best outcomes from that point of view.
GENERATION 26: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
Free agency has a lot going for it. It's an excellent choice for people who can (and want to) handle it. Not everyone has the drive and creativity it requires to succeed in that environment, but it's always an option worth considering.
I think those that don't have the drive or the confidence to try, ought to work towards unionization. Maybe they can avoid the mistakes of past unions? IMO, if IT workers don't have some solidarity at some point, whether it be refusing to work for corporations as regular employees, or be through a union, the industry is going to continue the steady march towards paying us as little as possible, and putting us in as piss poor working environments as possible.
I'm not going to play corporate games anymore. A corporation wants to hire me? Agree to my terms, show me the money, or don't bother calling. They sure as hell are not going to put me into a factory assemblyline environment.
Think for yourself, destroy your television.
I'm glad you're in a comfortable environment. I actually did have the extreme pleasure of working for a software company that gave a damn. Where are they now? They got bought about a larger software company and that was the end of that.
I've never found another company like that since then. Enjoy it while you have it. Suck the marrow out of it. You just never know when it's going to end. Don't lose contact with your friends and management that you are enjoying now, they will be more valuable than gold if anything should happen to your company down the line.
Think for yourself, destroy your television.
Geeez... wonder when was the last time you actually fixed something on a car? Was it a burned out bulb in the dash?
Lessee... this Pontiac shows it's running lean on bank 2, the downstream HO2 sensor is lazy changing state... Is it the O2 sensor itself? Or is it maybe the upstream O2 sensor operating below threshold and causing the lean condition? Or is it really the catalytic converter coking up and causing the erroneous reading? Oh wait - maybe it's one of those vehicles covered under a TSB about corrupted EEPROM files... Or maybe the left head temperature sensor has shifted range, making the computer think it's running colder than it is...
Knowing which one of these possibilities to chase first involves a lot of intelligence, experience, and in many cases, intuitive understanding that is more art than science.
Okay - this is a lot of automotive techspeak - just as you guys talk geekspeek about everything under the sun. My point here is simple - there are many levels of expertise in any field, and the higher levels of expertise will always border on artistry. (Or at least those involved will say so...) I realize that noone here will believe that say, a dozen script-kiddies crashing the SciFi.com IRC server amounts to anything but public masturbation, but on the other hand, I've seen some truly innovative code come out of the quieter corners of one of the IT departments (read insurance industry codemills) I used to schlepp cubicles and terminals in. And just as almost any idiot can hang an exhaust on a Mustang, it takes some artistry to bend the pipe on the fly and give the customer the "tucked-under" look he's asking for.
So... just give the monkeys a break.
As a wrench monkey with over 20 years experience I can tell you - there is artistry everywhere, even in the mundane task of hanging a pair of Flowmasters.
Software is highly custom to it's creator - there is a high barrier to entry for new creators to absorb the model created by the previous creator.
The only reasonable membrane between developers because of this is the API. However, it is unreasonable to have APIs that don't make sense or too many APIs that present similar or same (overlapping and confusing) services.
Instrumentation for software testing, internationalization and other purposes must be done throughout the development process or the costs multiply non-linearly.
This list can go on and on and on... but instead
The most succesfull software development technique is to break a project into teams that can co-develop in a sane way. Each team develops their "product" indepentantly, where every member of the team can be a subject matter expert on the "model" of the software being developed. Some specialization within the team is expected (e.g. this guy is instrumenting for testing, that guy is architecting new features, these three guys are wipping those features out and that guy is doing bug testing)... Keep the team under 10 people...
It is your personal duty to fight for what is right on a daily basis. Ignoring injustice is identical to approving
The MAMF often appears as "formal methods" or "algorithmic proofs" or in extreme cases "maturity models". The disease usually surfaces in comp-sci student authored articles, in CACM or IEEE, or other vectors for spreading academic ideas publicly. This suggests that universities publishing novel methodology ideas, have unanticipated consequences that are surprisingly dangerous to the common good. This is known and expected in some fields such as biological weapons, or nukes, its impact via software engineering may have been overlooked.
MAMF displays a broad class of characteristics:
What can we do to help avoid MAMF ?
Well the good news is that the answer does not involve Hobbits or Rings, or dark lords, or evil empires, unless you really want to get extremely philosophical.
The bad news is that this is like trying to cure the common cold, this marketing meme is successful because it mutates rapidly. I believe there is no simple cure. The common solution is to simply endure the parasites and discomfort, until the organizations natural immu
There is no god; get over it already! Never exchange a walk on part in the war, for a lead role in a cage.
For years, people have tried to make programming into a production line process.
Well - it is and it isn't! Mostly it isn't.
In a "real" production line there are the lines of people - and robots - bashing out the cars or whatever. They don't look like programmers to me.
But hidden away, in a back room somewhere, there's a guy who thinks about the new production line. Or improvements to the production line. THAT's the programmer equivalent.
(You can look up The Programmers Stone if you like. Read and enjoy)
"Cats like plain crisps"
Good "business" consists of things like "the customer is always right", "it is less expensive to keep a customer than it is to get a new one", and "a business' most valuable resource is its employees". Obviously the "business" you are shouting about ignores this time-tested wisdom.
If programming is such a devalued resource that programmers should be paid little and treated like dirt, then why are salaries going up in India, making them a nice balloon economy? Salaries going up in India indicate that programmers are indeed a valuable resource, and that they probably deserved the wages they got in the USA. (As a little reality check, not all of us made $80K+ salaries - my all time high in the Midwest was $40K.)
The word "business" does not give anyone the right to act unethically or illegally. Business is not above the law, and it is certainly not above justice. The robber barons of old got smacked down, the trusts got busted, the Nazis and their offerings of concentration camp slave labor to companies like IBM ended on VE day. The day of the greedy shark mega-corps will come to an end too. Their business, and their evil, is not sustainable.
Seeing that such evil is an aberration rather than the way of things, I suggest that you might want to adapt. As a start, I would recommend growing a heart.
"The path of peace is yours to discover for eternity."
Japanese version of "Mothra" (1961)
Individuals do reuse solutions, but for the most part, the world of software developers does not. Personally, I think we have enough tools and languages that could take the repetition out of writing software.
The problem is not the tools, but the smell factor. Your house, your car, your code takes on a nice familiar smell after you've lived in/driven/massaged it for a while. Someone else's code just isn't the same. Number one reason for our failure to reuse code (IMHO).
Ok, maybe we could gain some efficiencies of scope, to use the author's term. How about this? We pick one university in each state to hold the software awards for their area. Let the U decides which categories will be judged each year. Anyone can play. The winner doesn't get any money, but the next best thing, recognition and we hope they get contracts for the same type of work from all over. Sounds like a plan?
ps
Don't you maintain some skepticism when a paper is based on one source of information? Is software still being written the same as ten years ago? Is hand crafting the rule with only a few exceptions? It seems likely that delving into what the rats are doing in the privacy of their cubicles is not so easily done.
Ive read lots of posts say its been talked about for years but its a waste of time.
Projects are too individual and unique to hand off to a production line.
I agree.
However design and coding are only one aspect of a project. What about testing? Sustaining? Release engineering? All these areas are equally valid to the long term survival of your product.
Once you have the testing infrastrucure in place, if its correctly built, then getting new products into be tested is relatively easy (compared to starting a new test team for each new product).
So by all means have lots of teams making products, but how about a central test and release factory? If all your products go out the same way (RPM, tar balls whatever) then why not centralise it all?
The developers work away and produce a tar ball of source code which they give to the factory. The factory then compiles it and tests it and if its good enough, release it. Then as bugs are found, they are fixed by sustaining engineers in the factory and their code fix goes through the same process of test and release.
Most posts seem to focus on just the design and coding phases of software when there is much more to it when dealing with large scale real-world projects.
PS. The company I work for uses a similar software factory and I work in it.
that this manucatured code that comes out of india and russia is complete shit. this is fine by me, fire away move your development to india, get an application which bearly compiles and give untold told trouble. it just allows me to change more for my services when it fails.
If you mod me down, I will become more powerful than you can imagine....
India's software houses are nothing but assembly lines. What's so new about this story?
I used to work with a guy with about 15 years of experience in the games industry.
He was a very, very wise programmer. We got into this kind of discussion and he pointed out that some things have gotten better. He said that for a typical game around 1990 it would take 4-5 programmers 1 year to write say, 10 000 lines of C and you'd get whatever.
These days, the same number of coders would produce 100 000 lines of CPP, there would also be more people involved and the product would have a much larger scope and capabalities, and when done well, even quality.
Good coding tools (these guys talked about how version control only came in in the 90s!), faster machines and people understanding the coding process have improved our ability to write software.
The problem is, the specs have changed. People don't want what was state of the art in 1990. They want a GUI, help files and some visual stuff on almost every tool, a better backend and whatnot. And in 1990 people didn't want Visicalc either, they wanted stuff that could be used under Windows 3.1 So, nom ce change, plus ce change.
The software factory thing goes back to the debate about whether coding is like engineering and design or merely cranking the handle.
Management also has a tendency to want to eliminate engineers. In some industries you can see what has happened. In the US car industry engineering has become second to marketing. And the innovations of the US car industry have been cupholders and SUVs. In Germany, you don't get anywhere unless car engineers have far more input. You then get ABS brakes, fuel injection, Porsches, BMWs and Audis.
Take your pick.
According to the article:
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"?
I bet if you
1.change billion to million
2.change "software development" to "industry"
3.roll back the calender about 100 years
Wow, that PROVES HIS POINT
except, we aren't trying to make 1,000,000 boot hooks a year, as cheaply as possible. It's more like building a bridge. Can't build a bridge in a factory.
-- www.globaltics.net
Political discussion for a new world
...may not be the Answer.
In manufacturing the Assembly line is only ideal when you are building EXACTLY the same thing over and over again.
There are other factory layouts with far more synergy with software development.
Let us consider the functional layout; where you have a layout of work cells with specific functions, but no need to mindlessly trudge through in a specific order. Essentially for modular products (such as machinery and tooling, most commonly) this is ideal. This is alot like software; GOOD software design AFAIK is modular, with separate functions in separate libraries. So you have teams whose job it is to make libraries which are optimised and bug free, in isolation, and then integration teams who link these libraries into apps and feedback bugs, as if they were simply assembly or design problems to those specific teams.
Such an approach would require project managers with far more rigorous training than I (a mechanical engineer) have encountered from software companies in the past; as you need to be able to compartmentalise the components and objectively assess the whole to determine the most efficient breakdown and, more critically, the root cause of problems and plan effective resolution.
However, I see it as inevetable; Software development is more like manufacturing trades IMHO, toolmaking, boilermaking etc... than it is like consumer product manufacture, building cars or kettles etc... The layout I have described allows people to focus in their core skills without being forced into working like automatons; and the more skilled developers move higher up the product tree into integration groups.
Project managers could be anyone competent enough to schedule and manage the complex "assembly" whilst having sufficient skill to conduct root cause analysis on problems and assign solutions to appropriate groups and also be able to filter bitching and bullshit from facts when dealing with the team leaders.
Of course, I understand this is how many development companies already work to a certain extent.
Modularising like this would also make offshoring etc. less painful; as you keep the high value add work locally and ship out the low value add stuff to minimise risk and maximise return to shareholders (this is how Manufacturing is tending to go).
Course, Im far from an expert, just my $0.02.
err!
jak
Well, I was reading along, and a single paragraph pretty much summed up why this is crap....
In order to provide return on investment, reusable components must be reused enough to more than recover the cost of their development, either directly through cost reductions, or indirectly, through risk reductions, time-to-market reductions, or quality improvements. Reusable components are financial assets from an investment perspective. Since the cost of making a component reusable is generally quite high, profitable levels of reuse are unlikely to be reached by chance. A systematic approach to reuse is therefore required. This generally involves identifying a domain in which multiple systems will be developed, identifying recurring problems in that domain, developing sets of integrated production assets that solve those problems, and then applying them as systems are developed in that domain.
Just as many in the inustrial revolution believed that it's entire purpose was to leverage inventions like the cotton gin to expand their plantations for unlimited growth and profit, there are many people in the information age that believe that it's entire purpose is leverage their copyright holdings for unlimited groth and profit.
They are both wrong, the information age demands the unrestricted flow of information and the fall of copyrights just like the industrial revolution demanded the unrestricted flow of labor and the death of the slavery system.
When you hear phrases like "Reusable components are financial assets from an investment perspective" - Then it almost guarantees that they are trying to treat the uncontrolled flow of information more like a threat then an advantage, and they intend to treat each part like components that you need to pay for to use.
It is crap, they just won't get it.
Until the majority of my fellow programmers realize that making some new button, or a "slightly" different kind of menu, or defining functions a different way just to be fun, is NOT, NOT, NOT art, and that at work we should strive for boring things like code readability, standardized, logical interfaces, reusability, reliablity, and all that other "work" stuff, then code will suck and programming will still be a needlessly stressful job. Leave your bullcrap-wannabe-pretending-you're-fucking-creati
A lot of games, especially ones that are just updates to older engines, are great examples of the good option. The annual sports games from EA have mostly been perfected and are done quick. Most importantly, people buy them.
Some of the most technically brilliant games out there are made at a pretty rapid pace because of the Unreal and Quake engines. All it costs is a million or two for the license and code, so there's good and fast. The engines themselves are evolutions and reimplementations of a slow moving design, so there's good and cheap.
Really, I think the abstraction and scale aspects that the writer is talking about have been perfected in games, they use a lot of abstract tools and scripting for level design and modelling. UnrealEd in particular seems like exactly what he's talking about when he mentions ASIC design.
Game developers even work industrialized 19th century hours. Maybe this guy's on to something after all!
But really, the thing with games is that a lot of the best ones have no release date, even if they're completed in less than a year. The worst ones are usually that way because the publisher forced them out half done, making them unplayable. I think the problem with trying to write something well and quickly comes from the way it's done, project managers only treat the symptoms by setting dates in stone.
The author holds up ASICs as an example of an automated production process that could be used in software. The analogy may be somewhat unfortunate, as ASICs are rapidly being replaced by FPGAs (Field Programmable Gate Arrays). FPGAs are generic silicon devices that are given functionality by loading a binary image on device startup. This binary image is designed using a high-level language called VHDL, that is, hmmm... much like writing software. Why are FPGAs winning over ASICs? FPGAs are much more flexible and are not tied to a rigid object definition as ASICs are. The functionality can be fixed in the field, whereas an ASIC is fixed in functionality.
Interesting posts. But, where did anyone read that Software Factories are about making developers into drones or monkeys? Not in the article, I'm sure, because that's not what it's about. Quite the opposite, in fact. Software Factories are about building tools to make life easier by taking care of housekeeping. Why spend time on rote tasks, like copying and pasting things from one file into another, when tools can do that? Why write a web app in assembly language, when you can use C# or Java? I wrote a lot of assembly code in years past. It's fine for device drivers, but I don't need to scoreboard registers by hand to build a web app. I would rather use tools to do tedious things that don't involve much thinking, like copying and pasting files, or things that aren't the best use of a human brain, like register scoreboarding, which my compiler does well enough for most applications. That way, I can buy time for more interesting things. Software Factories just take that idea to the next level. Instead of just using existing tools, however, you build them, and then use them. It's like emacs in the large. Jack Greenfield
Reminds me of the book Snow Crash. In the story, the only software production was done in factories, with each person working on only a little chunk of code.
let me take a crack at this...Lessee... this Pontiac shows it's running lean on bank 2, the downstream HO2 sensor is lazy changing state... Is it the O2 sensor itself?
.... gm alternators on the other hand, i can change in my sleep.....
>well... bad O2 sensors have a way of glowing bright red when they fail.
Or is it maybe the upstream O2 sensor operating below threshold and causing the lean condition?
>well... what other symptoms does the car have? has the gas mileage changed drastically? how old is it? whats its repair history?
Or is it really the catalytic converter coking up and causing the erroneous reading?
>meh... i cant remember the last time i've had a gm have a problem with the cat coverter at all... and i'm on my second grandam, the first ran until 192k, this one is on 115k, and my buick century is at 185k... and never a cat conv problem....
Oh wait - maybe it's one of those vehicles covered under a TSB about corrupted EEPROM files... Or maybe the left head temperature sensor has shifted range, making the computer think it's running colder than it is...
> and this is why i absolutely hate having so many damn computers in a car these days... yeh yeh, more accurate, more efficient, and also an expensive pain in the ass when the go schizy... i had to replace an effing wheel bearing in my grand am, and the part was 220 because of the sensor... grumble.
... hi bingo
None of the things you've said negate my point... that repairing an automobile is a lot more complex than mere grunt work; as much an art as any science.
I'll have to disagree with you on the bit about O2 sensors glowing red when they fail however - the only time I've ever seen one do that is when the cat in front of it was burning lean due to a leak drawing in air, and then the cat was glowing cherry red too...
In case you're wondering, this particular vehicle was suffering from a partially clogged injector - poor atomization allowed unburned fuel to escape with the exhaust and burn before the cat, making the upstream O2 sensor read rich and causing the computer to constantly lean out the bank.
Mnem
"The grass is always greener over the grave of a defeated foe."
While some things about programming are scientific such as the math behind the code, innovation is very much a form of art. Doing the same old thing over and over doesn't require much creativity, but comming up with a new project and finishing it takes a decent amount of art and intuition. New problems are just that - new, and new problems require at least some form of innovation.
Everything I need to know I learned by killing smart people and eating their brains.
At any rate, there is a lot of crappy software out there. Just like there are a lot of crappy car manufacturers. There are a lot of crappy products, and they are the products that don't last. The products that do last are the ones that are engineered properly. Software is no exception. And having been in the software industry more than two days shows me that there are a lot of software engineers that make some pretty poorly engineered code.
Really, the writing of software comes in three flavors, and none of them lend themselves to assembly-line production. These are:
- Build this new thing
- Change this thing (faster, prettier, or more functionality - usually)
- Fix this bug
Equate that with assembly-line car manufacturing. It just doesn't fit (you insensitive clod!).I pity the foo that isn't metasyntactic
from my own web page created late 1996---
PROBLEMS IMPORTANT TO SOLVE
Attention Getting Points
------ FROM ------
COMDEX SPRING and WINDOWS WORLD 95
Power Panel - "What's Wrong with Software Development"
** In The U.S. Only **
$81 Billion = 31% of software development gets cancelled before complete
$59 Billion = 53% of software development has cost over-runs of 189%
16% success - project success and failure ratio
61% customer requested features and functions make it in
Maintenance and repair is where most of the U.S. dollars are going, instead of new, better, easier to use software.
---- Overall ----
Problems - all-around lack of complete documentation and weak training, faulty user input and feed back - self contradictory user request, lack of project leadership between developers and users, management created problems and low quality control standards, feature creep and software size increase, advancing technology rate of change and lack of general standards, solutions around the corner but never arrive and our tools are better than theirs attitude, lack of a value chain structure for value added abilities, failure to produce a functional model before coding and constant remodeling, etc.
Solution directions - code re-use, object oriented programming, component-based programming, distributed components, better tools, better programming methodologies, leaner software, a splitting of code writer types into two catagories - architects and assemblers, better effort to establish a working vocabulary between developers and users so users can in some way lead development, etc.
---- A Few Comments from Panel Members ----
A culture needs to evolve that respect software engineers as crafts-people. Writing code is not just writing code but like the field of writing where you have technical, creative, documentary, etc., there are different types of code writing. (Authors' note: I agree with this but also realize end users are even more specialized in what they need and do. Respect for the end user needs and abilities is needed even more so. Without respect given to the end user, the software engineer will not be given respect in return.)
A fundamental change in the programming environment needs to happen that allows the tools to work together more. (Authors' note: the panel member making this comment, did not specify what tools or who the tools would be used by. It was a very general comment pointing to a fundamental programming environment change. A lead in to the concept of componet programming. But, there was no recognition given to the concept of componet software or componet applications. At least not in the sense of being outside of "plugins". Read on!)
Jokingly - one of the best ways to copy protect software is to put it in a dll, give it an obscure name and put it in the windows system directory. Because you'd never find it. (Authors' note: This does not make it any easier for the end user in keeping their system organized, clean and optimized. This attitude of constraints, though humorous, cost end users alot.)
The meaning of "intellectual property" became questioned. Did it mean you take the best ideas or something owned? (Authors' note: it was the panel supporting "best ideas" but wouldn't the correct term for this use be "intellectual value" rather than "intellectual property"? What would happen, regarding this, in a court room? The audience member whom brought this up, was a bit angry about the distortion. Her question was: Is it the developers whom are creating the problems? And what are the developers going to do about it? The responce was "that's not the problem!")
Users shouldn't develope software but know, better than the developers, what they want and need. (Authors' note: users don't have the time to write code, it's not their job or duties!!! I can cut the lawn, I know how, but if I don't have th
Who said anything about stuffing programmers into factories? I hate grunt work, so I'm interested in building factories to make tools do things for me. It's not about making programming a mindless job. It's about automating the mindless parts of programming, so that we can get on with the creative parts that drew most of us in the first place.
The thing with a factory is you produce the same line of products repeatedly in mass quantities. We already have this in software and its very efficient. You can make an exact copy of a piece of software on CD very very cheaply without involving programmers.
Programmers get paid to solve problems (Analyst programmers), or do things differently to how they are currently done. The problems may be similar but they are not exactly the same. If they were exactly the same you would use off the shelf configurable software. If the business is small or the problem calls for a generic solution this is absolutely the right thing to do.
Packages have been applied in the areas of HR, management and timekeeping. However what you find is that companies that provide generic solutions force you into their methodologies and charge a mint for their supposedly superior software.
Each business is in fact different and wants slightly different solutions. Not just different look and feel, or configuration, but their organisational structure and decision making processes differ. As long as this is the case they may try to pay developers like factory workers but this will be an injustice, since the job is more complex and stressful than a repedative job in a factory.
These posts express my own personal views, not those of my employer
If you work for a company that still produces serious software, you don't use any of these ideas. You write software just like they did 20 years ago -- like a design engineer. Companies that really write software include Avid, Adobe, Apple, etc, companies that build difficult applications in c++ and assembly. Just like the old days.
If you stitch pieces of third pary libraries together for distributed IT applications, then these methodologies apply to you. It isn't much of a job, and it never was.
"It disturbs me that the general public and MBA types don't seem to understand how difficult software actually is."
Apparently it's "difficult" enough that our jobs are going overseas.
"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."
Tell Microsoft that.
I've read this and can see nothing that states how you get from current position to a software factory. All I can see is "this doesn't work" and "this would be good", but nothing about how you organise it or anything.
1. People not knowing what each other is up to. So someone builds a reusable module, but no-one knows about it.
2. People not working through the impact of changes in one part of a system on another. How do I find out all the places that a particularly column on a database table can be updated? How do I find out what it is set to? OK. This can be done, but it's very long winded.
3. Fragmentation of tools. As an ex-mainframe guy, we had COBOL and JCL. Now, people download pieces of software, build things in different tools. All these tools require training, which takes time to become mature in them (and often are discarded before maturity occurs).
4. Specs and code don't match. We should be at a point by now that this isn't an issue. The spec should be the code and the tool should run from the spec.
If you use it i'll sue
--darl
In fact, it would be detrimental to have a PHd working on one. Thus, the companies can have a person that will take their orders well, while MS can hire people that will (hopefully) develop well.
I'm torn on this article, I kind of agree with what he's saying but for a different reason.
I think its pretty obvious that if a developer stays in a particular industry for an extended period of time they grow familiar with the domain and the type of problems that companies face in that domain. So for example if I'm developing software for the retail sector I understand the lingo, if I'm developing for the financial sector I'm not puzzled by "industry norms" or TLAs.
I think thats a fine way for a developer to capture his knowledge, but unless he builds the libraries and shares them it isn't very reusable.
Let say that it happens (I'll talk more about how it could happen later), there is still a lot of complexity left in the problem. Unless the captured knowledge/library is 100% spot on in terms of quality (and even if it is!) the coordination of such software will be a very complicated task.
I can however see this playing out in a good scenario. To build such a tool, I would have to have a great understanding of my problem domain, not to mention excellent technical understanding of a particular architecture and platform. As a Developer I would have to have a great incentive to build a library that incapsulated my knowledge about this particular domain, such a developer is likely to be highly in demand.
I think Developers in this scenario would be likely to form into small companies and develop their expertise in thier specialised industry and technologies. Said software could then be licensed/developed for clients or other developers building more sophisticated solutions. It's not entriely unlike a law practice - I don't goto a lawyer who specialise in divorce about my tax problems do I? I'd goto one who specialises in tax problems and I'd probably have to pay more for it.
The IT industry is grappling with the fact it basically reeks. If you'd read the article you'd have met this sucker punch early on: According to the Standish Group [Sta94], businesses in the United States spend around $250 billion on software development on approximately 200 projects each year. Only 16 percent of these projects finish on schedule and within budget. Another 31 percent are cancelled, mainly due to quality problems, for losses of about $81 billion. Another 53 percent exceed their budgets by an average of 189 percent, for losses of about $59 billion. Projects reaching completion deliver an average of only 42 percent of the originally planned features. Nobody cares what IT workers do and do not want. The industry (in the US) is increasingly uneconomic and less than productive (do you know another industry that would tolerate an 84% rate of failure to meet targets?). Its within this context you have understand why corporations like MS have had enough. The supply will never run out precisely because of outsourcing. If you read between the lines of the article its not about a new working pattern for Americans, its an integrative programme for utilising high churn-rate outsourced labour.
It's amazing to me how long a completely screwed up and inappropriate model of development has managed to live in management. It seems every few years, we see some new hype (tripe) about how we are like craftsmen making each unit by hand while we need to be cranking them out on a assembly line.
The problem is, they're comparing the DESIGN phase of software to the PRODUCTION phase of everything else.
I agree 100% that software PRODUCTION should be on an assembly line. We simply MUST stop producing those CDROMS one at a time with a handheld laser. Manuals should be printed in bulk, we can't keep typing each one up by hand.
I propose that executive and middle management functions are at LEAST as good a cantidate for 'industrialization' as software development is. While there ARE managers who produce carefully crafted decisions that ACTUALLY reflect a grasp of reality and produce positive results, many could easily be replaced by a life sized version of those talking dolls with the pull string in their backs.
Interestingly, the gist of the article is fairly dead on, it just uses an ENTIRELY inappropriate analogy and so leads the reader to the wrong conclusions early on.It wouldn't be such a large problem except that management has been wandering down that bad conclusion over and over again throughout the history of software development.
I BELIEVE (correct me if I'm wrong) He's essentially saying we don't really need to keep writing essentially the same function to accept user input and validate that they entered a number over and over again. Quicksort is a well understood problem, quit writing quicksorts and get on with the meat of the problem (you're not likely to do any better than Knuth anyway).
Of course, there already is a movement within software developers to do exactly that sort of thing at even higher levels of abstraction. We call it Free Software. If an existing program does almost everything you want it to do, add the feature you need/want rather than writing yet another X.
That doesn't totally eliminate duplicated effort only because it's not always clear which approach to a design is best overall and there usually isn't a 'One True Way'.
Of course, the biggest obstacle to expanding the appropriate practice of reuse is our laws and economic basis. We have large bodies of law that focuses exclusively on preventing appropriate reuse and an economic system that creates a natural tendancy to expand rather than remove the body of IP law.
But the artist can't work in a vacuum. He needs to be told what he needs to create or you will end up with a master sculpture while you were after a painting.
And that is the real problem. Talented programmers are being wasted as their employers are unable to give them detailed instructions on what needs to be done. I can't count the number of times I had to spend days hunting after simple details like for example exactly what the minimum payout is on a cheque. It is not the programmer who can decide that and it not the programmers job to find it out either. Simple things like deciding wich fields in a database got to be unique. Social security number you say? What if people without are employed? Sure it ain't legal but it happens, I been in more then one company where a simple check on the social security number (in holland it can be calculated to see if it is a legit number) showed the company had employed people without a valid number. Wich by the way is illegal.
When managers don't manage programmers spend time not programming and projects run over budget. First step to more efficient development is to make sure that it is known what needs to be developed.
Most software developement is like building a building without it being decided if it shall be a house or flat. How many doors their shall be if any. What windows are.
You can tell how wrong software development is that they decide on the material before they decide on the structure. Would you choose straw as the building material without knowing wether you are going to build a hut or a skyscraper?
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Sounds a lot like India to me!
X01 001 110
This isn't about turning programmers into factory workers. It's about raising the level of abstraction to provide programmers with domain-specific model-oriented languages to program with instead of generic high-level languages like Java.
While domain specific languages are great to use, they are expensive to develop. The Software Factory is supposed to be a high-speed development environment for domain specific languages that will lower the cost of their development.
This work is Microsoft's "embrace and extend" offshoot of the OMG's MDA and a free metaprogrammable domain specific modeling framework from Vanderbilt University called GME.
Learn a little about the relevant technology before you scream "They're turning programmers into assembly line workers!"
The GOF Patterns book has wreacked nearly as much havok as it has helped to prevent.
But when you say:
I must take exception. If you really believe that this buys you anything in the long run, you're the one extrapolating out of your ass.Let me qualify this though. If you're on a competant team who knows the language, and you are doing test-driven (not necessarily test-first, mind you) designs, then you're probably in better shape than a good static-typing-driven team.
Let's discard Haskell and the ML family for just a second, the truth is that in most of these higher-level languages, 1 line of code is worth many more than the equivalent Java or C/C++ line. Sometimes, we can even get into 10:1 ratios.
A 100000 line project is huge. But a 10000 project is managable by one skilled person. If your language, dynamically typed as it may be, lets you cut down the overall size of the project it is going to be a net win. Program size is to system difficulty as speed is to car breaking distance; the dominant term in the equation.
Bringing ML-family languages into the mix, YMMV. I don't like them, but some people do and that's fine. If you're going to use static typing, at least use a modern system for it.
Don't mix your religious preferences in with your very good rational arguments please. Lots of people on Slashdot can't seem to separate them.
Slashdot. It's Not For Common Sense
Does anybody seriously believe that blackboxing programmers will increase effeciency?
We already have systems that blindly do exactly what they're told to do. They're called computers.
We need programmers to get them to do what we want them to do. As of yet, there is no DWIM instruction for people or machines.
For programmers to be effective, they have to have some involvement in the planing process. They have to make decisions and understand why they're doing what they're doing.
As a "programer", I design electrical drawings, hunt for parts, line up electricians, manage installations, test and troubleshoot builds (that's build as in tools, cables, wires, & pipes, not ./configure && make), etc, etc, etc.
I've seen programmers around here who "just do the software".
But I don't see them for long.
"Reality is that which, when you stop believing in it, it doesn't go away." - Philip K. Dick
Wasn't there a quote that had something to do with history and repeating? Oh well it probably wasn't important anyway....
Buffer overflows are partly a language issue and partly a hardware issue.
Programs written in C, C++ and other languages which use staticly sized buffers and no bounds checking are subject to buffer overflow attacks. Programs in languages like perl and java which have dynamic buffers or bounds checking are generally not vulnerable.
Most processors have stack-helper instructions which build the stack from the top of memory down. As a result, any positive buffer overflow of memory on the stack will overwrite earlier contents of the stack including the return pointer which can be highjacked to run the custom code inserted into the buffer. With the stack built from the bottom of memory up, such overflows would generally overwrite unallocated memory with little opportunity to highjack the program.
Solve either or both of those problems and the buffer overflow problem largely goes away.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Speaking of version control, are there any good and not horribly expensive tools to manage version control? Preferably suited to objects as well as pure code...
so, the answer was to clean the injectors?
oh, dont think that i disagree with you - i think that programmers (db programmers, in particular) think that they are somehow above "skilled labor" - they arent, they just dont admit it.
... hi bingo
harken unto my blog, if you will. (sigh. I HAD to say that. it scres off the boneheads.) http://slashdot.org/~packrat2/journal/79818 it's supposed to be funny. AND it's about programming.
packrat ; writer-informer. http://packrat.comicgenesis.com http://www.youtube.com/area163 https://www.smashwords.com/
Ahhh... I see. I guess I'm not qualified to judge that particular aspect of computer programming... my experience as a programmer is rather limited. Building some modules for custom apps written in BBX3/BBX4 back in the 90s, plus the bits of scripting and C++ programming I've had to do in my current pursuit of a Network Admin/CISCO track degree at my local community college. I assume from your obvious contempt that this level of skill is only a few steps above "Hello World"?
As for the Pontiac - the cure was to replace the #4 and #6 injectors, as they were beyond cleaning. The way I identified what was happening was that there was a small but noticeable difference in the heat discoloration on the headpipes - checking the temp of the exhaust with my handy dandy laser/infrared thermometer indicated a 260 degree difference from one side to the other. After finding that, troubleshooting the fuel system was my first course, and it was simple visual inspection that identified the two injectors as culprit.
VroomVrooom!
Mnem
"Bigger. Faster. Louder. All the good things in life..."
What gave you the idea that the article advocated black boxing programmers?
> 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.)
You're wrong on the first point - my brother is an architect and one of the reasons his ex-employer hired him productivity - "AutoCAD drafting speed" (for want of a better term).
You're right that the job takes skill though.
I don't think that structure or strong typing precludes good design or tests. You can have it all.
Tests are good and fine, and everyone ought to use them. Indeed.
But keeping me from passing the wrong arguments to the wrong function is another source of bugs eliminated. A source of bugs which can sometimes be rather insidious, since parameters can come from anywhere and get passed through 20 function calls. They can come from a user who (sometimes even deliberately) enters wrong data, the web designer who did this small change in the template and replaced the numeric ids with string ones, or the poor maintenance programmer who has a deadline to fix something he doesn't even understand.
And let me stress the last part: maintenance is the bigger problem, not writing the code. It's also the under-manned part: while when coding you could get only 10,000 lines per person, in maintenance one single person can well get a 100,000 or even 1,000,000 line project alone.
That person sees the program like through a keyhole. It's like seeing the Sixtine Chapel fresco for the first time... through a pinhole. You can scroll the view, but you see a couple of square inches at any given time. Good luck seeing the big picture. Good luck remembering it.
But when you're doing maintenance you're not always even allowed the luxury of getting the big picture. You're just expected to fix this one small problem, and fix it yesterday. Just quickly find the line that does that, and change it already.
Which brings problems like:
- where the heck _is_ the code that does that?
- where does it get its parameters from?
- are those parameters what I think they are? (E.g., does it always get a ClientDO object? Can it be null? Can it get some other data type instead?)
- I see FunctionX and FunctionY being called. Which in turn call functions A, B, C, D _and_ E. What _are_ their parameters? Am I sending the right data?
(E.g., I see it expects a Collection object. Will _any_ collection do? How do I know it doesn't get cast to ArrayList down the line. Don't laugh, I've seen code like that.)
- is my change breaking anything else? (E.g., passing the wrong data type to a function.)
And at that point _any_ help is most welcome. Good structure and strong typing and unit tests can give that maintenance programmer vital hints. Hints which otherwise he/she would have to spend weeks digging in code for.
That's really when that stuff is the most valuable. Sure, when coding you can often do without them. It's maintaining someone else's code that's the real kick in the nuts.
A polar bear is a cartesian bear after a coordinate transform.
The author makes the point that *only* under these specific circumstances will this idea of "software factories" work. He addresses the "craft question" ["But programming is a craft, not a science!"] and concedes that under those circumstances, software factories will *not* work.
Only in a high-reusability environment (like, natch, Microcruft) will this concept work.
DNA is a Turing machine. You, however, being dynamic and emergent, are not.
Most of the really good software development houses are very factory-like. You have a system architect, who describes the system to be developed in terms of patterns using a modelling language. The components of the system are implemented by competent junior developers. The architect keeps watch over the code as it is developed, refactoring and reorganizing as necessary. Developers work in pairs on important code, sometimes with the architect when they are not sure how to solve a problem. Everyone at every level can be happy in this situation, generally as long as the company is stable and making money, most people are satisfied. As the developers gain more insight and experience, they can move up to the architect level and start thinking more abstractly, stretching their brains a little. The more experienced architects spend more time experimenting with new ideas and passing them on to the team to improve quality and re-use, and take more of a mentor and R&D role. Nobody works extra hours or gets burned out on a problem, no one is blamed for failures because A: there are few critical problems; B: no one person is responsible for any of the code.
The opposite to this would be a company where the system architect is also the lead developer, quality assurance, manager, and support team. This person is probably on the brink of total burnout 90% of the time, as are his fellow programmers. The company's focus changes almost every week, as do the names of the CEOs/CIOs, etc. Nothing is documented, there are no standards, no one is learning anything, and people quit any chance they get. Management plays the blame game with the developers over suffering software quality, and the developers are engaged in constant infighting. This is what happens when managment does not understand modern software development, which is a common problem. Look around. Are people happy? If not, something is wrong.
The software 'factory' can be a reality, and it is not as bleak as it sounds. The bleak vision would be Neal Stephenson's 'Snowcrash' future where software developers are about as valuable to a company as burger flipping minimum wagers. Looking at how common offshoring is becoming, it's probably not too far off down the road. Languages and frameworks are becoming more abstract, but the need for abstraction and re-use is less critical when you have 5 times the development staff at half the cost. Hopefully software development will go the way of the ultra-efficient factory and not the ultra cheap sweatshop.
TallGreen CMS hosting
The factory analogy is wrong. Factories produce large quantities of the same thing over and over. The thrust of the business process is consistency and efficiency. I have always been puzzled why anyone would relate this to programming. Once a program is written and debugged, it can be reproduced with perfect consistency.
The construction business is a much better model, where there is a customer / end-user, an architect and various builders, some of which are generalists and some more specialized. Also, some elements are prefabricated, others have to be custom-built.
FWIW,
~mark
Learn programming by writing 2,000 line programs.
Learn software engineering by not writing 200,000 line programs.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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?
Look to your brethren in other industries and just say NO to Redmond style factorization. Okay, maybe it can't be stopped anymore but here's why it SHOULD have been:
Case 1> The automobile industry
Case 2> The energy industry
Case 3> The pharmaceutical industry
Case 4> The music entertainment industry
In all four of these cases the industry sentences itself to achieving a level of maximized profit margin utilizing cookie-cutter schemes. Innovation is stifled, intensely scrutinized, and accepted if and only if a maximum profit can be reaped by the people at the highest executive levels. Innovation which serves no purpose other than to make the job easier for the people actually working is brutally ostricized for fear of laziness. This business model leads to a very politically separated interior corporate structure where political maneuvers outweigh expertise or ability in the consideration of promotions. This system also leads to pigeonholing of the best talent by the extremes to which functions are delineated. One-trick ponies are favored while people with a broad range of knowledge and ability are either tolerated or thrown out as unable to perform in their position.
I understand that you can't fight big industry or big government. I guess this article and my post serve more as a warning for you working in the IT field: your day is coming just like it has come for every other industry in America. Soon you will lose your crazy haircuts and your pierced ears and your odd hours. You will be marginalized, minimized, and subjected to the brutal ego driven politics that those of us in the established professions have always had to deal with.
+++ATHZ 99:5:80