My IDE is hot

I know I am a bit late to join this debate, but :

• I was new at my job at the time. After a few years spent in a few french companies, I was obviously not quite used to the internet as it had become since I left college, and I must admit I was as close as could be to miss the web 2.0 buzz. This blog was a longshot then.
• July has only 3 full days left, and I realize it looks like my last oppurtunity to post something this month...
• After I had this casual conversation with our new intern where I stated half jokingly that there was nothing wrong for a developer to keep the default Fisher-Price-like Windows XP theme (except that it looked rather unprofessional ;-), he set himself to tweak the colors, not only of his system, but also of his Visual Studio syntax coloring ! This reminded me of Jeff Atwood's old post.

So here it is :

Having been raised with a DOS Turbo Pascal environment, I got used to the theme. When I switched to Microsoft tools, I tried to create something close, but with a darker background, which I find more resting. You can download the settings here. I have also posted it on Ning (where you might want to rate it).

Software Factory vs Usine Logicielle

Software Factory is a term that has been very closely related to Microsoft, ever since the company began promoting it. In this two pages advertisement (June 2004), you can read :

A software factory is a product line that configures extensible development tools like Microsoft Visual Studio Team System (VSTS) with packaged content and guidance, carefully designed for building specific kinds of applications.

The advertisement is a mashup of a 666 pages book named "Software Factories". The book is a complete tour of what a Software Factory is, written in a rather heavy and poor style, which is probably why a lot of people still argue about the term definitionhttp://en.wikipedia.org/wiki/Software_factory.

But even more controversial, I found, is its french translation : literally "Usine Logicielle". Read Keith Short (co-author of the above cited book) in this article :

"The key is not to think of a factory like a turn-of-the-century sweatshop," Short says. "The image we’d like people to have in mind when they see the word ‘factory’ is much more like a production line staffed by robots, where humans are doing the creative tasks in setting up the production line, but the rote or menial steps are done by robots."

So what am I supposed to think of when I read this article in 01 Informatique, a quite renowned french magazine, about Software Factory plants ? It describes how software developers are packed in production centers (I am to blame for the translation) :

Pour planifier, suivre et réagir au plus vite, le responsable de production s'appuie sur une multitude de tableaux de bord. D'ailleurs, à voir le PC de Benoît Mompon, on se croirait dans la cabine de pilotage d'un avion long courrier. Voyants, tableaux, et graphiques en tout genre lui fournissent en temps réel les indicateurs de productivité, d'avancement des projets, de niveau de satisfaction des clients. (...) Il s'agirait donc, à première vue, d'une simple transposition des pratiques de l'industrie. A une nuance près : « Ce sont des hommes, et non des machines que nous gérons », martèle Benoît Mompon.

In order to establish plans, follow them and still be highly reactive, the production manager relies on many indicators. Benoît Mompon's computer could easily make you think you were in a long-flight jet cockpit. Indicators, tables and graphs of many kinds provide him with real-time metrics for productivity, projects advancement, clients satisfaction level. (...) It would seem, at first sight, like a simple transposition of standard industry methods. With one nuance though : « We are dealing with men, not machines », hammers Benoît Mompon.

No April's fools, no joke, no false friends : some people here do think (and I suspect dream) that a Software Factory can be a sweatshop ! Let them do.

More common now are people who think a Software Factory is in fact a set of breaking edge and almost never heard of but allegedly highly efficient tools like Software Configuration Management, Unit Testing, Bug Tracking, Continuous Integration server... Yes, it seems actually that a vast majority of open source projects would be based on a Software Factory (without most of them being aware of it, I guess ;-) ! Take a look at NovaForge, which is exactly that : the english version reads "software forge" (subtle difference), while the french version reads "usine de développement logicielle" (no difference at all).

