Friday, November 30, 2007

Getting Better

I have had to spend the last few months of my life without ... a life ! Not that I had much of one before that, but this is not the point. We had this client we had signed a contract with in June for what we all believed to be a small project, due to be released in September. And we only managed to deliver our release last week : a web application (ASP .NET, C# 2.0, Oracle 10g) targeting IIS 6.0 on Windows Server 2003 and a desktop application (Forms, C# 2.0, Oracle 10g) on Windows XP Tablet PC Edition 2005. The whole thing amounts to about 185,000 lines of code (according to CLOC), if that should ever mean something to you (please share your experience if it does ;-).

The point is that we had to spend about twice as much resources on this project than was planned : we were 2 months late (on a 3 months project) and had to get additional developers involved at some point. So, what happened ? The answer is simple : a special blend of about all of the 36 Classic Mistakes (except, notably, the Technology-Related Mistakes). The project at some point seemed so doomed, with blurry ever-changing requirements and about no visibility on our project, that we consider our achievement as a big success (and also as a proof that we are on the right tracks with our growing Software Factory). But that does not mean we would accept to get through this again, and I know I, for one, would not.

Everybody involved in this project can be blamed. Me, us and them. And for this never to happen again, we all will have to learn from our mistakes. Starting with me, obviously. But the thing is that I cannot know for sure that my coworkers will have the same attitude. And that if they do, they will do it in (what I, in my humble opinion, would call) a sensible way. And I know for a fact that our client will not. So where do I go from here ? As for me, I sense I have to become a more accurate estimator. There seems to be a lot of work incurred, such as better organization and a lot of (boring) track keeping activity, but I guess it is what it takes. I also have to give more visibility on my work to people who lack the most basic technical skills.

And I committed myself to improve my skills in the fields that I sensed people I have had to work with lacked. Even if could have considered (probably erroneously) them as not directly related to my job. And if I can, at the same time, improve my communication skills (and there is much room for improvement here) so that I can share this knowledge with them, I think will have greatly reduced the risk of me having to live through this again. First things first, I will start with requirements gathering.

It seems like a lot of work. And I think it is. But I guess it is what I like about this job. It's : getting better all the time.

Tuesday, November 20, 2007

Software that works

I hate software that works. Deeply. From the bottom of my heart and soul. Let me try to explain why.

I have worked a lot with databases, and I have long been amazed at the ability Oracle has had to consistently ship software that works. Sure, they have their share of bugs, but who hasn't ? When you use their software, you can expect it to work. And nothing more. You can never expect consistency, nor OS integration, nor anything that could ease the pain of actually making it work. On the field of consistency for instance, I, for one, think that the procedures GETLENGTH  and GET_STORAGE_LIMIT (in the DBMS_LOB package) are inconsistently named. But it works. RTFM. Have you ever tried to change the name of a computer with Oracle installed (Express Edition on Windows XP for instance) ? Well, good luck if you want to see your database again.

In the world of software that works, there is no such incongruity as refactoring. Think of it as the activity of changing code that works into code that does the same thing, but in a different way. In other words, it is one of the most stupid things to do, the mother of all evils. One software I have had the opportunity to work on had at one time been ported from DOS (16 bit) to Windows NT (32 bit) (the source code was in C). Compiling it the first time resulted in hundreds of warnings (ints would not fit in shorts). My coworkers confirmed it was normal behavior, and that nothing could be done while the software worked. And certainly not refactoring. As a result, the compiler ceased to be my friend.

After a few years in the field, I have learn to develop a strong allergy to "software that works".

First of all, I regard the expression itself as pure nonsense. Yes, of course, software should work. And boats should float too. How would you call a boat that does not float ? Software that does not work is no software. Call it an attempt, a bunch of source code, junk, whatever. Software works.

But what does it do exactly ? Simple as this : software should do what it is supposed to do. This may sound a lot like "software should work", except that this expression subtly introduces the concepts of software requirements and of quality attributes.  What is your software supposed to do ? How efficient, usable or available is it supposed to be ? I realize now that almost none of the projects I have worked on in the past had a central repository (like a simple document) to gather answers to these simple questions. To be honest, nobody realized that these questions existed and could be asked. Unfortunately, and as far as I can tell, this is still the state of the art for the software industry.

When you have requirements and attributes, you know what you can do with your code. If your software is a prototype, then it may not be worth refactoring it. If you design APIs, you might want to be consistent while naming them. The ASCIIEncoding class in the .NET framework does not follow the capitalization conventions set by Microsoft itself. The difference with Oracle here is that there is a rule, and that exceptions are few (and can be seen as mistakes). Try to guess in which environment developers get more productive, more quickly ?

When you don't have requirements or attributes, your only sensible goal is to build software that works. Which means you don't really have a goal.

I love software development. It is a world where I can express a lot of creativity in trying to imagine solutions that fit into a set of requirements. Sometimes, I can even come dangerously close to the quixotic dreams of perfection I made as a teenager. I guess I have to be thankful that "software that works" regularly kicks in to bring me back to reality.

Thursday, November 15, 2007

Brief introduction

Hi all.  My name is Mac. Well, not really, but that is how my friends call me. I am 32 (still), I am a software developer, here in Paris, and have been so for the past 6 years. I have worked as a consultant in Quaternove for 5 years, developing software for a handful of diverse companies such as Wincor-Nixdorf (an ATM manufacturer), SERVIER (a pharmaceutical laboratory) or SAGEM (a mobile phone manufacturer), and developing skills (which I badly lacked ;-) in diverse technologies such as relational databases, C++, XML, Java or .NET.

This experience taught me that ordinary developers have a lot to learn in many fields, ranging from the technologies they use to the communication skills that are needed to build better software. It taught me as well that in this respect (at least), I was a very ordinary developer. So I am reading a lot, from virtual blogs to real books, to try to become a better professional.

After the discrepancies between how I was made things done and how I read (and came to believe) they could be done, I got myself a new job in a small company (we are 6 people), which I will keep unnamed (for now at least) as this blog is a personal initiative. I am considered a .NET expert, which I guess I can accept if it is taken as a relative notion. I am deeply involved in the realization of our vision of building our own to be able to develop better and cheaper software for our customers.

This blog is destined as a means to keep track of my problems, my solutions and my various thoughts about software development. And maybe share some of them.