All posts by Sébastien

See You at JavaPolis

That’s official: my AndroMDA Quickie proposal has been accepted and I’ll be giving a 15-minute demonstration of AndroMDA power on Wednesday, December 12th. That’s really great! Now I’ll just have to figure out the best possible way to make my point. For now, my objective is to realize some sort of todo-list demonstration in just 15 minutes. That’s short but I think that’s the only way I can get people to understand that scripting languages are not the only way to be productive with Java.

Now I still need to further test AndroMDA 4 to see if it’s ready for such a demonstration.

Anyway, if you’re curious about MDA in general and AndroMDA in particular, feel free to come by and ask plenty of embarrassing questions.

A Big Cat is in Town

On Friday night, when I came home from the office, I had a very big dilemma to sort out: I wanted to save money for the iPhone, but there was this Leopard thing that was nagging at me and… well, I cracked! I jumped into my car and at 6:00 PM, I was in front of the FNAC entrance in City 2, hoping that there would not be a long queue. And there wasn’t any!

p1000972.png

 Actually, it was so easy to get it into my hands, that I added another one: iLife’08. When it came out, I thought that it might be bundled up with Leopard, but since Steve didn’t do it, I bundled it myself, and BOOM (that’s what he said), I’m lighter of 210€.

So on Friday, when I came back home for the second time, guess what I spent my night on! Yes, I know, geeky… At first, I tried just to upgrade my existing system, but when I booted on Leopard’s DVD, it could never see my internal hard drive. After a few disk repairs and authorization fixing, it still couldn’t find it. I guess I have messed up with my partitions with all those bootcamp reinstallations. Nevermind, I took the opportunity to back up my whole stuff and do a fresh install. So I booted on Tiger’s DVD to erase my main disk, then I used Leopard’s DVD to install it. And I can tell you something: those minutes when he checks the integrity of the DVD are really a pain, because after that, it’s all just grace and wow!

Now I’ve been running Leopard (and iLife’08) for about 36 hours, and let me tell you it’s awesome. As they said everywhere, it’s not a revolution, but it’s definitely a nice evolution. It seems faster, UI look and feel is more consistent, the whole space thing is very neat, the new dock is cool and I’m so happy not having to worry about backing up anymore.

The only thing that really REALLY pisses me off, is the absence of Java 6 !!! I mean, Steve, my friend Steve, Steve my idol, could you please stop denigrating Java like that! First, you dismiss Cocoa Java API, then you don’t bundle Java in your iPhone, and now you remove your developer preview of Java 6 and there’s just no Java 6 SDK on Leopard. Come on!!! Come to JavaPolis this year, come to the stage and look at the audience, appreciate all those glowing apples in the darkness. You have a new community to satisfy, and you can’t just deny the fact that there are so many Java developers out there compared to Objective-C people. There’s something wrong in your attitude, I’m sure you must be up to something, otherwise… Otherwise nothing! I won’t leave my Mac anyway… But still!!!

The funny thing is that the fact I was willing to pay 210€ for software like that, me, a big Open Source advocate, made me think about software economic models. Maybe it will be the topic of a post to come…

You could think it’s obvious…

… But it’s not!!! Since the beginning of my career at Axen, I’ve worked for 4 differents customers including the one I’m currently working for. And it always amazes me to see how difficult it is for them to deal with such a basic need as project management tooling. And apparently, judging by a few discussions I’ve had with a bunch of colleagues in the consulting busines, it’s not only the customers I work for!

The thing is that, even if Agility is gaining more and more attention these days, with tight collaboration and cooperation at heart, most companies out there are still managing their IT in a very procedural way. They have project baselines and plans, forms, excel sheets and time sheets everywhere. Every decision has to go through the proper validation channel, and believe it or not: it’s slowing down their business. All those mandatory procedures create an enormous need for tools that can make it simpler and more effective to create, share and collaborate on project-related information. Source code assets, planning, documentation, issues, releases are amongst the most redundant tasks in IT projects, tasks which need tools like version control systems, wikis, issue tracking, release management, etc.

You could think, where there is such a need, there is a market, and where there is a market, there are solutions available! Wrong! Or to be more precise, there ARE solutions, there are too many of them, and the worst thing is they’re incompatible with each other.

Let me give you an example. On the project I’m working on right now, we needed a version control system. The company-wide default one didn’t suit our Java development needs, so rather than trying to force a cube into a circular hole, we chose not to use any version control system… until recently. Now merging code from all the developers is really becoming a big issue and we are losing a lot of time and money on it. So rather than staying in that situation until a new company-wide standard VCS is chosen, we proposed to install Subversion. And believe me, that’s a huge step forward!

