The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Industrialization of Software Development

If you are an active Software Developer, this site and its philosophy should scare the hell out of you.....what do you think? Do you think software development CAN be industricalized, and if so, what impact will it have on Software Developers' jobs in the future?

Here's the website for this forum reference:
Brice Richard Send private email
Friday, February 09, 2007
i was listening to a webcast the other day ago about Software Factories. I think it was called, "Why Software Developers don't run restaurants?".

Well, the reality is we do run restaurants. There are many different ethnicities of software (french, mediterrean, italian, american, etc.). Within each there is further subdivision, northern italian vs tuscan region. And further, some food is good, some is garbage.

I would like to see standards. But, I don't think we are there yet. We don't build bridges! We run restaurants and most of our food and service stink!
Patrick from an IBank Send private email
Friday, February 09, 2007
Check out the bios of the guys... they're all Enterprise Framework types.  We all know that once you have your Enterprise Framework in place, your secretaries can quickly program new applications to cover new requirements.

Sarcasm aside, this discussion has been happening for decades (Joel mentioned it recently about Legos)... OOP, code libraries, Design Patterns, open source... The catalyst is the different but the discussion is the same.
KC Send private email
Friday, February 09, 2007
No, same as it ever was, same as it ever was.

V'ayn kol chodesh tachas haShemesh (there's nothing new under the Sun).

People have been talking about this since I started programming in the early 80's. They're looking at the wrong spot, since coding is only about 10-15% of the effort in developing software.

If someone could automate the extraction of good specs from end users, then that would be something.
Steve Hirsch Send private email
Friday, February 09, 2007
but, Steve don't you feel that Agile programming is trying to say, "We can get complete specs, so admit it and deliver what we do know". The problem being is that corporate america likes things like Six Sigma and "Roadmaps".
Patrick from an IBank Send private email
Friday, February 09, 2007

NASA has a Software Evaluation Lab (SEL) at Goddard Space Flight Center in Maryland.  It's a partnership between Nasa, the University of Maryland, and Computer Sciences Corp. (CSC).

They evaulation "Software Factories" about 10 years ago.  The Japanese invested a LOT of resources into this around that time, also.

And the problem with this approach is that a "Factory" kind of requires a set of "Standard Widgets", that the "Factory" applies repeatedly to create software solutions.  And, to date, even WITH the use of OOA/OOD, the STL, Java, and multitudinous API's, the "Standard Widgets" keep evolving.

The problem is that the software domain is so fluid, and the problems attacked so diverse, and the trade-offs so different for each application, that any cost savings intended by re-use and a 'Factory' approach are overcome by the loss of flexibility that approach requires.

So far, anyway.  Similar to the "Programming through Pictures", the "Factory" approach is another 'Holy Grail' of Software Engineering.  I assume it will be achieved one day.  But as long as Java frameworks and C# and .NET keep evolving, that day is not yet.
Friday, February 09, 2007
you know what upsets me about MS is how they really don't even eat there own dogfood. I recently download there PetShop sample app from ASP.NET. Do you think there are using MS Ent Lib in it? NO!!!

Further, MS is moving toooooo fast to have standards. We go from DAO to ADO to ADO.NET and now there is this new Linq thing in 3.0. So I'm supposed to develop a factory, but the machinery in the factory is going to change every 18 months? I don't think so!
Patrick from an IBank Send private email
Friday, February 09, 2007
"Joel mentioned it recently about Legos"

Oh man, here we go again.  They're Lego blocks, people!
Kidding, of course
Friday, February 09, 2007
but that's why we can't/won't have factories.
Patrick from an IBank Send private email
Friday, February 09, 2007
I think we should all give them a break. How would you like to be an evangilist for a company that has its product delivery milestones measured in years?
Phil C Send private email
Friday, February 09, 2007
then quit wasting our time (and their own) on software factories.
Patrick from an IBank Send private email
Friday, February 09, 2007
Here is a senario:

To Engineer: "Make me a bridge that cars can cross".

Engineer: Ok.. here is your bridge.

To Engineer: "I changed my mind.. I want trains to cross it as well as pedestrain traffic. Ohh yea.. and I want it build in Holland."

Engineer: . . .

Software engineers get this all the time!

No one can made standard plugins because business requests are so "shotgun".