But the worst part is that even Microsoft France uses the term "Usine Logicielle" in this acception. In this success story description, they describe how, by automating their tests and their deployment (thanks to VSTS, of course), they could create "une véritable usine de développement logiciel".  Well, excuse me, but I see it more like a way to get the 4 cheapest points (out of 12) in the the Joel Test. 4 is far better than 0 allright, but this is far from giving you a Software Factory !

I am working on an actual Software Factory at NourY Solutions right now. And we are going all the way through our product line definition, our Software Factory Schema definition, our Domain Specific Languages definition. We are creating our own set of tools as well as configuring existing ones, developing our own set of libraries as well as integrating existing ones. Our work is still incomplete, but one thing is for sure : there is far more to a Software Factory than to use Subversion and CruiseControl. I even took it for granted that nobody could seriously develop software without these tools anyway ;-)

SQL Server 2005 Compact Edition released

I have been playing around with SQLite, which is quite effective and impressive. There is even an ADO .NET Provider that embeds in the same assembly the native SQLite API, so that your single dependency is a 538Ko assembly for a fully functional self-contained database. For all this, you will not get support for distributed transactions though. That seems fair, but no exception is raised when you try to enlist a SQLite connection into such a transaction (unlike the MS Access OLE DB ADO .NET Provider for instance).

Microsoft have just released their own version of an embeddable database. It could have been called SQL Server Everywhere Edition, but eventually we have SQL Server Compact Edition. Obviously, its main benefit is the compatibility with other SQL Server versions (especially the SQL syntax). There are even tools to "easily" synchronize your data with plain server hosted databases.

Beware though : if you install the SDK, you will also have to install the desktop client (or else you are very likely to get an error stating that the sqlceme30.dll file is missing...). And deployment does not come free : a private file-based deployment means to copy 8 files (including the ADO .NET provider), amounting to 1.6Mo.

The ADO .NET Provider documentation itself is rather scarce (mainly a redirection to the standard SQL Server Provider documentation). So the main thing is that distributed transactions are not supported, which is OK. Another thing is that the SqlCeCommandBuilder class does not support named parameters (the protected GetParameterName(string) method throws an exception). That is usually not a problem unless you use this hack. Oh yeah, and the SqlCeConnection.GetSchema methods are not supported (throw an exception) as well...

Back (?) To Business

As a new year resolution, I have freely decided to commit myself into blogging about software development. So let me start slowly and write about source code organization.

The usual way to organize source code for a new project is to create a directory and have your IDE create your solution and your project in it (VS2005 vocabulary, mutatis mutandis for other IDEs/languages). Hopefully, you will stick with it, but more realistically you will have to add new projects for your libraries, executables, installers. You will also have to share resources, files and other scripts between projects. You will start to hack your own project again and again in order to add new resources until it becomes a total mess. You are starting to "lose" (and then duplicate) files (especially resources, like images). Unused files are forgotten and left, only adding to the confusion. This pattern is described for a single developer, but it is even easier and faster to get there with many developers.

Another way would be to have rules (remind me to blog about rules in general) to keep your files consistently organized. Here is my template organization, which is obviously only worth what it is :

Here the folder hierarchy description :

• Work : the root folder. It may contain general files like ReadMe.txt...
  • bin : the actual released software (libraries and/or executables and/or installers).
  • doc : the user documentation folder. Contains all the documentation on how to use the pieces of software located in bin.
  • lib : the external dependencies (e.g. libraries) needed for the project.
  • src : the source code folder. At this level, one can find all the project solutions and other build scripts.
    • doc : the developer documentation folder. Contains diagrams, DSLs, generated documentation...
    • lib : the internal dependencies. For instance, I would put the NUnit libraries there.
    • misc : the files that could possibly not find a home elsewhere. I would have a Sample.snk file (holds a signature key) there.
    • NUnit : unit tests projects.
    • SampleProject1 : a sub-project would fit in there.
    • SampleProject2 : another sub-project would fit in there.

This pattern can be refined as necessary (e.g. doxygen scripts are in src\doc\doxygen, build tools in src\misc\Tools...). This hierarchy also helps enforce the way the software is released. More on that later...