But recently, there was a demo of the application and the project lead noticed a few bugs while using it, a few bugs that he naturally wrote down in a non-collaborative but so common Excel sheet. And now he realizes that, if he wants the bugs to be fixed, we need to have some sort of system to register and monitor those bugs, in other words, an issue tracking system. First integration problem: we need an issue tracking system that is compatible with our version control system so that, when a code change fixes a bug, there is a link between the commit and the issue it fixes. And that of course is totally independant of the fact that we need an issue tracking system that makes it easy enough to register new bugs, so that users and developers are not slowed down on the way.

But wait a minute: now if there is a version control system, and an issue tracking system, everybody has to know where they can be accessed. That and the documentation for the project, like design specifications, requirements, coding conventions, and all the information that the teams needs to know in order to work efficiently. First reflex, why not a wiki? A simple editable website where anyone can create and modify pages with just a few clicks. Sure thing! But hey, it must use the same user base as our version control and issue tracking systems. Are you getting it?

Yes, there are a lot of tools out there, both commercial and Open Source, for version control, issue tracking, documentation management, release management, planning, and so on and so forth. But believe it or not: for each of the projects I’ve worked on in the past five years or so, I have looked for a single platform that could integrate all of those very common tasks into a single consistent environment, something so easy to install, maintain and use that it would just… work! I’m not saying it does not exist, but I don’t see it anywhere, and judging by the amount of time I dedicate to technology watch every single day, I think that if such a miraculous tool existed, it would be everywhere!

Well, you know what they say: if you’re not happy with a situation, what prevents you to change it? In that case, nothing! And that’s why I’m currently working with Axen on such a platform. All I can tell you right now is that it’s called Basement PMS (Project Management System), and I would love it to be open-source. We just have to figure out a few details, and I’m working on a proof-of-concept to show off. But I’m convinced it’s gonna be awesome.

What do you think about that problematic? Have you ever encountered or worked in a company with a single, consistent and reliable IT project collaboration environment?

Do It Yourself!

Sometimes that’s what I would like to say to people dropping me an email or hooking me up on GTalk past midnight with some tricky framework-specific problem. But I don’t! Because I’m a nice guy ;o) And I have nothing against you guys, quite the opposite actually because I always learn a lot in the process, and the next time someone asks me the same question, I can pop the answer out of my hat like a magician and I love that.But because I’m such a nice guy, I’m just going to reveal a little piece of my secret for you. When you can’t find the source of an error intuitively or magically, there is a standard procedure that every call center guy in India knows about: troubleshooting. It can be a somewhat long process but it’s so simple that it can be… very fast. Here are the basic steps:

  1. Identify symptoms: not what happens, but how it manifests to you, what is the exact exception stack trace, what are the red lights on. And don’t try to interpret and filter out symptoms that you don’t think are important, or symptoms you don’t want to be important. Try to be objective and factual.
  2. List potential sources: try a google search based on your observations in step 1, try to guess based on your experience and knowledge, understand the process at work and what it involves, including all of its steps. And once again, don’t filter out some of them because you think they’re not important. Once you figure out what was going wrong, it’s always surprising to see how far it was from what you expected in the first place. And then try to order them by order of likelyhood.
  3. Proceed by elimination: take the first one in your list and figure out a way to eliminate this potential source, do some basic testing out of your specific context, isolate this source and test your problem against it. And do that for every element in your list until there is only one you can’t eliminate. And if it comes down to more than one option, then at least you have reduced your field of investigation and you can ask more precise questions to Google or people you know.

And once you’ve got the source, then congratulations, you’re almost done! All that’s left is to find a solution.

This process is so simple and so common that most people think it’s ridiculous. Look, take any user manual around you and you’ll find a troubleshooting section that leads you through that same process. Even psychologists sometimes use that approach to help you in finding a solution to your problem, I’ve seen it in coaching myself. So okay, it’s gonna take some time, but you know what they say: it’s not about the destination, it’s about the path to get there. And you’ll see that after a few times using that simple process, you’ll be far more efficient AND independent with it. And then people can drop you an email or hook you up on GTalk past midnight and ask you a cumbersome question, and you will help them eliminate a first potential source, post an rant on your blog, and go to bed hoping that the source list won’t be too long ;o)

Fire… Exclamation Mark.

The RIA world has been pretty much burning in flames during the past couple of days. All because of a very… let’s say “engaged” blog post by one of Gaia Ajax Widgets developers. Thanks to SlashDot and Digg, it seems that this post has touched a sensible string and turned into a very bad belief-vs-belief debate about which RIA framework is the best. You know, something like “mine is bigger than yours”. That’s just ridiculous and endless, as it’s immediately been followed by the answer, and an answer to the answer, and even some very strange answer to another response, not even mentioning all the enflamed comments on all those posts.