I work on an ERP and it puts a roof firmly over my head every day...

Friday, February 09, 2007
Another abuse of the factory analogy, how quaint.

Managers want programs to be like the output of a factory.  Install the right robots and tooling, start the process, and good software comes out the end.


Nearly everyone who makes the factory analogy misses a very fundamental point: the program is not the product. For one thing, unless you work for a software company selling shrink-wrapped software products you aren't ever selling the program. Joel covers this in his Five Worlds essay. ( ) Conventional wisdom says most programmers actually work for internal IT, so it's safe to say most programs are never sold.

Businesses don't want programs, they want credit reports ... and loan contracts ... and title searches ... and purchase orders ... and claim forms ...

So what *is* the right analogy? The program is the assembly line! So measuring bugs in the program is wrong. Even comparing compiling to manufacturing -- which is better than comparing programming to manufacturing -- is wrong. What you *should* be looking at is *the output produced by the program*.

Is your program a website? Measure the number of pages it can produce per unit time, without error. Is it an editor? Measure the number of pages it can spell-check per unit time, and with what accuracy.

When measuring the output of a manufacturing process, you literally *shouldn't care* what the process looks like, nor what tools are used, so long as it consistently produces the same output. This is not to say the process and tools don't matter. A bad process may be prone to unexpected failure. Tools may be harder to maintain or have a shorter service life. You may be locked into a service contract with the manufacturer. And coincidentally [ahem] all these factors apply to software.

So yes, programming can be compared to manufacturing. As long as you remember that the program is not the product, the program is the assembly line.
Drew K
Friday, February 09, 2007
Well, if we have software factories, then by implication the individual is nothing but faceless labor and a powerless cog. So I would want the protections that unions and formal working agreements provide as this happens.

The "only" thing that stands in the way of this is the masses of common programmers with Asperger's in varying degrees who are clueless Johnny One-Notes with no comprehension of external market forces.

I think this industry is moving inexorably toward a factory or industrial model of software development. The authors are quite right: the craftsmanship model of software development is being replaced by mass production tools.

I tend to dispute any specific attempt made to guess or forecast the form that this will take; most predictions have been incredibly off the mark.

Example: Business Week in 1993 cheerily predicting that C++ adoption would result in interchangeable lego style development. Even two years afterward, stuff like this reads incredibly "stupid".

I do think we are getting there, piecemeal. Visual Basic was a big "actual" step in this direction in the early 90s. Tools like Powerbuilder also. .Net removes a lot of the "need" to comprehend the actual platform - before .Net, a Windows developer had to understand Win32 to an extent - not so much now, and .Net removes the entire COM mechanism from the envelope of what a distributed programmer needs to know.

All tool development by major vendors (esp. Microsoft) is with the intent of de-skilling complex and sometimes creative work. The "fire and motion" of programming platform changes ensures that the concept of "senior" talent can be treated as irrelevant: IE, your track record means nothing in an HR context if you don't know .Net 3.0.

I think this kind of marketing writing is intended to play to managers and executive with little technical exposure or experience. Since they have little technology experience, yet they write the checks, they cannot really evaluate any of the claims made. It only makes sense to play up their ever present wish which is: you can simply kill off all of the old, bad, costly experienced people that you personally despise, and replace them with fresh faced lesser paid n00bs who are chanting the latest Kool-Aid.
Bored Bystander Send private email
Friday, February 09, 2007
I read somewhere how they tried that concept in Japan about 15 years ago. I don't remember the details except that it didn't work out too well ..
PO'd Contractor Send private email
Friday, February 09, 2007
I'm sorry but I find this topic totally ridiculous.  It boggles my mind as to why the OP even posted about this.

C'mon, are you serious? 

To try and draw a correlation between what human DNA can do with that of current computer technology is so laugh out loud, funny, that you should be embarrassed to even ponder such ridiculous thinking (or lack there of).

You only have to look at 12-31-1999 at 12:59:59 to realize how funny this is...  Believe me, if I'm wrong and I'm sure I'm not, I still won't be found purchasing me a stepford wife of sorts.

Next we'll be pondering how we should start stocking 55 gallon drums of water in your basement in case terminator like robots come looking for us.
Friday, February 09, 2007
"If someone could automate the extraction of good specs from end users, then that would be something."

