If you have a high turnover, and must replace experienced people leaving your company, by unexperienced developers, then Software Factories do make sense, as well as a ‘default architecture’ or, at least, default components re-usable in different architectures, along with procedures & ‘recipes’.

Also, one cannot expect to find passion in every software developers … some have passion, some, who work to pay their bills onyl, don’t.

In the end, you have to ask yourself ‘What is more harmfull … losing an important experienced developer, or losing your company know-how ?’ (also know as the ‘Truck Factor’ … what if your super genius architect is killed by a truck ? can your current project survive and reach the release ?)

So, I think it is a safe bet to industrialize important parts of you software development process, with key architects / developers coaching, teaching & ensuring that the processes are correctly followed by less knowledgable ones.

Anyhow, have a nice weekend and a productive workweek .

I totally agree with you that with the current understanding of development processes, doom would be upon us, but my opinion is that in a number of years / decades we will have to figure out how to enable this possibility, even if we don’t like this… and trust me, I’m not jumping for joy either.

But let’s agree to disagree… What I do believe we agree on is that integrating GAT recipes with Team System seems really appealing. Wouldn’t it be nice to just create a work item to, for example, create a new solution. When the workitem is created, the workflow of TFS enables some automated process to actually do the work for us via a GAT recipe? It would definitly ease my working day…

I’m convinced that we should bite the bullet and choose the hard way (introducing self-organizing teams) instead of choosing an easier path. A mind shift is needed instead of throwing more rules and ‘tools for fools’ at them.

In every branche, there are people who are good at what they do and there are people who are not so good at what they do. You need to accept this. I see this mostly as a HR problem. Taking someone from the streets, making him follow a course for two weeks an putting him behind some designer-like-development- environment where he can drag & drop himself to glory is a doom scenario. This is only going to create lots and lots of unmaintainable VB6-like applications, which is surely going to cost lots and lots of money. This is certainly not the direction where this industry should be going either.

I agree that we are all looking for people who have the potential, this means they can become the star developer of the team. As one of the compuware recruiters, I can tell you that these kind of people is all we are looking for, yet hard to find…

All that I’m saying is that this situation, this ideal situation, can’t be maintained for a long period of time with the current availabillity of people on the market… and that we should be prepared for it…

I’m with Nico on this one (surprise, surprise). I already wrote down my take, so I’m not going to repeat myself. I just want to add, that I believe in the people I work with, whether they are talented or not. Call me naive, but I’ve seen this work. I’ve been involved in the recruitment process in the past. The one thing I’m looking for in a developer is passion, not whether he knows some insignificant piece of the .NET Framework that is going to be obsolete with the next release anyway.

I don’t like to put people in boxes. Software developers want to be creative and involved if you just let them. When you take this away, you are practically killing the team. Being an architect or a team lead, is all about finding the right “path” for the team.

There is no such thing as a default or reference architecture. Being dogmatic about anything is not going to work. There are nog silver bullets, there is no universal thruth. Something that works for application X doesn’t necessarily works for application Y.

To wrap this up, I would like to quote the first sentence of the agile manifesto:

Individuals and interactions over processes and tools

That’s what I like about being “agile”.

PS: Unfortunately, I’m not part of a self-organizing team (yet). It’s still one of my goals to achieve this for my current team and I’m 200% convinced that we as a team can pull this off.

I don’t think we ’should’ hire unskilled workers, I believe we will be forced because of the lack of talent on the market and the ever increasing demand for faster software development.

To be honest, don’t you think most teams today allready have one or more unskilled person in their midst, like a Cobol developer for example that hasn’t really mastered that new paradigm called OO?

I think our future processes must accomodate to this evolution so that development can continue even when we have to resort to unskilled workers just to get the work done in a timely fashion…

Furthermore, I didn’t intend to give the impression that I wanted to ‘dumb’ the work down, instead i believe we should make a better analysis of our workflow, so that we know about all the details involved in creating a certain piece of the solution (be it a data access class, a piece of documentation or anything else…). This way we can extract those parts of the workflow that can actually be done by lesser skilled people (for example, managing some configuration files and packaging software into installer packages or a person who is dedicated to enforce the branching and merging strategy).

while the prospect of having a software factory as you explain it certainly seems promising I have some reservations about some of the things you say. My biggest gripe about your vision of the software development industry is that you think we should let less skilled developers do all the standardized labor and let more experienced developers do ‘the thinking’. I think this is a very Taylorism-like approach to software development. I’d rather hope we will skip the revolution of the 1800’s and go straight to the one of the +1950’s in which strong leadership will elevate ordinary developers to achieve stellar results. (Poppendieck on Leadership, PDF Link)

As P.Brooks says in his book The Mythical Man Month, one can divide the difficulties of software development into two kinds: essence, the difficulties inherent in the nature of software, and accidents, those difficulties that today attend its production but that are not inherent. The complexity of software is an essential property, not an accidental one.

While I do believe and agree with you that software factories can alleviate some difficulties from the software development process, I’m convinced that the difficulties they solve are only accidental ones. Imho you can only tackle the essential difficulties by building a great team. I do agree you need some star developers or designers, but I think you are putting too much emphasis on ‘dumbing down’ work to tasks less skilled developers can tackle, an idea which you seem to enforce through your assembly line analogy.

Having said that, I enjoyed reading your post and I’ll certainly stay tuned,
Cheers, Nico