Come on guys! Do you really think it’s useful and constructive. The main problem is that the original trouble maker asks for others to be constructive and objective, whereas he isn’t so himself in the first place. And why is that so? Because there is something like what we call a logical level confusion: everybody is talking about the capabilities of Flex versus Gaia, but the real FUD behind all of that is a matter of ideology. Should we be afraid of the big evil commercial Adobe and its not-so-proprietary technology? Should we put standards, openness, freedom and safety first, or live with our time and invest some time and effort in innovation?

At Axen, when we are in the middle of such a pointless debate, during a meeting for example, we have a very simple hook technique: what do we need? In this case:

  • Is it compatible with the surrounding technologies? Gaia is a library of .Net components, so forget about it on top of your Java backend.
  • Does it do what I ask it to do as a RIA framework, that is combine the best of both fat clients and web clients? Both seem to do.
  • And because a framework should never be a black box, is it possible for me to have a look under the hood to see how it works? Both are Open Source, or on the way to be for Flex. I really don’t care about the license and freedom and all of that. I just need to access the sources, something like what Java has offered for ten years.

Those are my needs right now. They are very likely to be different for you, and even for me tomorrow. Actually, I’ve taken the opportunity to suggest Gaia to colleagues working on a .Net project.

This “debate” has had a couple of interesting side effects though:

  • Obviously now many people know about Gaia whereas they didn’t know about it two days ago, so even if it’s not intentional, it’s a pretty smart commercial move.
  • And it’s bringing some more light on the RIA landscape that’s really getting a lot of momentum now, especially in business and enterprise applications. And that’s very good for innovation, that’s very good for the face of enterprise applications, and that’s very good for our business of course.

“You don’t know who’ll win!”, he said. But who said there has to be one winner, one way to go, one path to enlightenment. Adobe didn’t, Thomas Hansen did. Dude, in your fight for freedom, don’t forget the first one: the freedom to choose the tools that best suit our needs.

The Third Commitment

Let’s say you’re an Agile guy. You are pragmatic, and you perfectly understand the importance of added-value-driven development. You hate Big Design Up Front even more than his big brother “Big Requirements Up Front”. Why? Because it assumes that your customer knows exactly what he wants, and will never change his mind. And you know that it is ALWAYS wrong to assume that.

But let’s say you’re a contractor too, and at some point, before even starting to work, you need a contract. And where there is a contract, there are commitments.

Usually, the first one that comes into play is budget. That’s the big thing in the business world: customers want to have full control over their costs, and as long as your product is not online, your project is nothing but cost to them. Then of course, you can’t commit on budget when you don’t know what you will be asked to do for that budget. Or your customer has a strong time constraint, and tells you that your product has to be ready for such date. And that’s when excellent commercial skills start to become handy: budget, time and scope, those are three very difficult commitments to combine… and negotiate.

The problem is that if you’re just a good commercial guy, you end up committing on all of them because the customer is king, right? WRONG! Because you’re an Agile guy!

Imagine your contract as a bucket, and each commitment is some amount of water. If you start pouring budget and time in your bucket, then unless you’re very good at estimating technical constraints for a given functional scope, your bucket is very likely to overflow with scope water. And even though you know exactly what amount of functionality you can still pour into that bucket, it’s very likely that you will lose the market because other contractors won’t be as “good” as you are. And it’s the same with budget and scope first. Even if you’re good enough to estimate exactly how much time it will take, your customer is likely to be disappointed and to choose another contractor, who promises to do it in less time (even if he’s less realistic than you are). And it’s even more difficult when time and budget are strongly dependent on one another.

I heard someone in the back of the room: “And what about scope and time first?” Come on! Do you know many customers who can tell you “OK, we want to achieve that goal during that time, and we don’t yet about budget.” Well, there are such customers, there are such situations, but that’s more typical of a non-fixed price project. OK, so let’s say that you want to do fixed-price.

I guess the problem at that point is that there is always too much water for this small bucket, because of competition and because the customer doesn’t understand a thing about what you’re doing.

So, what’s the solution then? What’s the Agile Solution? Let’s quote the Great Martin Fowler, in his famous article about Agile Methodologies:

This doesn’t mean that you can’t fix a budget for software up-front. What it does mean is that you cannot fix time, price and scope. The usual agile approach is to fix time and price, and to allow the scope to vary in a controlled manner.

What does “controlled manner” mean? In other words, what third commitment can you use to just fill the bucket without losing the market?

Well, I would say it depends on your customer but I see at least two leads…

Continue reading The Third Commitment