Some Inaccurate Statements About Software Factories

  • Article

The CEO of 6th Sense Analytics recently published an article containing some inaccurate statements about Software Factories.

  • The article asserts that SFs are about making developers into battery chickens who squeeze out code. On the contrary, SFs are designed to automate the rote and menial tasks that make developers feel like battery chickens, freeing up time for the creative work of software development.
  • The article asserts that SFs attempt to solve software development problems by imposing process. On the contrary, SFs seek to enable the project team to be more agile by maintaining invariants to keep the product well formed and the project manageable, so that the overall process can follow any path that the team chooses to take.
  • The article asserts that Software Factories are imposed by people outside the team that uses them. On the contrary, they are generally developed by their users and are most effective when they serve as a repository of shared experience.

These misconceptions suggest that the author of the article does not know much about Software Factories, and perhaps has not even read what we have written about them. By themselves, they would not be serious enough to merit the time required to post a reply, as most people who evaluate a technology look at it deeply enough to get past shallow misconceptions.

 

However, the article goes on to say that SFs “crush the flexibility and creativity needed to build software and meet constantly changing requirements”. This statement is profoundly misleading, and requires a response for the sake of the those who have read or may read the article.

 

We have published a book, as well as many articles, papers and pod casts describing Software Factories. Reading just a few of them would make it easy to see why this statement is off the mark. Therefore, rather than explain SFs yet again here, I will refer to them. You can find pointers to many of them in my previous blog postings.

 

I would also like to ask the author of the article to answer the following 3 questions:

 

1. Which of the following innovations crush flexibility and creativity?

 

  • Compilers

  • Class Libraries

  • Frameworks

  • Patterns

  • Best Practices

  • Databases

  • Form Builders

  • Transforms

2. Which of the following practices crush flexibility and creativity?

 

  • Writing User Stories

  • Defining Service Contracts

  • Refactoring

  • Testing

  • Configuration Management

  • Defect Tracking

3. What evidence do you have that SFs crush flexibility and creativity?

SFs are a lot like the innovations and practices listed above in the way they organize and support software development, and in the way they help developers harvest experience and make it easy for others to reuse.

 

The author goes on to suggest that the key to success is visibility into project status, supported by metrics.

I agree and recommend the article that I co-wrote with Marcel DeVries on using Software Factories with Visual Studio Team System, soon to be published on MSDN.

 

It explains how, by providing a simple but effective architectural framework for organizing a project, called a schema, Software Factories help their developers define better metrics, and how, by providing a framework for harvesting and reusing experience, Software Factories help their developers use metrics more effectively to improve future projects.