This would be a sight to behold... I'll bring popcorn... Would probably have an R rating though...
Jeff Young
Friday, February 09, 2007
Honestly, all I think most management wants is predictable schedules.
Friday, February 09, 2007
The best analogy for making Software I've seen is that it's like making movies.  Every product is dramatically different from every other.  Yet there are standards for cameras and dollies.

Even the process is kind of standardized -- you write a script, maybe lay out scenes on a storyboard.  Yet when you're shooting scenes, it's a collaboration between the actors, the director, the lights and the cameras.  Stuff goes wrong, stuff gets fixed on the fly, the director gets a new idea in the middle and runs with it.

The big difference between software and movies is that we haven't been making software since the 1930's.  Making software is even LESS standardized than making movies.  And the customer for a software product IS quite likely to change scope on you in the middle of the process.

We WISH it was like a factory.
Friday, February 09, 2007
Allan, thanks for bringing up the movie comparison.  I actually like that one a lot.  And the lesson I wish people would take from it is that no one is trying to "fix" the way we make movies.

You want a good movie?  Get a good director and good actors.  And the more the studio tries to control things, the more likely you're going to get generic crap.  Sure, people will buy it anyway, because it's the only thing out there.  But a great director on a tiny budget can still have a hit.
Drew K
Friday, February 09, 2007
until we put a limit on human thought, software will have to change to meet the needs of new ideas which disrupt convention.

even in physical construction, ideas on how to build things change and the way that things are built requires innovation.  until the new style is masterd, issues are met that must be overcome.

the problem is that the rate of change in software moves at a faster pace since we are not limited to physical constraints, which may not be so obvious to the casual bystander.
Friday, February 09, 2007
People claim they will have this stuff every decade. Or it will be "just around the corner" each and every decade. Back in the 70s and 80s this pipe dream was called CASE.

I will believe it when I see it. And I don't see it yet.
Friday, February 09, 2007
Another example of "let's fight complexity by tossing another huge heap of complexity over it."

Benji Smith wrote a very interesting article about this:
Corentin Plouët Send private email
Friday, February 09, 2007
I guess it's much easer to industrialize management.
Rick Tang
Friday, February 09, 2007
After a fair amount of time dealing with this stuff, the closest thing I've seen to real improvement has been from widespread use (which tends to also mean relatively bug free) of commercial libraries.  Win32, VxWorks, imaging/graphics packages, communications stuff, MFC, all of those cross platform thingies, etc.

OOP has certainly tidied up things some and I don't mind using IDEs, but you'd be suprised how fast people can work with simple text editors+GCC+GDB.

My guess is that, in general, the reasonable complexity of a given project will go up in tandem with available/buyable chunks of other peoples' commercial software rather than some sort of super duper toolkit for capturing requirements.

Commercial libraries also make up 90% of what I think of as code reuse.
Saturday, February 10, 2007
Drew K. is onto something further above: The program itself is the factory. Even in manufacturing there isn't much thought into building "meta-factories" that can crank out factories, but that observation is somehow never considered in snake-oil solutions like the one originally referred to.
Roland Kaufmann Send private email
Saturday, February 10, 2007
"If someone could automate the extraction of good specs from end users, then that would be something."

Well, that would solve a part of the problem - but you also need a time machine so you can visit the future and see how the requirements will change over the course of the project.
Arethuza Send private email
Sunday, February 11, 2007
> Here is a senario:

Here's another.  "If architects had to work like programmers..."
Mark Jerde Send private email
Sunday, February 11, 2007
If I have control of the situation, I like to get good specs by creating prototypes with production data, then working directly with the end users.

Agile is nice, in that it recognizes that the perfect is the enemy of the good.

At the end of the day, developing software is an intensely complicated human activity; these tantrums on the behalf of managers, et. al. as to how costly sw development is are just that. Tantrums.

Why don't we have factories for play scripts? We kinda have that in American television and Hollywood movies, we've all seen how good their product is.
Steve Hirsch Send private email
Monday, February 12, 2007
A guy I work with is pushing this Enterprise Library Microsoft "stuff" right now, and pushing us to stop innovating our own solutions.

The problem I keep telling him, like so many here have mentioned......all new software is custom....if it wasnt, there wouldnt be a need to develop new software, would there? closed

- ranger
Tuesday, February 13, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz